The Business Sensei

How to make your company sick by treating the symptoms

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

Did you ever notice that doctors who deal with respiratory illness are known as Ear, Nose, Throat doctors, not Achy, Coughy, Sneezy, doctors? You don’t go to a doctor who specializes in coughs; you go to the doctor who understands the system in which coughs occur. Even when you go to a specialist, said specialist usually, or at least hopefully, has enough knowledge of the overall system to recognize when they are not the right person. We might go to a doctor because of our symptoms, but we do not go to Symptom Doctors.

In this case, the company was not addressing what was wrong; they were addressing a symptom. After their Decision Consultant finished working with the team on whatever it is that Decision Consultants do, things really did look better for a short while. It wasn’t long, though, before other decision making problems cropped up. So they brought their Decision Consultant back again, and so it went. The problem never really got better, but the symptoms were periodically alleviated. There was no increase in productivity, but everyone did feel better about the team, particularly the Decision Consultant.

The problem with just treating symptoms is that we end up making ourselves feel better while the problem is constantly getting worse. However, when the solution to the problem is to bring in a Symptom Doctor, that’s what ends up happening. Over time, this approach undermines morale and enthusiasm: not only are there clearly problems, but they must be very big problems because the organization is spending lots of money trying to fix them and they are not going away! Eventually, some organizations come to believe that the problems are simply part of doing business; at that point, the business becomes a very unpleasant place to work!

“Author Stephen Balzac has written a terrific book that gets into the realpolitik of organizational psychology – the underlying patterns of behavior that create the all important company culture. He doesn’t stop at the surface level, explaining things we already know like ‘culture beats strategy’ – he gets into the deeper drivers and ties everything back to specific, actionable stories. For example he describes different approaches to apparent “insubordination” by a manager; rather then judging them, he shows how each management response is interpreted, and how it then drives response. Balzac preaches real engagement with one’s own company and a mindful state of operation, especially by executives – who must remember that culture “just happens” unless and until they learn to recognize that their behaviors play a huge part in creating and cementing it. It covers the full spectrum of corporate life, from challenging bad decisions to hiring, training, motivating teams – and the secrets of keeping people engaged and learning – and/or avoiding actions which do the opposite. I highly recommend this book for anyone who wants to participate in creating and steering company culture.”

 

Sid Probstein

Chief Technology Officer

Attivio – Active Intelligence

What are the symptoms telling us?

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

Earlier, we discussed the process of looking at symptoms as the route to finding the problem. The danger here is that we become too focused on the symptoms. Treating the symptoms will often make us feel better in the short term, but only serves to mask the real problem. For example, if your car is making a weird knocking noise from one wheel, you can simply deal with the symptom by closing the windows and turning the music up. As they said on Car Talk, this approach works great until your axle breaks and the wheel comes off.

Of course, knowing that we get focused on symptoms isn’t the real question. The real question at this point is, why do we get focused on symptoms? The answer is because they’re there. Symptoms are easy to see and they seem easy to deal with. Making a symptom go away feels good. For a short time, everything appears to be working.

In one technology company, one of the engineering teams couldn’t make decisions. Now, we’ve looked at decision making from several different angles, and we therefore know that we’re looking at a symptom. There are any number of factors that can cause this symptom to appear:

1. We could be looking at a so-called leaderless team. As we’ve discussed, leaderless teams don’t work. This is one of the reasons why.
2. The team could be using wrong decision making method for the organizational culture or for the team’s stage of development. Stage one teams that attempt to use voting systems often end up stuck. Stage two teams are particularly resistant to directive leadership.
3. Lack of engagement: if the team isn’t committed, it isn’t really taking the decision seriously. As a result, and note that this is an additional symptom, no one is asking questions or pushing back on ideas.
4. Perceived lack of control: if the team doesn’t believe that their actions will matter, they won’t try. Decisions are a ritual they go through even though they “know” it won’t matter.

Indeed, even the basic problem, “can’t make decisions,” can mean different things: are decisions being made but not implemented? Are decisions not being made at all? Are they being made and then revisited and second-guessed? Each of these scenarios present different symptoms and point to different underlying problems.

