Who Gets to Decide: Centralization vs. Decentralization

Hierarchy, Span of Control, and Layers was about the shape of the org — how steep it stacks and how far a message has to travel to reach the top. This page is about something that shape enables but doesn’t settle: once a message reaches a given level, who actually gets to make the call? You can have a tall hierarchy where the front line still decides most things, or a flat one where nothing moves without the founder’s blessing. Height and decision rights are related, but they are not the same lever.

This is the single most consequential structural choice a company makes, and the one it never stops arguing about. Push decisions to the top and you buy consistency and control. Push them to the edges and you buy speed and local knowledge. There is no setting that gives you both, which is why every growing company re-litigates this balance every few years. This page gives you a way to read where a company has landed, why, and what it’s paying for it.

The core trade-off: consistency versus speed

Strip away the jargon and centralization is just this: how far from the actual work is the person allowed to decide?

• Centralized means decisions concentrate at the top or in a central function. The front line executes; someone above them chooses.
• Decentralized means decisions are pushed out to the edges — to local managers, individual teams, the people doing the work.

Neither is “modern” or “backward.” Each buys something real, and pays for it somewhere else.

CENTRALIZED (decide at the top)        DECENTRALIZED (decide at the edges)
  + consistency across the whole org     + speed — no waiting for approval
  + control, one clear standard          + local knowledge used directly
  + easy to change direction at once     + people closer to the problem
  - slow — everything waits in a queue   - inconsistency between units
  - top is far from the real detail      - duplicated effort, drift

Here’s the mechanism underneath both columns. The top of an org has the widest view — it sees the whole company, all the customers, the full budget. But it is far from the detail: it doesn’t know this particular customer, this particular machine, this particular shift. The edge is the reverse: it has almost no view of the whole, but it knows the detail intimately, because it’s standing in it.

So the trade-off is really a question about information. Centralize, and decisions are made by people with broad context but thin local detail. Decentralize, and they’re made by people with rich local detail but no view of the whole. The art is matching each decision to wherever the information that decides it actually lives — a point we’ll come back to, because it’s the whole game.

In practice — the same request, two answers

A customer at a hotel front desk asks for a late checkout. In a decentralized hotel, the desk clerk glances at the day’s bookings and says “sure, no problem” — decided in ten seconds by the person who can see the actual room situation. In a centralized one, the clerk says “let me check with my manager,” who checks with their manager, and the guest waits while a simple call travels up and back down a chain. The centralized version isn’t stupid — it guarantees the answer is consistent with policy and no clerk gives away rooms the hotel needs. But for a decision this small and this local, the speed cost is obvious, and the guest feels it.

What tends to be centralized — and what gets pushed out

Mature organizations rarely go all-in on either extreme. They split the difference by topic: some kinds of decisions are pulled to the center, others are deliberately handed to the edges. The pattern is remarkably consistent across industries, and once you see it, it stops looking arbitrary.

Things that tend to be centralized — because a single inconsistent choice can damage the whole company:

• Brand and identity. How the company looks, speaks, and is seen. One rogue logo or off-message campaign harms everyone, so this sits centrally.
• Finance. Who can spend how much, on what. Money leaks and fraud thrive on scattered, unaccountable spending, so authority to commit funds is tightly held and tiered.
• Legal and compliance. Contracts, regulation, anything that can get the company sued or shut down. The downside of one bad call is catastrophic and shared, so it’s centralized.
• Safety. In a hospital, factory, or airline, safety standards are never a local preference. One ward inventing its own hygiene rules is a disaster, so safety is dictated from the center and audited.

Things that tend to be pushed to the edges — because local knowledge decides them better than a distant executive could:

• Day-to-day operational calls. Which task goes first, how to handle this shift, how to solve today’s small problem — the people present decide, because only they can see the situation.
• Local adaptations. A store in one city stocking differently from one in another, a support agent bending a rule for an obviously reasonable customer.
• Small product tweaks. A team adjusting a feature or workflow they own, without a company-wide committee.

Notice the logic that sorts the two lists. The higher the cost of an inconsistent or wrong decision to the whole company, the more it gets centralized. The more a decision depends on local, on-the-ground detail, the more it gets pushed out. That single principle explains most of what you’ll see.

