2026-05-21
May 21, 2026
The flat-vs-tall debate is measuring the wrong variable. The org chart is a dependency graph in disguise — and dependencies, not reporting lines, are what slow you down.
In March, Fortune reported that Meta's new applied-AI group is running a roughly 50-to-1 employee-to-manager ratio — double the 25-to-1 that most org-design literature treats as the outer limit. The takes wrote themselves: flat is the future, middle management is dead, AI lets a handful of senior engineers do the work of twelve. Every leadership thread this spring has been some version of flat or tall, how many reports per manager.
That is the wrong argument. Span of control is a second-order variable. You can flatten a team to 50:1 and make it faster, or flatten it and grind it to a halt — and the difference has almost nothing to do with the reporting line. It has to do with how much a team has to hold in its head to ship, and how many other teams it has to negotiate with to get anything out the door.
Span of control is easy to count, so we argue about it — we've been arguing about it since V. A. Graicunas tried to put a formula on it in 1933. The thing that actually governs delivery speed — cognitive load and dependency structure — is harder to see, so it gets ignored in exactly the reorgs that are supposed to fix it. This issue is about looking at the variable that matters.
Start with the law nobody escapes. In 1968 Melvin Conway observed that any organization that designs a system will produce a design whose structure copies the organization's communication structure. Fred Brooks named it Conway's Law in The Mythical Man-Month. Sixty years on it is still the most reliable predictor of architecture we have: your system looks like your org chart because the org chart is the set of communication paths the system was built across.
Read backwards, that means your reorg is an architecture decision whether you treat it as one or not. Move the boxes and you move the seams of the software. So the question for any reorg is not "how many reports per manager" — it's "what shape do we want the system to take, and which team boundaries will produce it."
This is where cognitive load becomes the unit of measure rather than headcount. Matthew Skelton and Manuel Pais built Team Topologies — now in its 2nd edition (2025) — on a simple claim: a team has a finite budget of cognitive load, split across the domain it must understand, the technical complexity it operates, and the operational burden it carries. Push a team past that budget and it slows down and makes mistakes — regardless of how it reports. A 7-person team owning three unrelated domains is overloaded. A 50-person team owning one well-bounded domain with a clean platform underneath may be fine. The reporting ratio told you nothing; the load told you everything.
The corollary is where to cut. Team Topologies calls the good seams fracture planes — natural lines along which to split a system so the resulting teams own coherent, low-coupling chunks. The most common is business domain, but there are others worth knowing by name: change cadence (things that change together, ship together), regulatory/risk isolation, performance isolation, and user persona. A reorg drawn along fracture planes reduces the cross-team chatter Conway's Law would otherwise bake into the architecture. A reorg drawn for org-chart symmetry — "every director gets four teams" — slices straight through domains and manufactures dependencies that will haunt you for years.
It helps to be precise about why those crossings are so expensive, because it explains why adding people rarely fixes a slow team. Coordination cost scales with the number of communication paths a team must maintain, not with its size — and paths grow combinatorially. Two teams that must agree to ship have one seam; five teams entangled across one domain have ten. Every crossing is a meeting, a shared on-call rotation, a release that can't go out until someone else's does. So when a "bottleneck" team is drowning, the instinct to throw three more engineers at it usually makes things worse: you've raised the team's internal coordination load without touching the external dependencies that were the actual constraint. The same logic caps how flat you can go. Spans of 50 only function where each person operates with high autonomy and low cross-dependence — the moment those engineers must constantly negotiate shared surfaces, the missing managers reappear as latency, and no amount of "empowerment" language closes the gap.
Now the 2026 twist. AI augmentation genuinely lowers one kind of load: a senior engineer with agentic tooling carries less of the rote technical burden, which is the real engine behind the flattening experiments. But it quietly raises others — the operational load of reviewing agent output, and the domain surface area one person is now expected to own. The 2nd edition is explicit that AI agent fleets only stay trustworthy inside clear domain boundaries and constrained operating contexts, exposed through "vending-machine" platform interfaces. Translation: flattening to 50:1 works only if you simultaneously cut cognitive load — strong platforms, sharp domain boundaries, ruthless scope discipline. Flatten without that and you haven't removed the bottleneck; you've moved it from the manager's calendar to the team's working memory, where it's far harder to see and far more expensive to fix.
So when the next reorg deck lands with a new box diagram, ask the two questions the deck almost never answers. What is each team's cognitive load — how many distinct domains and operational surfaces does it carry? And how many other teams must it coordinate with to ship its most important thing? If either number is high, no reporting structure will save you. The fix is boundary redesign, not headcount and not a new layer.
Try this week. Take the one team everyone calls "the bottleneck." On a single page, write the distinct domains it owns and the number of other teams it must coordinate with to ship its top deliverable. If either list is long, you have an org problem disguised as a delivery problem — and the lever is the boundary, not more people. Bring that page to your next staff meeting instead of a velocity chart.
What it is. Deliberately structuring your teams to mirror the architecture you want, so Conway's Law works for you instead of against you. Coined by Jonny LeRoy and Matt Simons in the Cutter IT Journal (December 2010), as the counter-move to Conway's 1968 observation.
When to use it. When a desired architecture keeps failing to materialize because the current team boundaries keep dragging the design back to its old shape — typically during a platform or service-decomposition effort, or when changing the org from within is harder than changing the system.
How to run it:
When NOT to use it. When the architecture is already fine and the real problem is interpersonal or process. Don't reorg what a conversation can fix — and never run this mid-incident or before the target architecture is actually known.
Example: a payments group split along a business-domain fracture plane into "ledger" and "payouts" stopped two squads editing the same service in lockstep — and the service decomposition they'd failed to ship for a year followed within a quarter.
Meta's new AI team has 50 engineers per boss. What could go wrong? — The flattening experiment everyone is citing. Useful precisely as a stress test: it only works if cognitive load drops as fast as the layers do.
Team Topologies, 2nd Edition — Skelton and Pais elevate cognitive load to the central design principle and extend the model to AI-augmented orgs — clear domain boundaries as the guardrail for trustworthy agent fleets.
What AI's impact on engineering tells us about where org design is headed — Charter on why decision-making is collapsing toward the teams doing the work, and what that does to the shape of the chart.
"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."
— Melvin E. Conway, How Do Committees Invent? (Datamation, 1968)
Don't miss what's next. Subscribe to Critical Path: