The Business Sensei

Tortoise and Hare Schedules

Remember the old story of the tortoise and the hare? Aesop’s old fable about a race between the extremely fast hare and the slow tortoise is a famous one, appearing in countless children’s books. It also made its appearance on Rocky and Bullwinkle and The Bugs Bunny Show. In the latter case, the role of the hare was played by no less a personage than Bugs Bunny himself, which is almost, but not completely, totally unlike getting Sir Lawrence Olivier to appear in a high school production of Hamlet.

The fact is, though, the story has tremendous longevity. This little race fable has, as it were, “legs.” If there is one thing that story tortoise, it’s that speed simply isn’t all it’s cracked up to be. Indeed, one of the fastest people I’ve ever met was a 75 year old Judo master. He never seemed to move all that much, but no matter how fast we tried to hit him, somehow we always hit the ground instead. His secret, he told us, was that we simply had to be in the right place at the right time. As long as we could do that, we didn’t have to move very fast.

This same question of speed plays into how we experience time and, by extension, how productive we are. When we feel that we don’t have much time, we try to move faster. This is tiring: the hare, as you’ll recall, fell asleep before the end of the race. Not only that, and odd as it may sound, the faster we move, the less time we feel like we have. In a shocking counterpoint to Einstein’s Theory of Relativity, which says that the faster we go the more time slows down, when we go fast, time seems to speed up as well. My physicist friends assure me, however, that this would change if I could simply move at a rate approaching the speed of light. Failing that, we need to learn to experience time differently, and use time in ways that maximize our productivity without leaving us exhausted.

Fortunately, there are ways to do this. Instead of viewing time as ticks on a clock or blocks on a calendar, we need to step back from that rigid construction of time and instead view time for what it actually is: Nature’s way of making sure everything doesn’t happen all at once. Time imposes a sequence on our activities, and it does that no matter how much we may wish otherwise. That sequence, however, can be used to our advantage. Instead of being locked into a rigid, clock-based image of time, we can instead view time as a series of events. Each event triggers the next event. What does this mean?

When we are locked into a clock-based view of time, we attempt to start and stop activities according to the number on the clock: 3pm have pre-meeting meeting, 3:30pm meeting, 7pm post meeting discussion, and so on. When we are working with others and need to coordinate a variety of different people, use of space, and allocation of other resources, then we need to impose some of that clock based ordering. Too much of it though just slows us down: if something takes longer, or shorter, than expected, suddenly the whole schedule is thrown off. We get distracted and suddenly find ourselves running behind or forget to take breaks and wear ourselves out too soon.

Instead, within our blocks of time, and whenever we are working in a relatively unstructured environment, we need to think in terms of events. What events are happening around us? What events are we causing? Our events can be used to trigger us to change activities or take breaks. In one office, the coffee cart coming around was the trigger for people to take a break and move to a different task. An engineer working at home used the school bus driving by in the morning and mail deliveries in the afternoon as events to trigger him to switch tasks. We can even take this a step further, and create explicit linkages of events for our own uses: when I finish testing this piece of code, I will make a cup of coffee. When I finish my coffee I will review the documentation. When I finish… and so on.  When we plan and connect events this way, it’s amazing how much time we don’t waste just trying to decide what to do next.

The other piece of managing our perception of time is to create a schedule that we can beat. It’s quite amazing: when we’re ahead of schedule, we are simultaneously more relaxed and more energized. We focus better and come up with more creative solutions to problems. Unexpected obstacles are fun challenges. When we are behind schedule, we feel rushed. Every delay feels like a crisis. We take shortcuts and make more mistakes.

Ultimately, teams that are ahead end up further ahead. Teams that are behind, end up further behind. People who are rushed don’t see what is in front of them, lose track of where they are, and exhaust themselves too soon. If you want to win, design a schedule that you can beat not one that beats you.

Death of Thousand Knives

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 their clients or from 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 also 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 that 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?

The Secret Life of Pies

So there you are on Thanksgiving. Dinner is over and it’s time for dessert. You bring out the traditional impressive array of pies. However, with the exception of some teens, everyone is stuffed (five minutes ago, this included the teens).  The pies just sit there, and you are facing the possibility of a house full of leftover pie.

Of course, some people might not have any problem with this.

