The Business Sensei

Outrunning the Ballmer

There’s an old story about two people walking through the woods. One of them, Pete Ahtear, is a track star. The other, that famous dessert maker Eaton Flanagan, may be an expert in the kitchen, but is not otherwise known for his speedy movement. As the two men are walking, they hear behind them the unmistakable sounds of a very hungry bear.

“That doesn’t sound good,” says Flanagan.

“That sounds like a hungry bear!” replies Ahtear. “Don’t you have a pot of honey or something you could toss at it to distract it?”

“Sorry, fresh out of honey.”

At that point, Pete Ahtear sits down, pulls his track shoes out of his backpack, and quickly puts them on.

“Even you can’t outrun a bear!” exclaims Flanagan.

“I don’t need to outrun the bear,” replies Ahtear with, it must be admitted, a somewhat smug tone to his voice. “I only need to outrun you.”

Indeed, were we to look at these two men, the truth of Ahtear’s statement could hardly be more obvious: one, a slender athlete in prime physical condition; the other, well, let us just say that Eaton Flanagan is a man whose skill at making desserts is exceeded only by his enjoyment of eating those desserts. Losing weight, given the time available, is not an option. Although quite possibly as large as that pursuing bear, regrettably Flanagan is sadly lacking in the sharp teeth and long claws department. On the scale of bears, Flanagan may be more closely likened to “Teddy” than “Grizzly.”

Speaking of bears, it’s getting closer.

Thinking quickly, Flanagan knocks Pete Ahtear to the ground, kicks him, and then uses the window of opportunity thereby created to tie Pete’s shoelaces together. Flanagan then lumbers off. He may not be able to outrun a bear, but he can now outrun Pete Ahtear. What follows is best left to the imagination.

As a further exercise of the imagination, consider how this philosophy might play out in a large corporation. What would outrunning the bear look like? What would such a competitive atmosphere do to employee cooperation and collaboration? How about problem solving and innovation?

Unfortunately, according to a number of articles about Microsoft, we don’t need to use our imaginations. Microsoft is one of a number of businesses that practice the fine art of “employee stacking.” In other words, employees are rated on a performance scale. The top performers are highly rewarded, while the bottom performers are… not. Sounds good, right? After all, won’t this push people to constantly push themselves to excel, and won’t it weed out the weakest performers?

Sadly, that’s not what’s happening at Microsoft. Excelling and taking on a risky project or trying something new are often mutually exclusive. Furthermore, what constitutes “excelling” can vary with comparison to others. In fact, as more than one Microsoft employee observed, they quickly learned to look like they were cooperating with their teammates, while actually withholding critical information or otherwise sabotaging their progress. In other words, when the performance review bear is approaching, all I really need to do is outrun you. That can happen in a great many ways: as Eaton Flanagan so ably demonstrated, not all of them involve actually being a better runner.

The side-effects of the Microsoft Way are far-reaching and not always immediately obvious. It goes well beyond employees sabotaging one another in order to make themselves look good. Hiring is effected: will you really hire someone more skilled than you are if that might push you down the rankings? Or will you prefer to hire people less skilled so that someone else will take the fall? What will that do to the overall level of employee skill? What about problem solving? When the goal is to make sure someone else trips and falls, are we going to fix the problem or merely fix blame? How about team work? Are you really going to ask to be on a team with other high performers?  It’s much safer to be surrounded by bear food than it is to work with someone who might be able to run faster than you. How badly will that reduce collaboration, creativity, innovation, and product quality?

Now, one might make the argument that Microsoft’s approach can’t be that bad. After all, they became the world’s largest software company and still dominate the PC market. Indeed, outgoing CEO Steve Ballmer was quoted in one article swearing by employee stacking. He thinks it’s wonderful.

It is possible that during the 1980s and 1990s, when Microsoft was surfing the great PC technology wave, that Microsoft’s review process really did produce high performance. Possible, but unlikely. Far more likely is that having a hot product in a rapidly growing market protects you from a lot of errors. When Microsoft’s stock was doubling practically every year, it was easy for them to constantly hire the best people. Most of those people were motivated to achieve not primarily because of the employee stacking system but because they were excited by their work, the company’s vision, and, yes, the stock options. So what if some of them become bear food? There are always more where they came from! Even if your teams are performing at only a fraction of what they are capable of, being in the right place with the right product can be enough for a long time.

Microsoft today is in an interesting position. As I’ve written about in several articles and books, they lost their way in 2000. While some people have argued that employee stacking is the reason for Microsoft’s malaise, it’s really only one factor. Granted, it is a very serious factor: at a time when Microsoft most needs to regain the innovative vision and energy of its early days, that pursuing bear means that few people indeed are going to be taking any chances.

But wait! Shouldn’t the creative vision come from the top? If that were to happen, wouldn’t that solve the problem? While vision may come from the top, leaders are more creative when they are surrounded by creative people. People staring at the ground, looking for an opportunity to trip up their colleagues, are not looking ahead and imagining the future. That’s an awful lot of psychological inertia for a leader to overcome.

In the end, when employees are forced to compete with one another, your productivity gains are brief and inevitably cost you far more than they are worth. It’s always easier to outrun your buddy than the bear, particularly when tripping your buddy is all it really takes.

At least the bear eats well.

 

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck. Steve is the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill, and a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play.” Steve’s latest book, “Organizational Psychology for Managers,” is due out from Springer in 2013. For more information, or to sign up for Steve’s monthly newsletter, visit www.7stepsahead.com. You can also contact Steve at 978-298-5189 or steve@7stepsahead.com.

