The Business Sensei

Future Retrospective

Once upon a time there was a staircase. Although it wound its way up from floor to floor in the manner traditionally associated with staircases, this was no ordinary staircase. Although it stood in a courthouse in Franklin, Ohio, in a fashion much like other staircases, yet it was not like the other staircases. With most staircases, those who look down see stairs beneath their feet. With this staircase, however, those who looked down saw the floor below and those people walking up the stairs. They saw those who stood at the bottom of the staircase, for this staircase, you see, was made of clear glass. While we have no information as to whether those climbing the staircase felt a sense of vertigo when they looked down, we do have definitive information about what they said when they looked down: “Hey, those people at the bottom of the stairs are staring up my dress.”

Although the news report was slightly vague on this point, we may safely assume that this comment was made only by those who were, in fact, wearing a dress.

But yes, it seems that people on the staircase made an observation that had eluded the architects who designed the staircase: that if you can look down through the glass, you can look up through it as well.

When questioned on this point, the architects responded by saying that they had naturally assumed that no one would be so inappropriate as to stand at the bottom of a glass staircase in a courthouse and look up women’s dresses.

When this insightful observation was relayed to the judge, he replied that, “If people always exercised good judgment and decorum, we wouldn’t need this building.”

The architects had carefully considered their building material. They had thought about how to make the glass durable and resilient. They had considered the problems involved in building a glass staircase in such a way that it would continue to look good even after having hundreds of people walking up and down it each day. They had, in fact, solved each one of these problems.

What they had not considered was how the customer, to wit, the people in the courthouse, would actually use the product. They were so fixated on the concept that a staircase is for walking on, not staring through, that they failed to consider the ramifications of their architectural decisions. To be fair, architects are hardly unique in making this type of mistake. It can be very easy to let your assumptions about how something should work or how it will be used to blind you to how it will actually work or be used. Consider the example of the business school competition to design a helicopter. The contest was judged on a number of factors, including the weight of the finished product. The winner was the helicopter without an engine. Apparently, no one had included “able to fly” in the criteria for success. The assumption that, of course, a helicopter should fly was so taken for granted that no one thought to see if it was included in the rules.

On the bright side, it had considerably less severe consequences than the situation involving the helicopter that flipped upside down while in flight. Or the data analysis software package that looked like it had crashed the computer, causing users to reboot shortly before the calculations were complete. Or the organizational improvements that led to a massive talent exodus.

In each situation, the people designing the end result honestly believed they were giving the customers, including the employees in the final case, what the customers had requested and that belief prevented them from considering any other possibilities.

“We asked!” the designers protested. “That’s what they said they wanted.”

Were the customers really asking for a helicopter that flipped upside down or an expensive glass staircase that had to be subsequently covered? Of course not. But somehow, that’s what the designers heard.

The problem was that they asked the wrong questions, further leading them into their one, narrow, view of the result. Thus, no one ever stopped to imagine how the end product, be it staircase, contest rules, helicopter, software, or organizational procedures would actually be used.

In each situation, rather than seeking information, the people asking the questions sought validation. They already had an idea in their heads, and any inquiries they made were aimed at confirming that idea, not testing it.

When you say, “This is what you wanted, right?” or “What do you think of this approach?” odds are you aren’t requesting information; you are requesting validation. Indeed, even if you are seriously trying to get information, such questions usually get you validation instead. This is because the client assumes that you, as the expert, know what you’re talking about.

So how do you ask for information? One answer is to change the time frame. Instead of asking them to imagine the future, pretend it’s the future and imagine the past: “If we went with this approach, and six months from now you weren’t happy, what would have gone wrong? If you were happy, what would have gone right?”

This small change causes people to actually imagine using the product or living with the new procedures. Now, instead of validation, you’ll get information. That information may shake up your carefully constructed vision of the future, but that’s fine. Better now than after the sightseers congregate at the bottom of that glass staircase. A future retrospective also forces you to more honest with yourself and address the issues in front of you.

What challenges are you facing? If, six months from now, you had successfully addressed your most persistent problems, what would you have done to make that happen?