But let us suppose that you really would like your guests to eat the dessert. I’m not sure why; perhaps you don’t want a house full of desserts or maybe it involves a clever plot to take over the world (hey, it’s no less believable than many James Bond plots). In any case, how do you get a lot of people to eat the pie?

Well, if you have a lot of people there, it’s not that hard. Just bring out one pie. The moment it looks like there’s not enough dessert for everyone, suddenly everyone is hungry again. Once one person takes a piece, the rest won’t be far behind. Fortunately, the odds are extremely low that your dinner will degenerate into a frantic struggle for control of the pie, although putting out a single pastry could result in a sudden game of scones.

So what does this have to do with business? That depends on how much your company values teamwork. In some companies, teamwork is irrelevant. No one cares, it’s not important, and it’s not how you get things done. In that case, you probably won’t care about the rest of this article. On the other hand, if teamwork does matter to you, then you might want to keep reading. Teams of all sorts tend to be very concerned with pies, and it’s not because an army travels on its stomach. Rather, much like that Thanksgiving dinner, what matters is the size of the pie. Different flavors can help, but primarily size matters.

Ultimately, the degree to which team members will cooperate or compete with one another depends very much on the size of the metaphorical pie they are working towards. When the pie is perceived to be large enough for everyone, you get cooperation. When the pie is perceived to be too small, you get competition.

But isn’t competition healthy? Friendly competition can be healthy under the right conditions. However, when the competition is at work, and the “trophy” directly impacts your job, then the competition quickly starts to look like an episode of “Tom Slick,” complete with all the dirty tricks and without the humor. In other words, not particularly healthy competition.

If all this seems too theoretical, or is just making you hungry for pie, think about Microsoft. For much of their corporate existence, they practiced employee stacking:  members of each team were rated from high to low. The highest rated people got the rewards, and the lowest rated were eliminated. Now, there is a claim that this encourages people to work harder. What it actually did was encourage their top people to avoid working together so that they wouldn’t be in competition with one another. It encouraged hiring weak performers so that there would always be someone to take the fall. It encouraged team members to sabotage one another rather than cooperate. It encouraged people to become very skilled at looking like they were sharing information while still withholding critical details. To be fair, they did work very hard at these tasks. Unfortunately, it can take years to regain the trust lost along the way.

Although it may seem counter-intuitive, the big pie encourages cooperation while the little pie triggers competition. If you want a successful team, and a successful company, find ways to expand the pie, and focus your competitive instincts on your real competition.

And if you’re bored after your next big holiday meal, you can always try serving a single pie and see what happens. Let me know how it goes.

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?

Of Cats and Unwanted Prizes

I have three cats. Cats being the creatures that they are, I have only to sit down to read a book and instantly there is a cat on my lap. Regardless of which cat it is, a familiar pattern ensues: first, the cat carefully positions itself in front of my book. Once I adjust to move the book, the cat then carefully positions itself on one of my hands. This continues until I give the cat the attention it’s seeking. At that point, it first butts its head against me and then, purring loudly, turns and sticks its behind in my face.

I am sure that there are people who find this end of a cat absolutely fascinating. I’m even quite sure that there are contests in which cats win awards for having the most beautiful behind. For cat breeders and cat fanciers, it can be a big deal to win one of these cat trophies. It is a cause for great celebration.

In an office environment, however, a catastrophe is anything but a cause for celebration.

The worst thing about catastrophes is that they happen about as often as a cat sitting down on top of the book you’re reading. At least, to listen to some managers, it certainly sounds that way. Somehow, every little thing, every small problem, was magnified until it had the aura of impending doom. In short, every setback was becoming a prize for the cat with the most beautiful behind. At one company, the conversation went something like this:

“We’ve found a major bug in the software.”

“We can’t delay the ship.”

“We can’t ship with this bug.”

At that point, the manager started screaming that the product would go out on schedule, or else. When he finally calmed down and I was able to talk with him privately, he told me that he knew that if the company didn’t ship on time, the customers would abandon them and they would go out of business. He was happy to ship non-functional software to avoid that fate.

When he calmed down still further, he agreed to delay the ship.

I am sure that most readers are chuckling to themselves right now. After all, delays in software are legendary. Obviously, this manager was overreacting. True enough; the question is, why? Why would a perfectly sensible, intelligent man react so negatively to something which is, frankly, a common event in the software business?

