I’ve discovered that most of the time, when executives tell me that “what we need around here is more accountability,” what they really mean is, “I need to know who I should blame when things go wrong.”
The sentence that usually follows implies that without accountability, no one will do what it takes to meet deadlines, deliver quality products or succeed in general. Just below the surface, the assumption behind this thinking is that fear of blame — or at least fear of the consequences associated with blame — is an effective motivator.
If your goal as a manager is to enforce compliance with well-articulated policy and adherence to established procedures, this may be a reasonable way to think. But for most of us in IT, our goal is to help our staffs apply their knowledge and creativity to the broad array of problems presented to them.
Fear isn’t a particularly potent motivator when it comes to inducing creativity. If it were, editors would simply threaten to lock novelists in gulags until they produced Pulitzer Prize-winning prose.
As a manager, you must understand the difference between accountability and blame.
One morning back when I was managing a group of consultants, I received a call from Jim, a very conscientious senior programmer. Just from the way he said hello, I could tell he was in a state of near panic. “I’ve got a serious problem,” he told me. “I accidentally deleted the entire source-code library for the project I’m working on, and it turns out that the client wasn’t backing up the disk. I never thought to ask. What do I do?”
I asked Jim how much work he had lost, and he explained that he had been working on this particular project for about a month. I asked, “Given that you’ve already been working on this, how long do you think it will take to re-create the lost code?” He said he thought it would take a week, and then he asked again, “What should I do?”
I told him to do two things. “Go tell the client exactly what happened and that we will figure out a fair way to take care of the consequences of the problem. Get to work on re-creating the code.”
Less than 24 hours later, Jim called, sounding tired but relieved, to tell me that he had completely re-created the lost code. “Great,” I told him, “now go do two more things. Update the client and tell them that we won’t charge them for the lost day, and make sure that they start backing up the code library.”
There was a long pause, and finally Jim asked me, “That’s it? You’re not going to fire me?” I told him, “I don’t fire people for making mistakes. I fire them for making the same mistakes repeatedly. Do you know what mistakes you made?”
“Yeah,” he said, somewhat tentatively. “I assumed that they were backing up, but I didn’t check, and I deleted files without thinking.”
“Good,” I said. “Now don’t make those mistakes again. Next time, make better ones.”
Nothing more was ever said about the incident, and Jim remained a loyal and productive employee for many years.
For me, this event helped to draw the distinctions between accountability and blame. In my mind, accountability is the ability to discern and attribute individual and collective results. Blame is about who is going to pay the price for problems. If there’s no clear accountability (and even if there is), you can blame anyone for problems. But fear of being the whipping boy isn’t going to help you build a productive, learning organization.
That day, I learned that I didn’t need to blame Jim. With clear accountability, he learned what he needed to learn from his mistake. Beating him up over the error would only have made him more defensive and less likely to learn from the situation.
Both accountability and blame have roles to play in good management. If you think carefully about the distinctions between the two, your responses to problems can be much more nuanced and tailored to both the situation at hand and the needs of individual employees.
Paul Glen is an IT management consultant in Los Angeles and the author of the award-winning book Leading Geeks: How to Manage and Lead the People Who Deliver Technology (Jossey-Bass Pfeiffer, 2003; www.leadinggeeks.com). He can be reached at info@c2-consulting.com.
