Lead, Follow, or Get Fired! eBook released

On March 9, the Kindle version of Lead, Follow, or Get Fired: 9 Steps to Unstoppable Teams was officially released. The first print edition is expected in early summer.

My goal with this book was to help executives everywhere identify failed managers and consultants and provide them the tools to trace the cause of problems, to show them how to identify processes and people that actually work and dump the rest.

As the Amazon blurb says...

Whether you’re working with the executive board of a mega-corporation in Boston, a construction crew in Southern New Mexico, or with your extended family at the movies, on every team, there are leaders, followers, and those who would be more productive somewhere else. This book will provide tools to identify failed leaders, dysfunctional followers, and the rotten apples on your team.

This book will show leaders, step-by-step, how to transform teams into those that are self-improving and constantly evolving—a group of cross-functional experts so focused on goals and culture that team members do not tolerate failed processes or people of any kind.

Check out the book and tell me what you think. The beauty of Kindle book is the fact that I can update the book in real time, based on reader input, and you'll get the update instantly, free of charge.

Scrum’s no silver bullet. It’s the holster!

Ken Schwaber and Jeff Sutherland, the creators of Scrum, describe it as a lightweight framework designed to address complex problems in an adaptive manner, while creatively delivering products of the highest value. I like to say Scrum is common sense. They say that it is simple to understand, but extremely difficult to master. I say the “extremely difficult to master part” could point to a team or organization’s lack of common sense or their willingness to acknowledge weaknesses.

You’ve heard too often that Scrum is no magic bullet. Folks says that for the same reason they say Scrum is difficult to master. Scrum is a process framework designed to manage complex product development, but it can’t do the work for you. Think of this framework as a tool, better yet, a bicycle. Climb on a bicycle. You can ride across country, but the bicycle isn’t motorized. You still have to apply muscle to get you where you need to go. Climb on the bike backwards, and you’ll find it “extremely difficult to master”, but peddle properly, and you’ll find yourself moving forward.

The Scrumbuts out there would take the chain off the bicycle and tell everyone Scrum didn’t work for them.

Scrum works by exposing the deficiencies of your management and development practices so that you can improve. It is not a silver bullet because it is not a process or a technique for building products. Scrum is the holster for those bullets, a framework of rules and processes to manage the other tools and techniques you employ. Within this holster, you’ll organize your Scrum Teams and their associated roles, events, and components.
Each tool within your holster serves a specific purpose and is essential to your success with Scrum. If you discard one of these tools, you have Scrumbut. However, your holster is large and accommodating. You can add all of the additional bullets or tools you need. Used properly, your holster binds each together by monitoring and managing the relationships and interactions between them.

What is a Perpetual Team?

Do you recall hearing of “perpetual motion” or “perpetual motion machines”?
Perpetual Motion generally refers to any closed system that produces more energy than it consumes.
When the industrial age was in it’s infancy, several inventors attempted to create “perpetual motion machines”—devices that completely eliminated friction and maintain motion forever through mass inertia.
It was an interesting idea, but unfortunately, the laws of physics made their success impossible.
However—lucky for us—the laws of physics have no effect on the creation of Perpetual Teams.
Think of your team as a machine, where each member is a moving part, constantly pushing the other moving parts forward. As long as each part continues to push the other forward, the whole of the parts will produce more energy than was consumed.
If each team member is constantly pushing the other towards a goal—routinely asking: what can we do to deliver better, faster—then two or more heads will not only be better than one. They will be better than teams triple their size.
Of course, there is one caveat…
When one of those parts stops working, that part must be replaced, before the corrosion contaminates the other parts.
I know that sounds harsh, but it is a reality.
To believe anything else is to fool yourself and damage the morale—and the throughput—of your team.
This is not to say that a part cannot be repaired. The team itself should work to oil and adjust its parts to keep them from failing, and the mechanic—the manager—shouldn't be called until such repairs are beyond the abilities of the team.
Everything starts with a truly motivated, self-managed team.
Successful teams lead themselves, and within each team, there are strong members that will push for improvements.
However, those leaders must not be allowed to dominate, as one persons improvement is often another persons impediment.
You must have strong leaders that counter other strong leaders, ensuring the team is always moving forward and weighing options based on everyone's input, in order to find the optimal solutions to all problems.
Any who sees a problem with current processes should lead the team to improve it, just as they would any other problem.
If a member cannot identify a problem with current processes, it is that member's responsibility to support those processes—continuing to move forward and to push other members to move forward.
Those old tried-and-true words of Thomas Paine are still alive and well today: "Lead, follow, or get out of the way" of those who are trying to improve and/or support the team.
Yea, I know what you are thinking—and you are wrong.
There is nothing negative about this perspective for two simple reasons:

• REASON ONE: The process is a fair one. Everyone has the opportunity to support the team as is or help change the team and its processes for the better. Finding a team where you are a better fit is truly a last resort.
• REASON TWO: The process has proven time and time again that it works!

Here’s something else to keep in mind. If you can build one Perpetual Team, you can build many. Just as one member can push another member forward, one team can push another team forward—creating a Perpetual Organization—an organization that produces five times more than it consumes.
You’ve heard consultants babble on about company’s crossing the chasm from good to great? The only way you’ll really do that is with Perpetual Teams.

Perpetual Teams deliver Perfection

The Japanese word Shibumi translates roughly to "effortless perfection", but this is not the definition of Shibumi as much as it is the goal of Shibumi.
Shibumi is an ancient discipline that disallows stress when obstacles appear—“Worrying is a sin”, grandmother used to say.
Students of Shibumi inspect problems, then improvise and adapt to the best solution presented. If a better solution presents itself later, the students inspect, then adapt again. This cycle continues until one reaches the infinite goal of effortless perfection.
For years, I have described what I termed "The Perpetual Team" and considered this methodology to be my own, but Japanese artists and Jujitsu masters have been teaching the fundamentals of this philosophy for centuries.
If an idea works, you stick with it.
On the Perpetual Team, office politics and the blame game are non-existent. Team-members are committed to the same goals, enabling each member to hold themselves—and each other—accountable for missteps. Each admits mistakes and weaknesses immediately in order to get team advice and address problems by leveraging the collective wisdom of the team.
For a team to achieve Shibumi, they must become Perpetual Teams.
Members of Perpetual Teams push each other to deliver on their commitments. Members are constantly inspecting team makeup and processes, diligently asking, "What can we do to deliver better, faster?"
Like the disciples of Shibumi, Perpetual Teams are constantly identifying inefficiencies and adapting to improve.
If you are reading this and thinking that Shibumi actually translates to "pie in the sky", then you have much to learn about the potential of Perpetual Teams in an organization or even in a family.
If everyone on a team is truly committed to the goal, that team can move mountains.
Commitment happens when team meeting attendance actually synergizes team members.
This synergy manifests when goals are clear and prioritized, and when everyone on the team trusts everyone else to do their best to achieve those goals.
This kind of trust develops when the team believes that everyone else—management included—is being truthful about motives, goals, and obstacles as they arise.
Establishing transparency throughout the team is the key to fostering truthfulness. Everyone must clearly see who is doing what, where, and when, and what problems have or may arise. Teams with fewer than a dozen members achieve transparency with little effort, but dividing larger teams into multiple Perpetual Teams works just as well, if the goals of each team support the goals of the organization.
To ensure this support, Leaders form Perpetual Teams of their own. Just as each member of a team pushes the other to reach the goal, leaders of teams can push other leaders, driving the organization to reach the organizational goal.
The trust introduced by transparency solidifies when leaders stop punishing teams for missteps and learn to improvise, working with teams to find solutions that correct mistakes and to define processes that prevent those mistakes from reoccurring. As Akio Morito, co-founder of Sony Corporation, once said, “Don't be afraid to make mistakes, but make sure you don't make the same mistake twice.”
Does Shibumi translate to “Pie in the Sky”?
At Decade Software, the Perpetual Team concept originated in the Development Department, and then spread to the Design Team and Customer Service. Our company tripled production and elevated quality to the fourth power in less than two years. Where we once released a product annually, today we release new features eight times per year, and we release every product upgrade with zero known defects—a feat previously unheard of in the software industry.
Seriously evaluating the rewards of effortless perfection, a stress-free work and home environment, together with committed trust and transparency between peers and management, another definition of Shibumi becomes clear.
Shibumi is little more than “common sense”.

Hiking to Success at Decade Software

My wife and I took a few vacation days and hiked to the Hollywood Sign, but even the hot sun and aching muscles couldn’t keep my mind off the office.

We’ve got so much going on: business is booming, our biggest release ever is just around the conference, we’re hiring in every department, and our training conference is two months away. Decade Software is truly a company on the brink of jumping from good to great.

That said, I ask myself how we got here.

We got here, the same way a middle-aged overweight man made it to the top of the Hollywood Sign. We navigated the obstacles, the heat, the pitfalls with pure adrenalin and a little something called teamwork.

Decade Software has conquered it’s Hollywood Sign. Now, we’re ready to tackle El Capitan.

