Onpode
Cover art for Why growing bigger usually means moving slower — the coordination cost paradox

Why growing bigger usually means moving slower — the coordination cost paradox

August 5, 2026 · 7 min

Eliza Ward & Brian Reed

Coordination costs in organizations scale at roughly headcount to the power of 1.5–1.8, while revenue per employee grows closer to headcount to the 0.9 — meaning the gap widens by arithmetic as companies grow, not because of bad decisions. Even well-designed frameworks like the Spotify Model relocate overhead rather than eliminate it.

As organizations grow beyond small teams, they inevitably install coordination mechanisms—reporting hierarchies, approval processes, and cross-team dependencies—to manage complexity, ensure consistency, and control risk. These mechanisms are not optional: without them, larger organizations risk operational chaos and failure.

0:006:55
Get the next episode on Business

Follow it free — new episodes land in your feed.

Or make your own — any topic, in minutes

More Onpode episodes on Business

About this episode

Every company that's grown past a certain size has felt it: the org that used to move fast now needs three approvals to book a conference room. The easy explanation is bad management. The more unsettling one is that slowness is structurally baked in — and this episode makes the case for the latter. Coordination costs are estimated to scale superlinearly with headcount while revenue per employee grows more slowly. The gap widens not because anyone made a mistake, but because communication pathways multiply combinatorially as teams grow. Max Weber saw this a century ago: bureaucracy is genuinely efficient at coordinating large groups and genuinely rigidity-producing, and those two things are inseparable. The episode traces what happens when organizations try to engineer their way out — through agile-at-scale frameworks, squad models, flatter hierarchies — and why the coordination drag keeps coming back. The Spotify Model gets particular attention, partly because it was so influential, and partly because one of its own architects later acknowledged it was more aspiration than operational reality. What emerges is a clearer way to think about organizational speed: not as a culture problem or a talent problem, but as a question of where you choose to place unavoidable friction. The episode is honest about what the evidence can and can't tell us, which makes it more useful than most takes on this topic.

Frequently asked

Why do large companies move slower than small ones?

Coordination costs in large organizations scale at roughly headcount to the power of 1.5–1.8, while revenue per employee grows closer to headcount to the 0.9. As headcount rises, potential communication pathways multiply combinatorially, so coordination overhead widens faster than output — by arithmetic, not mismanagement.

Did the Spotify Model actually work?

Anders Ivarsson, who co-authored the original Spotify Model documentation, later publicly acknowledged it was more aspirational than an accurate picture of how Spotify actually operated, especially once cross-team dependencies multiplied. The model relocated coordination overhead rather than eliminating it; it did not escape the structural tension it was designed to address.

What is the coordination cost paradox in organizational growth?

The coordination cost paradox is that every mechanism added to manage a growing organization — reporting hierarchies, approval processes, cross-team dependency checks — individually solves a real problem but collectively slows decision velocity. Max Weber identified a century ago that bureaucracy is both genuinely efficient at scale and genuinely rigidity-producing; those two effects are inseparable.

Do agile-at-scale frameworks like SAFe or LeSS reduce coordination overhead?

Agile-at-scale frameworks like SAFe, LeSS, and the Spotify Model shift where coordination friction lands on the speed-control spectrum, but cross-team dependencies regenerate the drag the framework was designed to replace. The overhead relocates rather than disappears, because the dependencies between teams are load-bearing — they cannot be designed away.

Is the slowdown from organizational growth inevitable or can it be managed?

The structural pressure toward slower, more hierarchical organizations as they scale is real and documented — Burns and Stalker found no large organization stays flat and fast. However, deliberate structural design can meaningfully shift where friction concentrates. Whether specific fast-moving large companies chose that consciously or benefited from early structural defaults is difficult to measure from the outside.

Grounded in 7 sources
Proceedings to the 27th Workshop "What Comes Beyond the Standard Models" Bled, July 8-17, 2024 · arxiv.org
A Taxonomy of Hierarchical Multi-Agent Systems: Design Patterns ... · arxiv.org
Learning in the Large - An Exploratory Study of Retrospectives in Large-Scale Agile Development · arxiv.org
What is Large in Large-Scale? A Taxonomy of Scale for Agile Software Development · arxiv.org
Self-organising Roles in Agile Globally Distributed Teams · arxiv.org
What makes Individual I’s a Collective We; Coordination mechanisms & costs · arxiv.org
Communication network dynamics in a large organizational hierarchy · arxiv.org
Read transcript

Brian Reed: Eliza, hey — I had a weird moment this morning, I was trying to book a conference room through my company's system and I needed three approvals for a one-hour slot, and I just — I sat there thinking, someone designed this.

Eliza Ward: Someone absolutely designed it. And they probably thought it was an improvement over the chaos before it.

Brian Reed: Which is — hang on, that's actually the thing, right? Because that's what I want us to dig into. Is the slowness baked in, or did someone just keep adding layers without noticing?

