The Business Sensei

Death of a Thousand Knives

As published in Corp! Magazine

Very few companies are ever driven out of business by their competitors.

I’ve found that this statement upsets a great many people, all of whom are quick to jump up and start providing examples of companies that were, in fact, driven out of business by their competitors. This is missing the point. Indeed, it’s rather like a detective in a murder mystery concluding that the cause of death was that the victim’s heart stopped. It matters whether the heart stopped due to lead poisoning, for example in the form of a bullet, or due to some other cause. Indeed, understanding exactly what led to that heart stopping moment is a key part of solving the mystery.

Similarly, while it’s not so unusual for a failing company to have the coup de grace administered by a competitor, how they got to that point makes all the difference. Focusing only on the end point provides a very simple, comfortable solution, but not necessarily a particularly useful one.

Robotic Chromosomes, for example, was a company that dominated a particular niche in the bioinformatics market. They were an early entrant into the field and their products were initially the best on the market.

Over the course of several years, though, they developed a view of their clients as idiots. The fact that their clients were all highly educated research scientists did not enter into the equation. If they had trouble using the software, they were idiots. As a result, the company became increasingly less open to feedback from either clients or the market. While their market share was increasing faster than the market itself, they could get away with that attitude. Eventually, though, their growth started lagging the growth in the market. Phrases like “law of large numbers” and “temporary aberration” were batted about. When their market share started shrinking, phrases like, “temporary aberration” became even more popular. The view of the clients as insanely stupid for buying competing products became more common.

Today, they no longer exist. Were they driven out of business by their competitors? Only in the sense that they put themselves in a position to allow their competitors to drive them out of their dominant position in the market. Sure, their competitors may have pushed them over the cliff, but they were the ones who chose to walk to the edge and lean over.

Now, it may reasonably appear from the preceding description that Robotic Chromosomes was taken down by a clearly defined event, that is, viewing clients as idiots. That is not, however, quite correct. While it may appear that way in retrospect, the reality is that Robotic Chromosomes suffered from a series of cascading errors. Each mistake was small, easily overlooked or ignored. Each mistake led to more mistakes until eventually the company was suffering from so many small cuts that it eventually had no strength left to resist when its competitors moved in. So how does a company avoid this death of a thousand knives?

The obvious answer is that they needed better communications. While true, it again misses the point. Communications is where problems show up, but the communications are rarely the problem. Rather, the dysfunctional communications are the symptom of the problem. It’s critical to look beyond the symptoms to identify the real problem. Otherwise, you spend all your time looking at the wrong things, as Robotic Chromosomes so eloquently demonstrated.

Avoiding that fate requires a willingness to accept negative feedback; it means being willing to hear what people are saying about your product, your service or your management style. If you aren’t willing to listen, or if you structure the way in which you listen to negate the feedback, you’re setting yourself up for failure, one step at a time. For example, creating a culture that mocks and demeans your clients is not a recipe for success, and closes you off from valuable feedback from those clients.

Being willing to accept feedback is only a first step though. You have to create a context in which employees are not afraid to give you that feedback, and in which they believe that providing feedback is worthwhile. If people believe they’ll be punished for being critical or regarded as “not a team player,” it’ll be hard to get them to provide feedback.

Next, you need to clearly define your goals and also define how you’ll know whether you’re succeeding or failing. Robotic Chromosomes had very fluid definitions of success, definitions that shifted regularly to avoid facing unpleasant results. It’s important to separate the evaluation of the feedback you’re getting from the testing to see if the criteria for that evaluation are valid. In fact, verifying the validity of your criteria should be done before you then evaluate your feedback: otherwise, it’s too easy to redefine success and give yourself a few more cuts. None of them seem all that bad at the time.

Step by step, over the course of several years, Robotic Chromosomes successfully created an environment where any negative feedback could be ignored because that feedback was always coming from idiots. Their competitors didn’t drive them out of business. They drove themselves out of business; their competitors simply put them out of their misery. How will you avoid the death of a thousand knives?

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 leaders grow their businesses. 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?

Real Science Fiction

As published in Corp! Magazine

See if you can identify the actual science fictional elements from the following description of a scene from the original Star Trek.

