Understanding Accountability as a Management-Control Process
Accountability is a management-control process. Responding to a person’s actions lets the person know whether he’s on target or whether he needs to make a correction. Not responding to unacceptable performance unfortunately increases the likelihood that it will occur again.
Consider the following example:
You've recently joined a team working on a project to develop and implement an upgraded inventory control system for your organization. When you learn that your friend Eric had been on this team until a month ago, you call him to discuss his experiences on the project.
After listening to his in-depth account of his project involvement, you explain that you and three other team members have been asked to develop the new system’s users’ manual. You ask him whether, in view of his extensive knowledge of the project’s history, he’d be willing to do you a favor and write a draft of Chapter 1 of the manual that recounts the system’s background and evolution. Today is Monday, and you explain you need the draft by a week from Friday. Eric agrees, and you both hang up.
Unfortunately, you never receive the draft of Chapter 1 from Eric. He never calls you to explain why he didn’t submit the draft, and you never check with him to see what’s happening.
You probably make and receive requests like this one several times each day. Unfortunately, too many times people promise to help you out but don’t deliver. You have to find ways to hold people accountable when they make agreements to complete assignments for you — even if you have no direct authority over them.
Of course, you can hold people accountable only if they accept responsibility in the first place. Therefore, in the preceding illustration, the first question you have to ask is: After your phone call, did Eric accept the responsibility to write the draft for you and your colleagues?
Very simply, the answer is yes. How do you know? Because he said he would. Although Eric is responsible for preparing the draft of Chapter 1, you and your colleagues aren’t off the hook. Your responsibility to prepare the users’ manual hasn’t changed, but Eric accepted the responsibility to prepare the Chapter 1 draft for you. That Eric no longer works on the project or that he doesn’t report to you or your boss is beside the point. He’s responsible because he said he would be.
Eric may argue that he has a personal obligation to complete the draft (because he said he would) but no organizational obligation because the agreement wasn’t in writing and he wasn’t officially on your project team. That argument doesn’t hold up, though; he’s responsible because he said he would be. If he didn’t want to accept the responsibility, he only had to say no.