The Missing I

As published in MeasureIT

 

“There is no me. I had it surgically removed.”

— Peter Sellers

At one high tech company that I worked with, I watched an interesting scenario unfold: after completing a major milestone, the engineers were high-fiving and taking some time to brag about their accomplishments. Enthusiasm and excitement were running high when a member of senior management decided to interrupt the gathering with the reminder that, “There is no ‘I’ in team.”

This utterance had an effect not dissimilar to that of a skunk wandering into a fancy dinner party. On the scale of wet blankets, this was one that had been left out in the rain for a week. Within a few seconds, all that enthusiasm was gone, vanished into the ether. Properly harnessed, that enthusiasm could have catapulted the team into its next milestone. Instead, the team approached its next milestone with a shocking lack of energy, especially given the successes they’d had to that point.

The problem is that while there may not be an “I” in team, a team is made up of individuals. There are three “I”’s in individual. What does a team do? Well, in most situations we hope the team will win. There’s an “I” right there in the middle of win. Oddly enough, you can’t win if you take out the “I.”

While it’s critical for a team to be able to work together and for members of the team not to be competing with one another, that’s only a piece of the puzzle. It’s equally important that each member of the team feel that they are an integral part of the team’s success. Without that personal connection, it’s extremely difficult to get people excited about the work.

Unfortunately, I see companies far too often treating team members as interchangeable parts, not as unique individuals. Not only does this undermine the team, it is also a tremendous waste of resources: a major advantage of having a team is that you have access to multiple eyes, ears, hands, and brains. Each person brings unique skills, knowledge, and perspective to the problems the team is facing. When a company fails to take advantage of those people, then they are spending a great deal of money for very little return.

In the Mann Gulch disaster, Wagner Dodge failed to appreciate the perspectives and opinions his team brought to the table. He relied solely on his own eyes, ears, and brains. Had he bothered to obtain information from the rest of his team, it is highly likely that most of them would not have perished under Dodge’s command. When the team has no “I,” the team cannot see.

On the flip side, some companies go too far in the other direction. One company, that shall remain nameless, spends so much time on “I” that there’s no time left for “we.” There have no team; there’s only a group of people who happen to be wandering in something vaguely approximating the same direction. Meetings are characterized by constant jockeying for position and arguments over turf. Different groups in the company see themselves as competing with one another for the favor of the CEO and for the eventual rewards. Oddly enough, the level of excitement and commitment in this situation is about the same as the one in which there is no “I.” When you have too much “I,” no one can agree on what they are seeing. In other words, too much “I” or a missing “I” produce much the same degree of blindness. That’s not good for the individuals, the team, or the company.

So how do you make sure you have the right “I?”

Start by creating something worth seeing. Paint a vivid picture of the company’s future, and show each person how they, as individuals, matter. Remind employees of the skills, knowledge, perspectives, and abilities that led to them being part of the team.

Show each person how they fit into the overall picture, and how their colleagues fit in as well. Make sure each person has a clue about what the others are doing. Ignorance breeds contempt.

Strengthen individual autonomy: find opportunities to allow people to decide how they’ll get their jobs done. Don’t regulate anything that isn’t absolutely necessary to getting the product out the door.

Always praise successes. Highlight significant contributions, remind people of their strengths.

Encourage and provide opportunities for team members to continuously develop their strengths. Improving individual skills dramatically improves team performance.

For a team to win, it needs to see where it’s going. That requires the team to have “I”’s and something to look at. How can you provide both to your team?

Flawed Execution — Don’t Lose Your Head Over It

I’m pleased to announce that my next book, “Organizational Psychology for Managers,” will be published by Springer in 2013.

This article was originally published in Corp! Magazine.

There’s an old joke about a lawyer, a priest, and an engineer being sent to the guillotine during the French Revolution.

The lawyer goes first. He kneels, and the blade comes swishing down. Suddenly, it stops just before it hits his neck. The crowd gasps. After a hurried discussion, the executioner announces that since the lawyer survived, it wouldn’t be legal to try again. He’s released.

The priest goes next. Once again, the blade stops just before it severs his head. The executioner declares that clearly it was the divine hand of providence at work, and so the priest is released.

Now it’s the engineer’s turn. Just as he’s about to kneel down, he looked up at the blade and says, “Hey, I see the problem.”

Leaving the engineer aside for the moment, what we have here is a classic case of flawed execution. It’s a fairly common, though less dramatic, event in many businesses. Unlike this particular example of flawed execution, however, when it happens in a business heads often end up rolling.

This, of course, is exactly the problem.

Now, it may seem like flawed execution is a bad thing. In fact, though, what is more important than the execution itself is how the company responds to its success or failure. This is particularly true in organizations that claim to promote innovation or organizational learning.

When a leader takes the view that mistakes mean that heads will role, that sends a very clear message to the rest of the organization: mistakes are something terrible. They are to be avoided at all costs. In other words, always play it safe because if you make a mistake, you’re in trouble. It also means never experiment because your experiment might not work out. In fact, most experiments don’t work; we conduct them to find out what will work.

To put this in perspective, at one software company the engineers on one project had to make some decisions about how users would interact with the program. They had several possible designs, but could not choose between them. Eventually, they made the logical decision to pick one and conduct some user tests. The first few rounds of tests did not go well, but eventually they hit on a design that the users liked. The response from the department head was, “That’s great, but why didn’t you get it right the first time? Your errors cost us a lot of time and money.”

