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 Prise-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."
