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 the author of the award-winning book
“Leading Geeks: How to Manage and Lead People Who Deliver Technology”
(Jossey Bass Pfeiffer, 2003) and Principal of C2 Consulting. C2 Consulting
helps IT management solve people problems. Paul Glen regularly speaks for
corporations and national associations across North America. For more
information go to www.c2-consulting.com. He can be reached at info@c2-consulting.com.