On the next product cycle, the engineers simply picked one alternative and when it didn’t work blamed marketing for not providing them sufficient information. Naturally, marketing responded by blaming engineering, and so it went. Once heads start to roll, the most important thing is to make sure that someone else’s head is the one that goes. This rapidly undermines trust and teamwork.

Conversely, in highly innovative organizations, mistakes are accepted as a necessary part of the game. Indeed, these organizations try to avoid simply jumping to an answer. They recognize, as the engineer in our little joke did not, that jumping to a solution can have fatal consequences. Palm Computing, for example, conducted numerous user tests before releasing the first Palm Pilot. Many of those tests simply involved people walking around with pieces of wood in order to find the right form factor for the Palm devices.

The trick with both innovation and organizational learning is recognizing that you often don’t exactly know what you’re going to build or learn. Learning in particular is a product of making mistakes; when you don’t allow mistakes, you also don’t allow learning. As for innovation, well, it’s very hard to pick the right answer when you’re exploring unknown territory. Rather, getting to a right answer is a process of exploration and experimentation. That process of collaborating with your team, sharing successes and failures along the way, is what truly builds a strong and resilient team, as well as high quality products and services.

In the end, it’s the flawed execution that really gets you what you want, while jumping to the apparently correct answer too quickly can be fatal. No joke.

Stephen Balzac is an expert on leadership and organizational development. He is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck, and the author of “The 36-Hour Course in Organizational Development.” Contact him at steve@7stepsahead.com.

For Want of a Rubber Band

The other day, my DVD player stopped working. Naturally, this happened the night I was sitting down to watch a movie I’d been looking forward to. Quite simply, the tray wouldn’t open (presumably, it wouldn’t close either, but there was no way to test that). As we all know, a feature of modern electronics is that there are “No user serviceable parts inside.”

Nonetheless, I decided to open it up anyway. If nothing else, I figured I could at least recover the trapped DVD one of my kids had left in the machine.

Opening it up was an interesting experience. Inside was mostly empty space with a tray and a circuit board. Apparently the major difference between a portable player and a non-portable one is the amount of wasted space.

There was also one user serviceable part: the rubber band.

Yes, in the midst of the electronics there was a broken rubber band. That rubber band acted as the “drive train” to open and close the DVD tray. Just think about that: all this high tech electronics rendered completely useless by the failure of a sixty cent rubber band. How much is that rubber band really worth? Sometimes the value is not the cost of the item but what it makes possible. Sometimes the critical problem that is blocking us from moving forward turns out to be something small and simple, but only if we know where to look and what to look for. While I could have replaced the DVD player, that would have been a much more expensive solution than replacing the rubber band. Knowing the real problem enabled me to pick the best possible solution.

I was asked recently about my opinion on attendance point systems.

“Why?” I replied.

The person explained her company was having problems with absenteeism and people changing shifts without notifying anyone in authority. Based on this, she wanted my opinion of attendance point systems, presumably on the logic that implementing one would solve her problem. Unfortunately, without knowing exactly why people are not showing up for work on time and without knowing why they’re constantly switching shifts, implementing an attendance point system is as likely as not a solution in search of a problem. Sure it might work; on the other hand, it might not work. It’s basically a roll of the dice.

So why jump to that solution? Simple. It’s easy. Faced with a problem without an obvious solution, the natural response is to impose a solution that fits the symptoms. Symptoms, unfortunately, are not the problem; they’re just the symptoms. Like taking an antibiotic for the flu, it doesn’t help and may make you feel worse.

Instead, we need to work backward from the symptoms to understand the underlying problem. With my DVD player, the symptom was that the tray wouldn’t slide out. Had I assumed the problem was that the electronics were fried, I would have tossed it and bought a new one. By investigating the problem, I had a working DVD player in less than fifteen minutes.

Investigating the problem, however, requires a certain amount of effort and frequently appears overwhelming and expensive. The lure of an obvious, easy, and, above all, cheap solution is very strong. The fact is, there are a lot of obvious, inexpensive solutions to many problems. In a business, it’s particularly easy to find an easy solution particularly if you don’t care if it actually works. If you want a working solution, though, the choices become somewhat more limited.

Investigating a problem is rarely as overwhelming as it first appears. With the DVD player, it was easy to open it up and see what was going on inside. With human systems, on the other hand, taking them apart in that way can be a bit problematic. Putting them back together again is even more tricky. The real key is to see how often the symptoms appear and under what conditions. What other symptoms are there? What do people say when you ask them about their experiences and their observations? As you put together a picture of the symptoms and when they appear, you can start brainstorming about possible causes. Does your organization have a cold? The flu? Is it suffering from growing pains?

At one company, everything was going great until they went public, had a huge influx of cash, and began a rapid expansion. Suddenly, all sorts of symptoms appeared: increased conflict, passive-aggressive behavior, confusion, inability to follow through on decisions, and so forth. Fixing the problem required first identifying what was really going on, and then crafting a solution appropriate to that organization. None of the problems were that big, but, like that rubber band, they were in critical places.

In a sense, it’s not how big the problem is that matters most. What matters most is what that problem is preventing you from doing.

How much was that rubber band worth again?

The Speed of Mistrust

