Optimizing the organization

“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.