Take Two Aspirin

As we all know, when we have a cough, the best thing to do is to visit a Cough Doctor. When we have a fever, we visit a Fever Doctor. Also, when our car is making a funny knocking noise in the key of C, we take the car to a mechanic who specializes in funny knocking noises in the key of C. Or maybe we just hope the problem will go away because the only mechanics we know deal with knocking noises in the key of B.

Okay, so maybe this is a bit of an exaggeration. We don’t actually look for Cough Doctors or Fever Doctors and I very much doubt that anyone outside Car Talk would ask if the knocking noise is in the key of C. When we go to the doctor because of a cough or a fever, we go because the doctor understands, or can figure out, why we have that cough or fever. When we take the car to the mechanic because of that weird knocking noise, it’s because we’re hoping that the mechanic can figure out why that noise is happening and what it means. We go to the doctor or the mechanic because of our symptoms, but we don’t go to Symptom Doctors. To be fair, Symptom Doctors are great when all we have is a cold: take two aspirin and call me in the morning.

The fact is, treating symptoms can make us feel a lot better. Having a fever isn’t much fun, and a couple of aspirin can work wonders. Of course, if that fever is because we have the flu, then maybe suppressing it isn’t the best thing to do. That knocking noise from the left rear wheel can be easily tuned out by simply playing the radio loudly enough. Then we don’t have to worry about it until the wheel comes off. Hopefully, this happens while we’re at the gas station and not when we’re traveling at 65 mph on the freeway. Treating symptoms doesn’t make the underlying cause go away, it just lets us feel good. Therein lies the problem.

The symptoms we see are only that: the symptoms. That cough and fever might be a mild cold or it might be the flu. That knocking noise might be nothing or it might be a wheel getting ready to declare its independence from the collective body that is your car. When it comes to fevers and coughs, we can usually tell what’s going on and most of the time the consequences of being wrong are only inconvenient or a bit uncomfortable. With cars, most of us are not quite so good at figuring out what the noise means, while a trained mechanic can do it in minutes or seconds. Not only do they know what it means, they also know the cause, and which parts of the car are affected. The symptoms enable them to identify the problem, and by treating the problem, they also make the symptoms go away. The converse, as we’ve discussed, is not true.

So why would anyone call a Symptom Doctor? Well, just treating the symptoms makes us feel like we’re accomplishing something. We feel better for a brief time. Most important of all, we feel successful. When the symptoms return, we just want them to go away again and we want to feel successful again. So we call the Symptom Doctor back and once again the symptoms go away for a brief period.

In one situation, a certain engineering manager had a team that was always argumentative to the point of being unable to reach agreement on anything. After carefully observing the situation, he decided the problem was that Joe disagreed with everyone too much. Joe had a “difficult personality” and hence was the cause of team’s problems. He fired Joe. Lo and behold, everyone stopped arguing. The manager was very proud of himself for solving the problem. Four months later, a different member of the team had revealed herself to have a “difficult personality.” That’s right, the arguments and lack of agreement had returned in force. Firing Joe hadn’t solved anything; it had simply made the symptoms disappear for a short time. When they reappeared, they were worse than before.

Now, in this particular example, the manager was his own Symptom Doctor. Symptom Doctors can also be brought in from outside: companies hire “Decision Consultants,” or “Consultants For Leaders Who Don’t Listen,” or “Consultants For Leaders Who Listen Too Much,” or “Consultants For Leaders Who Listen With Their Head Cocked At A Funny Angle.” Okay, maybe the last one is a joke. The results of going to a Symptom Doctor, however, are rarely a joke. They are wasted time, wasted energy, and lost resources.

So what do you do instead? Like going to the doctor or the mechanic, you need someone who can understand what is going on. Not a Symptom Doctor, but someone who either knows, or can figure out, what the symptoms mean. It may not be as cheap or as easy as going to a Symptom Doctor, but, unlike the Symptom Doctor, it just might solve your problem.

Don’t Lose Your Marbles!