It turns out that this particular company prided itself on holding to very aggressive schedules. The schedule was so aggressive that they were virtually always running behind. Therein lay the problem.

Time is a funny thing. We react very differently depending on how we perceive it. Being behind schedule all the time had the effect of generating a certain sense of urgency, which was the stated intent of the aggressive schedule. Unfortunately, the urgency generated in this situation was of the slightly breathless, heart-pounding sort similar to what one might experience if being chased by a very large cat of the “has a big mane” variety. A cat which, I might add, is looking to do more than just sit on your book.

The problem with aggressive schedules is that, in fact, being behind schedule can generate the same panicked response in people that they would feel in a situation which actually was dangerous. While in those situations, we’re very good at running away or fighting desperately, but we’re not good at making cool, rational decisions or developing innovative solutions to problems. Each pebble encountered along the road becomes a giant boulder. When we do finally get to the end of the project, rather than feeling a sense of accomplishment and success, there’s more of a sense of relief that at last it’s over. What’s missing is the thrill of victory that energizes people for the next project. That feeling of success is the key to getting, and keeping, people excited and motivated.

In short, instead of the team beating the schedule, the schedule was beating them.

Conversely, when a team is running slightly ahead of schedule, something very different happens. Running ahead of the game means that the team is feeling a constant sense of success. When people feel successful, they work harder, they are more creative, and they look forward to coming into work each day. Teams that are running ahead of schedule are more likely to develop innovative new solutions to problems rather than just slap on band-aids. Feeling that you have the time to stop and think is critical: just think about how easy it is to miss the obvious when you are feeling rushed.

The trick is to view your schedule as a living document. It’s something that you will constantly adjust according to the situation, especially at the beginning of a project. The less you know about potential difficulties down the road, the harder it is to plan: so don’t. Instead, plan to plan. As you move forward, you can revise and project the schedule further and further into the future.

If you find yourself running behind, that’s feedback. Pay attention to what it’s telling you. Is something more complicated than expected? Is someone overwhelmed with a task that turned out to be significantly more time-consuming than you thought? Did something go wrong? Is a vendor habitually late with parts? Is your schedule just plain too aggressive?

If you’re running ahead, that’s also feedback. It might mean that the schedule is too easy and your team isn’t being challenged. Be willing to become more aggressive. It could mean that you need to slow down: are people rushing and cutting corners? At one company, pressure on QA engineers to rush product inspections led to some very expensive and embarrassing recalls and some very irate customers. Moving way ahead of schedule could also mean that your team is working too hard too soon: success is a marathon, not a sprint. Burn out early and you won’t reach the finish line.

Leave the catastrophes to the cats.

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 McGraw-Hill 36-Hour Course in Organizational Development,” and “Organizational Psychology for Managers.” He is also 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.

Not In Front of Me!

Legendary bank robber John Dillinger was reputedly asked why he robbed banks. His answer, at least according to the aforementioned legend, was, “Because that’s where the money is.”

When you think about it, Dillinger did have a point: it would be silly to go to all that effort and risk if there was no money there! However, Dillinger did not rob just every bank: he was actually somewhat picky. In particular, Dillinger did not rob banks that the police were actually watching. That’s not to say that he was never rudely interrupted as he went about his business, but, as a general rule, John Dillinger did try to avoid committing his crimes in front of the police.

Somehow, though, the police had no trouble figuring out that he was involved.

Recently, several employees at a particular technology company came to the CEO with concerns about the inappropriate behavior of a certain manager. After listening carefully to their concerns, the CEO then told them that they were obviously mistaken: he had never seen the behavior, so clearly it could never have happened.

We can but imagine just how much John Dillinger would have appreciated having this man in charge of the police!

“Sir, John Dillinger just robbed the bank.”

“Nonsense! I didn’t see it, so it couldn’t have happened.”

While this would have been great for Dillinger, perhaps it would not have been so great for everyone else. As a form of leadership, well, it might be considered a bit thin.

One of the less attractive parts of leadership is dealing with unpleasant situations and badly behaved employees. This often means dealing with a situation that is not well defined: some people are unhappy, and someone else is claiming that nothing at all is going on. As a leader, it’s often easier to just shrug and decide that it’s not your problem; as long as it doesn’t happen in front of you, then you can just ignore it. That, however, is not leadership.