Remember the scene in the original Star Wars where Luke, Hans, Chewbacca, and Leia are trapped in the garbage disposal with the walls closing in on them? As the walls inexorably press closer and closer, they engage in increasingly desperate attempts to stop them, a ritual made famous in dozens of adventure movies. No matter how hard they push back against the walls, their efforts are futile. Of course, they are the heroes of the movie, so they do find another way out; after all, if they had not, the movie would have come to an abrupt ending and the fans would have been crushed.

Of course, rather than counting on finding a miraculous escape, it would have been better to have not been in that tight a predicament in the first place.

At Soak Systems, the CEO, whom we’ll refer to as Luke, recently made the comment that, “I guess I should have pushed back harder.”

He was referring to a disastrous product release, one whose eager anticipation by their largest customer was exceeded only by that same customer’s anger and disgust when they finally received it. Their subsequent email was, to say the least, crushing.

In the inevitable post-mortem, it quickly came up that Luke had made at least a couple of attempts to play with the product before it was shipped, but that engineering had “refused to let me see it.”

In retrospect, Luke felt that if he had only insisted more strongly, then clearly engineering would have complied and he would have been able to identify the problems and save the release. Luke is also capable of holding back those moving walls with just the little finger of his left hand. Okay, well maybe not.

While it was gallant of Luke to accept some of the blame for the disaster, he was actually missing the point. In fact, the question is not whether Luke could push back hard enough to convince engineering to cooperate. The question is why he was in that position in the first place. Why, as CEO, does he need to push back that hard just to get basic cooperation? It’s hard to imagine how a release that disastrous could occur without plenty of warning. If nothing else, the stink should have been obvious.

At this point, the traditional thing to do is to nod sagely and observe that if they simply had better communications, the problem could have been avoided. While that observation may be true, it is definitely useless. Of course they weren’t communicating! Why not?

In Star Wars, our heroes at least had the excuse that they landed in the garbage disposal because they were trying to avoid pursuing Storm Troopers. In the resultant rush, they didn’t really have a chance to sit down and calmly discuss their options. At Soak, Luke didn’t have that excuse. There was no rush and no panic, other than the ones that he manufactured.

Effective communications comes from building trust, and trust comes from taking the time to build connections with employees and from, yes, communicating. The problem is that, as CEO, people don’t typically drop by to chat. If you want to get people talking to you, you need to seek them out. Luke didn’t do that. By comparison, IBM’s founder, Tom Watson, was legendary for showing up unannounced at different IBM locations and just dropping in to chat with different people. He was trusted as few CEOs have ever been: employees believed that he cared about them personally.

Luke, on the other hand, talked only to the people he’d worked with in other companies. When he came down to engineering at all, it was mainly to exhort them to do more or complain that they weren’t doing enough. When it became clear that the release had problems, the engineers had mixed feelings about talking to Luke. They couldn’t decide whether he would yell at them and go ahead anyway, threaten them and go ahead anyway, or simply ignore their input completely and go ahead anyway. The VP of Engineering wasn’t able to help them figure out which one it was either, so they decided to simply say nothing.

This is, perhaps, not the best way to establish strong and effective communications with your team.

Now, the fact is, Luke was certainly communicating with the rest of the company. His particularly choice of what to say and how he said it served to build a foundation of mistrust, not a foundation of trust. Sadly, in this environment, the speed of trust has nothing on the speed of mistrust.

Worst of all, Luke’s response, that he “should have pushed back harder,” only confirmed that mistrust. From the perspective of engineering, the release failed due to a number of serious problems that Luke and the rest of senior management were unwilling to address. Acting as if just yelling and demanding more would have changed anything was telling everyone in the company that Luke still didn’t acknowledge the severity of the problems.

The net result: nothing has changed since the release. The metaphorical walls are continuing to close in, Luke is ineffectually pushing back, and one after another the top people at the company are resigning. While Luke may end up with a company full of people he can push around, it’s not at all clear that any of them will be able to push a product out the door.

The situation is not totally irreparable, although it’s getting close. Luke needs to take the time to sit down with his people and actually talk to them and listen to their answers. He needs to take the time to actually get to know more employees than just those with whom he worked in the past. He has a lot of mistrust to overcome and doing that will not be easy. Whether he succeeds or not really depends on whether he is willing to recognize how little trust people have in him, and whether or not he’s willing to work to change that. Until he makes those changes, trust gets the dirt road and mistrust gets the superhighway.

Which is running faster in your company, trust or mistrust?

Yankee Swap Rorschach

This article was originally written a couple years ago, but always seems rather appropriate for the holiday season…

The holidays are the season for Yankee Swaps. Now, a Yankee Swap would seem to be a fairly simple and straightforward activity: each person either chooses a wrapped gift or steals an opened gift from someone else. This latter activity can, of course, trigger a chain reaction, but that’s part of the fun. At the end, everyone feels like they had at least some measure of control over the outcome. One would think it difficult, if not impossible, to mess up a Yankee Swap.

However, all things are possible. In this case, one company held a Yankee Swap with incredibly detailed and complicated rules which had as its most salient feature that no gifts were opened until the very end. In other words, the experience was transformed into the equivalent of a very slow grab bag: a long, frustrating, totally random process at the end of which people felt that they had no control over the outcome. Ironically, the most common complaint from employees at this company is that many of the rules are complex, time consuming, and leave them feeling like they have very little control over how they get their work done.

