Every few years an organisation reorganises. It pulls procurement, IT, or marketing into a central team to stop the duplication, then, a few years later, pushes them back out to the divisions because the centre had become slow and remote. The same company swings back and forth, each move a sincere correction of the last. If that sounds familiar, the problem is rarely the direction of the swing. It is that the choice was made for the whole organisation at once, when it should have been made one decision at a time.

The quick version

  • Centralisation means decision authority sits at the top or the centre; decentralisation means it is pushed down to the units, regions, or teams closest to the work. Most real organisations are a mix, not one or the other.
  • Centralisation buys you consistency, scale, and control. Decentralisation buys you speed, local fit, and ownership. You cannot maximise both at once, every design trades one for the other.
  • Organisations swing between the two because each extreme creates the pain the other cures. The swing is normal; treating it as a permanent fix is the mistake.
  • The better move is to decide function by function and decision by decision: centralise what benefits from scale and uniformity, decentralise what benefits from local knowledge and speed.

The idea in depth

Start with what the words actually point to. Centralisation and decentralisation describe where decision rights live, who gets to choose, not where people sit or how the boxes on the chart are drawn. A company can have regional offices all over the world and still be highly centralised if head office signs off every price, hire, and supplier. The opposite is just as common: a single building full of teams that each set their own course.

The cleanest way to sharpen this is Henry Mintzberg's distinction in Structure in Fives (1983) between vertical decentralisation, how far formal authority is delegated down the chain of command, and horizontal decentralisation, how far power flows sideways, out to analysts, specialists, and experts who aren't line managers at all. The two come apart in practice. A factory can delegate scheduling to the shop floor (vertical) while a central engineering group still dictates the standards everyone follows (horizontal control retained). So the question is no longer "are we centralised or decentralised?" but, for each important decision, down the line or out to a specialist, and how far.

An honest limitation. Mintzberg's configurations are a vocabulary, not a measuring instrument. They help you name what you have; they won't tell you the right amount of decentralisation for your business. For that you need the contingency view below.

Why there is no universally right answer

If one setting were always best, the pendulum would have stopped long ago. It hasn't, because the right design depends on the conditions. The foundational evidence here is Tom Burns and G.M. Stalker's study of around twenty Scottish and English firms in The Management of Innovation (1961). They found two viable patterns. Mechanistic organisations, centralised, rule-bound, hierarchical, performed well in stable conditions, where predictability and efficiency mattered most. Organic organisations, decentralised, fluid, with authority sitting wherever the relevant knowledge was, performed better under rapid change, where rigid hierarchy couldn't keep up. Neither was "better." Each fit a different environment.

That insight became the spine of contingency theory: structure should fit the situation, not a fashion. So read your own conditions honestly before you reorganise. Is the work stable and repeatable, where a standard done once and applied everywhere saves real money? Centralise it. Is it fast-moving and local, where the person on the spot knows things the centre never will? Decentralise it. The error is importing whatever the last conference or the last acquirer happened to favour.

flowchart LR
  A(["A decision to place"]) --> B{"Stable & repeatable,
or fast & local?"}
  B -->|"Stable, gains from scale
& consistency"| C(["Centralise
one standard, applied widely"])
  B -->|"Fast, needs local
knowledge & ownership"| D(["Decentralise
authority near the work"])
  C -.->|"centre grows slow
& remote"| E(["Pressure to push back out"])
  D -.->|"units duplicate
& drift"| F(["Pressure to pull back in"])
  E -.-> B
  F -.-> B
Each extreme breeds the pain that justifies the next swing, which is why the decision is better made case by case than once for the whole. Leaders Loop

This is also the historical pattern. Alfred Chandler's Strategy and Structure (1962) traced how firms like General Motors, under Alfred Sloan in the 1920s, moved away from a single centralised functional structure toward the multidivisional (M-form), autonomous divisions making day-to-day decisions, with a small central office handling strategy, capital allocation, and oversight. Chandler's enduring phrase is that structure follows strategy: GM decentralised not for its own sake but because a sprawling, multi-product strategy made central control unworkable. The lesson in miniature, decide what you're trying to achieve first, then place authority to serve it; don't redesign the chart and hope a strategy emerges.

The pendulum is real, design for it, don't deny it

Knowing the theory doesn't stop the swinging, and it helps to know why. McKinsey's analysis of corporate functions describes the dynamic plainly: functions move back and forth between centralised and decentralised modes, centralising first to capture efficiency and scale, then handing power back to business units to win speed and accountability ("Redefining corporate functions"). And they put their finger on a telling cause: the redesign is, in their words, "often prompted more by who is designing them" than by the evidence. When functional leaders hold the pen, things tend to centralise in pursuit of scale; when business-unit leaders weigh in, things decentralise in pursuit of control. The design reflects the designer.

Centralise what gains from scale and sameness. Decentralise what gains from speed and local knowledge. Re-ask the question when conditions change, not on a calendar.

So treat the design as provisional and make the reasoning explicit. When you centralise something, write down the benefit you expect, lower cost, one standard, less risk, and the cost you're accepting, slower turnaround, weaker local fit. Do the reverse when you decentralise. That record turns the next swing from a mood into a decision: when someone proposes pulling marketing back to the centre, you can check whether the conditions that justified pushing it out have actually changed, or whether you're just feeling the predictable ache of the current setting.

The most useful single test comes from Herman Vantrappen and Frederic Wirtz, writing in Harvard Business Review ("When to Decentralize Decision Making, and When Not To," December 2017). Their guidance, in plain terms: decentralise a decision when local knowledge and speed matter and the cost of an inconsistent answer is low; keep it central when consistency, scale economies, or the risk of a bad local call outweigh the benefit of responsiveness. Run a real decision through that filter and the answer is usually clearer than the all-or-nothing debate ever gets.

A worked example

Take a retailer with forty stores, call it Harbour & Co. (Illustrative throughout; this is a teaching example, not a real company.) After a rough year, the new operations director announces a centralisation drive: head office will now set pricing, promotions, staff rosters, and the product range, store by store. The logic is sound on paper, stop the inconsistency, capture buying scale, present one brand.

Six months in, two things are true at once. Centralised purchasing is a clear win: negotiating as one buyer instead of forty cut costs and ended the chaos of every store ordering differently, stable, repeatable, gaining directly from scale, textbook centralise. But centralised rostering is a quiet disaster. Head office can't see that the seaside store empties on rainy Tuesdays or that one branch sits beside a stadium with home-game surges. Schedules set from afar leave stores overstaffed when it's dead and short when it's slammed, local knowledge the centre will never hold, textbook decentralise.

flowchart TD
  A(["Harbour & Co.
'centralise everything' drive"]) --> B(["Purchasing
scale, one standard"])
  A --> C(["Pricing & range
brand consistency"])
  A --> D(["Rostering
needs local, real-time read"])
  B --> E(["Keep central
clear win"])
  C --> F(["Mostly central,
local override allowed"])
  D --> G(["Push back to stores
within a budget guardrail"])
The same reorganisation, sorted decision by decision, not every box belongs in the same place. Leaders Loop

The fix isn't to declare the whole drive a failure and swing back. It's to sort it. Purchasing stays central. Pricing and range stay mostly central for brand coherence, but with a documented local-override the store manager can use for genuinely local conditions. Rostering goes back to the stores, inside a labour-cost budget the centre owns. Harbour & Co. ends up neither centralised nor decentralised, but deliberately mixed, with each choice tied to whether the centre or the store holds the better information. That is what a working operating model actually looks like.

For the opposite extreme done on purpose, look at a real case: the Chinese appliance maker Haier, whose former chairman Zhang Ruimin broke the company into thousands of small, self-managing "microenterprises", radical decentralisation as deliberate strategy, described in his conversation with McKinsey. It works for Haier because its bet is on entrepreneurial speed and closeness to customers. It would be reckless for a business whose edge is uniformity and safety. Same axis, opposite answer, because the strategy is different.

Frequently asked questions

Is decentralisation always more modern or better?

No. Decentralisation is fashionable, but Burns and Stalker showed sixty years ago that centralised, mechanistic structures outperform in stable, predictable conditions. A payroll operation, an airline's safety procedures, or a regulated compliance process often should be centralised, consistency and control are the point. "Better" depends entirely on the environment and the strategy, not on which one sounds more progressive.

What's the difference between centralisation and just having a hierarchy?

They're related but not the same. Hierarchy is about reporting lines, who answers to whom. Centralisation is about where decision authority sits within that hierarchy. You can have a tall hierarchy that pushes real decision rights well down the chain (decentralised), or a flat one where a single founder still signs off everything (centralised). When you redesign, separate the two questions: how many layers, and who decides what.

Can we centralise some things and decentralise others?

Yes, and that's usually the right answer, not a compromise. The useful unit of decision is the individual function or even the individual decision, not the whole company. Most well-run organisations centralise where scale and consistency pay off (procurement, core IT, finance controls, brand) and decentralise where local knowledge and speed pay off (frontline service, hiring, day-to-day operations). The skill is sorting, not picking a side.

Why do we keep reorganising back and forth?

Because each setting eventually produces the pain the other setting cures, and because who runs the redesign tilts the outcome. Centralise and you'll feel slow and remote; decentralise and you'll feel duplicated and inconsistent. McKinsey describes functions oscillating between the two modes for exactly this reason. The way out isn't to find the one true setting, it's to make each placement deliberately, record why, and only re-open it when the underlying conditions genuinely change.

How do I decide where a specific decision should sit?

Ask three things. Who holds the best information to make this call well, the centre or the front line? How costly is an inconsistent answer across units, trivial, or serious? And how much does speed matter here? If the front line has the knowledge, inconsistency is cheap, and speed matters, decentralise it. If the centre holds the picture, consistency is critical, and a bad local call is expensive, keep it central. Vantrappen and Wirtz's HBR framework is essentially this test, written out in full.

Related in the Toolkit

Where decision authority sits only makes sense alongside the shape that carries it, the structures you choose, and the rules that say who actually decides what (decision rights). Those three together are your operating model.

Where to go next