The Reorganization Reflex: Backbone Before Boxes

Executive Summary

Every organizational chart I have been handed came with the same instruction, phrased as though it were a courtesy: the structure has been decided, so make the systems fit it.

I am almost never asked the question that should have come first. Not how do we implement this, but why this, and why now, and what did we consider instead. By the time the diagram reaches anyone who has to operationalize it, the expensive decision is already behind us, and what remains is the work of making a settled thing function.

I wrote recently that an operating model is a schema somebody eventually has to implement: decision rights are an authorization model, a service catalog is an interface contract, an employee lifecycle is a state machine. That piece named the parts. It did not say when to build them, or what they cost you when the structure arrives first. This one does, and the answer runs against the instinct I started with.

Why does reorganization fail so often?

Not because companies do it too much. Because they rebuild the foundations every time they do it.

I want to concede the strongest version of the opposing case first, because it comes from people who have studied this more closely than I have and it is more persuasive than the caricature. McKinsey’s Aaron De Smet and Shannon Hennessy argue, in a conversation on the rules that make reorganizations work, that restructuring is not an event to be survived but a capability to be developed. Hennessy: “I see reorganization as a way of life in today’s corporate environment,” with most companies “conducting a pretty big reorganization every couple of years.” De Smet is blunter about the necessity: “it’s getting harder and harder to stay competitive if you don’t reorganize fairly frequently.” [Source: Aaron De Smet and Shannon Hennessy, “Reorganization rules that work,” McKinsey Podcast, November 2016]

That is a direct challenge to anyone whose instinct is to counsel restraint, and I think it is correct. Structural change is not inherently the problem.

The same conversation supplies the number that complicates it. “Only about 23 percent of reorganizations are deemed successful by the companies as they look back on them,” De Smet says, adding that among the failures, “most of the failed attempts actually unwound a number of the changes they had made because they weren’t working.”

Hold those two findings together, because the resolution is in the tension. Reorganizing frequently is necessary. Reorganizing frequently is also, as practiced, mostly unsuccessful and often reversed. That is not an argument for doing it less. It is an argument that the thing most companies do when they reorganize is the wrong operation.

The backbone and the layer above it

De Smet’s own resolution is the most useful idea in the transcript, and he reaches for a technology analogy to make it.

Some elements of an organization are meant to be stable — the platform that does not change often. Others are meant to be fluid. The failure is treating everything as one layer, so that any change requires rebuilding the whole thing. His image is a smartphone: hard-wire every capability into the hardware and operating system, and adding one new function means designing a new phone. Leave the platform deliberately minimal and open, and new capability arrives as an app. “The minimum spec hardware and operating system on which I can apply dynamic capabilities,” as he puts it. “In some ways, a natural fluid reorganization would be deleting one app and adding a new one.”

Any architect will recognize this immediately, because it is the argument for a platform layer, and it is the same argument whether the thing being built is software or a company.

What belongs in the organizational backbone is unglamorous and specific, and it is the same three items the schema reading arrives at from the systems side — there they appear as an authorization model, an interface contract, and a state machine:

Decision rights. Who decides, who is consulted, who executes, written down and published. Hennessy names role clarity as “oftentimes one of the biggest failure modes” of a reorganization — and role clarity is a backbone property, not something a new box on a chart confers.
Service definitions. What each function delivers, to whom, at what standard. Boundaries that get argued case by case feel like a structure problem and are almost always a definition problem.
Systems that hold the transactional load. De Smet’s warning here is pointed: companies “take the cost and the people out before they have actually built the systems that fully automate what they’re trying to do. That can be disastrous.”

Build those, and structure becomes genuinely fluid — reporting lines can be redrawn without relitigating who decides what, because that was settled at a layer the redraw does not touch. Skip them, and every reorganization is a platform rebuild, which is precisely why the typical one is disruptive, slow, and, per De Smet, so often partially unwound.

The 23% figure is not evidence that reorganization is a bad instrument. It is evidence that most organizations have no backbone, so every structural change is a full-stack rewrite performed live.

Why the structure cannot simply be imported

This is where the HR business partner model is worth examining closely, because it is so often adopted as a backbone replacement when the actual need sits in the layer above.

Ulrich’s own framing does not support importing it. When Ulrich, Younger and Brockbank described an HR organization directly, in The twenty-first-century HR organization in Human Resource Management in 2008, they built it on a premise stated at the outset: the HR organization should be structurally aligned with the structure of the business. [Source: Ulrich, Younger & Brockbank, Human Resource Management, 2008] They then derived different answers for different business shapes — a holding company, a diversified or allied group, a single integrated business.

That is a derivation, not a template. The structure is downstream of what the enterprise already is.

The scale conditions sharpen it further. Practitioner guidance converges, if loosely, on a scale condition: the three-legged structure suits mid-to-large organizations, commonly put at somewhere between five hundred and a thousand employees and upward with multiple units or geographies, because that is where transaction volume justifies a dedicated service function and headcount justifies specialist depth. The figure is a rule of thumb rather than a research finding, and sources disagree on where exactly it sits. Below roughly five hundred to a thousand people, the guidance runs the other way: a lean generalist model, because maintaining three separate legs costs more than separating them returns.