Not long ago, I had the opportunity to observe participants in an estimation contest. Participants were given a problem along the lines of figuring out how many marbles are in a jar or balls in a pit. Participants then had to come up with an approximate answer based on the information that they could glean from the scenario: for example, they might be able to at least approximately measure the size of the marbles.

I was particularly impressed by one of the groups: they were very analytical. They discussed the problem in very reasoned terms. They only included very few people in their discussion. They came up with a very well-written, very logically developed answer. They were very wrong. While all the other answers clustered around the correct response, this one group had an answer that was so far out in left field that it was in some other stadium.

This, of course, is the challenge in estimation games: it’s easy to make very simple mistakes early on and then run merrily off along a completely wrong, but apparently logical, trail. In estimation games this is pretty much harmless. However, in more general areas of problem solving the same errors that can derail an estimate can also lead to much more significant problems. This isn’t necessarily all that surprising in that real-world problems are much more similar to estimation games than we might like to acknowledge: they often require us to make assumptions, act with incomplete information, make deductions about facts we cannot easily observe, and come up with a best guess at the end. Fortunately, there are some lessons we can draw from estimation games that will improve real-world problem solving, particularly when people are involved. Consider, for instance, any scenario in which you need to work with other people or cooperate with another organization and where your goals are not necessarily in complete alignment.

It’s easy, as the left-field group did, to limit participation in the discussion. In fact, this is often necessary, as too big a group can easily become unmanageable and prevent any productive discussion from taking place. However, keeping the size of the group small does not mean keeping the knowledge base available to the group equally small. Group members need to track their assumptions and the conclusions based on those assumptions. They then need to go out and verify as many of their assumptions as they can: it’s easy to find evidence to support your conclusions; the hard part is looking for evidence that will contradict them. The second is what needs to happen. Identify what information would tell you if you’re making a mistake, and then figure out to identify that information. Speculate. Play “what if?” games.

Of course, it’s also important to remember that marbles in a jar have no motivation (outside of a bad joke about method acting). Situations dealing with people have considerably more moving parts.

An important part of “people estimation” is understanding motive. When dealing with human systems, being able to think about what other people are doing and why they might be doing it is critical. Peter Ossorio, of descriptive psychology fame, makes the argument that in any given situation people will try to make the most advantageous move they can. This doesn’t mean that they’ll always get it right or that they’ll always execute even a right action correctly or effectively. However, it does mean that it can be very productive to consider how other people might view a problem or situation and consider what their likely course of action might be. Consider as well why they might doing what they are doing.

Their reasons might not be obvious, they might not be comfortable for you to think about, and they may contradict some of your basic assumptions, but those reasons exist. Figuring out what they are goes a long way to enabling you to make a better “estimate” and take actions that are more likely to get you to a result that you like. To be fair, maybe the other people involved are stupid or evil; I’ve certainly heard this given as an excuse for not considering their perspective. Ultimately, what difference does it make? They will still take actions, and your success may well depend on your ability to anticipate and work with or around those actions. Approaches which shut down speculation and exploration are most likely going to do nothing more than decrease the accuracy of your estimate.

When dealing with marbles in a jar, being in left field just means that you’ve failed to win a prize. When dealing with people problems, being in left field might just mean that you’ve lost something considerably more valuable. In this case, maybe it’s not so bad if you’ve only lost your marbles.

Caught By The Chrome

Anyone remember the power failure during the 2012 Superbowl? Probably not, for all that it lasted for a whopping 35 minutes, or, as comedian Stephen Colbert put it, “only two months short of New Orleans’ personal best.”

The funny thing about the power failure, however, was not Stephen Colbert making jokes about it, but how a number of people blamed the failure on Beyonce. Did Beyonce have anything to do with it? Well, Beyonce was playing at the time, but that’s about the only connection. I know that a lot people think she’s pretty impressive, but knocking out the power to the Superbowl? Even for Beyonce, that’s a bit much. Nonetheless, the fact that the two events were coincident in time meant that, for many people, there must have been a connection.

