All Posts in Policies and Procedures

|In: Leadership|Last Updated:

“Violence is the last refuge of the incompetent,” or so said Isaac Asimov through Salvor Hardin, a character in the Foundation trilogy. With all respect to an excellent epigrammatist (and apologies to Ambrose Bierce who I’m paraphrasing), it isn’t the last refuge, it is the first.

While physical violence in the workplace is, of course, generally frowned upon, its close relative, punishment (also known as disciplinary action, probation, or the ever-popular “holding employees accountable”) is not just commonplace, but encouraged.

“We have to hold people accountable!” This, the sum and substance of root cause analysis in popular culture today, is our new panacea. Never mind that there’s no unbiased evidence demonstrating that lack of accountability is the root cause of very many problems. Never mind that when organizations instead focus on fixing processes and systems, the rate at which problems crop up plummets, nearly every time.

Never mind all that. We have to hold someone accountable, even if that someone is just a scapegoat. Which in all likelihood it will be, because that’s all we ask of the real culprit — the person responsible for the integrity of the broken process. We ask only that he or she “hold someone accountable,” meaning performing some act of public punishment.

If there’s a problem, someone must be at fault. The not-holding-people-accountable explanation is, as a result, doubly satisfying, since it lets us blame one person for the problem itself and a second for failing to punish the first. The result: The real culprit cries “We need to hold people accountable,” as well, using the phrase to avoid his or her own accountability, and as a fringe benefit also avoiding the hard work of identifying and fixing the real problem.

When something goes wrong and you perform a root cause analysis, there are five places to look. Most often the problem lies with your systems and processes — how employees go about performing whatever business function is involved. Holding someone accountable means insisting whoever is responsible for the system or process in question figure out what about it allowed the problem to happen and make the necessary changes to prevent a recurrence.

Systems and processes are far from the only source of problems, though. Two other common ones are that the organizational structure or corporate culture … core responsibilities of leadership … preclude the behaviors needed to prevent problems from occurring. Another is substandard tools and technologies, which can absorb a lot of an employee’s time and attention. You can, and perhaps should hold people accountable for overcoming these sources of difficulty. Just keep in mind that what you’re really doing is holding them accountable for overcoming barriers you put in their path, rather than holding yourself accountable for removing the barriers.

Yes, sometimes the root cause of a problem really is the result of an employee just flubbing an assignment. Your next task still isn’t finding a punishment that fits the crime. It’s finding out what caused the employee to flub the assignment. If the cause was insufficient training, excessive workload, or conflicting work direction (often the result of “matrix management” — a structural flaw), holding the employee accountable won’t fix anything. You might address a symptom temporarily, but address the root cause? Not a chance.

If the cause was bad character or simple, chronic incompetence, you also won’t fix it by holding the employee accountable. You’ll fix it by separating the employee from his or her job, terminating bad employees and reassigning incompetent ones to roles better suited to their aptitudes, if that’s possible.

Nothing ever get fixed by holding employees accountable as the phrase is usually used. Punishment rarely accomplishes anything, and the threat of punishment results in blamestorming sessions that preclude discovery of the actual source of the difficulty. Even when the phrase is used properly, meaning you insist the responsible employee fix the problem and prevent future recurrences, it’s only a cure for a very specific, limited set of causes.

So when a problem arises because of a lack of diligence, attention to detail, or persistence on the part of an individual employee, by all means hold that employee accountable. In any other situation, you’re just taking the lazy way out. That’s a bad idea.

Because someone might hold you accountable for it.

Comments

|In: Leadership|Last Updated:

“I don’t want to know the larger context. Just tell me what the program has to do, and I’ll write the code that does it.”

A programmer said this during an IT Effectiveness Assessment my company, IT Catalysts, performed for one of our clients. Or, to be more accurate, at least one programmer has said something along these lines in every IT Effectiveness Assessment we’ve performed. It’s an awful way to approach the job of programming, and in particular it’s an awful way to approach a career in programming, assuming you don’t want to see your job moved offshore.

It isn’t only programmers who think this way. So do many managers, at all levels of any organization. Only instead of resulting in good code that yields pointless results, managers who focus solely on their own responsibilities lead business functions that are highly effective internally, but thoroughly disruptive to the company as a whole.

You can’t optimize the whole by optimizing the parts, whether you’re designing a car, a software system, or an IT organization. Don’t believe me? Let’s look at yours.

Being an optimizing kind of person, you tell your managers to focus on their areas of responsibility, optimizing every aspect of their operation. If they each run their area at maximum efficiency, you explain, the whole organization will run at maximum efficiency.

The Help Desk manager takes your advice to heart, and immediately starts optimizing. “I want productivity to increase,” she tells her analysts. “That means shorter calls. If you can’t resolve a user’s issue within three minutes, escalate it and get onto the next call.”

Help Desk productivity soars — every analyst handles more calls per hour. As a fringe benefit, unexpectedly lower call volumes result in time-in-queue statistics improving as well.

Of course, the only reason the Help Desk is doing so well is that it has shifted the difficult work to other areas. Many end-users, not willing to call the Helpless Desk (as they now call it since it escalates any problem that can’t be solved with a reboot) call their favorite analyst directly, interrupting project work to ask an expensive developer to solve what had previously been taken care of by Help Desk staff. Help Desk optimization has reduced productivity throughout the rest of IT.

And those end-users who do still call the Help Desk now wait a day or more for their problems to be resolved, as the analysts to whom problems are dispatched squeeze the unexpected work into their schedules. Here, Help Desk optimization has reduced productivity throughout the company.

Think you can solve this by redefining “optimize” around some other measure … say, the percentage of calls resolved by the Help Desk staff? Think again. Gauged against this measure, no Help Desk analyst will ever escalate a problem, since every escalation is now defined as a failure.

The only measures that work are those that include areas external to the Help Desk: Total elapsed time for problem resolution, total effort needed for resolution, and total cost of resolution. Optimizing the process of helping end-users requires sub-optimizing both the Help Desk and the various organizations to which the Help Desk escalates problems.

And sometimes, when problem escalation would disrupt some other critical process, end-user support has to be sub-optimized, recognizing that an additional delay in resolving some complaint or other is outweighed by (for example) the need to allow key developers to focus on a time-sensitive project.

You can’t optimize the whole by optimizing the parts. When you try to do so, all that happens is that each part ends up optimizing itself at the expense of other areas, and of the whole organization.

Which is to say, “I got mine, Jack. You take care of your own problems,” is something less than the epitome of good design.

Comments