The common trap — centralizing by fear, not by logic

The clean logic above is what companies say they do. What often actually happens is that decisions get centralized not because inconsistency is costly, but because someone senior got burned once and never wants to be surprised again. One bad hire leads to every hire needing VP sign-off. One overspend leads to every purchase over fifty dollars needing three approvals. Each rule feels prudent in isolation, but the accumulated weight is an org where nobody at the edge can do anything, and everything queues at the top. The test isn’t “could this ever go wrong?” — everything can. It’s “is the cost of it going wrong high and shared enough to justify making everyone wait?”

The real rule: put the decision where the information is

Everything above collapses into one principle worth memorizing:

Decision rights should live wherever the best information to make that decision lives.

This is the honest core of the centralization debate, and it cuts through most of the politics around it. When you feel a decision is being made in the wrong place, it’s almost always because decision rights and information have come apart:

• A too-centralized call is one where the person deciding is far from the information — a head-office executive choosing how a single store should be laid out, when the store manager can see the actual foot traffic and the exec cannot. The decision is slow and worse.
• A too-decentralized call is one where the deciders each have local information but nobody has the whole picture — twelve teams each independently picking a different tool, when a single company-wide choice would have been cheaper and interoperable. Every local decision was reasonable; the sum was a mess.

So the goal is not to centralize or decentralize in general. It’s to route each type of decision to the level that holds the information that decides it — and to move decision rights when the information moves. If the front line starts collecting data the center used to hold, the decision should follow the data outward.

The evidence — pushing decisions down is a recurring management finding

A long thread in management thinking, from decentralized command in military doctrine to lean manufacturing to modern “empowered team” writing, keeps landing on the same conclusion: for fast-moving, information-rich decisions, authority given to the people closest to the work generally beats authority held at the top. The oft-cited reason is that local operators see and respond to changes long before the information could travel up a chain and back. The finding is robust in direction, though the right amount is always situational — the same literature is equally clear that safety, financial, and standards decisions belong at the center. Treat “push decisions down” as a strong default for local calls, not a universal law.

How this interacts with structure and hierarchy

This choice doesn’t live on its own — it sits on top of the org chart and the hierarchy you already met, and it can quietly cancel out or amplify them.

The key thing to see is that structure and decision rights are separate dials. A tall hierarchy tends to centralize (there are many rungs to climb, and each is a chance for someone to reserve the call), and a flat one tends to decentralize (fewer rungs, so authority naturally sits closer to the work). But the link isn’t automatic:

                 Decisions at TOP        Decisions at EDGE
  Tall org    |  classic bureaucracy  |  delegated hierarchy
              |  (slow, consistent)   |  (layers, but empowered fronts)
  Flat org    |  founder bottleneck   |  autonomous teams
              |  (few layers, but     |  (fast, may drift)
              |   nothing moves)       |

That “founder bottleneck” square is the one that surprises people. A startup can be gloriously flat — three layers, everyone one step from the boss — and still be brutally centralized, because the founder insists on approving everything. The chart looks decentralized; the decisions aren’t. Reading a company means checking both dials, not assuming the shape tells you where power sits.

The structure choice matters here too. A divisional org — grouped by product or region — is already a bet on decentralization: it exists precisely so each division can decide for its own market. A functional org — all of one discipline together — leans centralized within each function, because there’s one head of engineering, one head of sales, setting one standard. Choosing a structure is partly choosing where decisions will naturally fall.

Case study — Amazon’s “two-pizza teams” as decentralization by design

In the 2000s, Amazon organized much of its work into small, autonomous “two-pizza teams” — teams small enough to be fed by two pizzas — each owning a service end to end and empowered to decide and ship without wide sign-off. The intent was explicitly to push decisions to the edges so the company could keep moving fast as it scaled, avoiding the queue-at-the-top slowdown that kills large organizations. What’s instructive is what Amazon didn’t decentralize: financial discipline, and the technical standards that let all those independent teams’ systems still talk to each other. The lesson isn’t “decentralize everything.” It’s that you can hand out local speed only if you centralize the few standards that keep the independent pieces from drifting into chaos. Exact team sizes and rules varied and evolved; the design principle is the durable part.

