All Posts in Organizational Design

|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

|In: Organizational Design|Last Updated:

The internal customer is dead. And it’s about time.

I had the pleasure of facilitating a panel discussion for the local chapter of the Society for Information Management (SIM) last week. On the panel were a CEO, CFO, and three CIOs. One question dealt with the preferred relationship between IT and the rest of the business — should IT be viewed as a supplier, a partner, or an “information utility,” whatever that means?

The panel was unanimous: The business works best when IT operates as an equal partner. “Internal customer” has outlived its usefulness. This is a remarkable transformation: Just five years ago, the notion that IT should view the rest of the business as its customer was pervasive.

IT’s adoption of the internal customer model has always required a degree of schizophrenia. “You’re my customer,” and “You have to adhere to our standards and policies or risk disciplinary action,” are awfully hard to harmonize, as is “We need the authority to stop users from loading whatever software they want on their PCs,” with “Our job is to do more than just satisfy our customers — it’s to delight them.”

The whole thing often smacked of a desire to avoid accountability: When you have internal customers, your role is to process orders. Business acumen is Someone Else’s Problem (SEP).

So is recognizing technology-driven business opportunities. As a nice counterpoint, one panelist described a new strategic initiative — the biggest in his company’s history. It’s a comprehensive redefinition of the company’s business processes, intended to consolidate duplicate efforts among its business units. IT first conceived of the effort, and championed it throughout the company.

Think it’s an inappropriate role for IT to take on? If so, ask yourself this: In a complex business, assembled through a combination of growth and acquisitions, what other organization will be in a position to recognize and champion this kind of opportunity? It’s either IT or accounting, and of the two IT is in a much better position to understand business processes.

In the most effective organizations, change is a collaboration between business and IT at all levels. Business and IT leaders collaborate to provide a shared picture of where the organization is going and how it’s going to get there, and to communicate a strong commitment to the effort, including the investment of money, staff and time. Business and IT middle managers collaborate to add the clarity that comes from knowing how the business really operates, and to provide trained, enthusiastic staff to implement the change, and when the time comes to insist that all employees migrate to the new way of doing business. Business and IT staff collaborate to sweat the details that are the difference between a great-sounding concept and something that works.

There are those who think this means dividing accountability, ensuring failure since no individual is responsible for the success of the program. But then, there are those who think that if everyone just does their job as defined by the company’s organizational chart that the business will somehow succeed. Both views are wrong, and for the same reason: To optimize the whole, designers usually have to sub-optimize the parts.

When the subject is business as usual, viewing your job as optimizing your part of the organizational chart means ignoring the larger needs of the business when the conflict with the needs of your department. When the subject is business change, making just one person accountable means everybody else is only responsible for the tasks assigned to them.

Organizational change does require a business sponsor, with ultimate responsibility for ensuring the program succeeds. That’s vital — the buck has to stop someplace.

Everyone else involved has to consider the success of the whole program to be their responsibility as well. If they don’t, it’s certain you’ll hear the equivalent of the defense contractor’s battle cry:

“Oh … you wanted wings on that airplane?”

Comments