Eliza Ward: Both, kind of — wait, no, let me be more precise. The layers accumulate because they each solve a real problem. A reporting hierarchy, an approval process, a cross-team dependency check — each one is a coordination mechanism, and each one trades speed for control. That tradeoff is structural. Max Weber identified this a century ago: bureaucracy is genuinely efficient at coordinating large groups, and it is genuinely rigidity-producing. Those two things are inseparable.

Brian Reed: So this isn't new thinking at all.

Eliza Ward: Not remotely. Burns and Stalker put a name to it — mechanistic versus organic organizations. Mechanistic: hierarchical, slow, stable. Organic: flat, fast, dynamic. And their finding was that no large organization stays organic. You scale, you mechanize, that's the structural pressure.

Brian Reed: And that mechanistic drift — so where does the math actually enter it? Because you're saying structural pressure, but pressure feels like a metaphor. Is there a number behind it?

Eliza Ward: There is, and it's — okay, this is the part that stops being philosophy. Coordination costs are estimated to scale at roughly headcount to the power of 1.5 to 1.8. Revenue per employee grows closer to headcount to the 0.9. So the gap widens by arithmetic, not by anyone making a bad call. Picture a compliance officer at a 4,000-person fintech — Thursday afternoon, she spots that a single API change touches payments, data governance, and legal. She doesn't make that call herself. She schedules a meeting, that meeting surfaces three dependencies nobody had mapped, those dependencies each need their own sign-off chain. Decision velocity — the actual time from identifying the problem to executing anything — just collapsed. And nobody did anything wrong.

Brian Reed: Wait — where do those exponents come from? Like, 1.5 to 1.8 sounds precise. Is that a controlled study or is someone's pattern-matching dressed up as a law of physics?

Eliza Ward: That's — yeah, I have to be honest there. The sourcing is fuzzy. It's empirical pattern-matching across organizations, not a controlled experiment. The combinatorial logic is solid — as headcount grows, potential communication pathways multiply combinatorially, so the coordination load can't be linear. That part holds. The specific exponent? Directionally right, precision uncertain.

Brian Reed: So if the exponent is uncertain — is some organization actually escaping the curve, or do we just not have clean enough data to see whether they are?

Eliza Ward: That's the crack, and I don't want to paper over it. What we can say is that adding hierarchy, standardization, cross-team dependencies — organizations add those not to get better, just to hold function at scale. That's coordination overhead as a scaling law. Whether anyone's genuinely bending the curve versus choosing deliberately where the friction lands — actually, that's where the Spotify Model becomes really important, and what Anders Ivarsson said later about it is going to change how that whole question looks.

Brian Reed: The part I don't get yet is whether agile-at-scale frameworks are actually reducing coordination overhead or just relocating it.

Eliza Ward: Relocating it — that's exactly the right word, and the Spotify Model is the proof. Squads of six to twelve people, acting like mini-startups, grouped into tribes, chapters for professional development, guilds for knowledge sharing. Clean architecture. Anders Ivarsson co-authored the documentation. And then later — publicly — he acknowledged it was more aspirational than a true picture of how Spotify actually operated, especially once cross-team dependencies started multiplying.

Brian Reed: Wait — the co-author said that? Not a critic, the person who built the thing?

Eliza Ward: The co-author. Which means — okay, that's not a footnote. That's the most-cited counterexample to the inevitability argument, and its own architect walked it back.

Brian Reed: So squads are mini-startups until they need to talk to each other — and then you've just rebuilt the org chart with cooler names.

Eliza Ward: That's — yeah, that's basically it. The overhead relocates, it doesn't disappear. SAFe, LeSS, the Spotify Model — they're genuine partial solutions, they shift where you sit on the speed-control spectrum. But cross-team dependencies regenerate the coordination drag the framework was designed to replace. You can't structural-design your way out because the dependencies are load-bearing.

Brian Reed: So Ivarsson's admission isn't evidence that the design failed — it's evidence the tension is real even when the design is good.

Eliza Ward: That's the hinge. The Spotify Model doesn't disprove the structural tension — it demonstrates it. The most carefully engineered escape attempt hit the same wall. That's not a design flaw you iterate away. That's the thing itself.

Brian Reed: Fine — but here's what I still don't know. How many leadership teams are actually making that choice consciously versus just waking up one day and realizing the org chart made the decision for them? Like, is there any evidence that the companies moving faster at scale chose to, or did they just get lucky with what they happened to build first?

Eliza Ward: I don't have a clean answer to that. The deliberate design case is real — you can meaningfully shift where the friction lands even when the math is against you. But whether anyone sat down and said, we're choosing this consciously — I mean, versus it just crystallizing around early structural defaults — I genuinely don't know how you'd measure that from the outside.

Brian Reed: That might be the most honest place this lands. The tension's real, the severity isn't fixed — and we mostly can't tell who chose it.

Why growing bigger usually means moving slower — the coordination cost paradox · Onpode