This is called getting caught by the chrome: rather than focusing on the actual problem in front of us, such as a power failure, our attention is caught by something peripheral. Sometimes, if we get lucky, that bit of chrome might also turn out to be a symptom of the problem, but not always.

Basically, a problem is composed of three elements: the problem itself, the symptoms, and the chrome. Most of the time, we can’t actually see the problem. What we can see are the symptoms and the chrome. The symptoms are useful: they can lead us to the problem. When you go to the doctor and the doctor asks questions about how you are feeling, she is exploring your symptoms. Knowing your symptoms helps her identify what is wrong with you, or at least sound authoritative when she tells you to take two aspirin and call the advice nurse in the morning.

The chrome is the shiny stuff that’s nice to look at: the things that are easy to see and, because it’s easy to see, also easy to mistake for a symptom or the actual problem. Sometimes we also mistake the symptoms for the actual problem, essentially treating the symptoms as chrome instead of as clues to what is actually wrong.

Now, at least for those watching on TV, whether Beyonce was problem, symptom, or chrome, was probably pretty much irrelevant. But for those actually tasked with dealing with the problem, figuring out the difference is considerably more important.

Let’s consider the case of Tim, newly appointed CEO of big data company Hornblower Software. Hornblower is considered a rising star in the big data space, yet when Tim came in, the company hadn’t produced a product in over a year. The reasons for this varied, freely mixing chrome and symptoms. Was it the engineer who was incompetent and insubordinate, doing whatever he wanted and doing it all badly? Was it the engineer who was competent, but completely unwilling to take direction, making changes as he thought fit? Was it the several engineers who did enough to get by but who weren’t willing to make major efforts on the part of the team? The first guy quit shortly after Tim came in, producing a belief that the problems would all go with him.

There is a cliched scene in countless murder mysteries in which our hero is suspected of the murder and arrested. Another murder then occurs while he’s sitting in jail, forcing the police to grudgingly conclude that maybe he really isn’t guilty. The problems at Hornblower didn’t go away when the first guy quit, suggesting pretty strongly that he was at best a symptom of the larger problem, at worst nothing more than chrome. Well, in that case the problem must the other guy, the one would wouldn’t take direction! After all, as the VP of Engineering put it, “I can’t tell him what to do.”

We can certainly agree that if you have an employee who refuses to take any direction that is A problem, whether or not it is THE problem. In this case, it was also a distraction from the real problem.

The trick to solving the real problem is first to identify the real problem. To do that, you have to get away from the chrome and focus on the symptoms. There were many: the lack of products, rogue engineers, infighting, dispirited team members, to list just the major ones. When did they start? Where did they occur? Were there any common elements? When we take the time to examine the symptoms and identify the boundaries of their occurrence, then we can start to understand the real problem. In this case, the common element was the VP of Engineering, who, it turned out, was either intimidating or ineffectual: those who found him intimidating exhibited low motivation, while those who realized that he was a paper tiger simply ignored him. And while he might have been quite competent technically, he wasn’t capable of communicating with other team members, organizing them, or focusing their efforts. The net result was an ineffective engineering organization.

The only real question left at this point is whether Tim will be able to see past the chrome fast enough to make a difference.

Controlling the Little Things

One of the more painful experiences I had in jujitsu was when my instructor taught finger holds. We assume that because our legs are generally quite strong, it would be difficult for someone to force us to go somewhere we don’t want to go. That assumption lasted as long as it took my instructor to apply a finger hold. All he had to do was take control of the smallest joint of one finger and suddenly my legs would go exactly where he wanted them to go. By manipulating one little thing, he could convince people much larger and stronger than he was to become extremely cooperative. Controlling one small joint gave him control over their entire body, however controlling the body did not produce the same control over the arms and legs: the hands and feet still moved freely, and would regularly engage in what may be politely referred to as “nose seeking behavior.”

Now, you might be thinking, “Well, so what? That’s just leverage!”

Well, yes, it is leverage. And if that was the whole point, the correct reaction would indeed be “so what?”