Why isn’t my company doing better?

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

As we’ve discussed previously, when we set goals we need to know not just if we’re on track, but if we’re off track as well. We can’t really trust a system that doesn’t give us tools to recognize and correct problems. Just as this is true at the individual and the team level, it is true at the organizational level. It’s not enough to know what you should do; you also need to know what to do when things don’t work out as expected.

Fundamentally, Murphy’s Law holds true in organizational development just as it does in engineering. Things will go wrong. Mistakes will happen. People will misunderstand, miscommunicate, misconstrue. Go back to our discussion of team development in chapter 3: people have to learn how to talk to one another. This process takes time. While we certainly hope that problems will be small, localized, and easily dealt with, we need to be prepared to handle the situations where that’s not the case. Remember, most teams get stuck somewhere along the way to high performance.

The goal of organizational diagnosis is to apply our skills at problem solving to understand what is going on in our organization and then apply the information we’ve discussed throughout this book to moving the organization forward. Organizational “problems” can take many forms, from obvious failures or outright disasters; to feeling stuck, meaning that you’re expending a great deal of energy on something, but not seeing results; to strong performance that can’t quite make the jump to extraordinary performance. This last can be particularly pernicious as management becomes complacent and becomes unwilling to take the risk of improvement. In any and all of these situations, the key is to be able to identify what is happening, propose possible courses of action, evaluate those proposals, form an action plan, execute it, and be able to evaluate the results. For something ostensibly so simple, why is it so difficult?

Riveting!  Yes, I called a leadership book riveting.  I couldn’t wait to finish one chapter so I could begin reading the next.  The book’s combination of pop culture references, personal stories, and thought providing insights to illustrate world class leadership principles makes it a must read for business professionals at all management levels.

Eric Bloom

President

Manager Mechanics, LLC

Nationally Syndicated Columnist and Author

Now can I solve the problem?

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

Unfortunately, you still can’t solve the problem. There’s still just a bit more to do before you dive in and implement your solution. Examine the goals you just developed: how will you carry them out? Which steps can you plan and which steps can you not plan in advance? How will you know if you’re successful? This last point may seem silly: after all, if you’re successful, the problem will go away! While that’s true, it helps to identify precisely what you expect to happen and when. Back to goals and feedback: we want to know if we’re succeeding before we get to the end. Conversely, if we are solving the wrong problem or if our solution is flawed, we want to know this as early as possible. As with all goals, we have to define our intermediate steps and identify the factors that will tell us if we’re going off course. At the end, we don’t want to get bogged down arguing about whether or not we’ve succeeded: by defining our criteria ahead of time, before we’re invested in the results, we avoid the danger of getting somewhere random and simply declaring that to be the finish line.

If the implementation of the solution is going to be carried out by other people, it pays to bring them into the process at this point if we haven’t brought them in already. People who have to implement a solution will feel more engaged and committed if they are involved early on in the process of coming up with that solution: respect their competence and build relatedness. On a purely practical level, they are also likely to have expert insights that others may not: I worked once with an architecture firm whose head architect made a point of involving builders in the earliest stages of design. He told me it was because that way he wouldn’t end up giving the client drawings for something that didn’t exist.

At this point, you can go ahead and implement your solution. At the end, do a final check: did it work? Since you’ve already defined the criteria for success, at least in theory this shouldn’t be too hard to determine. In practice, it’s often a bit messier than it sounds on paper, so be prepared for that. If it didn’t work, you have a choice in how to respond:

Option 1: Clearly the failure is someone’s fault. Heads must roll!

Option 2: What have learned that we didn’t know before? Remember our discussion of hindsight in chapter 11. Just because something is obvious now doesn’t mean it was obvious before. Based on what we’ve learned, how can we now solve the problem? What else have we improved along the way?

Cultures that focus on blame typically go with option 1. However, the more optimistic and successful organizations choose option 2. That doesn’t mean not doing a post-mortem and trying to identify mistakes or failing to refine your processes; it simply means that you’re proceeding from the perspective that you have competent, committed people who have no more interest in wasting their time on a wild goose chase than you do. The secret to solving large, difficult problems is accepting that there will be mistakes along the way. The secret to optimistic organizations is that they actually treat those mistakes as feedback and learning opportunities instead of merely giving the concept lip-service.