As the leader, you are the model for how people in your department or your company will behave. What you do sets the tone: show people that it’s okay to ignore problems that you don’t want to deal with, and they’ll quickly learn to do the same: unhappy customer? Didn’t happen in front of me. Product defect? Didn’t happen in front of me.

The “didn’t happen in front of me’s” can be quite contagious. They’re easy to use and they make the difficulty go away, or at least become someone else’s problem.

So what can you do about it? After all, it can be difficult to figure out just what is really going on.

Start by asking questions. Not just any questions but particularly difficult questions, at least for a leader: genuine ones. It can be challenging to acknowledge how much we don’t know about a particular situation and ask the sorts of questions that show our ignorance. However, when we put our preconceptions aside and start asking about what people are actually experiencing, it’s amazing how much we can learn. MIT social psychologist Edgar Schein describes this process as humble inquiry. It involves taking the time to speak with people and enable them to become comfortable with you, and it involves being honestly curious about what they are doing even when it doesn’t matter. Building those connections is what enables information to flow upstream to you.

One of the most important lessons of leadership is that most things don’t happen in front of you. And, most leaders are very unhappy when they suddenly realize that things are happening in the company that they didn’t know about. Unpleasant situations are much easier to deal with when you’ve established the groundwork and shown genuine curiosity and interest. The question is not whether or not it’s happening in front of you, but what you are doing to make sure you’ll find out about it when it does happen. If you’re nervous, just remember, odds are extremely good that it won’t involve John Dillinger.

Princess Bride Problem Solving

Once upon a time there was an organization. It was a fairly good sized business, not too big and not too small. It was a business, in fact, much like your business. And it came up with a way to apply the battle of wits from the Princess Bride to dealing with some long-lasting and thorny problems. For those who may not recall this scene or, hard though it may be to imagine, have never seen the movie, it occurs relatively early in the film. Vizinni the dwarf has kidnapped Princess Buttercup and is fleeing with her to Guilder. In pursuit is the mysterious Man in Black. The Man in Black defeats the master swordsman, in a duel, and Fezzik the Giant in a wrestling match. He then confronts Vizinni in a battle of wits: two goblets, one supposedly containing deadly Iocane powder, sit before the two men. Vizinni must deduce which goblet contains the poison and then both men will drink.

What follows is a dizzying, and often hilarious, chain of logic as Vizinni attemps to solve the puzzle.

Vizzini: But it’s so simple. All I have to do is divine from what I know of you: are you the sort of man who would put the poison into his own goblet or his enemy’s? Now, a clever man would put the poison into his own goblet, because he would know that only a great fool would reach for what he was given. I am not a great fool, so I can clearly not choose the wine in front of you. But you must have known I was not a great fool, you would have counted on it, so I can clearly not choose the wine in front of me.

Man In Black: You’ve made your decision then?

Vizzini: Not remotely. Because Iocane comes from Australia, as everyone knows, and Australia is entirely peopled with criminals, and criminals are used to having people not trust them, as you are not trusted by me, so I can clearly not choose the wine in front of you.

Man In Black: Truly, you have a dizzying intellect.

Vizzini: Wait till I get going! Where was I?

Now, the fact is, none of the problems the business was facing were particularly unique or new problems. They were problems that the organization had had for many years: difficulties in setting priorities and making decisions; allocating resources and providing clear direction to employees. In other words, the sorts of problems that many businesses struggle with.

These problems were the topic of much discussion, but despite all that discussion nothing ever changed. Attempts to solve the problems almost resembled the classic model of two steps forward, one step back. The resemblance broke down in the second half: they usually took two steps back.

Eventually, someone suggested bringing in a consultant to help with the problems. This is where things got creative. It turns out that there are two types of consultants, at least for this particular business: those who were closely connected to the business and known to people there, and those who had no connection at all.

We now come to Vizinni and his Dizzying Intellect.

Consultants in the second group could clearly not be hired because they knew nothing about the company. How could they possibly be of assistance? Therefore we must look at consultants in the first group.

Consultants in the first group were too close to the organization. Clearly they too could not be hired. Therefore, we must go back to consultants in the second group.

