All Posts in Organizational Design

|In: Leadership|Last Updated:

Harriet Wasserman writes:

We just came back from Stockholm where we visited the Vasa ship exhibit. In 1600 something, the king modified plans for his giant ship, to make it bigger and with more guns. His shipwrights (comparable to our engineers) told him he couldn’t add enough ballast and would have problems. He insisted, and they constructed the giant ship, covered with gorgeous carvings and carrying about a zillion guns. It got out into Stockholm harbor, tipped because of too little ballast, all the guns rolled to one side, and it sank. It was retrieved in 1963. The design story is all too familiar.

Core Principle #1 of the KJR Manifesto states that in order to optimize the whole you must sub-optimize the parts. It isn’t original (although I’ve been unable to track down its author). And it raised an objection in the correspondence I received in response to last week’s column that introduced the KJR Manifesto‘s core principles.

The objection was entirely reasonable. Paraphrasing, it’s that optimization never makes sense except in the concept of the larger whole, but that a naive manager, reading this catch-phrase, could use it as an excuse for poor operating discipline.

It’s a fair criticism. It can be applied to nearly any succinct statement of principle. That’s why each core principle is accompanied by explanatory text. It also raises a larger subject that’s well worth exploring: That in organizational design, when it comes to parts and wholes, “whole” is purely a matter of choice.

Consider General Electric. It’s pretty much run as a holding company. The point of optimization for GE isn’t the whole corporation — it’s the individual business units. They aren’t evaluated according to their functional contribution to the larger entity. Each must be one, two or out all by itself. That stands in contrast to Costco or Nucor, whose parts optimize Costco and Nucor, respectively.

Or take the pre-SBC-acquisition AT&T. Its point of optimization was the shareholder, and optimization was defined in terms of the price of a share of stock. It certainly wasn’t the company itself or any of its business units. The word that comes to mind when describing those is “pathetic.”

CEOs are responsible for clearly defining what gets optimized — the enterprise, individual business units, product lines, or what-have-you. Call that the Optimization Unit. Whoever is responsible for each Optimization Unit defines optimization priorities (perhaps cost, then speed, then quality), and aligns systems and structures with them.

Those who manage the divisions that make up an Optimization Unit deal with more complexity than the Optimization Unit manager, because any change … any improvement they might want to make in their own division … could have an impact on one or more of the other divisions in the Optimization Unit, as was the case with the Vasa and its improved armaments. And unlike physical engineering, organizational engineering is an imprecise discipline under the best of circumstances.

This analysis leads to the potential for conflicted IT. Imagine an enterprise that adopts a holding company structure, like GE. Now imagine a central IT organization that tries to support the enterprise. One IT organization that has to support multiple, autonomous Optimization Units won’t be able to sub-optimize its own operations in a consistent rational way.

Which is why, I think, CIOs in this position usually choose to either establish IT as an internal outsourcer, or to structure IT as an “organizational mirror” with separate departments, each aligned to a business unit.

Most managers, up to and including the Board of Directors (and, it appears, some Swedish kings) don’t understand this principle at all, figuring global optimization is nothing more than the sum of local optimizations. So they set up systems that assess the performance of sales, procurement, manufacturing, and distribution in isolation. I know this from personal experience, having been responsible for the manufacturing budget once upon a time. We were to develop our budget in isolation from sales forecasts. Predictably, the CEO pushed Sales to increase their forecast, and simultaneously pushed Manufacturing to reduce its budget. You can guess what happened next.

With all of the above in play, I don’t mind “sub-optimize the parts to optimize the whole” at all. It is catchy. More important, the phrasing requires executives and managers to figure out what constitutes the “whole” and their relationship to it, and to recognize that they can’t make choices in isolation.

A longer essay doesn’t do the job, because they’ll never read it … unless the catchy phrase first grabs their attention.

Comments

|In: Leadership|Last Updated:

We organized the KJR Conference on the theory that Keep the Joint Running is as much a community as it is a weekly column. The theory proved out: At our reception the first evening it was clear we didn’t have attendees. We had a bunch of old friends who were meeting for the first time.

Our most adventurous effort was to start work on the KJR Manifesto. Among the challenges: Nobody at the conference, including me, was sure exactly what the KJR Manifesto would turn out to be. We still aren’t certain, but we made a start.

The concept is simple: Provide an alternative to what’s usually bandied about as “best practice,” in a form that’s immediately useful to working IT managers, because much of what the industry calls “best practices” are nothing of the sort.

Many are descriptions of what one or two large corporations do and like, applied as prescriptions for every company regardless of whether they fit the circumstances or not. They’re one-size-fits-nobody recommendations. Other best practices aren’t practices at all. ITIL, for example, is more of a classification scheme, describing what rather than how. Then there’s a point that emerged from our Sarbanes-Oxley discussions: In many cases, “best practice” really means “basic professionalism.”

Lest any reader be uncertain: Keep the Joint Running is in favor of basic professionalism.

We started creating the KJR Manifesto with a set of core principles for IT, ending up with a Codd and Date dozen (although like the Pirates Code in Pirates of the Caribbean, they’re really more guidelines than principles). They are:

0. There is no best practice. There are practices that fit best. Different situations call for different solutions — form follows function.

1. To optimize the whole you must sub-optimize the parts. Being clear about where your company wants to optimize is critical to organizational design. Doing so doesn’t absolve managers from their responsibility to make their organizations as effective as possible. It redefines “effective” to prevent organizational silos from competing with each other instead of the company’s competitors.

2. Big solutions that work great generally start as small solutions that work acceptably. In general, putting something into place and iterating is a more certain route to success than trying to “get it right the first time.”

3. Relationships Precede Process. Process is often important. But it doesn’t come first, since no process can succeed until its participants trust each other.

4. Relationships Outlive Transactions. Conflict is natural. Conflict is good — it means employees actively and openly explore new and different ideas, consciously deciding among them. It’s when conflicting parties view each other as enemies instead of opponents that the organization becomes dysfunctional. You might win today; you might lose tomorrow … but when you lose your ability to work together, everyone loses.

5. There are no IT projects. Projects are about changing and improving the business or what’s the point?

6. Measure carefully, because bad metrics are worse than no metrics. You get what you measure. If you measure the wrong thing, or measure the right thing wrong, you’ll get wrong results.

7. Incomplete metrics create organizational dysfunction. If four factors combine to drive success, and you only measure two of them, employees will ignore the other two. Your metrics will have prevented success.

8. Governance must be value-based, not cost-based. Value is the difference between (or ratio of) benefit and cost — cost by itself is an incomplete metric. If you can’t connect cost and benefit, or only measure cost, you’ll reduce the value you deliver, while creating organizational dysfunction.

9. Benefit has three core components: revenue enhancement, cost reduction, and risk mitigation. Everything else fits into one of those three categories.

10. Benefit belongs to the business. When IT focuses on reducing its own costs or headaches, it stops enabling solutions, becoming a barrier instead.

11. IT is an integral part of the business. Run IT in a businesslike way, not as a separate business. Running IT as a separate business violates Guideline #1.

12. Every part of the company, including IT, has the same customers. These are the people who make buying decisions about the company’s products and services. When IT (or anyone else) has internal customers, very few employees have a stake in making sure the people who decide to buy from the company have any reason to do so.

These principles (okay, guidelines) are, like the rest of the manifesto, a work in progress. I welcome your comments, and will use them to refine things.

I have to. Otherwise I’d be violating Guideline #2.

Comments