Captain Kirk and his officers are sitting around a conference table aboard the starship Enterprise. They are looking at screens set into the table, on which information is being displayed. Occasionally someone taps a screen to get more information. Kirk and the others conduct their meeting, periodically referring to the displays.

Now, the Enterprise is certainly fiction. We don’t have any starships, despite the more optimistic predictions from the TV show.

The touch sensitive video screens were certainly science fiction back in the 1960s. Today, they’re almost quaint. We’ve moved well beyond that, with our Blackberries, iPhones, iPads, laptops, and tablet computers. So, no points there.

The real science fiction in this scene isn’t the array of gadgets or even the starship. It’s the fact that not one person is using the screen for anything other than business. No one is checking email, no one is Tweeting, no one is browsing the InterstellarNet, and no one is playing Angry Birds. Everyone is actively engaged in the meeting. Granted, these meetings usually occurred when the Enterprise was about to be destroyed by Romulans or something, but even taking that into account the behavior of the crew is still pure fiction. How many meetings have you attended where everyone was actively engaged like that? While it does happen, most businesses I speak with would like to see it happen rather more frequently than it currently is happening.

The first, and perhaps most important, thing about getting people engaged in meetings is to recognize the feedback you’re getting. When you start a meeting and everyone is already nose deep in a Blackberry, that’s feedback. The trick is to recognize what it’s telling you. Some possibilities include:

• Participants do not see the point of the meeting.
• Participants are not interested in the topic or material being discussed.
• Participants do not see how the meeting is relevant to the work they’re doing or the deadlines they are facing.
• The meeting is lacking in focus or does not have clear objectives.
• You are boring.

Let’s take the last one first.

Sadly, not all presenters are the most interesting people on the planet. Some speak in a monotone,. Others don’t know when they’ve made their point and keep talking. Still others don’t respect the schedule. Naturally, if you’re reading this, that clearly doesn’t apply to you. However, not everyone listening to you realizes that. Therefore, it helps considerably to pay attention to your own presentation style so that you can be sure to get through to those who might otherwise assume that you are going to bore them.

Why are you holding your meeting? On Star Trek, there’s always a good reason for the meeting: for example, figuring out to avoid being eaten by a giant space amoeba. While it is unlikely that you are facing a similar threat, nonetheless there needs to be a point to the meeting. What is the goal? At the end of the meeting, what do you expect to have accomplished? If the answer is that you simply wanted to convey information to people, or have people share status updates, perhaps emails would better. After all, do the status updates really need to be shared at that moment in that place?

Along with the point of the meeting, it also has to feel important to the people you want present. They need to know that being there matters to them. This can be surprisingly tricky: far too often people assume they need to be present when they don’t. Since there are times when, surprising as this may seem, attendance at meetings is used as a gauge of employee engagement, it’s not too much of a stretch to realize that people might be attending the meeting to avoid being seen as disloyal. You can avoid this unfortunate misperception by having a clear agenda for the meeting and making that agenda known ahead of time.

Another advantage of a clear agenda is that the purpose and time requirements for the meeting are known ahead of time. This allows your employees to better plan their schedules. A documentation review session might be held for a specific period of time, while a brainstorming session might be more open-ended. Of course, even then it’s best to not “go until you are done.” Rather, define the duration in advance and also clearly define how you’ll know when you’re done. If you find that people can’t agree on how they’ll know when they’re done, you need to resolve that before you hold your meeting!

I’m occasionally asked when is the best time to start a meeting. Early? Late? Mid-day? The answer is that the best time is the time you specified. When people know when a meeting will start, they can plan accordingly. They walk into the conference room with their brains already focused on the meeting. If you don’t start on time, you create an opening for them to become bored waiting and get sucked into their smartphones. Once that happens, it’s much harder to get their attention back than if you’d not lost it to begin with.

A great deal of Star Trek is no longer science-fiction. What are you doing to make sure that employee engagement in meetings is on that list?

Death of a Thousand Knives

As published in Corp! Magazine

Very few companies are ever driven out of business by their competitors.