But consultants in the second group would clearly not care about the results. So they could not be hired. Back to the first group.

But consultants in the first group could not be hired because they might care too much. So they too could not be hired.

And so it went, on and on, until eventually nothing was done. People continued to complain about the problems, but no one wanted to act.

In the movie, of course, Vizzini finally chooses a goblet and drinks the deadly Iocane powder. In reality, it didn’t matter which goblet he chose as the Man in Black had developed an immunity to Iocane powder and poisoned both goblets.

Similarly, in this case it wouldn’t have mattered which choice the business actually made: bring in someone totally unconnected or someone close and known to the people there. The important thing was to make a choice and actually take action to deal with the long-term problems that were interfering with their productivity. Whichever choice they made would have different benefits and different drawbacks, but either could have helped them. It’s only the choice to do nothing that has no hope of success. Let’s face it, if the problems haven’t gone away on their own after months or years, odds are pretty good that they won’t be going away on their own tomorrow or even next year.

Choose a goblet. Take action. Nothing will change until you do.

Such a Bargain!

I recently read the claim that, “Each American wastes $300 worth of food every year.” That’s right, three hundred dollars of food is wasted per person per year. The piece went on to offer a variety of products designed to help people eliminate this waste from their lives. Naturally, this is something worth jumping on, right? Well, let’s take a look: $300 per year comes out to 82 cents per day, slightly less on leap years. For a family of four, we’re talking about wasting $2.50 per day. Would it be nice to eliminate that waste? Of course it would; the question is whether or not it’s worthwhile. How much effort is involved in saving $.82 of wasted food per person each day? Just how much food is that anyway? A few grapes? Half a cup of coffee? What is the cost of that effort in terms of time, money, and emotional energy against the returns obtained: $300 in a year, plus whatever sense of feeling good that may result? One fewer cup of coffee each day would save far more than $.86, but is it worth it? Intangibles, such as concentration, motivation, alertness, happiness, and so forth, are difficult to measure, but their lack definitely impacts the bottom line.

One always has to wonder if a savings or a bargain is really as good as it seems. While it’s initially very easy to find major savings in almost anything, as the system becomes steadily more efficient it becomes harder and harder to continue to find cost-effective savings. Thus, requiring employees to not fly first class is an easy way to save quite a bit of money and probably will not significantly impact business. Requiring employees to fly red-eye flights in order to gain minor savings can have a significant impact on productivity, creativity, and decision making. In this situation, only the easily measured aspect of the value gained is being examined: the cost savings on the airline ticket. Why the company is sending the person on the flight, what benefits the company hopes to gain by doing so, and whether those benefits will still be achieved if the employee is sleep-deprived or unable to concentrate during the flight are not being factored in.

Naturally, this is a mindset that manifests in a variety of ways in a business. At one company I worked with, an engineer requested a raise; this employee had a skill set that was very much in demand, and he had discovered that he was being significantly underpaid. The CEO refused on the logic that it would cost the company too much to provide the raise. The person quit, taking a job at a salary considerably higher than what he’d asked for at his original company: he wanted to stay, he just didn’t want to feel taken advantage of. The CEO discovered that it was not so easy to find someone with that skillset, especially at the salary they were willing to pay. They eventually found someone much less experienced and whom they had to pay almost as much as the person who had left. The CEO was actually happy because he hadn’t had to pay a salary for about six months, and then “got a bargain” because the new person was slightly cheaper. The engineering team was furious because they lost the expertise of the person. The cost to the company of not having available the skills and knowledge of the senior engineer is, of course, impossible to calculate. Clearly, however, this person provided some value or he would never have been hired in the first place. It’s worth noting that the company is no longer in business.

Now, the fact is, people love bargains. Most of us love a chance to save some money or make things a little more efficient. The problem is things are often worth what they cost. There’s a reason why a BMW is considerably more expensive than a Saturn or a top notch engineer demands a higher salary than someone less skilled: in the case of the engineer, you expect a far greater return on your investment. It’s not a bargain if it ends up costing you more than you gained. It’s not a savings if the effort involved in saving the money reduces the value of the result by more than the amount saved: saving $.86 on food is going to cost most people at least several dollars a day in effort or lost opportunities.