We’ll return to these concepts when we discuss organizational diagnosis later in this chapter.

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

Could you make that noise again?

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

Ever listen to NPR’s “Car Talk?” For those who might have been under a rock for the past 25 or so years, Car Talk features “Click and Clack, the Tappit Brothers,” also known as Tom and Ray Magliozzi, taking questions about and giving advice on car repair. In the course of the hour show, they will take several calls, laugh at their own bad jokes, and ask a series of questions such as, “Does it make that noise when you turn to the right or to the left?” “And it goes away above 30 miles per hour?” and, “Could you make that noise again?” I suspect the last question is mostly because they find it hilarious to listen to callers attempting to imitate the odd sounds their cars are making.

What Click and Clack are doing through their apparently random questions is identifying the symptoms of the problem. The symptoms are not the problem; they are merely the symptoms. However, when we understand the symptoms, we are able to gradually identify the problem. Going back to our discussion of goal setting, we are defining and executing learning goals. We are setting goals that will help us answer several important questions:

1. What are the observed symptoms? Exactly what is happening?
2. When do the symptoms occur? All the time? At certain times?
3. When did it start? What changed?
4. Where do they occur? In one location or many? In one product or many? At one customer site or many?
5. How long do they last?
6. What is affected?
7. Who is affected?

Organizational Psychology for Managers is phenomenal.  Just as his talks at conferences are captivating to his audience, Steve’s book will captivate his readers.  In my opinion, this book should be required reading in MBA programs, military leadership courses, and needs to be on the bookshelf of every Fortune 1000 VP of Human Resources.  Steve Balzac is the 21^st century’s Tom Peters.

Stephen R Guendert, PhD

CMG Director of Publications

Failure

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

While there are certainly lessons to be learned from failure, and failure is necessary for successful innovation, we also have to take the time to enjoy the progress we are making and take pride in what goes right. Optimistic people are those who take pride in their successes, who recognize how their efforts made those successes possible, and who keep failure in perspective. Pessimists, on the other hand, focus on how they contributed to failure and tend to view success as being as much about luck as anything else.

Now, people have assured me over and over again that they are optimists! They are not focused on failure, no way, no how. Actions, however, trump words in this case, as they so often do. If you engage in behaviors that orient you toward success, you are an optimist; if you engage in behaviors that keep you thinking about failure, you are behaving pessimistically. When planning is all about avoiding failure, that’s inherently pessimistic!

Although pessimists so often seem rigorous and logical, optimists are happier and more successful. An organizational culture can be biased toward either optimism or pessimism; the most successful organizations are fundamentally optimistic. Optimism works.

Of course, it’s not enough to just say, “Be more optimistic!” If that were all it took, you wouldn’t need this book. Being optimistic is more than just some sort of mythical power of positive thinking. Rather, real optimism, the kind of optimism that gets things done, is based in identifying the positive, building resilience, engaging in behaviors that reinforce our sense of control over the world, and learning to reframe failure into useful feedback. Building an optimistic organization, enjoying success, and knowing how to learn the right lessons from failure, are all skills that take time to develop.

In this chapter, we are going to look at how to do just that. Along the way, we’ll see how the different aspects of organizational behavior that we’ve already discussed fit together to reinforce that message of optimism.

Balzac preaches real engagement with one’s own company and a mindful state of operation, especially by executives – who must remember that culture “just happens” unless and until they learn to recognize that their behaviors play a huge part in creating and cementing it. It covers the full spectrum of corporate life, from challenging bad decisions to hiring, training, motivating teams – and the secrets of keeping people engaged and learning – and/or avoiding actions which do the opposite. I highly recommend this book for anyone who wants to participate in creating and steering company culture.

 

Sid Probstein

Chief Technology Officer

Attivio – Active Intelligence

Blame and the Vortex

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

