By Stephen Balzac
April 26, 2012
It sounded like the beginning of a James Bond movie.
M: “Bond, are you familiar with Phobos-Grunt?”
Bond: “Either a rather amusing parody of ‘Atlas Shrugged’ or a Russian satellite recently launched into orbit. I assume you mean the latter.”
M (rolls eyes): “Thank you, 007. Yes, I mean the satellite. It’s falling out of orbit.”
Bond: “Seems to be the in thing. Why does this concern us?”
M: “The Russians are blaming the Americans for the satellite’s failure. They claim it was sabotaged in space while the Russians weren’t looking.”
Bond: “And the Americans?”
M: “Of course they deny it.”
Now, if it really were a James Bond movie, it would turn out that SPECTRE had secretly been sabotaging satellites with the idea of provoking a confrontation between the U.S. and Russia. Bond would save the day just before the nuclear confrontation. In this case, though, what really happened is that a Russian satellite called Phobos-Grunt fell out of orbit in January 2012, and the Russians did blame the United States. Much to the disappointment of would-be James Bond villains, that was the end of it, demonstrating that actual politics and James Bond politics are just slightly different.
While blame might make a great James Bond plot, and appears to have no effect on falling satellites, in the office blame can lead to increased product failures and decreased customer satisfaction, productivity, and motivation. In fact, in the office, blame produces exactly the effects that SPECTRE is trying for, albeit on a much smaller scale. Oddly enough, what blame does not do is increase the quality of products or services.
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 lead to the lost sale or crashed server is considerably more useful. This requires looking at the organization as a system and understanding how the system is failing.
At Koloth, 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. Second, 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 7 p.m. as they were getting ready to go home, and announce, “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, but that’s another story, other than to observe that 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. 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 had some explanation for why it wasn’t his or her 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 took the time to understand all the components of why they were losing sales, identify the real bottlenecks, and fix them. Blame wasn’t the goal; solving the problem was 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. When you get rid of blame, it’s amazing how helpful, energetic, and creative your employees will be in helping you solve the problem.
As for the Russian claims about Phobos-Grunt, we’ll leave that to James Bond.
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. You can contact Steve at 978-298-5189 or [email protected].