Leverage, as we all know, enables us to move something large through control of something small. Jujitsu is merely a fairly straight-forward application of this principle. However, the principle is not limited to the physical. Our perception of control is determined not by the big things in life that we control, but by the little things. To put this another way, if we want people to tackle big, challenging projects, we have to convince them that they have at least some control over the outcome; they have to believe that their actions matter and have a reasonably good chance of producing positive results. Conversely, when we don’t have control over little things, we tend to assume that we can’t control the bigger things. Even worse, that feeling of not having control translates into a loss of initiative and creativity. Leverage cuts both ways.

In any organization, those stressors that decrease our sense of control are thus the most damaging. Organizational politics are one obvious example, but at a more direct level, the less control employees have over their immediate environment, the less initiative they take overall. Being able to, within reason, decorate your office or cubicle creates a sense of control. Conversely, when companies have elaborate rules that unduly limit personal expression, control is seriously decreased. Without that sense of control, employees become more like the person whose finger is being twisted rather than like the person doing the twisting: they might be compliant, but they are not enthusiastic or committed.

An article in the NY Times discussed how Google addresses exactly this issue. Google doesn’t just allow employees to decorate their work area; employees get to design their work area. Google provides them with the equivalent of high tech tinker toys that employees can use to build the work area they want. Feel like having a treadmill? No problem. Walking desk? Sure. The article pointed out that Google doesn’t even have an official policy about coming in to the office; rather, the assumption is that the employee will work out a reasonable schedule with her team. This is control in action: employees are given control over their environment, even whether to come to the office to work. This control, coupled with making the office an very enjoyable place to work, leads to employees who exercise their control to work longer and harder than anyone could ever force them to work. Indeed, one of the problems Google has is that sometimes they have to chase people out of the office! What would you do to have problems like that?

When we have to force someone to do something, either through threats or through lavish rewards, they don’t get a sense of control or commitment. They are being controlled, but they are not in control. Now, if all we want is compliance, maybe that’s just fine! Indeed, if the task is easy, that may even be sufficient. However, if we want a committed, enthusiastic work force that believes themselves capable of tackling big projects and overcoming apparently overwhelming obstacles, the secret to getting there is to give them control of the little things.

When Goals Take Over

“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 most computers will run before crashing (or installing an update without warning). 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, speed 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.

So why were these teams so insistent upon solving the wrong problems? 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. At that point, once goals are set, they become the focus of everyone’s attention and a lot of work goes into accomplishing them. That is, after all, the best thing about goals; unfortunately, it can also be the worst thing about goals.

While clear, specific goals are certainly good things, goals also have to make sense. You need to have the right goals. 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 possible 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 the results you actually need.

Once goals are set, they have a way of taking over. What are you doing to make sure you don’t set goals before you know where you’re going?

Solving Yesterday’s Problems

Once upon a time there was an employee working on a knotty biotech problem. Weeks, then months, passed with no results. The employee’s manager decided that the employee clearly wasn’t working hard enough, fired him, and hired someone else.

Weeks, then months, passed with no results. The second person was also clearly not working hard enough and was swiftly replaced.

The next two people didn’t work hard enough either.

The fifth person got lucky: someone in a different lab was working on a similar problem and figured out that the process was fatally flawed. No one had noticed. Everyone, especially the manager, assumed that it must be correct. The manager, in particular, was unwilling to even consider the possibility that the problem could be the process, not the people, until it was shoved in his face.

In a slightly different example, I was conducting a leadership and negotiation exercise with a group of would-be managers. As part of the exercise, they were each given various items and told to obtain various other items. Naturally, everyone started trading back and forth. Some items, though, simply could not be found. As a result, the people who needed those missing items started hording the items they did have: they wanted to make sure they had leverage to get other people to give them the items they needed.

At the end, there were a number of very frustrated people complaining that the exercise was unfair because items were missing.

“I needed an apple, and there were no apples,” complained one irritated individual.

When I asked him why he hadn’t just gone down to the cafeteria and bought an apple, he just stared at me.

One woman complained that no one in the room had willow leaves. I asked why she didn’t just walk outside and pick some off the tree.

Again the stare.

