Centralise, Devolve, Repeat: Why the Pendulum Keeps Swinging
Most organisations centralise a function, undo it a few years later, and centralise it again after that. Each swing is argued well and costed carefully — and each one is judged on the half of the trade-off that happens to be countable.
Procurement, IT, HR, finance. Pick one and look back fifteen years, and you will usually find it has been centralised, broken up and centralised again.
Each of those decisions was taken by capable people with a decent case. That is the part worth explaining.
1. Both Cases Are Genuinely True
Centralising removes duplication. One team, one contract, one system, one way of doing things — and the savings are real.
Devolving improves fit and speed. The people making decisions understand the business they are making them for, and they answer to somebody who feels the consequence.
Neither is a fashion. Each is an accurate description of a real problem, and each becomes the answer when that problem is the one currently hurting.
2. Only One Side of the Trade Is Ever Counted
Duplication is countable. You can name the four contracts, the three systems and the eleven roles doing similar work, and put a number against removing them.
The other side does not count as easily. Slower response, decisions taken by people who have never met the operation, a queue for things that used to take an afternoon — none of it lands in a spreadsheet.
Every swing trades a visible cost for an invisible one, and is judged only on the visible half.
3. The Trigger Is Usually an Event, Not a Strategy
Watch how these decisions start. A cost review lands, and centralisation becomes obvious. A serious service failure lands, and devolution becomes obvious.
The direction is set by whichever failure happened most recently, which is why the cycle has roughly the period of a leadership tenure.
That is not cynicism. Recent, vivid problems are simply more persuasive than diffuse ones.
It does mean the analysis usually follows the direction rather than setting it — which is why these papers read as unusually confident.
4. The Real Variable Is How Similar the Demand Is
There is a question underneath all this that is rarely asked directly. How similar are the things the business units actually need?
Where demand is genuinely common — payroll, statutory reporting, network operations — centralising works, and the standard product serves nearly everybody.
Where demand differs in ways that matter to customers, a central function ends up running a long queue of special cases. The savings then arrive, and so does a growing sense that nobody is being served properly.
5. Structure Is Not Usually What Failed
Look at a shared service that people complain about and the structural design is rarely the cause.
More often it is that nobody agreed what the service actually is, no one owns the outcome end to end, and a business unit has no route to get something changed within a reasonable period.
Those faults survive both structures intact. Move them to a devolved model and they reappear in six local versions instead of one. The test is straightforward — if a complaint would survive a change of structure, structure is not what caused it.
6. Nobody Prices the Switch
Each swing carries a cost that never appears in the case for making it:
- eighteen months of senior attention that could have gone somewhere else
- people who understood the exceptions leaving during the transition
- relationships between functions rebuilt from nothing
- two operating models running at once while the change beds in
Do that every five years and a good deal of the saving from either model has been spent moving between them.
7. Ask Which Failure You Prefer
There is no configuration in which both costs disappear. The choice is between a system that occasionally duplicates effort and one that occasionally fits nobody very well.
Stated that plainly, the conversation improves. It stops being about the right structure and starts being about which risk this organisation, in this market, would rather carry.
Most leadership teams have never had that conversation directly — only the version where one option arrives already presented as obviously right.
8. Then Make the Interfaces Do the Work
Once the direction is chosen, most of the value comes from things that have nothing to do with the org chart. Define the service. Name who owns the outcome. Publish how a business unit gets something changed, and how quickly.
Get those right and either model performs acceptably. Get them wrong and the pendulum will swing again — on schedule.
The question is not whether to centralise. It is which of the two failures you would rather be explaining in three years’ time.