Reading the dial: signs a company has gone too far either way

Because there’s no correct setting, the practical skill is spotting when a company has drifted too far one way. Each extreme has a recognizable smell.

Signs it’s too centralized:

• Bottlenecks. Work piles up waiting for one person or one committee to approve it. The queue is at the top, and it never clears.
• Slow, distant decisions. Simple local calls take weeks and come back wrong, because the decider couldn’t see the detail.
• Learned helplessness. This is the quiet, corrosive one. When people are never allowed to decide, they stop trying. They escalate everything, even things they could clearly handle, because deciding has only ever gotten them in trouble. The org has trained its own edges to be passive — and then complains they lack initiative.

Signs it’s too decentralized:

• Inconsistency. The same company gives different customers wildly different answers; two branches feel like two different businesses.
• Duplicated effort. Multiple teams independently build the same thing, buy the same tool, or solve the same problem — nobody had the whole view, so the work was done three times.
• Drift. Local units quietly wander away from the shared standard, brand, or strategy — each step reasonable, the cumulative distance large.

The common trap — treating the symptom as the disease

When bottlenecks appear, the instinct is “decentralize!” — and when inconsistency appears, “centralize!” But swinging the whole company one way to fix one department’s problem usually just relocates the pain. The mature move is surgical: identify which specific decisions are stuck in the wrong place, and move only those. Often a company isn’t uniformly too centralized — it’s centralized on three decisions that should be local and decentralized on two that should be shared, all at once. “Move decision rights, don’t flip the whole org” is almost always the better fix.

Try this

Pick one decision you or your team make regularly that feels slow or frustrating — a purchase, an approval, a customer exception, a scheduling call. Trace it: who actually holds the right to say yes, and where does the information that should drive that decision actually live? If the two are in different places — the decider is far from the detail, or the person with the detail can’t decide — you’ve found a mislocated decision right. Write one sentence proposing where it should sit and why, framed as information, not preference. That sentence is exactly how a good delegation or escalation conversation starts.

Reflect

1. Name one decision at your work that feels centralized in the wrong place — made by someone too far from the detail. Where does the information that should drive it actually live?
2. Name one that feels too decentralized — where local calls are reasonable individually but add up to inconsistency or duplicated effort. What single shared standard would fix it without killing the local speed?
3. Look at your own team: are you holding decision rights you should push down? What’s the real reason you’re holding them — genuine risk, or a past scare?
4. Is your organization tall-and-centralized, flat-and-decentralized, or one of the surprising mixes (a flat founder bottleneck, or an empowered tall hierarchy)? Which does its behaviour say, versus its org chart?
5. Recall a time you stopped taking initiative because deciding had gotten you in trouble before. Was that you — or was it the org training its edges into learned helplessness?

Show reflections

1. The tell is a decision that is both slow and frequently wrong — that combination almost always means the decider can’t see the detail. The fix isn’t to complain that the decider is bad; it’s to notice the information lives at the edge and argue, on those grounds, for moving the call there.
2. Good answers resist the urge to “centralize everything back.” The skill is finding the minimum shared standard — one tool, one policy, one template — that removes the inconsistency while leaving the genuinely local decisions local. You’re separating the part that needs to be uniform from the part that benefits from local judgment.
3. This is the honest one, aimed at your own behaviour as a manager. Most over-holding of decisions traces to a specific past scare, not a present risk. Naming that lets you ask the real question: is the cost of a rare mistake at the edge actually higher than the daily cost of the bottleneck and the learned helplessness you’re creating?
4. The point is to check both dials — shape and decision rights — independently. The surprising mixes are the instructive ones: a flat startup where nothing moves without the founder, or a big tall company whose front line is genuinely empowered. What the org does is the truth; the chart is only the claim.
5. This reframes a personal frustration as a structural symptom. If you’ve gone passive, it’s often a rational response to an org that punished deciding — not a character flaw. Seeing it that way is the first step to either reclaiming the decisions you can safely make, or naming the pattern to whoever can loosen it.