Collaborate, support teamwork, or go home!

In an interview this week with John Chambers, CEO of CISCO, they asked him what has changed in business in the last few years. His answer was dead on…

“Big time, the importance of collaboration. Big time, people who have teamwork skills, and their use of technology.

Today’s world requires a different leadership style — more collaboration and teamwork, including using Web 2.0 technologies. If you had told me I’d be video blogging and blogging, I would have said, no way. And yet our 20-something's in the company really pushed me to use that more.

If they’re not collaborative, if they aren’t naturally inclined toward collaboration and teamwork, if they are uncomfortable with using technology to make that happen both within our company and in their own life, they’re probably not going to fit in here.”

That is exactly how I feel about my team.

Customer design or Too Many Cooks Sink Ships

When designers attempt to please everyone, someone always ends up angry. The key to good design is bringing all interested parties together in order to balance interests and find solutions that work for everyone.

In the early days of EnvisionConnect, customer advocates on staff shouted:

“Our users know what they need better than anyone else. Let them design the software and force the developers to deliver exactly as they define.”

Who could argue with that philosophy? The customer knows best, right?

Let’s return to the mixed metaphor of “Too many cooks sink ships,” and let me tell you a story…

There once was a shipbuilder who hired the best engineers, but he sold ships to the government and was forced by contract to design the ship according to specs put together by a government committee.

The shipbuilder ordered the designers to build every gadget and widget the government committee could dream up, and the ship that evolved from the process was beautiful!

On this ship, you didn’t have to take the stairs to go from deck to deck. Everything in the ship was put on one easily accessible deck. And all of the gadgets, widgets, bells, and whistles glistened. It was the most spectacular-looking ship the government committee had ever seen.

When war broke, the government ordered the ship launched. It would sail to the other side of the globe and squash the evil doers.

Unfortunately, the ship was too heavy. It moved too slow. By the time the ship reached the enemy, the war was over. That’s not all that bad really. If every country followed this design model, the world would be a more peaceful place.

The moral of the story is that all interested parties have to be involved in design.

Luckily for us, the world of Agile software design doesn’t work like ship building.

We do insist that users of the software design by committee on the first pass (in industry jargon, the first iteration) but then it’s up to the engineers to weigh the needs of the many against the wants of the few and refine (industry jargon again, refactor) the product into that happy medium that makes everyone happy.

This year, our customers will notice that we’re changing the way we collect customer feedback—finding ways to extract information faster without wasting customer time, and our developers are defining “the how” and restricting customers to defining “the what”. And when some “what” is ultimately detrimental to a more important “what”, it’s our job to help customers understand the trade-off they are asking to make.

Now, you know why it’s taking a while to christen EnvisionConnect 4.0.

EnvisionConnect 4.0 as she stands today is the most beautiful and the most powerful ship in the fleet, but Envision outruns her. As goals go, our next BIG target is making EnvisionConnect faster, even if it means dropping a few bells and whistles overboard.

Watch this space to see how we do.

Now, that’s a real team!

Friday night, Joey, one of the leaders on my team got married.

Mike, another on our team played guitar, and Dave, a friend of ours, conducted the ceremony. My wife, Janna, said it was a beautiful reception, but men only attend such events for the reception—so I’ll skip ahead.

Mike, Janna, and I sat at a table with folks from Joey’s father-in-law’s old neighborhood. They still keep in touch, meeting annually for a combination golf tournament and old neighborhood reunion.

We were the only ones at the table not from the old neighborhood. We didn’t mean to crash their party, but all of the other seats were taken. More people had shown than had originally RSVP’ed.

“Who are you?” One of them asked.

“I work with Joey.” I replied.

“What does HL stand for?”

“Hard Luck.”

“Really? That should be my name.”

And this conversation repeated every time another from the old neighborhood joined us. However, over the music, one of the wives missed my introduction, and asked Mike, “Who is he?”

“He’s mine and Joey’s manager.” Mike said.

Her husband heard and said—loud enough for the whole table to hear, “Hey! HL is Joey’s boss. He said he just worked with the guy.”

And someone else said, “Now, that’s a real team.”

Indeed, it is.

Building a better Vulcan

Outside of the office, I love nostalgia, but inside, I am the first to promote change. Keep the things that work. Build on those things, and throw out the bad.

However, when Paramount Pictures took this approach with Star Trek, I was afraid of the change. I did not trust that JJ Abrams would be able to handle the job.

This was because I was not Paramount’s Product Owner, and their team did not ask me for buy-in, when they gathered requirements to fix something that I didn’t think was broken.