I’ve found that this statement upsets a great many people, all of whom are quick to jump up and start providing examples of companies that were, in fact, driven out of business by their competitors. This is missing the point. Indeed, it’s rather like a detective in a murder mystery concluding that the cause of death was that the victim’s heart stopped. It matters whether the heart stopped due to lead poisoning, for example in the form of a bullet, or due to some other cause. Indeed, understanding exactly what led to that heart stopping moment is a key part of solving the mystery.

Similarly, while it’s not so unusual for a failing company to have the coup de grace administered by a competitor, how they got to that point makes all the difference. Focusing only on the end point provides a very simple, comfortable solution, but not necessarily a particularly useful one.

Robotic Chromosomes, for example, was a company that dominated a particular niche in the bioinformatics market. They were an early entrant into the field and their products were initially the best on the market.

Over the course of several years, though, they developed a view of their clients as idiots. The fact that their clients were all highly educated research scientists did not enter into the equation. If they had trouble using the software, they were idiots. As a result, the company became increasingly less open to feedback from either clients or the market. While their market share was increasing faster than the market itself, they could get away with that attitude. Eventually, though, their growth started lagging the growth in the market. Phrases like “law of large numbers” and “temporary aberration” were batted about. When their market share started shrinking, phrases like, “temporary aberration” became even more popular. The view of the clients as insanely stupid for buying competing products became more common.

Today, they no longer exist. Were they driven out of business by their competitors? Only in the sense that they put themselves in a position to allow their competitors to drive them out of their dominant position in the market. Sure, their competitors may have pushed them over the cliff, but they were the ones who chose to walk to the edge and lean over.

Now, it may reasonably appear from the preceding description that Robotic Chromosomes was taken down by a clearly defined event, that is, viewing clients as idiots. That is not, however, quite correct. While it may appear that way in retrospect, the reality is that Robotic Chromosomes suffered from a series of cascading errors. Each mistake was small, easily overlooked or ignored. Each mistake led to more mistakes until eventually the company was suffering from so many small cuts that it eventually had no strength left to resist when its competitors moved in. So how does a company avoid this death of a thousand knives?

The obvious answer is that they needed better communications. While true, it again misses the point. Communications is where problems show up, but the communications are rarely the problem. Rather, the dysfunctional communications are the symptom of the problem. It’s critical to look beyond the symptoms to identify the real problem. Otherwise, you spend all your time looking at the wrong things, as Robotic Chromosomes so eloquently demonstrated.

Avoiding that fate requires a willingness to accept negative feedback; it means being willing to hear what people are saying about your product, your service or your management style. If you aren’t willing to listen, or if you structure the way in which you listen to negate the feedback, you’re setting yourself up for failure, one step at a time. For example, creating a culture that mocks and demeans your clients is not a recipe for success, and closes you off from valuable feedback from those clients.

Being willing to accept feedback is only a first step though. You have to create a context in which employees are not afraid to give you that feedback, and in which they believe that providing feedback is worthwhile. If people believe they’ll be punished for being critical or regarded as “not a team player,” it’ll be hard to get them to provide feedback.

Next, you need to clearly define your goals and also define how you’ll know whether you’re succeeding or failing. Robotic Chromosomes had very fluid definitions of success, definitions that shifted regularly to avoid facing unpleasant results. It’s important to separate the evaluation of the feedback you’re getting from the testing to see if the criteria for that evaluation are valid. In fact, verifying the validity of your criteria should be done before you then evaluate your feedback: otherwise, it’s too easy to redefine success and give yourself a few more cuts. None of them seem all that bad at the time.

Step by step, over the course of several years, Robotic Chromosomes successfully created an environment where any negative feedback could be ignored because that feedback was always coming from idiots. Their competitors didn’t drive them out of business. They drove themselves out of business; their competitors simply put them out of their misery. How will you avoid the death of a thousand knives?

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 leaders grow their businesses. 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.

Of Deck Chairs and Ocean Liners

As published in The CEO Refresher

“Just give me the numbers!”