When there’s a problem, perhaps a critical deadline was missed or you lost an important client, what could be more fair and just than finding and punishing the person responsible? Surely fixing blame is the best way to make sure such problems don’t happen again! Blame is, after all, a natural response when something goes wrong. It’s what we do in our larger societal culture: after all, if you get a speeding ticket, it’s clearly your fault, right? You did something wrong. You were to blame for going too fast. Or maybe the real blame lies with the unfairly and ridiculously low speed limit, or the cop who just happened to pick you even though other people were obviously going much faster. In any case, though, you’ve learned an important lesson: pay more attention to whether there’s a police car on the road and maybe invest in a good radar detector. What about the speeding? Well, that behavior may change for a short time, but rarely does the occasional ticket produce permanent, lasting change.

This is the problem with blame: it may fix responsibility, but it does not fix the problem. While it can be very satisfying to identify the perpetrator of the disaster that lost the sale or crashed the server, actually solving the problem that led to the lost sale or crashed server is considerably more useful. This requires returning to the concepts we introduced in chapter one, looking at the organization as a system, and understanding how the system is failing. Failure is feedback. If you listen to that feedback and learn to understand what it is telling you, you will identify a weak point in your organizational systems.

At Koloth (once again, the names have been changed), an internet startup, website malfunctions were a regular event. Each time a problem occurred, the person responsible for making the mistake was identified and punished. The problems didn’t go away. Even firing repeat offenders failed to stop the website problems.

What was really going on? Upon investigation, it turned out that several factors were contributing to the problem. First, the company had a very aggressive, eight week development cycle. The aggressiveness of the cycle meant that serious design decisions were constantly put off in favor of short-term, “temporary,” solutions.

Next, the database engineers were chronically overworked, so developers were instructed to not bother them unless it was really important. As a result, developers would roll their own database code, usually copying it from somewhere else. This created numerous subtle problems which the database engineers had to spend their time tracking down, further reducing their availability.
Finally, a particular senior engineering manager was infamous for his last minute demands on his team. It was not unusual for him to walk into someone’s office as they were leaving for lunch, or at 7pm as they were getting ready to go home, and announce that “this component must be completed right now!” When the component failed or was not completed on time, said manager was quick to blame the team member to whom he’d assigned it. Of course, obvious a problem as this may be, it didn’t come out until we investigated to see why there were so many failures. Once we got past the blame, and saw the outlines of the system it became possible to address the actual problems and change the outcome. Along the way, it turned out that the manager in question was secretly running a web-design business out of his office at Koloth: his clever use of blame prevented anyone from noticing for quite some time.

Now, one might argue that Koloth involved actual dishonesty, and that blame is an effective tool when dishonesty is not present. Unfortunately, when people are given an incentive to be dishonest, dishonesty emerges: this is our self-fulfilling prophecy at work. At Double Coil Systems, a bioinformatics company, when someone was found responsible for costing the company a major client, that person was disciplined or fired outright. As shocking as this may sound, it wasn’t long before no one was ever responsible for anything. Each person involved in any problem had some explanation for why it wasn’t their fault. The problem was always due to some other event. When someone did end up taking the blame, it was usually some hapless member of the IT staff. Apparently, the most junior member of the IT department at Double Coil ran the whole business and had complete control of every laptop at all times. Employees at Double Coil had mastered the art of CYA, and so the actual problems were never addressed. Even worse, when employees did notice a problem, they concealed the information lest they be blamed for it (particularly if they had made the mistake!).

The difference between Double Coil and a world class organization is that at the latter they take the time to understand all the components of why they are losing sales, identify the real bottlenecks, and fix them. Blame isn’t the goal; solving the problem is the goal.

In the end, affixing blame only encourages people to conceal problems or pass the buck. No one wants to be the one to take the hit, so they try to avoid it altogether. When the problem finally does come out, it’s far bigger and much uglier than it would have been had it been addressed early. Even worse, your employees are going to be too busy trying to dodge the blame to really concentrate on fixing things.

If you actually want to solve your problems, focus on the organizational system and understand how it may be inadvertently contributing to the problems you are observing.

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

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

Princess Bride Problem Solving

Once upon 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 in dealing with some long-lasting and thorny problems.

None of these problems were 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.