I was wrong. The movie was great, and I learned a lesson I have been preaching to others for years…

“The needs of the many outweigh the needs of the few.

–Mr. Spock, Wrath of Khan”

This became clear today, as I was reading new words of wisdom this week from Joel “on software” Spolsky…

“Typically, the product owner wants something simple and easy to understand for the users, featuring a telepathic user interface and a 30" screen that nonetheless fits in your pocket, while the developer wants something that is trivial to implement in code.

Lacking a product owner, your garden-variety super-smart programmer is going to come up with a completely baffling user interface that makes perfect sense if you’re a Vulcan. The best programmers are notoriously brilliant, and …have a tendency to get attached to their first ideas, especially when they’ve already written the code.

One of the best things a program manager can add to the software design process is a second opinion as to how things should be designed…

….ideas for how the UI should work, which might be better, or worse, than the developer’s idea. And then there’s a long debate.”

For those of you that speak Scrum, I have substituted Joel’s use of the label “Program Manager” for “Product Owner” to point out that our objectives are the same—the common techniques that work from one software process to the next are essentially the same. Common sense is universal.

Software Engineers know the “how” better than anyone, but the “what” must be defined by those that interact with the customer—or better, by the customer themselves. However, we can’t forget that ancient Decade proverb “everyone doesn’t know what they don’t know”. That’s where the give-and-take and “happy mediums” of good design come from.

Despite what you were taught, compromise is not a bad thing.

In fact, its what makes good teams great. Meeting in the middle has nothing to do with losing ground. It is about everyone coming together to see the big picture and finding the optimal solution for all involved.

Code long and prosper.

Beware the Wizard of Oz

Sometimes you’ll find team members or leaders pushing for something really hard—something that you struggle to understand why, because they have trouble articulating why it is important to them.

Beware the Wizard of Oz.

Pay attention to the man behind the curtain.

In most cases like these, the person making the case doesn’t have all of the facts, because they are just acting as mouth-piece for another team member or members.

The person talking can’t convince you of the importance of the issue, because they may not personally have a stake in it themselves. Their objective is simply to not let those down who coerced them into speaking on their behalf.

Dig deeper, and you will uncover the Wizard of Oz—and maybe even a flying monkey or two.

Happy Teams will weather the crisis storms

Alex Kjerulf calls himself a CHO—Chief Happiness Officer, and he is one of my favorite bloggers.

He has a new book in the works that explores the economic crisis and it’s effect on happy teams.

The book has three central claims:

1: Most of what companies traditionally do in a crisis doesn’t work.
The way many organizations typically handle crises is by cutting back on all expenses and doing mass layoffs. While this can be necessary, studies actually show companies who choose this approach recover more slowly.

2: It is possible to be happy at work even in a workplace in trouble.
Of course it’s easier to be happy when everything is going swimmingly, but people can still be happy at work in a crisis. It takes determination and focus, but it can be done. Surprisingly, a crisis can make people happy at work, provided that it becomes a reason for people to focus and pull together—rather than an excuse to give up.

3: Happy workplaces get out of a crisis faster.
Especially in a crisis, an organization needs to get the best out of its people—and when we’re happy at work we are more motivated, creative and productive.

I can’t wait until the book comes out. I predict it will be a worthy read.

I never assign work to anyone

Although I am very good at delegating work, I never assign a task to anyone.

Day to day, I prioritize my workload, and then ask myself…

“Okay, which tasks can be delegated and which am I uniquely qualified to tackle?”

This daily decision is the key to being a good manager.

If you are doing too much, you are saying to your team: I don’t trust you to do as good a job as I will do.

On the other hand, assigning work is a command and control vessel. To “assign work to someone” is to say that their current tasks are unimportant.

Instead, explain why you believe the team member is suited for the task, and then ask them to accept the task, weighing and prioritizing the task against their current workload.

By asking someone to commit to a task, you are building teamwork and proving that you trust that teammate’s skills and judgment.

When you say that you are assigning work, you are essentially saying what you parents told you as a child…

“Do it, because I said so. I am the boss.”

Whether you realize it or not, a simple word like “assign” will lower morale and hurt your team(s) and the culture of your organization.

Shine the Light or John Travolta versus Perry Como

Regular readers of this blog—and those who attend my public presentations—know that I was shouting the virtues of transparency long before the recession made the term a household word.

What you may not know is that my first insights into the subject began much earlier—with one of my seventh grade teachers.

In the 1970s, Carolyn Higginbotham was a guidance counselor and teacher at the only school in Holden, Louisiana.