Because each person was visibly presented with a bag of items, everyone immediately jumped to the assumption that all the items were present and that they could be obtained through trade. Even when that failed to work for everyone, no one questioned the basic assumption. Instead, those who couldn’t find what they needed assumed that people were withholding items and responded by withholding their items. Instead of engaging in brainstorming or problem solving, they just glared at each other. Unlike the biotech manager, the option of firing one person and hiring another was not available. This was probably fortunate under the circumstances.

In both the lab and the exercise, the people involved had become so focused on the results that they weren’t thinking about how they were trying to accomplish those results. Indeed, the process had somehow achieved the status of holy writ, to the point that no one even thought of questioning it.

Results are important, make no mistake about that. However, it’s equally important to think strategically about how to accomplish those results. By mindlessly assuming that only one path exists or one way of working exists, the different groups trapped themselves in failure.

The more difficult the problem being solved, the more important it becomes to pay attention to the process. Assuming that there is only one process or blindly believing that everyone has to fit a certain image or work a certain way reduces the likelihood of success and can even lead to the results not being accepted. The lab manager could have made something of a name for himself if he’d been the one to publish the identification of the flawed process! The groups looking for the items could have all succeeded if they’d stopped to revisit their assumptions and seek out alternate means of accomplishing their goals.

If you’re trying to solve yesterday’s problems, then ignoring the process is frequently a great way to go about it. By the same token, it would be very easy to win the lottery if you could only buy based on yesterday’s paper. Unfortunately, the first option is actually available in business.

The more complex the problem, therefore, the more important it becomes to stop and look at what you’re trying to accomplish, how you’re trying to do it, and why you’ve chosen to do it that way. If you want to think strategically, it helps considerably if you don’t limit yourself to preconceived notions about how the problems must be solved. The more hidden assumptions you can overturn, the more likely you are to accomplish your goals.

That Was Obvious!

The solution always seems so obvious once Holmes explains it.

I’ve been reading the Sherlock Holmes stories to my son. Even though I read the stories years ago, I find that I can rarely remember the endings. As a result, I’m puzzling them through along with my son. While it’s certainly true that sometimes Holmes is taking advantage of information not available to the reader, such as his encyclopedic knowledge of mud or cigar ash, quite often the clues are present. Even when Holmes doesn’t clue us in until the end exactly what about the cigar ash was important, we do get to see that he was interested in it. Quite often, that should be all a reader needs, except, of course for the fact that it isn’t.

At the end, Holmes finally reveals how he solved the mystery. Watson expresses his astonishment, Holmes shrugs and, despite belief to the contrary, usually does not say, “Elementary, my dear Watson.”

Whether or not Holmes says it, what he is doing is not elementary. Putting together the apparently unrelated clues to assemble a picture of how the crime was committed is a very difficult skill: consider how many readers are unsuccessful! Yet once we know the answer, it is equally difficult to imagine the pieces fitting together any other way. Harder to imagine is putting the pieces together to anticipate the murder before it has even happened! I suspect that Holmes himself would have trouble with that: indeed, in the stories where he had to do just that, he was rarely able to do it fast enough to prevent the crime from occurring. The reader, of course, is even more in the dark than Holmes: even knowing that he’s solved the case from the information presented, we still can’t figure it out.

When reading Sherlock Holmes, the resultant feelings of frustration, amazement, admiration, and feeling like an idiot for missing the obvious clues, are all part of the enjoyment of the story. In a business setting, however, it’s not enjoyable at all.

I can’t count the number of times I’ve heard statements like:

“I can’t believe he made a mistake like that. He should have seen it coming!”

“If Fred was as good as he claims he is, he would have anticipated that.”

“I can’t believe she was taking the project seriously!”

I could go on, but you get the idea. When someone makes a mistake, we often confuse hindsight with foresight: while hindsight might be 20-20, foresight is not. In fact, in a great many cases it’s more like 20-2000. But, because things are so obvious in hindsight, the tendency is to assume the person who made the mistake must have been careless, or foolish, or goofing off, rather than making the best decision they could with the information they had at the time. Perhaps there was some way of looking at the information that would have suggested the problem was in the offing, but, like in a Sherlock Holmes story, putting together the disparate pieces of data in just the right way in the time available is no trivial task.