So how does a company go about figuring out whether or not something really is a bargain? It’s extremely important to ask the right questions:

• What are we trying to accomplish? In other words, what is the actual problem we’re facing?
• What savings are we looking for? What benefits do we think will accrue?
• What is the cost of this solution? Are we looking only at things that are easily measured, such as an expense report or a salary? What intangible factors, such as team productivity, motivation, happiness, increased distraction, etc, might factor in?
• What does success look like? How narrowly or broadly are we defining it?
• What opportunities will this solution cost us? Is there another way?

It’s time to see what your bargains and your savings are costing your company.

This article originally published at Practical Performance Analyst.

Unity of Crisis

Marvel Comic’s Avengers are a pretty impressive bunch. Thor, Captain America, Ironman, and the Hulk make a fearsome combination: Captain America is practically indestructible, Thor flies around throwing lightning, Ironman, aka Tony Stark, is like Bill Gates and Steve Jobs rolled into one, and the Hulk is, well, the Hulk. When it comes to fighting off alien invasions, these guys have power to spare. That’s a good thing, because impressive as they are individually, as a team they aren’t so hot. Their inability to coordinate well would have been a total disaster if they hadn’t had such tremendous power and a friendly script writer in the basement to back them up. In fact, after watching them in action, it’s easy to understand why Samuel L. Jackson’s character, Nick Fury, is bald.

But wait! Sure, the Avengers have their issues, but they do pull together and beat off the invasion. They may have been at each other’s throats earlier in the movie, but aren’t they a team by the end? What’s the problem?

Fundamentally, the problem is that the Avengers are not really ever a team; rather, they are a group of people, more or less, who are able to agree that working together is less awful than the alternative. That, as the poet said, is not exactly a ringing endorsement! Even without Loki’s mind games, they were already barely civil to one another. He merely accentuated what was already happening, pushing them into open conflict.

The Avengers, of course, are fiction. Sadly, this unity of crisis is not. A common problem in business settings are teams whose members barely interact until the pressure of the oncoming deadline forces them to work together at least enough to get something out the door. At one company, this non-interaction took the form of endless debates and decisions that were revisited every week or two. At another company, the team ended up dominated by a couple of loud members, while the rest simply tried not to be noticed. In neither situation was there productive debate, problem solving, or effective decision making; unlike the Avengers, the motions they went through were not particularly dramatic or exciting. On the bright side, again unlike in the movie, no flying aircraft carriers were harmed.

When I’m speaking on organizational development, it’s at about this point that someone interrupts to tell me that they are communicating: they are sending email. Don’t get me wrong; email is a wonderful tool. However, it’s not some sort of magic cure-all. When I actually sit down with groups to look at their communications patterns, we quickly find out that while emails may be sent to everyone in the group, they are really only for the benefit of the team lead. Quite often, the email chain quickly becomes an echo chamber or an electronic trail useful only to prove a point or hurt a competitor when reviews come around.

The challenge every team faces is helping its members learn to communicate. It seems so simple: after all, everyone is speaking the same language. As we see in the Avengers, though, that is not entirely true. While the words all may sound the same, each person is bringing their own perspectives, assumptions, and beliefs to the table. Moreover, each person is bringing their own assumptions about what the goals are and the best way to accomplish them. Also, not unlike the Avengers, there is often a certain amount of friction between different team members. While most business teams do not explode into physical violence, the verbal equivalent does occur. Unlike the Avengers, when that happens many teams simply fall apart. Although the Avengers avoid that fate, it was close. While that experience may be exciting in a movie, I find that most business leaders would rather skip the drama.

So what can be done to create real unity, instead of a unity of crisis? To begin with, it takes time. Sorry, but just like baking a cake, if you simply turn up the temperature of the oven, all you get is a mess. Teams are the same: if you rush, you still spend the same amount of time but with less to show for it.

Assuming that you use your time well, it is particularly important for the team lead to set the tone: invite questions and discussions, but also be willing to end debate and move on. At first, team members will be happy to have the leader end the debate; eventually, though, they’ll start to push back. That’s good news: your team is coming together and starting to really engage. Now you can start really dissecting the goals of the team, and really figure out the best ways of doing things. Start letting the team members make more of the decisions, although you may have to ratify whatever they come up with for the decision to be accepted. Encourage questions and debate, but do your best to keep your own opinions to yourself: the process of learning to argue well isn’t easy and if the team members realize you have a preference, the tendency is for the team to coalesce around that preference. Alternately, the team may simply resist your choice just because it’s coming from you. Better to not go there.