"Ms. Carolyn" was considered somewhat of a radical among the traditional southern teachers of the day. In fact, the blue-haired disciplinarians with their combination rulers and seat warmers thought she was a little nuts.

In her classroom, she and the students designated 25% of the room as a combination library and student lounge by carpeting the floor. Students were led to work together, and when their teams completed tasks on time, they could relax in the makeshift lounge.

This strategy dramatically increased team morale and individual self-esteem by spotlighting both group and individual accomplishments.

[If Ms. Carolyn is reading this, she has crossed out at least half of the words in the preceding paragraphs with a red Sharpie, but I am not embarrassed. One of the first tenets she taught me about writing was that you can break the rules, as long as you know a rule and have chosen to ignore it as a matter of style.]

My class had conducted a fund raiser, and with the money collected, we were directed to purchase something for our student lounge—something that would serve generations of junior high students to come.

As a lesson in democracy, Ms. Carolyn tasked us with campaigning and voting for our vision of that ideal purchase. After hours of debate, the majority vote was in favor of the new Saturday Night Fever record album, featuring an up and coming actor named John Travolta.

Ms. Carolyn thought our idea was unwise—I would have said "stupid" but she hated that word with a passion—but she wanted the class to discover the error of our ways on our own. To assist, she began what she later called "shining the light" on the absurdity of the situation.

Today, I think of the approach as "exaggerating transparency".

It works like this: If your colleagues in a debate do not possess the sense of urgency you know they should have, you can cut through the noise quickly by exaggerating an option that mirrors the one gaining the popular vote.

In the middle of our debate, the teacher raised her hand.

"I'm changing my vote," she said.

"I think Perry Como's Greatest Hits would be a wiser choice. Saturday Night Fever is new and unproven, but this album has stood the test of time."

Some of the class grew annoyed, almost angry, others found confirmation that their teacher was bonkers, but an inspired minority actually saw the light.

I was among that inspired minority, and I count Ms. Carolyn's light as one of the best tools in my leadership toolbox today, but—as you might have guessed—when I use it, some on my team get annoyed, some get really, really angry, and some just think I'm nuts.

However…

There is still that inspired minority that see the light, giving me hope that Ms. Carolyn's torch to transparency will serve them as wonderfully as it has me.

I'll bet you're wondering what became of Carolyn Higginbotham.

Today, she leads the team that manages federal programs for the Livingston Parish School Board.

Unfortunately, I haven't spoken with her since the 1980s. I believe she had just gotten back from astronaut training, when I asked her to assist me with a murder.

...but those are stories for another day.

Customers get bug-free software

Yesterday, in my entry entitled Angry Customers Tell 3,000 Friends, I explained how I became involved in customer relations at Decade Software. Kevin and I had devised a plan to allow customers to more freely communicate with us and with each other through a new web site.

By increasing transparency, we would bolster a trusting environment where everyone freely helped everyone else become successful using our products.

Our past successes had told us that teamwork using cross-functional teams was the secret to meeting goals, so the first thing I did was form a new team. The Customer Communications Task Force was formed to get clients talking.

We scheduled meetings with customers and began demonstrating our ideas for the web site and our ideas for opening communication between customers—and they loved what we were doing!

The CCTF had picked up speed, and we were soaring to the finish line, and then we turned a corner—and we hit a brick wall.

We discovered quickly that launching a new web site is an action that steps on multiple toes, and in short order, I was accused of invading the territories of Marketing, Client Services, Graphic Design, and Administration.

They said, you're moving too fast. If you modernize our web tools, you'll have to change the look and feel of everything, and that will cost the company time and money—and that will cause customers to ask: why are you spending time and money on web sites, when you could be fixing the defect I reported?

I couldn't argue with that logic. Making customers happy is a goal we all share.

So, I gave up and turned my attention back to the Development Team and those defects everyone was so worried about.

To my knowledge, we were the first team of developers ever to adopt a no defect policy. Every 30 days, we plan the next 30 days of work, and we commit to closing every defect reported by our customers. We've been doing this for over a year.

Now, someone was challenging our logic, saying...

"You're fixing every defect reported, but how do you know if all existing defects have been found?"

Kevin responded by hiring three additional testers and an additional developer.

All along, Kevin and I had agreed that our new customer outreach could not succeed unless quality was top-notch, so I asked him to approve overtime to commit to defects as they are reported.

In other words, my team no longer commits to closing all defects every 30 days.

We now commit to closing all defects every day.

This is an accomplishment previously unheard of in the software industry, but my team makes it happen.

