The Business Sensei

Is Congress Running Your Business?

It’s been pretty impressive listening to the news lately. Will Congress deign to return from vacation to debate whether to grant military authorization to attack ISIL? It seems sort of odd to even be debating whether or not they should be doing their jobs! Now, I could at this point draw some trivial parallel to around how many people get to just blow off their jobs and not really worry about it, but that would be pointless. I doubt anyone is having any trouble seeing that issue!

What I find much more interesting is why they are so eager to avoid debate, and what that can teach us about similar problems in a business.

Politics is an interesting game: in a very real sense, it’s not so much about doing a good job as it is about looking good. Debate military authorization before elections? No matter what you decide, events might prove you wrong. In this case, prove really means that a completely arbitrary and unforeseeable event makes whatever decision you just made appear to be wrong in hindsight. Of course, once this happens, then it becomes an opportunity for your political opponents to swoop in and declare that they would have magically foreseen the future and made a different decision.

In the immortal words of Monty Python, there are three lessons we can take from this and the number of the lessons shall be three.

First, hindsight is very comforting, but is fundamentally an illusion. Hindsight only appears to be 20-20. In reality, what appears obvious in hindsight is frequently only obvious because we know the answer. Go read a good mystery, be it a Sherlock Holmes story or something by Agatha Christie, and try to figure out the clues. It can be done; Conan Doyle, for instance, played fair. You don’t need to know that Holmes picked up a particular brand of cigar ash from the floor; it’s sufficient to just know that he found something interesting. The problem is that it doesn’t help: even with the clues in front of us, it’s still extremely difficult to solve the mystery. Once Holmes explains it, however, then it’s obvious; in fact, it’s hard to imagine that it could have gone any other way. That’s the problem with hindsight: once we know how events turned out, clearly it was obvious all along. That’s why everyone bought Google stock the day it went public and held on to it ever since. While hindsight, used properly, can certainly teach us some useful lessons about our decisions, the hindsight trap teaches us to avoid taking action.

Second, how do we react when someone makes a mistake? In any business operation, mistakes will happen. Are those mistakes feedback or are they the kiss of death? Does a wrong decision become an opportunity to bring out the knives and get rid of a rival or find an excuse to not give someone a promotion or a raise? Or does a wrong decision become an opportunity to revisit the process of making the decision and learn how to make better decisions? In other words, are you fixing the problems or are you simply fixing blame? Fixing blame may feel good, but doesn’t actually solve anything: the same problems just keep reappearing in different guises.

Third, are you evaluating your employees based on results, strategy, or both? Even the best strategy sometimes fails, but when you focus on strategy your odds of successful results are much higher. If you only focus on results, you are telling people to not take risks, not accept challenges, but rather to play it safe. If you only focus on strategy, you lose the opportunity to reality check your plans: if a strategy fails, it’s important to understand what happened. Did the market change? Did something unexpected and unpredictable occur? What are the things that can derail your strategy and what can you do to make your strategies more resilient? What can you control and what is outside your control? Athletes who focus on strategy, process, and winning, win far more often than those who only focus on winning.

When you get caught in the hindsight trap, fix blame, and ignore strategy what you are really doing is telling people that inaction is better than action, pointing fingers is better than improving the business, and playing it safe is better than pushing the envelope and seeking excellence. Is that really the business you want? If it’s not, what are you going to do?

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

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.