Now, a Yankee Swap is a pretty insignificant event, little more than an amusing party game. However, how a business goes about designing a small process says a lot about how it goes about designing larger, more significant processes: process design is strongly influenced by institutional habits and beliefs. With a small process, it’s easy to see the results of that belief in action because the entire event can be seen at one time; with larger processes, cause and effect may be separated by weeks or months, and the process is often so big that no one ever views it as a whole. The company ends up wondering why their results are poor, but can’t figure out the reasons. Those small processes can provide valuable insights into the company’s methodology and assumptions; recognizing consistent causes of small problems can enable you to avoid large ones. Ultimately, more important than improving one process is improving how the company designs all its processes.

In designing a process, it helps to clearly understand what you are trying to accomplish. Why did this particular company choose to redesign the Yankee Swap? Was there an actual problem that someone was trying to solve? Clearly, someone felt a need to come up with something, although their motives are impossible to fathom. As a result, they got a process that rather missed the point, but did end up reflective of the organization as a whole. However, it’s generally more successful to focus on results:

• Clearly define the objective. If the objective is to solve a problem, take the time to look at the symptoms and consider what they mean. When do they come up? Under what circumstances? Remember, the symptoms are not the problem, they’re just the symptoms. Generate a list of hypotheses and then test them to see if they lead to the observed symptoms. Solving the wrong problem will generally make things worse, not better.
• Describe what a successful outcome will look like. What will have changed? What behaviors will be different? Make this concrete. If success is, “people will have more fun,” how will you know? If the picture isn’t clear, identify the questions you need to answer to bring clarity. This may be an iterative process.
• Identify what you can change and what you can’t. You probably can’t change the economy, but you can change how you deal with it. Tom Watson Sr., founder of IBM, used the Great Depression as an opportunity to build up a highly trained, extremely loyal workforce and a stockpile of equipment. When WWII started, IBM was in an excellent position to capitalize on the reawakening economy. If everything falls into the “can’t change” category, you need to revisit your goal or problem formulation.
• Brainstorm possible solutions or approaches. Record ideas and do not evaluate any of them until you have a significant number of possibilities. Don’t worry if some ideas are silly or off-the-wall: innovative solutions come from the most unlikely sources.
• Will your solutions really get you where you want to go? Do research. Don’t rely on opinion and conjecture.
• Define your action steps.
• Execute and evaluate. Did it work? If not, check your problem formulation and try again.

If you’re not getting the results you want, what steps are you missing?

Sir CEO and the Green Knight

As published in the CEO Refresher

One fine day, Arthur, the CEO rode forth upon his trusty steed. At his side hung his magic sword, Expostfacto. Expostfacto was widely considered to be a sword with a sharp legal mind. Arthur had made his fortune renting camels, which he parked every day in a large camel lot.

The sun was shining. The birds were singing. Suddenly, a dragon came roaring out of the sky, heading straight for Arthur. Flame billowed from the dragon’s mouth. Arthur drew his sword and with one swift blow, buried the dragon in a shower of subpoenas.

So it went, as Arthur spent many days enjoying the freedom of facing foes instead of sitting in stultifying board meetings, where, regretfully, it was seen as déclassé to employ the full might of Expostfacto upon annoying board members or customers. Against the power of Expostfacto, each foe swiftly fell under a massive pile of paperwork.

So it went until the day that Arthur encountered Maldive, the Green Knight.

“None shall pass!” quoth Maldive.

Many blows were exchanged, with Expostfacto screaming its legendary battle cry, “Lorem ipsum dolor sit amet,” a phrase which has become familiar to all internet users. Eventually, though, with a mighty blow, Arthur struck Maldive’s head from his shoulders. That should have ended the fight right then and there, but Maldive was an internet marketing scheme. He simply put his head back on and continued the fight. Eventually, Maldive knocked Expostfacto to one side, and placed the point of his sword at Arthur’s throat.

“I could slay you now,” said he. “But on your honor, I will spare you if you can answer this question: What does every engineer desire? Swear on Expostfacto that you will return in a month. If you have the answer, you will live. If not, you die.”

Ignoring Expostfacto’s muttered comments on possible loopholes and the inadvisability of signing anything, Arthur took the oath to return in a month with the answer or without it.

Arthur rode across the land searching for an answer to the question. He called together all his senior managers and asked them, to no avail. He even posted the question on Twitter and Facebook, leading to some very interesting answers and suggestions, particularly from certain ex-politicians in New York and California. However, since Maldive had asked about engineers, Arthur knew those answers couldn’t be true because an engineer wouldn’t know what to do with one even if he found someone willing to go on a date.

By day 29, things were looking quite bleak for Arthur. As he rode through the frozen lands of Nadir, he encountered a strange looking man. The strange thing was that the man did not appear to be in a rush. As a CEO, Arthur was quite used to people rushing around following his orders. He could always tell when things were getting done by how much people were rushing.

“Who are you?” asked Arthur, puzzled at the sight of someone so calm and relaxed.

“Merlin,” was the reply.

“Merlin the Magician?” asked Arthur.

“No, Merlin the consultant. What seems to be a problem?”

“Nothing, nothing at all,” said Arthur who, like most CEOs, became very cautious at the sight of a consultant.

“Good,” said Merlin, who turned back to whatever he was doing, completely ignoring Arthur. This was a very unusual experience for Arthur, who was not used to being ignored by anyone.

After several minutes, Arthur said, “Well, I guess I’ll be on my way.”

There was no response.

“I’m going now,” said Arthur.

There was no response.