Last week, one of our support technicians reported...

"It is really nice when customers call with how-to questions. It has been a long time since someone called to report a defect, and even when they do, it's nice to say it will be fixed immediately."

This empowered the CCTF to return to our communications goals, and this time, with the full support of everyone in every department...

...that is, until I suggested changing the company logo.

Everyone is Authoritative on a self-managed team

One of my teammates said the other day…

“It is important that someone authoritative review all requirements documents.”

I gave him one of my you-killed-my-dog looks.

Considering this definition of authoritative…

“Having due authority; having the sanction or weight of authority: an authoritative opinion.”

…or this one…

“Having an air of authority; accustomed to exercising authority; positive; peremptory; dictatorial.”

…then everyone on a self-managed team is authoritative. This is because they are empowered to track down any answers they do not have.

However, there is another definition of authoritative that may be relevant…

“Substantiated or supported by documentary evidence and accepted by most authorities in a field.”

The most successful self-managed teams are those that are cross-functional, providing them with a balanced view of problems from all sides. If they do not have the variety of inputs they require to answer the questions at hand, they must seek out the advice of the experts—quite often “the experts” translates to “the customer”.

Once the team has collected all available inputs, they weigh the pros and cons—the “whats”—and then the team formulates their best “hows”.

If a better solution comes along later, they don’t waste time and resources defending lesser solutions. They adapt to the better solution ASAP and learn from the experience.

Now, if members of the team aren’t asking the right questions or identifying the domain experts they must consult, then those are different problems—”impediments” in Scrum—and they must be addressed by the team. If those problems are not being addressed by the team or the leaders within the team, only then should they be addressed by a manager.

If you have a process where one person has to “sign-off” instead of a process that compiles the wisdom of the crowds—aka project stakeholders—then you do not have a self-managed team. You have a command-and-control operation, and you are on the slow road to success.

Another Team Parable: Quality and the Self-motivated team

Nearly a month ago, I called the team together to discuss defects. I wanted their feedback on an idea that I had.

I started the sentence with “What if…”

Someone said “uh-oh” and some eyes began to roll.

I said, “What if we stopped committing to and addressing all defects during a single 30-day sprint and instead committed to addressing them only in overtime. That way, we’d continue to maintain our zero defect count, but we’d be able to deliver more features, sooner.”

“What do you think?”

My team has always hated overtime with a passion.

As always, they thought I was crazy and told me so…

“This is not Agile,” they said. “This will not work. We’ll be coding into the late hours of night. We’ll be exhausted. Quality will decline.”

The sky is falling. That’s what they said.

I then said what I always say in times of change. “It’s your decision. You are a self-managed team, but I would appreciate it if you would at least give the idea a try. If it doesn’t work, say the word, and we can go back to the old way or try something new.”

And with that, my team elected to trust me enough to give the idea a try.

As I said, that was nearly a month ago.

Yesterday, the Scrum Master who most opposed the overtime idea was in my office for our monthly one-on-one.

He said…

“I’ve noticed something really odd lately. We seem to be creating very few defects lately. Now, even the guys who want to work overtime are having trouble finding something to fix.

“We’re coding the way we always have. We didn’t change our processes at all. We code as fast as we always have, and we test the same way we always have. I just don’t understand what changed.”

I said…

“That is bizarre. It’s almost as if the team found some reason to be more attentive to their work. Perhaps, it’s a testament to your leadership?”

He looked at me a moment and said only, “Isn’t it time for your next meeting?”

If it’s worth doing, it’s worth doing great!

I’ve recommended Jim Collins’ Good to Great before. Once in reference to Scrum—and once on the subject of estimates—but I thought the book might be worth summarizing for you wannabe leaders who are too busy to read.

To understand Jim’s thinking, first ask yourself: what goes into a company's transformation from mediocre to excellent?

Using volumes of data, Jim and his team compared and categorized three types of companies:

• Those that went from “Good to Great” and are still growing

Companies like Abbott, Circuit City, Fannie Mae, Gillette, Kimberly-Clark, Kroger, Nucor, Philip Morris, Pitney Bowes, Walgreens, and Wells Fargo produced and sustained great results, evolving into companies that would be around for the long haul.

• Those that directly compare with “Good to Great” companies

Upjohn, Silo, Great Western, Warner-Lambert, Scott Paper, A&P, Bethlehem Steel, RJ Reynolds, Addressograph, Eckerd, and Bank of America are companies in the same industries with the same resources and opportunities as “Good to Great” companies, but they demonstrated no obvious leap in performance.