Falling firmly into the “I just can’t make this stuff up” category, the preceding statement was made by the head of a certain engineering department. He wanted the performance figures on a series of database lookups so that he could determine if the database code was performing up to specifications. This would be a perfectly reasonable request except for one minor problem: the database code was not producing the correct results in the first place. Performance was sort of irrelevant given that getting the wrong answers quickly is not necessarily all that helpful, although it may be less irritating than having to wait for the wrong answers. It’s rather like driving at 75mph when lost: you may not know where you are or where you are going, but at least you’ll get there quickly. Or something.

In another example, the engineers developing a bioinformatics data analysis package spent all their time arguing about the correct way to set up the GUI elements on each page. The problem was that when they actually ran one of the calculations, the program appeared to hang. In fact, I was assured by everyone, it just “took a long time to run.” How long? The answer was, “maybe a few weeks.”

This may come as a shock to those few people who have never used a PC, but a few weeks is generally longer than either a PC or a Mac will run before crashing. Besides, the complete lack of response from the program regularly convinced users that the program had crashed. The engineers did not want to put in some visual indicator of progress because they felt it wouldn’t look good visually. They refused to remove that calculation from the product because “someone might want to try it.” Eventually, they grudgingly agreed to warn the user that it “might take a very long time to run.”

In both of these cases, the team was solving the wrong problem. Although there were definitely complaints about the speed of the database, that was very much a secondary issue so long as the database wasn’t producing correct results. And while the user interface decisions were certainly important, designing an elegant interface for a feature that will convince the user that the product is not working is not particularly useful. At least rearranging the deck chairs on the Titanic was only a waste of time. It didn’t contribute to the ship sinking.

The element that made each of these situations noteworthy is that in both cases there were people present pointing out that the wrong problems were getting all the attention. The people making the decisions didn’t want to hear that. They wanted to solve a certain set of problems and, by golly, they were going to solve them! This is a version of the Hammer syndrome: when all you have is a hammer, everything looks like a nail. Sometimes, though, that nail turns out to be a thumbnail.

So why were these teams so insistent upon solving the wrong problems? Fundamentally, because they could. Simply put, if you give someone a problem they can solve comfortably, and one that they have no idea how to approach, they will do the former. In addition, they had never established clear metrics for success, never established standards by which they would know if the database was fast enough or the user interface was good enough. As a result, they built their goals and evaluated their performance around those issues. They were not being evaluated on whether they got the right answer, despite the opinions that the customers might have in that regard.

While clear, specific goals are certainly good things, goals also have to make sense. When a company is constantly seeing flaws in its products, it can be a very valuable exercise to look at the goals assigned to each person and each team in the company. Do those goals make sense? What problems or challenges are they addressing? Are the goals complementary, or are there significant gaps? If the engineering team is being evaluated on how many bugs they can fix and the QA team on how many new bugs they can find, what happens to the step where fixed bugs get verified? If no one is responsible for that happening, it won’t get done (and didn’t, in several software companies!). If the team focuses on the wrong problems, they’ll spend their time fighting symptoms or revisiting solved problems, and never deal with the real issues.

Therefore, even before you can set goals, you have to know what the problem is that you are trying to solve. That means first separating the symptoms of the problem from the problem itself. The symptoms are only symptoms; frequently, they can point to many possible problems. It’s important to look at the symptoms and brainstorm which problems they could be indicating. When you start developing solutions, you then need to ask what the final product will look like if you go ahead with your solution and you need to know what success looks like. Make sure that your proposed solution will actually solve at least some of the potential problems you’ve identified, and develop some way of testing to make sure you are solving the correct problem. In other words, have some checkpoints along the way so you can make sure that you’re actually improving things. Only then can you start to set goals that will effectively guide you to producing a quality product.

What are you doing to make sure that you are not rearranging deck chairs on the Titanic?

The Accidental Leader

As published in Corp! Magazine

Does this sound painfully familiar?

The team leader left the company or was transferred elsewhere. No one knows anything about the new person coming in. Everything is up in the air. It’s almost impossible to get any work done because everyone is too busy wondering what’s going to happen next. Is the team going to be kept together? Will the project be cancelled?

Or how about this situation:

You were just assigned to take over a strong team. The former leader, well-respected by the team, is leaving. When you get there, there is a marked lack of enthusiasm. Everyone smiles and nods, but the suspicion is palpable. No sooner do the first words leave your mouth when you have a sinking feeling that whatever it was you said, it was exactly the wrong thing.