Arthur started to ride away. There was still no response from Merlin, who seemed quite happy to let Arthur leave. Arthur had not ridden very far before he stopped and turned back.

“Do you know what every engineer wants?” asked Arthur.

“Why do you ask?” replied Merlin.

Before long, Arthur was telling Merlin exactly why he wanted to know and what would happen if he didn’t find out. I wasn’t long before a price was agreed upon and Arthur had his answer.

“That’s it?” exclaimed Arthur. Reflecting on it further, he said to himself thoughtfully, “But that’s what everyone wants!”

The next day Arthur showed up at the appointed time for his meeting with Maldive.

“Well?” said Maldive.

“Is it money?” said Arthur.

“No.”

“Is it a fast car?”

“No.”

“Sex?”

“We’re talking about engineers,” responded Maldive. “If that’s the best you can do, then prepare to die.”

“Wait,” said Arthur. “What engineers want is the freedom to make their own decisions.”

There was a long silence.

“I see you encountered Merlin,” growled Maldive. “Very well. But I doubt you will learn from this experience!”

And so Maldive turned and rode away.

Arthur, meanwhile, departed for home in a very thoughtful mood. What, indeed, did it really mean that people want to make their own decisions? Obviously, if he allowed all his employees to make their own decisions, surely chaos would result. No one would know what anyone else was doing! There would be no coordination between departments.

The moment Arthur returned to his office, he discovered the true meaning of chaos. Thousands of emails needing his attention; projects stalled because he hadn’t been around to tell people what to do; irate customers complaining about badly maintained camels (even camel renters have some expectations!); employees angry and frustrated because they couldn’t get anything done in his absence.

“I knew I should never have taken a vacation,” Arthur thought ruefully to himself. “This happens every time! It’s even worse than when I’m in a meeting or on a call.”

As Arthur dove into sorting out the confusion that came about from his taking his guiding hands off the corporate reins, he kept wondering how much worse it could really be if he allowed his employees to make their own decisions. Would it really be worse than what he dealt with every day? Arthur decided to experiment: instead of solving the problems in one department, he gave them limited decision making power. They could approve all expenditures, including customer returns or gifts, up to a fixed amount. After a couple of false starts as everyone got used to the new arrangements, Arthur found that that department was suddenly taking up much less of his time and energy. Moreover, the increased productivity of his employees more than made up for the occasional decisions that Arthur might have made differently. Indeed, simply by building some structure, Arthur found he could permit much more freedom and limit the downside of the occasional mistake, and create almost unlimited upside. At the same time, he also found that he could now focus much more on the strategic direction of his company instead of spending all his time putting out fires.

Best of all, as Arthur spread these changes throughout his company, he found that work didn’t come to a halt whenever he wasn’t available. Productivity increased because employees no longer needed to look busy in order to appear to have a purpose; instead, they could actually engage in purposeful activity. Sure, there were still moments of frustration, but on the whole, employees were happier and more motivated than he had ever seen them. Motion does not equal progress, Arthur realized. Progress equals progress.

In the end, the ability to give people the freedom to work as they would like to work comes from building the structure to enable them to know what to do. Without structure, there may a lot of motion, but very little progress. What will you do to change that?

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck. Steve is the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill, and a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play.” For more information, or to sign up for Steve’s monthly newsletter, visit www.7stepsahead.com. You can also contact Steve at 978-298-5189 or steve@7stepsahead.com.

The Efficient Light Bulb

As published in The Imaging Executive

Once upon a time, there was a light bulb. This light bulb was quite a remarkable light bulb: it was praised far and wide for its incredible efficiency. This light bulb gave off no waste heat. This light bulb did not contribute to global warming. It had no carbon footprint.  It did not rely on fossil fuels. Truly, it was an amazing light bulb and visitors came every day to see this remarkable light bulb.

One day, though, a traveler coming to see the light bulb in action was delayed by an unfortunate flood that closed several roads. He did not arrive until well after night had fallen. Much to his surprise, he found the light bulb sitting in a pitch dark room.

“Why aren’t you giving light?” asked the traveler.

“Give light!” replied the light bulb in shocked tones. “You must be joking. If I did that, I would use fossil fuels. I would have a carbon footprint. I would give off waste heat. I would no longer be efficient.”

“But isn’t the purpose of a light bulb to give light?” asked the traveler.

“I’ve always been told to be efficient,” replied the light bulb with a shrug. If you have never seen a light bulb shrug, it is truly a wonder to behold. The traveler would have been amazed, except, of course, that the room was too dark for him to see the miraculous event.

Once upon a time, there was a software company named “Soak, Inc.” Soak’s product relied upon a very complex database server. One day, the VP of Engineering stormed into the office and declared, “The server is too slow. We need to speed it up.”

From that day forth, every effort was focused on improving the speed of the server. Other issues were deemed insignificant beside the one, critical, goal of performance. Engineers who dared to raise other issues were publically humiliated for wasting the company’s time. Bugs that did not relate to performance issues were deemed “optional.” People who spent time reviewing the optional bugs and trying to fix them were warned that their insubordination would cost them their jobs if it did not cease immediately.

Eventually, Soak developed an amazingly efficient server. It was fast. It was robust. It was ready to demonstrate to potential clients.

The demo started out remarkably well. The server did not crash, causing some to believe that this couldn’t actually be a demonstration of a software product. Indeed, the server performed flawlessly. All would have gone well indeed for Soak had not someone noticed that the data being delivered by the server didn’t make sense. Yes, what the server had gained in performance it had lost in accuracy. In other words, it was incredibly good at very rapidly delivering useless or incorrect information.