Conversely, there are times when people do correctly recognize the clues that suggest a serious problem is in the offing. At one technology company, several engineers saw the clues and put in the time necessary to analyze them and avert the impending disaster. Their thanks was being yelled at for wasting time: the problem was clearly obvious, even though no one else had seen it, and they had clearly not been working very hard if it took them “that long” to figure it out.

Lest this be viewed as a problem unique to the tech industry, I had a similar experience running a management training predictive scenario game. At the end of the exercise, one of the participants told me in no uncertain terms how the outcome of the game was clearly predetermined. He explained in great detail how the different factors in the exercise could play out only the one way, and that this was basically unfair. I gently broke the news to him that I’d run that particular exercise over a dozen times, with wildly different outcomes.

“Impossible!” he said, and stormed off.

Mixing hindsight and foresight isn’t such a good thing, but is it really anything more than what amounts to an annoyance? In fact, yes. When we fall victim to the 20-20 foresight in hindsight trap, and disparage people for not spotting the “obvious” problem, what we really are doing is telling them they are incompetent. Done often enough, they might start to believe it, reducing performance, motivation, and innovation in the company. When someone does successfully anticipate a problem and we dismiss that accomplishment, we are implicitly telling them not to bother doing that again! The results of that should be obvious.

Neither of those points, though, are the most serious problem: when we convince ourselves that problems are always obvious, we don’t spend as much effort trying to anticipate them. If it’s not obvious, it must not be there. It’s sort of like saying that if you close your eyes when crossing the street, there won’t be any cars.

That is a good way to get blindsided by some very big problems indeed.

Bring Me The Head Of Shinseki The General

When I was a kid, I used to watch a lot of old WWII movies and B-grade science fiction on TV. There wasn’t a whole lot of difference between them. The WWII movies involved airplanes or submarines, while the science fiction involved space ships. Beyond that, the plot lines were remarkably similar. The bad guys always appeared absolutely overwhelming and were led by a seriously tough, supremely competent general who terrified everyone. He, and it was almost always he, would usually be introduced in scene that involved him killing off one of his subordinates for failing at something or another. The good guys always were slightly disorganized and Our Hero started the show in deep trouble: he was either being dressed down for some major screwup or the major screwup occurred early in the show. But, because these were the Good Guys, he would be given another chance. Naturally, because this was the nature of that type of movie, Our Hero would then turn out to be the one person who could save the day. It was very clear, even then, that if the good guys killed people off for failing, they would have been defeated. Indeed, this was the major difference between the good guys and the bad guys in a lot of those movies, a point emphasized in some movies where it would also be revealed that Our Hero’s earlier screwup was due to attempts by the bad guys to discredit him. Meanwhile, assuming he survived to this point, the bad guy general would kill himself or be killed for his failure.

The fact is, when a team fails it’s not uncommon to kill off the leader, albeit these days the death is more likely to be symbolic. As news of the problems at the Veteran’s Administration surfaced, General Eric Shinseki ended up resigning his post as head of the VA. Now that he’s gone, naturally all the problems at the VA will immediately disappear.

Well, maybe not.

Killing off the leader can be a very satisfying move, and certainly has a sense of poetic justice to it. Certainly, when the screwup is large enough, it’s more satisfying than killing off some junior flunky. However, as a means of producing effective organizational change it is not necessarily going to be all that effective; indeed, you just may be getting rid of someone you’ve spent a long time training. Instead, it helps to stop and look at the organizational system and understand the forces at play and what is actually taking place. Organizational systems can be very complex and unexpected interactions or badly constructed goals can have serious unintended consequences independent of any particular leader.