Although it may seem that the difference is which side of story you happen to be on, in reality, the situations aren’t really any different at all. In both cases a once functional team is tossed into a state of chaotic uncertainty. From feeling comfortable and secure, suddenly everyone is wondering if there’s another shoe about to drop.

Oddly enough, when the new leader comes in, the situation often gets worse. Rather than allaying people’s fears, too often those fears are increased. It’s not that the new leader is trying to scare people; it’s just that whatever she says, it just doesn’t seem to come out quite right.

At one company, the new executive director was welcomed with great fanfare. Thus, she was totally unprepared when her modest proposals to improve how the company delivered products ignited a firestorm of protest and resistance. This was a very painful situation, although I was able to help them work things out in the end. Still, though, perhaps we might want to look at a more upbeat scenario.

At another company, the new president decided to try something different. When he took over, he didn’t tell people how things would be; rather, he asked them how things should be. Rather than set deadlines, he asked employees what deadline the previous, successful president would have set for their projects. Rather than set new rules, or even focus on existing rules, he asked people what sort of structure would most help them. Rather than try to Impose His Mark on the organization, he took the time to understand what mark was already there. Rather than fight the natural resistance people have to change, he invited the rest of the company into the change process. The transition ended up going remarkably well. What was even more interesting was that along the way he took a fair bit of heat from his board that he was not “acting like a leader.”

He ended up being one of the best leaders the company ever had. Despite initial beliefs to the contrary, it was no accident. By now, you might even recognize the company.

Most leaders respond to a chaotic situation by trying to impose order. This isn’t necessarily a bad idea, at least in theory. Chaotic situations are unpleasant and without some sort of structure, nothing is going to get done. Despite this, when order is imposed too rapidly, suddenly everyone is fighting for chaos.

The secret to taking over a new team, indeed, to dealing with any team or company in a chaotic situation, is to move slowly. Speed comes from being in the right place at the right time, not from rushing to get things done. When you take the time to find the most serious pain points, the places where people are most scared or most upset, and you resolve those situations, you build the trust you need to succeed.

How do you find those points? Ask the team. Involve them in the process. Don’t impose order; rather, create order.

Are people concerned about deadlines and how changes in product schedules might impact them? Invite them to help set the deadlines. Is product quality an issue? At one training company, the fear was that the changes would compromise the quality of the training being offered, which would, in turn, drive away clients. The solution was to stop fighting about it and instead identify the metrics currently being used to determine quality: both the official ones and the ones that staff members used privately. Once those metrics were brought to everyone’s attention, then the new CEO could help the staff members see how the new training would actually surpass the old training. Sounds simple, but the experience was anything but!

You impose order when you walk into the situation and tell everyone what to do. You create order when you find points of maximum leverage and invite people to suggest the order they want you to provide. The second may be slower, but, paradoxically, it gets you to where you want to go a lot sooner. How will you create order in your organization?

The Blofeld School of Management

As published by the American Management Association

Fans of James Bond movies might recall a scene that goes something like this:

We are looking at an unidentified room. Two people we’ve never seen before are standing in front of a desk. We might be able to see the back of the head of the man who sits behind that desk. A voice rings out:

“You have failed SPECTRE. Number 3, why did you not kill 007 as ordered?”

Number 3 stammers out some response and the voice turns its attention on the other person.

“Number 5, you have also failed SPECTRE…”

Eventually, Number 3 is told everything is forgiven and he can leave. Of course, this is SPECTRE. As soon as he walks out of the room he’s dropped into a tank of piranhas, or the bottom of the elevator turns out to be a trap door and Number 3 learns that Maxwell Elevators really are good to the last drop, or he dies in some other Rube Goldbergesque manner.

SPECTRE, as all Bond fans know, is the villainous organization headed by Ernst Stavro Blofeld, the evil genius who spends most of his time trying unsuccessfully to kill 007. Of course, given his track record, as evil geniuses go, he frequently seems more like Wile E. Coyote.