When the engineers were questioned about this unfortunate oversight, they shrugged and replied, “We were told to be efficient.”

While it is not nearly as amazing to see an engineer shrug as it is to see a light bulb shrug, the effects are much the same.

Once upon a time, there was a large company called “Red.” Red Inc. had a team of salesmen who were, it seems, not producing the necessary volume of sales.  While this may have gone a long way toward explaining the name of the company, it was not exactly a viable long-term strategy.

One day, the VP of Sales decided that the problem was clearly that the salesmen were not calling enough potential clients. They were wasting their time. They needed to be more efficient with their calls.

Much effort was spent focusing on the calling habits of the salesmen. They were given scripts. They were forced to practice making calls with various managers listening in and rating them on their performance on these practice calls. Those salesmen who demonstrated too great, or at least too obvious, a reluctance to make calls were dismissed. Those who questioned whether this was the right way to approach the problem either learned quickly to shut up or were also dismissed.

The sales team became very efficient at making calls. Sales did not increase. The remaining salesmen shrugged.

It turns out that even the best salesmen are reluctant to make calls. The problem was not with making the calls. The problem was with projecting the necessary confidence and optimism to attract and hold the interest of the client. Clients, it seems, are not all that likely to buy from salesmen who do not appear enthusiastic and confident in what they are selling. It also helps to know how to close the deal.

In each of these situations, a goal was set, a metric for success was defined, and that metric became the sole determinant of progress. Goals are extremely powerful tools: the best thing about them is that you accomplish them. Unfortunately, sometimes the worst thing about goals is that you accomplish them. In each of these examples, they accomplished their goals. A dead light bulb is extremely efficient, but not useful. Similar observations can be made about the server and the sales team.

Before leaping into setting a goal, especially a goal to solve a problem, it helps to understand the actual problem and to understand what the actual symptoms are. At Red, they assumed that an unwillingness or inability to make calls was the cause of the low sales and set their goals accordingly. We’ll never know how many top salesmen they dismissed because they didn’t realize that even the best salesmen suffer from call reluctance. Rather than create useful goals, they fixated on a symptom. That did not, however, actually change anything.

At both Soak and Red, the respective VPs stated that they were trying to solve the problems their companies were facing as rapidly and effectively as possible. They were setting goals. They were Taking Action! Taking action is certainly helpful, but it is even more helpful to be taking the correct action. Since it’s not always possible to determine just what the correct action is, it becomes even more critical to listen to the feedback and questions from the people who are charged with actually executing the action. The engineers and the salesmen knew that something was wrong, but no one was willing to listen to them. Remember, a key aspect of successful goal setting is understanding the feedback you’re getting.

I realize that many of you reading this are probably chuckling to yourselves and thinking that this scenario could never happen at your companies. The folks at Soak and Red said the same before, during, and even after it happened to them. The light bulb had no comment.

Setting a goal, for example, to be more efficient , seems like it makes sense and certainly feels good. However, it pays to determine if that goal is actually going to get you what you want. Otherwise, you may just end up with a dead light bulb.

The Peter Principle of the Thing

As published in Corp! Magazine

A good many years ago, I was working at a small software company. For various personal reasons, the VP of Engineering abruptly left the company and one of the senior engineers was promptly promoted to take this place. Now, this guy was an excellent engineer and I learned a great deal from him. He was a fun person to work with and someone who was always enthusiastic. He was picked for the job exactly because of those qualities and because of his engineering prowess. However, as a manager of engineering, he never appeared to have the same joy and excitement about his job. Indeed, he often gave the impression that he’d rather be writing code than managing other people who were writing the code. After the company folded, as far as I know, he went back to engineering.

At another company, Jim was a star researcher. He was brilliant. He was the person who came up with idea after idea. He did so well that eventually he was put in charge of the lab. At that point, things went downhill. Working through other people drove Jim up the wall. He wanted to be in the lab, not arguing about the best way to do things. He couldn’t go back, though, without being viewed as a failure. At the same time, he couldn’t get promoted until he “shaped up” and “made his lab more productive.” He was trapped doing a job he didn’t particularly enjoy and wasn’t particularly good at.

Both of these stories are examples of a hypothesis first proposed in the 1960s by psychologist Lawrence J. Peter. Today, the “Peter Principle” is spoken about with a certain amusement and a smug “yeah right” attitude. Unfortunately, “yeah right” is the only construction in the English language in which a double positive makes a negative. In other words, the Peter Principle is popularly seen as a joke. In fact, it’s not. Moreover, it turns out that when you have an environment in which someone can be promoted into a job that is significantly different from what they’ve been doing, the Peter Principle is virtually inevitable. The key point lies in recognizing what constitutes “significantly different.”

Well, as it happens, managing engineers is significantly different from being an excellent engineer. Managing researchers is significantly different from being a top researcher. Managing salesmen is significantly different from being a top salesman. However, being a top engineer, researcher, salesman, or whatever is exactly what brings that person to the attention of senior management. If this isn’t disturbing enough, in the study confirming this phenomenon, authors Pluchino, Rapisarda, and Garofalo also found that the best way to avoid it was to either promote people randomly or promote the best and the worst performers equally.

As Monty Python might say, “This is getting silly!” After all, how can it possibly be true that random promotion would work better than promoting the best performers into management?