These problems were the topic of much discussion, but despite all that discussion nothing ever changed.

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 the Princess Bride.

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 iocaine powder. In reality, it didn’t matter which goblet he chose as the Man in Black had developed an immunity to iocaine 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 darn 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.

Riveting! Yes, I called a leadership book riveting. I couldn’t wait to finish one chapter so I could begin reading the next. Organizational Psychology for Managers’ combination of pop culture references, personal stories, and thought providing insights to illustrate world class leadership principles makes it a must read for business professionals at all management levels.

Nationally Syndicated Columnist and Author

There Can Be Only One

The other morning, I noticed one of my cats running around with her catnip mouse. Now, this isn’t such an unusual occurrence. However, the difference this time was that the other two cats also wanted to play with the mouse. This is unusual: normally, when one cat gets the toy, the others ignore it.

It wasn’t until the cat dropped the mouse that I realized that either it wasn’t a catnip toy or the cat had been playing with a Pinocchio mouse that had picked a very unfortunate moment to become a Real Mouse.

As soon as the mouse was on the ground, it immediately tried to run from the cat. The only thing that saved the mouse was when another cat got in the way. It was a bit hard to tell, but I’m pretty sure that the cats were more interested in competing with one another over which one would get the mouse than in working together. It reminded me of an old Tweety and Sylvester cartoon.

What was particularly interesting, though, was how the mouse behaved whenever a cat did catch up to it: it would open its little tiny mouth, raise its front paws, and try to look fierce. It was pretty funny watching a mouse trying to intimidate a cat that outweighs it one hundredfold. Oddly enough, though, every time the mouse did this, the cat would hesitate, which usually gave enough time for another cat to get in the way. At that point, the mouse would run and the third cat would quickly chase and catch it, causing the whole process to repeat. Eventually, I managed to trap the mouse in a container and release it outside.

To be fair, one can hardly blame the cats for taking an “every cat for herself” attitude. After all, in this situation, we’re talking about a very fixed pie, or mouse. Only one cat will get the prize. Whether that prize is then eaten or proudly left as a gift on a bedroom pillow, there can be only one winner, and it’s not the owner of the pillow. For cats, this is quite normal. Unfortunately, it is also quite normal on far too many so-called teams. Indeed, it is quite disturbing how often teams work together almost as well as did the cats.

Like the cats, though, in a very real sense you can’t blame the team members either. When there is only one mouse, or pie, suddenly the priority becomes getting it. Put another way, whenever team members are in a position of “I win, you lose,” you don’t really have a team; you have a mob or a horde of cats out for themselves.

It doesn’t matter whether there’s a fixed amount of money being given out to the “best” members of the team, or bottom ten percent are being fired. Quite simply, when members of a “horde” are competing with one another for the rewards, performance is drastically and dramatically reduced compared to a strong team. How bad can this be, you ask? A team outperforms a horde by at least tenfold, and can sometimes outperform by a factor of a hundred or more. What is that level of performance worth to you?

Like the cats being “intimidated” by the mouse, members of a horde are also more likely to be flummoxed by relatively simple problems. By behaving in an unexpected fashion, the mouse could startle the cats, in large part because each cat was devoting the bulk of its efforts to competing with the other cats. Thus, they were less able to focus on the mouse. Similarly, when team members are devoting the bulk of their efforts to competing with their supposed colleagues, they spend less effort solving problems. After all, the reward is not for finding the best ideas, but to finding an idea that looks better than the ideas that other team members came up with. In some cases, just being good at making someone else’s ideas look bad is enough to win. Well, at least the individual wins; the team, and the company, end up with a dead mouse on their pillow.

Competition on the team also means that you, the manager, have to spend most of your time keeping your cats walking in the same direction and focused on your goals. This can be exhausting, as anyone who has ever taken their cats for a drag can attest. Team members will only care about the goals of the team when no other way of getting ahead is available. As for taking risks, forget it. Why take a risk when that means someone else gets the mouse? It’s smarter to play it safe and let another person make the mistake.

Far better to eliminate competition within the team and focus team members on competing against other teams, preferably teams at other companies. Use the competition to bring them together instead of driving them apart. If someone on the team isn’t carrying his weight, it’ll become obvious and can be dealt with simply and directly at that point. Building a strong team takes effort, but it sure beats herding cats.