A unity of crisis can be very useful for a one off event, such as saving the world from an alien invasion. But for more mundane, ongoing, projects, real unity is a far better outcome.

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 McGraw-Hill 36-Hour Course in Organizational Development,” and “Organizational Psychology for Managers.” He is also 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.

Killing the Princess: The Dangers of Goal Lockdown

Remember the Ford Pinto? If you don’t, you are not alone. The Pinto’s history was a troubled one, complete with explosions, fires, and lawsuits. In a nutshell, in the 1970s, Ford committed to building a small, light, inexpensive car. It turned out that while they were so committed to that goal, that they also made a car that was prone to exploding in an accident. Why did that happen? According to management professors Lisa Ordonez, Maurice Schweitzer, Adam Galinsky, and Max Bazerman, it was because the management at Ford set goals.

Wait a minute! Aren’t goals are supposed to be a good thing? Normally, yes. However, Ford’s management was supposedly so committed to their goals that they developed metaphorical tunnel vision. In other words, although they knew there were design problems with the Pinto, they ignored those problems in favor of the more powerful outcome goal they were committed to accomplishing. Interesting concept, but are there other examples?

In fact, yes. According to the same four professors, setting specific, high outcome goals led to dishonest behavior at Sears Auto Repair: by requiring mechanics to generate $147/hour of revenue, the mechanics were effectively incentivized to cheat customers. They also implicate goals in the Enron fiasco of the late 1990s. So, if goals are supposedly such wonderful things to have, how can we explain what happened? While it would be easy and comforting to simply say these four professors are ivory tower academics, that would be unjust and incorrect. In fact, they have a point: the best thing about goals is that you might just accomplish them; and the worst thing about goals is that you might just accomplish them.

To put it another way, goals are powerful tools. Like all power tools, it’s important to know how to use them correctly lest you cut yourself off at the knees. In a very real sense, the rules for goal setting and rules for chess have a great deal in common: both sets of rules are relatively simple, but the strategies for success within those rules are complex. Failing to understand the proper strategies leads to defeat. In the case of goals, it can lead to a phenomenon that I refer to as, “Goal Lockdown.” In Goal Lockdown, people become so fixated on their goals that they ignore all feedback or other information that they might be heading into trouble. Indeed, in extreme cases, they will take any feedback as confirmation that they are on track, even when the feedback is someone yelling, “Hey, didn’t that sign we just passed read ‘Bridge Out?’”

The dangers of improper goals are not limited to giant firms like Ford or Enron. I ran an organizational development serious game for a certain high tech company. This particular serious game takes participants outside of the normal business world, instead presenting them with a fantasy scenario with very real business problems. Instead of playing their normal roles of managers, engineers, salesmen, and so forth, the participants are kings, dukes, knights, wizards, and the like. Participants still must recruit allies, motivate others, negotiate over resources, and solve difficult problems. Changing the scenery, however, makes it fun and increases both learning and retention of the material.

In keeping with the fantasy nature of the scenario, a number of plots involve the princess. Unfortunately, for all those people who had plots, and goals, that included the princess, she was eliminated from the exercise; in other words, figuratively killed. What was particularly interesting, however, was that the people whose goals involved the princess found it extremely difficult to change those goals, even though they had just become impossible! This was Goal Lockdown in action. Fortunately, by experiencing it during the exercise, we were able to discuss it during the debriefing and the people at that company are now on guard against it.

Ultimately, if you don’t want to bother with serious games and if you do want to avoid Goal Lockdown, there are some steps you can take. The simplest is to identify your outcome but then focus on your strategy. How will you accomplish the goals? What are the steps you will take? How will you know you are succeeding and how will you know if you’re failing? A system that doesn’t tell us what failure looks like is a system that we won’t trust under pressure. In the long run, the more we focus on process and how that process will move us towards our objectives, the more likely we are to be successful: we are focusing on the things we can most easily change. It’s when we focus on the result and let the strategy take care of itself that we become most likely to fail, sometimes in very dramatic ways!