• Those that looked great for awhile

Burroughs, Chrysler, Harris, Hasbro, Rubbermaid, and Teledyne are companies that made a short-term shift from good to great but failed to maintain growth.

Through careful comparisons of the three groups, Jim’s team identified 23 principals “Good to Great” companies followed that the others did not:

1. Ten out of eleven Good to Great company leaders or CEOs came from the inside. They were not outsiders hired in to save the company. They were either people who worked many years at the company or were members of the family that owned the company.
2. Strategy per se did not separate the good to great companies from the comparison groups.
3. Good to Great companies focus on what Not to do and what they should stop doing.
4. Technology has nothing to do with the transformation from good to great. It may help accelerate it, but is not the cause of it.
5. Mergers and acquisitions do not cause a transformation from good to great.
6. Good to Great companies paid little attention to managing change or motivating people. Under the right conditions, these problems naturally go away. 
7. Good to Great transformations did not need any new name, tagline, or launch program. The leap was in the performance results, not a revolutionary process.
8. Greatness is not a function of circumstance; it is clearly a matter of conscious choice.
9. Every Good to Great company had Level 5 leadership during pivotal transition years. Level 1 is defined as a Highly Capable Individual. Level 2 is a Contributing Team Member. Level 3 is the Competent Manager. Level 4 is an Effective Leader. Level 5 is the Executive who builds enduring greatness through a paradoxical blend of personal humility and professional will.
10. Level 5 leaders display a compelling modesty, are self-effacing and understated. In contrast, two thirds of the comparison companies had leaders with gargantuan personal egos that contributed to the demise or continued mediocrity of the company. 
11. Level 5 leaders are fanatically driven, infected with an incurable need to produce sustained results. They are resolved to do whatever it takes to make the company great, no matter how big or hard the decisions.
12. One of the most damaging trends in recent history is the tendency (especially of boards of directors) to select dazzling, celebrity leaders and to de-select potential Level 5 leaders.
13. Potential Level 5 leaders exist all around us, we just have to know what to look for.
14. The research team was not looking for Level 5 leadership, but the data was overwhelming and convincing. The Level 5 discovery is an empirical, not ideological, finding.
15. Before answering the “what” questions of vision and strategy, ask first “who”
    are the right people for the team. 
16. Comparison companies used layoffs much more than the good-to-great companies. Although rigorous, the good-to-great companies were never ruthless and did not rely on layoffs or restructuring to improve performance.
17. Good to Great management teams consist of people who debate vigorously in search of the best answers, yet who unify behind decisions, regardless of parochial interests.
18. There is no link between executive compensation and the shift from good to great. The purpose of compensation is not to ‘motivate' the right behaviors from the wrong people, but to get and keep the right people in the first place.
19. The old adage “People are your most important asset” is wrong. People are not your most important asset. The right people are.
20. Whether someone is the right person has more to do with character and innate capabilities than specific knowledge, skills or experience.
21. The Hedgehog Concept is a concept that flows from the deep understanding of the answers to the following three questions:
    • Realistically, what can you be the best in the world at and what can you not be best in the world at?
    • What drives your economic engine?
    • What you are deeply passionate about?
22. Discover your core values and purpose beyond simply making money and combine this with the dynamic of preserve the core values – stimulate progress, as shown for example by Disney. They have evolved from making short animated films, to feature length films, to theme parks, to cruises, but their core values of providing happiness to young and old, and not succumbing to cynicism remains strong.
23. Enduring great companies don't exist merely to make money. In a truly great company, profits and cash flow are absolutely essential for life, but they are not the very point of life.

In my opinion, the 21st item may be the biggest secret Jim has uncovered.

Think about it. The other items may be the effect with the Hedgehog Concept as the cause. If you are doing anything that you care deeply about—and you truly believe in it—it’s impossible to imagine not trying to make it great.

18 definitions that can make you a better leader

When I first took this job, I started jotted down notes, regarding different ways to interpret words. I've come to believe that real leaders have a slightly different dictionary than managers, bosses, dictators, and elected officials.

Here are my top 10 definitions used by real leaders...

Attitude–A state of mind, an emotional and intellectual inclination and predisposition to actions based on what you convince yourself is the truth.

Communication–Refers to anything, verbal or nonverbal, that imparts information, thoughts, or feelings. It is a vehicle than enables leaders and followers to connect with each other and to learn about their respective worlds.

Defensive Culture–A world in which people are more concerned with their image than they are with solving problems.

Desires–Unexpected bonuses or other pleasant surprises. The items that complete a staff member's statement that begins with, "It sure would be nice if..."

