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.