De Smet says the thing I would otherwise have spent three paragraphs saying: “Don’t look at a best practice and feel like you should copy it just because somebody said it was a best practice. Use it to inspire you, inform you, educate you.” And on benchmarks generally: “don’t let the benchmark make the decision.”

Hennessy’s account of how that plays out in a room is worth repeating in full, because every advisor has watched some version of it. A client looked at the peer comparisons and said, “Tell me which one of these companies looks exactly like us.” Her answer was “None.” The useful conversation started only after that — running through roughly twenty things peer companies did, of which five to ten turned out to be applicable, and applicable in ways the client had not considered.

None means none. It does not mean the exercise was worthless. It means the output is inspiration, and the decision still has to be derived.

What to exhaust before redrawing anything

If the backbone is missing, build the backbone. The items are cheaper, faster, and reversible, and they are the same list whether or not a restructure eventually follows:

Decision rights, because most problems presented as structural are unresolved authority. This costs a workshop and a document, changes behavior within weeks, and can be revised when it is wrong. De Smet’s meeting test is a good diagnostic: if a decision meeting has ten decision makers, the problem is not the org chart.

Service definitions, because naming what a function owes resolves a surprising share of what looks like a boundary dispute.

Capability, because a partner layer can be underpowered by the people rather than the boxes. Reorganizing around a capability gap relocates it.

Systems, because if the load is genuinely transactional and high volume, absorbing it in software is faster and cheaper than absorbing it in a new department — and, per De Smet’s warning, must be built before the headcount comes out, not after. This is where spending discipline pays better than headcount.

Then reorganize, as often as the business genuinely changes. On a real backbone that is a normal operation rather than a ten-month ordeal. Explaining that sequence to a board is a more useful contribution than delivering the redesign they asked for.

The Mistakes I Keep Seeing

1. Copying the visible artifact of someone else’s decision. The emulated company adopted its structure at a scale and shape the emulator does not share, usually years earlier, usually after trying cheaper things. What travels between companies is the diagram. What does not travel is the derivation that produced it, and the derivation was the valuable part.

2. Treating structure as free because nobody invoices for it. A restructure has no line item, which is exactly why it escapes the scrutiny applied to a system costing a fraction as much. Technology investments arrive with a decision framework attached; organizational ones arrive as leadership prerogative. Price the disruption and the comparison changes.

3. Reorganizing the backbone when the problem is in the layer above. This is the expensive version of the mistake and the hardest to see, because the symptoms are real and the proposed fix is coherent. The tell is whether anyone can state, before the redesign, who currently decides what. If they cannot, the reorganization is about to rebuild a foundation that was never poured.

Frequently Asked Questions

Is the three-legged model wrong?

No. At sufficient scale the logic is close to unavoidable, because separating transactional, specialist, and partnership work genuinely does make each better. The error is treating a scale-dependent derivation as a universal template. A design that pays handsomely at ten thousand employees and costs money at three hundred is not wrong; it is conditional, and the condition is the part that gets lost in transit.

How do you tell a structural problem from a capability problem?

Ask whether a demonstrably excellent person could succeed in the role as currently defined. If yes, and the incumbent is struggling, it is capability or fit. If no — if the authority does not match the accountability, or the work is split across people who do not report to each other — it is structural. Most organizations skip the question, because the diagnosis is uncomfortable in a way that redrawing boxes is not.

We already adopted the structure and it is not working. Now what?

Resist the second restructure. It is the most expensive available response and the most common one, and De Smet’s finding that failed reorganizations mostly get partially unwound suggests how those end. Ask instead which backbone elements were skipped on the way in. Decision rights and service definitions can be built underneath an existing structure without touching the chart, and in most cases that is the whole of the missing work.

Does this apply outside HR?

Yes. The HR version is simply the one with a named framework attached, which makes it easy to point at. Finance, legal, and IT all separate into strategic, specialist, and transactional layers at scale, and each field has its own imported model with its own missing derivation. Any function that describes its target state by naming another company’s org chart is making the same error in a different vocabulary.

What Travels and What Does Not

I set out to write the case against reorganizing, and the evidence would not support it. Companies that restructure frequently are responding correctly to a market that changes frequently. The instrument is not the problem.

What the research actually indicts is reorganizing without anything stable underneath — which turns a routine reconfiguration into a foundation rebuild, and produces a 23% success rate that gets misread as proof the whole exercise is futile. It is not futile. It is being performed at the wrong layer.

Ulrich wrote a derivation: given this business shape, this structure follows. What thirty years of adoption produced was the structure without the derivation, which is a diagram. Diagrams are procurable, arrive on a schedule, and present well to a board. Backbones take years and cannot be announced. That asymmetry, not any flaw in the framework, is what keeps getting rebuilt.

Specify the backbone, then redraw as often as the business genuinely demands. Those are two halves of one instruction, and almost every organization performs them in the wrong order.