Blofeld’s problem, of course, is that every time one of his agents makes a mistake that agent dies. Those whom James Bond doesn’t kill are terminated by Blofeld himself. This makes it extremely difficult to conduct any form of on-the-job learning. When every mistake is fatal, the lessons tend to come a little too late to do much good. As learning organizations go, SPECTRE has issues.

Although the consequences are generally not so flashy, businesses do face some similar problems. Granted, most business mistakes don’t make for a good action movie, and dropping people in piranha tanks is generally frowned upon. However, there is still the very real problem of figuring out how to enable people to learn from their mistakes without those mistakes harming the business. James Bond, after all, at least gets a script.

Part of the challenge is that even when leaders are well-trained and highly skilled, there is a big difference between what one learns in most management training classes and the actual experience of leading a team, department, division, or company. That doesn’t mean that the training is useless, but it does mean that the training needs to be appropriate.

In sports, for example, athletes drill constantly: they practice the fundamental skills of their sport until they can execute those skills without thought. Doing that, however, is not enough to make an athlete a successful competitor. Such training is necessary, but it’s not sufficient.

As a soccer-playing friend once commented to me, there’s a big difference between the drill and the game. The drill is controlled and predictable; the game is not. The game is confusing and chaotic, and in the moment of truth all those carefully drilled skills simply vanish away. The problem is that chaos is overwhelming: it takes getting used to in order to navigate it. The Japanese term, “randori,” used to describe Judo competition, means “seizing chaos.”

Athletes practice getting used to chaos by moving past drills and practicing in various free play scenarios: mock games, spring training, practice games, randori, etc. These experiences enable the athlete to experience the chaos in small doses and hence become increasingly comfortable with it. They learn which skills to execute when. The day of the actual tournament, they are ready. When they do make mistakes, they also have something fall back on to improve their skills, as opposed to something to fall into and get eaten.

Business leaders can produce much the same results through the use of predictive scenarios. A predictive scenario is a live-action serious game focused around leadership and negotiation. Like all serious games, it both educates and entertains. Because it is live-action, rather than a computer game, leaders are forced to interact with other people as they would in daily life. Because the game is complex and competitive, participants engage with the game: there is no one right answer. Rather, the situation is chaotic and ambiguous; it’s not possible to predict an optimal solution or a perfect move. Participants are forced to constantly revise and adjust their strategies in order to counter what other players are doing.

Thus, a predictive scenario becomes a powerful practice environment for leaders who want to improve their skills and the skills of their subordinates without risking the financial health of the business. As with athletic training, a mistake is an opportunity to develop new skills or improve existing ones. Surprise outcomes will often indicate someone whose potential is not being developed or recognized: an employee may turn out to be a unexpectedly skilled speaker, be remarkably talented at inspiring and motivating others, display unexpected gifts as a salesman, or reveal themselves to be a masterful problem solver. If that’s not the job they already do, you’ve just been alerted to talent being wasted!

After the game, participants can analyze the action much as an athlete would analyze her performance with her coach. This analysis helps the participant recognize whether problems that arose were the result of a lack of skill or a failure to correctly apply a skill. In either case, you know what to do. There’s no need to guess, no expensive consequences, and no need for piranha tanks.

One of the other advantages of a predictive scenario is that the setting need not be restricted to a pale imitation of the office. Rather, it can be anything imaginable, provided that it forces participants to act as leaders, negotiate with one another, work together, come into conflict, and so forth. You could even be James Bond… or see just how well Mr. Bond would actually do against a Blofeld who knew what he was doing.

Storming the Black Gate

Near the end of the award winning movie, Lord of the Rings: The Return of the King, Aragon leads his pitifully small army to the Black Gate of Mordor, realm of Sauron the Dark Lord. Sauron’s forces outnumber Aragorn’s by easily a hundred to one. On the surface, there appears to be little chance of success. Indeed, during the planning of the assault, Gimli utters the famous line: “Certainty of death, small chance of success… What are we waiting for?”

As those familiar with the story know, the attack is diversion. Its goal is to draw the attention of Sauron so that Frodo can destroy the Ring of Power. Aragorn, however, cannot let on that the attack is anything but an all-out assault on Sauron’s fortress. To fool Sauron, indeed, even to convince his soldiers to follow him, he must act and speak as though he has complete confidence that his badly outnumbered army can win. Aragon must not just be confident, he must be so confident that people will be inspired to follow him to almost certain death. That act of confidence is what makes it possible for Frodo to succeed and for Sauron to be defeated.