For example, at one time Sears Automotive famously gave all of its car mechanics a goal of generating some $200 dollars an hour of billable revenue. The problem, of course, is that they had no control over how many people came to them for auto service nor did they have any control over the particular problems those drivers were having. But the goal focused only on the result: a specific number. Failing to make that number meant failing to remain employed. As a result, the goal became all-consuming: mechanics focused on it to the exclusion of all else. Not surprisingly, they found a way to make their numbers: they invented problems out of thin air. This worked very well until Sears was caught. The wrong short-term goal can blind people to longer term consequences. Changing leaders only helps if the goals are changed as well.

In another situation, IBM in the early 1990s decided that it needed to do a better job of getting technology out of its scientific centers and to the market. They decided that the engineers in the scientific centers needed a stronger incentive. The incentive some senior VP came up with was to tie the performance evaluations of the engineers to how well their products did in the market. This produced a couple of significant problems:

First, the engineers had no control over the sales force. Salesmen had their own numbers to make, and tended to push only those products that they were most comfortable with. They had no particular desire to risk their bonuses! The net result was that it was pretty random which products were being actively marketed and which were not. This, as one might imagine, did not exactly thrill the engineers. The problem was further aggravated by the fact that the sales people were often in a different geographic location from the engineers.

Second, instead of collaborating and cooperating, engineers on different projects now had an incentive to compete with one another. Since they really had no idea how to make one product or another more attractive to the sales team, competition was, at least, mild. Mostly it served to waste energy and distract people. Each new leader who came in was caught up in “the way things were done,” and a lot of good people quit. Replacing the VPs didn’t change anything; it wasn’t until Lou Gerstner came in that anything actually changed. Changing leaders can help, but only if the new leader can also change the culture. Otherwise, you’re just replacing an experienced leader with a less experienced one, and telling the new one that he’d better not make any mistakes. That is not a recipe for success!

In a third situation, a manager was fired because customers were complaining that products were being released too slowly. The manager had been told several times to speed up the process. After the manager was fired, shipment speed dramatically increased. Unfortunately, so did two other things: customer complaints about defective products and, to the surprise of no one except senior management, product returns. I suppose one could argue that they fired the wrong manager in this case. The real culprit, though, was problems with team coordination across the company. Killing the various leaders was not the solution; training them properly was. When that happened, and the various managers were allowed to learn from their mistakes, things began to improve.

Particularly in high profile situations, killing the leader can feel very satisfying. It has a feeling of justice being served. However, quite often it does not actually solve the problem. It’s only when we stop to look at the system and understand what is really happening that we can take the actions that will actually make changes that we want.

What do you see?

This is an excerpt from my new book, Organizational Psychology for Managers

Sherlock Holmes on more than one occasion told Watson that it was foolish to speculate until all the facts were available. One of the most difficult aspects of organizational diagnosis is separating what you see from what you think about what you see. I’ve conducted exercises in which people are asked to do something, for example ask to cut into a line, and then describe what the reaction is. Many people tell me that, “She didn’t allow me to cut in because she was in a bad mood,” or something similar.

The observation is only whether or not the person let you cut in the line. Everything else is interpretation. We don’t know why she didn’t let him cut in the line; perhaps he didn’t say please. The point, though, is that it’s hard to separate what we see from what we think about what we see. This can pose a challenge in organizational diagnosis: instead of acting on what is in front of us, we act on what we think about what is in front of us. For example, earlier we discussed the case of the passive aggressive manager. By interpreting the behavior instead of simply observing it, the person making the complaint created chrome out of thin air. No amount of fixing of this mythical passive aggressiveness would have solved their very real problems, whereas merely observing the situation quickly led to the solution. As we discussed in chapter 9, managers observing employees working late rated those employees as more productive, even though what they were really doing was surfing the web. The observed behavior was “in the office late.” The interpretation was, “productive.” The employees who didn’t stay late were rated as less productive and no one could figure out why productivity was always so low.

Observing without interpreting is difficult, but if we don’t learn to do it, all we really do is create chrome.

Balzac combines stories of jujitsu, wheat, gorillas, and the Lord of the Rings with very practical advice and hands-on exercises aimed at anyone who cares about management, leadership, and culture.
Todd Raphael
Editor-in-Chief
ERE Media