Consider how much time, effort, and training is required to become a top engineer, researcher, salesman, doctor, or just about anything else. Nothing in the training these people receive prepares them to manage others. In fact, good management is, in many ways, the antithesis of being a successful solo performer: instead of doing the work yourself, you are now doing it through others. Motivating others is a different experience than motivating yourself. Helping others stay focused and on track is different from keeping yourself focused and on track.

So, without resorting to promoting people randomly, what could be done to prevent the Peter Principle from taking over in your company?

Well, if it were possible for someone to both be a manager and not be a manager at the same time, you would be able to see if they could do the job, and allow them to continue along the track they’re on if they don’t shape up. Unfortunately, literally attempting this is pretty hard on the person and the business; someone who tries to be both a manager and an individual contributor at the same time usually ends up doing one, or usually both, badly.

An alternative, though, is to take a page from sports and provide practice space for people. Just as a sports team might rotate players through different roles before figuring out what each one is best at, companies can use predictive scenario leadership games and exercises not just to train existing leaders, but to find leaders. Quite simply, when people don’t know what to do, they do what they are most comfortable doing. In predictive scenarios, people have the opportunity to demonstrate talents that might not be obvious or which may never come up in their regular jobs. For example, the best managers create order in chaotic or ambiguous situations and know how to build employees’ confidence. When you enable an entire department to participate in a predictive scenario, you can see who is actually doing those things. Rather than promote randomly, you can pick the people who most strongly demonstrate the desired skill set for the position you are looking to fill!

Is this easy? Not necessarily. It takes some serious effort to avoid the Peter Principle. I suspect that many of you reading this are thinking that you simply can’t afford do anything about it. The real question is, can you afford not to?

Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead (www.7stepsahead.com), an organizational development firm focused on helping businesses get unstuck. Steve is the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill, and a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play.” Contact him at steve@7stepsahead.com.

The Engines Cannae Take Much More…

As published in the CEO Refresher

Imagine for a moment Mr. Scott giving his famous, “Captain, the engines cannae take much more of this,” line and Kirk responding, “No problem, Scotty. You take a break and I’ll fix the engines.” Even for Star Trek this would be ludicrous. Kirk may be pretty smart, but he’s not the master engineer that Scotty is. It makes no sense for him to try to do Scotty’s job; that’s what he has Scotty for. Oddly enough, Star Trek is one of the few places where this scenario never happens.

Where does this scenario play out? In far too many businesses. I am always fascinated when a manager tells me that he would never ask his employees to do something that he couldn’t do. What is the point of having a team? A team that limits itself to the abilities of the leader is not really a team. It’s a group of henchmen who may be good at carrying out instructions, but who are not capable of achieving high levels of creativity or performance. It would be like Kirk refusing to order Scotty to fix the engines because Kirk can’t do it himself.

In an effective team, the abilities of the team are greater than the sum of the individuals. It is the capacity of the team to work as a unit, to be able to put the right person or subset of people in the right place to deal with problems that makes the team strong. Fictional though they are, the crew of the Enterprise is an effective team exactly because they know how to put the right people in the right place at the right time. While it certainly helps to have a cooperative script writer, the fact is that the level of teamwork that they demonstrate is not fictional at all. It is something that all teams can achieve, for all that barely one in five actually do.

To bring this into the real world, or at least as real as the software industry gets, I worked once with a software company that had the idea that every engineer should become expert in every other person’s code. Unfortunately, this was a fairly large project and the different pieces required different areas of highly specialized knowledge. Each of the engineers had spent many years building up that expertise and could not simply transfer it to every other engineer. While having partners working together makes a great deal of sense, trying to have everyone doing everything is self-defeating. It sacrifices the benefits that come from applying specialized knowledge to specific problems.

However, this was not nearly as dysfunctional as the suggestion by one senior manager at a high tech company that part of having everyone in the company better understand one another’s jobs, each person should spend time doing each of the other jobs. When it was pointed out that engineers are not always the most socially adept people, and that perhaps having the engineering team trying to market to customers wasn’t the best choice, his response was, “Then they need to learn.” When it was pointed out that marketing and sales professionals, talented as they are, generally are not trained engineers, he had the same response. Fortunately, wiser heads prevailed: while those engineers who wanted to become more involved in customer facing activities were given the opportunity to do so, the engineers did not end up trying to sell the product and the sales force did not end up attempting to build it.

Now, the fact is, this manager did have a point. Helping people to become more knowledgeable about one another’s jobs is important. If you understand just a little about what other people are doing, you have a much better sense of what is a reasonable request and what is not, what you can do that will help them accomplish their jobs, and what you can do to help them to help you do your job.

So how do you develop that level of mutual helping? Different people bring different skills to the project. The more people can get to know one another, to appreciate the perspectives, experiences, and ideas that each one brings, the more they will start to come together as a team. The leader needs to set the example that asking for help is not a sign of weakness and accepting help is not a sign that you can’t do your job. It is exactly because you have multiple perspectives and approaches, multiple skill sets and ideas, that the team becomes strong.

The leader can do this by, well, leading. Not by ordering or threatening or attempting to coerce people, but by demonstrating the behavior that he wants other people to engage in. The leader must be the first one to acknowledge that the reason there is a team in the first place is because the leader can’t do it all himself. If he could, why is anyone else there? Whether it’s Captain Kirk trying to run the Enterprise single-handedly or one man trying to play all nine positions on a baseball team, a leader who can’t accept help is not a leader.

What are you doing to help your team members help you?