Read the rest in the Journal of Corporate Recruiting Leadership

Smell Test

As published in Corp! Magazine

The door opens onto a room filled with equipment: banks of computers, spectrometers, air and tissue samplers and things that you cannot even recognize. The hum of electronics fills the room and there is a definite odor of fish. As you look around, you can see dozens of fish waiting to be analyzed for oil contamination. The purpose of all this machinery is to determine if seafood is safe to eat after the Gulf oil spill.

Sounds like something out of a science-fiction movie. That’s because it is something out of a movie: reality is not nearly so visually impressive. It turns out that the most sophisticated instrument for determining the safety of seafood is the trained human nose. With remarkably little training, the human nose can do something that all the expensive and elaborate electronic equipment cannot do: figure out whether a fish is contaminated or not.

About 20 years ago, a Japanese business decided to conduct a thorough chemical analysis of fine wine. They used sophisticated equipment and complex computer analysis to determine the chemical composition of the perfect bottle of wine. They then produced a wine that perfectly matched their profile.

In the ensuing blind test, tasters had no trouble recognizing the Japanese wine: it was universally described as “having the taste of dishwater and a bouquet of dirt.”

Once again the human nose proved superior to all the fancy equipment that was brought to bear on the question.

When speaking to a group of managers, I asked them to describe their company’s goals. The response was a rather confusing medley of Gantt Charts, Microsoft Project, comments on the latest decision support software and so forth. What was their approach to management? Once again, the same cacophonous medley ensued.

Fish, wine and management have a couple of things in common.

First and foremost, all those fancy tools and gadgets are tools, nothing more. There is nothing inherently special about them, any more than there is anything inherently special about a hammer. In the hands of a master craftsman, a hammer can be a very useful and versatile tool; in the hands of someone without that skill, a hammer is little more than a device for making sure that every problem looks like a nail.

By the same token, the value of management support software, or whatever other power tools are being used, is only as great as the skill of the manager using it. Tools leverage skill; if there is no skill, there is no leverage. There is also a strong possibility of cutting yourself off at the knees: power tools can be dangerous. In other words, all the management support tools in the world won’t help someone who doesn’t know how to manage. More to the point, just as a trained human nose is the best tool for detecting contaminated fish, the best leaders and managers are those who have actually learned how to lead and manage.

From a very practical perspective, the best leaders are those who can connect with their followers. It’s not about Gantt charts or other fancy tools. It’s about building trust and enabling people to feel that they can count on you.

Wait, isn’t that backwards? Doesn’t the leader need to be able to count on his followers? Sure. And the way you get there is by demonstrating that they can count on you, that they can trust you.

In a sadly familiar tale, at Soak Systems, no trust exists between different departments, between marketing and engineering, between engineering and the CEO. Why is there a lack of trust? The CEO constantly visits clients and makes promises that engineering can’t possibly fulfill. Even worse, he regularly changes direction and priorities: one day project X is vital to the future of the company, even when it fails to ship on time or when it ships and doesn’t work. The next day, it’s project Y. Each prediction of impending doom is followed by another prediction of impending doom if the project doesn’t work.

At this point, no one believes the CEO. No matter how important or unimportant his pronouncements, they are all greeted with the same level of skepticism. All his charts and graphs are failing to convince anyone. Is it possible for the CEO to reverse the trend and actually build credibility? Sure! The easiest way is for his prediction of doom to come true just once. Granted, that’s not particularly useful, but it is the easiest approach.

A more difficult approach is to put aside all the shiny tools and actually pay attention to the people. If he is willing to learn how to build trust and establish connection with his followers, then there’s a good chance he can turn things around. But he has to be willing to learn instead of being distracted by all the pretty toys.

I said earlier that there are two things that wine, fish and management have in common. We’ve discussed one. The other is pretty simple.

They all stink when they’re bad.

When the Fat Tuesday Sings

As published in the CEO Refresher