Free Article By Paul Glen of C2
Consulting
Every month we add to this collection of articles from the free monthly
newsletter IT Professionalism.
You are also free to print these articles in your newsletter or magazine if
you follow our Reprint Policy.
To subscribe to it, click here.
Accountability vs. Blame
(This article first appeared in Computerworld
USA and Computerworld Hungary.)
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.