Expectations—Refers to perceived entitlements, any deliverable or treatment staff considers essential to happily performing their jobs.

Fertile Workplace Culture—An environment that encourages individuals to grow, learn, and be as good as they can as employees and as people.

Harassment–Selfish behavior by someone who places more value on personal desires and interests than another's right to privacy or happiness.

Leader—A respectful and genuine person who motivates others and builds strong communication bridges by being sensitive and appropriately responsive to others' feelings and desires.

Managing–The ongoing process of developing mutually rewarding and productive relationships with staff.

Mentor–An effective teacher, counselor, or master gardener, helping others improve the quality and quantity of work.

Planned Spontaneity–Knowing in advance what you hope to gain, where you want to begin, and where you hope to end. This is followed by a patient, sensitive, flexible stream of questions and answers that leads from one goal to another.

Problem–A deviation between what is acceptable and what is occurring.

Problem-solving Culture–An environment where leaders trust followers to be responsible and worthy of respect, treating each accordingly and encouraging progress as appropriate.

Quiet Strength–Having a positive influence without making obvious one's methods: being clear about expectations and desires and then supporting staff when obstacles arise.

Risk–The potentially adverse consequences of any action.

Symptoms–Behavioral evidence of a potential problem.

Tone–Emphasis given to specific words or groups of words, created by changes in speed, volume, or pitch of speech.

Weed–A valueless, troublesome, or noxious plant growing wild, especially one that grows profusely or on cultivated ground to the exclusion or injury of the desired crop, detracting from a garden's beauty and using both time and energy that could be spent cultivating those desired crops.

Weeds should always be removed as early as possible.

My team's success is built on Trust

Michael Hopkin reported today is his blog "Lead on Purpose" that "Trust is essential to building a successful team"—something readers of this blog have seen proven time and time again.

Michael said...

"One of the best ways to gain trust is to be up front with the people you lead. Great leaders are not afraid to admit mistakes. At first blush it implies weakness; however, admitting mistakes actually helps leaders gain credibility because the people they lead see them as down-to-earth and genuine."

A recent article in Investors Business Daily discusses the importance of winning the trust of your team. Some leaders waste time trying to win acceptance—or even popularity—with their teams, rather than being vulnerable—open, honest, and transparent—about their strengths and weaknesses.

Trust is ultimately more important than popularity.

Patrick Lencioni, one of my favorite authors of wrote...

“Ironically, pretending you’re strong when you’re not is a sign of weakness. Trust is the most important thing a leader can have. People will walk through walls of fire for you if they know they can trust you. Without trust, nothing else matters to them.”

Leaders fulfilling promises and providing feedback—on both desired and undesired behaviors—will gain the trust of their teams and strengthen their organizations.

Lead, Follow, or Get Fired!

After a few false starts, I still have not been motivated to get my podcast up and running, and I am beginning to think I need a co-host. With a team in place, perhaps we can push each other forward.

Afterall, that's what the phrase Lead, Follow, or Get Fired is all about.

Teams must be perpetual—where each member is a moving part pushing the other moving parts forward. When one of those parts stops working, that part must be replaced.

I know that sounds harsh, but it is a reality.

To believe anything else is to fool yourself and damage the morale—and the throughput—of your team.

This is not to say that a part cannot be repaired. The team itself should work to oil and adjust its parts to keep them from failing, and the mechanic—the manager—shouldn't be called until such repairs are beyond the abilities of the team.

Successful teams lead themselves, and within each team, there are strong members that will push for improvements.

However, those leaders must not be allowed to dominate, as one persons improvement is often another persons impediment.

You must have strong leaders that counter other strong leaders, ensuring the team is always moving forward and weighing options based on everyone's input, in order to find the optimal solutions to all problems.

Any who sees a problem with current processes should lead the team to improve it, just as they would any other problem.

If a member cannot identify a problem with current processes, it is that member's responsibility to support those processes—continuing to move forward and to push other members to move forward.

Those old tried-and-true words of Thomas Paine are still alive and well today: "Lead, follow, or get out of the way" of those who are trying to improve and/or support the team.

Yea, I know what you are thinking—and you are wrong.

There is nothing negative about this perspective for two simple reasons:

• REASON ONE: The process is a fair one. Everyone has the opportunity to support the team as is or help change the team and its processes for the better. Finding a team where you are a better fit is truly a last resort.
• REASON TWO: The process has proven time and time again that it works!

So, about my podcast: I need to get a partner who can lead me, follow me, or fire me. This has gone on long enough.

Any takers?