QWERTY Culture

Remember the last time the keys on your computer jammed because you were typing too fast? Neither do I.

The fact is, our QWERTY keyboards are an artifact of history, a solution to a problem that hasn’t existed for at least half a century: typewriter keys jamming when you type too fast. The solution was to design a keyboard which reduced the speed at which someone could type. Even though that problem hasn’t existed at least since the 1960’s IBM Selectric Typewriter, with its “letter ball,” we still use QWERTY keyboards. Better keyboard layouts do exist, but that hasn’t changed the fact that QWERTY still owns approximately 98% of the keyboard market. QWERTY is so accepted that even my spell-checker recognizes QWERTY as a word.

Now, one can make all manner of arguments about how QWERTY persists because there is a significant investment in QWERTY keyboard manufacturing in place, or because most people are comfortable with QWERTY keyboards and don’t want to learn something new, or that learning the more efficient Dvorak keyboard isn’t a transferable skill, and so forth. All of these arguments are even sort of true, albeit of questionable relevance. Fundamentally, they call boil down to tradition. We’ve always done it this way, so let’s keep doing it this way. Everything else arises in response to that.

Maybe this isn’t such a big deal in the world of keyboards. After all, most people are pretty happy with their QWERTY keyboards, and it’s not that hard to use a Dvorak if you really want to. The QWERTY phenomenon can be more of a problem, though, in large organizations where continually solving a problem that no longer exists wastes time, energy, and resources.

The “way we’ve always done it” is very attractive. It’s familiar, safe, something we often don’t think much about. Doing things the way we’ve always done them feels good, like putting on a favorite coat. Sure, it may not be as nice or as warm as a new one, but it’s comfortable. We’ve grown used to it. Quite frequently, we’ve built up structures or procedures to help us do whatever it is we’ve always done. Those structures and procedures, like QWERTY keyboard factories, give us a convenient excuse to not make changes.

Founded over a century ago, General Motors learned many lessons about how to sell cars. Those lessons were the results of hard won victories over competitors and economic disasters including the Great Depression. Those lessons made GM the most successful auto maker in the world for many years. Those same lessons, unfortunately, also eventually led to a GM executive pointing to a GM parking lot and declaring there was no need to worry about competition because there were no foreign cars in the lot. The world, and the competitive landscape, had changed and GM hadn’t kept up. They were, metaphorically, still happily using their QWERTY keyboards in a world where everyone else had moved on to something far more effective. It took an economic disaster and the near destruction of the company to force them to start facing modern problems instead of hiding comfortably behind old ones.

By comparison, IBM badly misjudged the computer market in the late 1980s and early 1990s. They were so accustomed to being on top that they simply couldn’t imagine any need to do things differently. Thus, the techniques they’d learned selling giant multi-million dollar computer systems to large corporations were the same techniques they applied to selling little tiny PCs to individuals. The results were underwhelming. It took the first loss in the company’s history to shake them out of their complacency. For the first time in IBM history an outsider, Lou Gerstner, was brought in to run the company. He successfully refocused IBM on the market in front of them, not the market they were used to being in.

Giant companies are not the only ones vulnerable to this “QWERTY trap.” It’s a game everyone can play. One Silicon Valley company I worked with asked me to convince all their employees to work twelve hour days. When I pushed them on what they were trying to accomplish, they first spoke about deadlines, fixing bugs, and customer commitments. When I kept pushing, it eventually turned out that they wanted their employees to work twelve hour days because, “This is Silicon Valley and that’s what we do here!” Once I convinced them that a more sane work schedule would make more sense, we saw productivity go up and both the quantity and the severity of software bugs go down. The company actually started hitting its deadlines.

It’s easy to get caught up in the idea that the way to do things today is the way we’ve always done them. It’s also easy to use existing procedures and policies to justify our desire not to change. Doing things the familiar way feels good. However, just because something feels good doesn’t mean it’s actually doing what we think it’s doing. It pays to stop periodically and check to see that we’re doing is actually solving the problems in front of us, not problems that disappeared fifty years ago.