Interface Math: Why Teams Multiply — and When to Go Divisional

Fifteen teams do not coordinate three times harder than five — they coordinate ten and a half times harder. Apply Brooks's Law, n(n-1)/2, and five teams hold just 10 point-to-point interfaces while fifteen hold 105, a 10.5x explosion in coordination links from a mere 3x change in team count (as reported by LoomStack).

That quadratic — not annual recurring revenue, not headcount — is what tells you when to carve divisions. A 90-person startup running 15 teams is further past the cliff than a 600-person company running 8, because leaders break somewhere between 45 and 105 direct interfaces, not at any milestone of size. Divisionalization is an interface-reduction maneuver: you restructure to collapse the number of links each leader must personally manage.

AI tooling pulls that cliff closer. Individual output scales linearly — an engineer with Copilot or Claude Code can hit 2x to 5x their base rate on well-scoped tasks — but coordination complexity scales quadratically with active work streams (LoomStack, 2026). One engineer running five parallel AI sessions already carries a five-person team's coordination surface; five engineers doing the same approach a 25-person load, roughly 300 potential interaction paths managed by five humans. Count interfaces per leader, and act before the math acts for you.

Interface Math

The sixteenth team you approve doesn't add one relationship to your org chart — it adds fifteen. That asymmetry is the entire game. Derive it from first principles: when team k joins, it must connect to every team already standing, k−1 new links. Sum 1 + 2 + … + (n−1) and you get n(n−1)/2 — the channel-count argument Fred Brooks introduced in The Mythical Man-Month (1975). According to LoomStack's application of Brooks's Law, the sixth team creates 5 new interfaces while the sixteenth creates 15, so each team added at scale costs three times more to absorb than one added early. Tabulate it and the punchline lands: tripling teams from 5 to 15 multiplies coordination load 10.5×.

An interface is not a line on a slide. One interface concretely consumes a recurring cross-team sync, a negotiated API or data contract, a shared on-call rotation, a joint OKR negotiation, and a cross-team code-review queue — often several at once. Budget it with a planning heuristic of 1–2 hours per interface per week per side. At 105 interfaces, that burns roughly 105–210 engineer-hours weekly on pure coordination — the full weekly output of two to five engineers, spent before anyone ships anything.

Melvin Conway named the second-order damage in 1968. "How Do Committees Invent?" argues that system design mirrors communication structure, so a 105-edge full mesh doesn't just burn hours — it writes your architecture. Every pairwise sync hardens into a shared library; every negotiated contract becomes a coupled release train. The sequencing rule that follows: leadership must partition communication paths before partitioning the codebase, because the dependency graph will copy whatever conversation graph it finds.

Clustering is the arithmetic escape. Split 15 teams into 3 divisions of 5 and the mesh collapses: 3 × (5×4/2) = 30 intra-division interfaces plus 3 inter-division bridges ≈ 33 total — a 69% cut from 105. Ownership determines whether the cut holds. The 3 bridges belong to named division GMs, not standing committees: a committee-owned interface gets scheduled, a GM-owned interface gets decided.

The human ceiling explains why the cliff sits between 10 and 15 teams. Robin Dunbar's layered group sizes — stable circles at roughly 5, 15, 50, and 150 — bound how many relationships a person maintains with real knowledge of each member's state. Team Topologies (Skelton & Pais, 2019) adds the cognitive-load principle: a team degrades once it owns more than a handful of live dependencies. A 10-team functional org already asks every team to hold 9 live dependencies; at 15 teams it's 14, beyond the circle where individuals track one another at all. "One big happy functional org" fails on arithmetic, not attitude.

At 15 teams the 3×5 divisional cut wins outright: 33 interfaces against 105, three bridges, three names accountable for them. Run the cut before the second product line forces it — the table above is the whole business case.

In 2012, McKinsey Global Institute audited where the knowledge-work week actually goes. Its report, "The social economy," found knowledge workers spending 28% of the week reading and answering email and another 19% searching for internal information. Name it plainly: that is the invoice for unmanaged interfaces. Nearly half the workweek gets consumed paying coordination debt before a single deliverable moves — and every inter-team link you approve extends the billing cycle.

The Coordination Tax, Measured

The nonlinearity is what founders underestimate. According to Microsoft's Work Trend Index, weekly meeting time surged 148% between February 2020 and February 2021, when remote work densified collaboration graphs almost overnight. Meeting load did not track headcount; it tracked connection density. LoomStack's engineering-coordination analysis, published March 17, 2026, finds the identical shape in the AI era: individual velocity with better tools scales linearly, while coordination complexity scales quadratically with the number of active work streams. Two measurements, fourteen years apart, same curve — densify the graph and the tax compounds faster than the roster grows.

At the top of the curve sits the founding evidence base. Alfred Chandler's Strategy and Structure (1962) documented that DuPont, General Motors, Standard Oil, and Sears each abandoned centralized functional structures once they diversified beyond a single product line — four companies at four different scales, one common trigger. Product divergence, not size alone, forced the divisional turn. That is also the cleanest burial of the milestone myth: if you are waiting on a headcount or revenue round-number to restructure, you have misread the variable entirely. The breaking point is interfaces per leader — a lean org sitting at the divisional cap runs deeper past the cliff than a sprawling one holding at eight teams.

Oliver Williamson's Markets and Hierarchies — the argument that later carried him to a share of the 2009 Nobel in economics — formalized the mechanism: the multidivisional form relieves bounded rationality at headquarters by converting hundreds of operating decisions into a few capital-allocation decisions. Read that against the 105-interface divisional ceiling established above. Blow past it, and headquarters quietly re-absorbs hundreds of operating decisions; you are left with an M-form org chart running a functional brain.

The bottom of the curve brackets just as hard. J. Richard Hackman's Leading Teams (2002) sets the empirical ceiling: no work team should have membership in double digits. Ringelmann's rope-pulling experiments (1913) measured individual output falling as group size rises — the first recorded coordination loss. Together they explain why oversized coordinated groups lose to clusters of small ones. The 2026 edge case sharpens this further: according to the arXiv research LoomStack cites, five engineers with frontier AI agents can match the output of fifty without, at far less coordination overhead. AI lifts individual velocity linearly, so the winning configuration is smaller teams with better coordination — which means the caps bind tighter now, not looser.

Do one thing this week: pull the last month of calendars and tag every recurring meeting whose attendees span two or more teams. That census is your live interface count. When most coordination hours cross a boundary you have not drawn yet, the divisional question has already arrived — whatever the headcount says.

Scored honestly on the five rows that decide operating models, the functional-versus-divisional-versus-matrix debate collapses to a 2–2–0 result. Functional takes interface topology and decision latency below ten teams. Divisional takes P&L accountability and the scaling ceiling above ten. Matrix takes nothing — and it actively inflates the one variable this entire guide counts. A dual-reported team answers to two managers instead of one, so every dual-reported team literally doubles its interface count: two escalation paths, two priority stacks, two sets of lateral commitments to reconcile. Mark matrix "never the answer" at any intermediate stage — it is a transition state you pass through during a reorg, not a structure you operate.

Functional vs Divisional vs Matrix

The trigger sits inside the table, gated on both conditions at once: switch functional-to-divisional only when a second product or market needs at least 3 dedicated teams AND total teams exceed 10 (45 interfaces). Either condition alone fails. A second product needing two teams is a feature crew inside the existing org; twelve teams stacked on one product line means you blew the ceiling without a second line to absorb the split — that is a scope problem to fix before it becomes a structure problem. Below the joint threshold, the table's verdict is simply "stay functional."

The scaling-ceiling row is graph shape, not culture. A functional org saturates around 10 teams because each new team must connect to the whole existing mesh — team eleven adds 10-plus fresh edges on day one, so the marginal cost of growth climbs with every approval. A divisional org scales near-linearly: a new division brings whatever teams it needs inside its own boundary and contributes only a handful of new bridges to headquarters — a finance rollup, a platform dependency, a talent pipeline. Identical headcount trajectories, opposite curvature, because edges accumulate inside closed boxes instead of across one open mesh.

Divisional carries its own hidden tax, and it collects at headquarters. The split only nets out if corporate retains roughly 8 or fewer shared functions — finance, security, identity/platform, and talent form the canonical core. Past roughly eight, every additional centralized function re-threads cross-division edges through the center, and headquarters silently rebuilds the functional mesh the split was meant to dissolve. Treat eight as a budget to defend, not a law: when a division asks HQ to absorb one more shared service, price it in interfaces before you price it in salaries.

Run three counts this quarter. Teams per product line, checked against the 10-team gate. Shared functions retained at HQ, checked against the roughly-eight budget. And any team currently reporting to two managers — log it as structural debt to retire, because every quarter it survives, it pays double rent in interfaces.

Start with the disclosure most guides skip: the interface curve is arithmetic, not physics. Each added team connects to every existing one — a combinatorial identity, and identities don't carry error bars. What varies is how many of those potential connections carry live coordination traffic. A platform team publishing clean internal APIs converts dozens of would-be peer-to-peer edges into a single hub-and-spoke relationship; a startup where every team queries every shared database directly carries nearly all of them. Identical team counts, wildly different loads. The formula locates the cliff; it cannot tell you how close to the edge your particular org is standing.

Now the evidence base, stripped bare. Nobody randomizes companies into competing org charts, so everything rests on quasi-experiments — and firms that restructure tend to swap executives, strategy, and tooling in the same quarter, muddying attribution. Publication bias does the rest: Spotify's squad diagram circled the globe because it flattered its authors, while the companies whose topologies failed rarely publish interface audits. Recorded edge weights also predate the async-tooling and AI-assistant era, so they may be stale in either direction. One adjacent-system data point: according to Augment Code's essay "Why 3 Agents Cost 10x," multi-agent setups exhibit cost compounding as collaborators multiply. Treat that as a shape-check from software agents, not proof about human teams — a practitioner essay, not a study.

What the Data Doesn't Tell You

Case variance runs wider than any single threshold implies. Valve's famously flat structure minimizes hierarchy and maximizes potential peer-to-peer edges — which is why its leaked handbook reads as cautionary as much as aspirational. Amazon's two-pizza heuristic caps a team's appetite, not its interface surface. Domain coupling moves the load more than payroll does: a payments ledger couples tightly across teams; a marketing site barely couples at all. Haier's microenterprise model pushes coordination to the market boundary entirely. None of this contradicts the curve — it shows topology choices slide you along the curve faster than any headcount figure ever will.

Where the rule strains. Platform-dense orgs: past the ten-team mark the rule stops guaranteeing safety and starts demanding measurement, because a strong internal platform can hold a single product line together well beyond where an unplatformed mesh fractures — the honest reading is "instrument before carving," not "the threshold is wrong." Acquisitions: the second-product-line trigger fires the day a deal closes, yet carving before integration completes strands shared services mid-flight; sequence the split behind the integration map. Regulated industries: compliance imposes matrix reporting lines regardless of interface count — the cap still binds, but boundary redraws follow the regulator's map. And the redline itself has an instrumentation gap: most orgs cannot count active interfaces today, because doing so requires dependency-graph and ticket-routing analytics most haven't bought. Unmeasured, the tripwire is decorative.

One myth dies here: the milestone reflex — split when we hit some headcount or revenue mark. Backwards. The breaking variable is interfaces per leader, not payroll. A 15-team org of 120 people is deeper past the cliff than a 600-person org running 8 teams, because the first carries the compounding load and the second doesn't. A split calendar keyed to an ARR milestone outsources a topology decision to a finance number that has never counted an edge.

The caveats collapse into one discipline: the curve sets the guardrails, measurement sets the timing. Scan the table's final column — in every failure mode, instrumentation precedes surgery. Most reorg post-mortems skip exactly that step. That is the entire prescription.

n(n−1)/2 has never described an organization that actually existed. The formula counts every pair that could coordinate; dependency audits — the unglamorous exercise of mapping who actually calls whom, pulled from service catalogs, code-ownership metadata, and on-call rotas — typically find each team actively depending on only two to four others. Treat the formula as a ceiling, not a measurement. In a modular org it overstates drag; in a tangled one it understates it, because the worst edges never appear on any chart: the shared vendor escalation path, the deployment freeze two "unrelated" teams negotiate every quarter, the compliance review that quietly couples five squads.

So the instruction is mechanical, not philosophical: before acting on the ten-team ceiling derived above, count live edges. Draw the who-calls-whom graph from your own systems and compare it to the full-mesh bound. Fewer audited edges than the bound means you hold slack the formula hides; more means you are past the cliff in reality, and no reorg label rescues you.

Where the Formula Lies

The counter-case has a name and a date. In 2020, Jeremiah Lee published "Spotify Doesn't Work," a widely read essay establishing that the famous squads/tribes/chapters/guilds model was partly mythology even inside Spotify. By 2023, reporting indicated Spotify itself had moved away from the model. The lesson is not "don't copy Spotify" — it is that celebrated org designs fail quietly at the very companies that inspired them, so importing a topology label imports nothing measurable. Import the audit instead.

Then there is the denominator nobody plots. According to McKinsey's long-running transformation research, roughly 70% of large-scale change programs fail to reach their stated goals. The visible ING-and-Spotify-style stories sit atop a large invisible population of stalled reorgs that redrew boundaries, announced squads, and quietly reverted. Structure changes succeed or fail on execution capacity the interface math cannot see — whether leaders hold the boundary, whether the platform ships before divisions need it. The formula tells you when the cliff arrives; it says nothing about steering.

Finally, adjust for domain, because regulation edits the graph directly. Banking compliance, medical devices, and aviation impose mandatory cross-team reviews — design approvals, validation sign-offs, audit trails — that add forced edges regardless of the org chart. Two companies with identical team counts can face radically different coordination loads: a fintech is not a dev-tools shop. Match the regulatory regime first when benchmarking against any case study.

The audited-edge count is the operating number; the formula survives only as the upper bound it always was.

Roughly 3,500 ING Netherlands employees spent 2015 dismantling their own functional bank. Marketing, product, IT, and operations had each been handing work over the wall to the next; according to McKinsey's 2017 interview with then-CIO Bart Schlatmann, the rebuild produced approximately 350 squads of up to nine people, clustered into 13 tribes. Note what did not trigger the move: no employee milestone, no revenue round number. The trigger was the shape of the work — a single customer-facing feature crossed four-plus departmental boundaries and stacked up dozens of handoffs before it shipped, and no box on the org chart owned any of it.

Model the pre-2015 state honestly: call it roughly 40 concurrent cross-department projects, each needing alignment across all six functions. The precision here is a modeling choice, not a measurement — but the failure mode it captures is exact. Every project touched every function, so every delay propagated everywhere. Coordination load grew faster than the work being coordinated, which is the signature of a graph, not a headcount, problem.

The redesign attacked topology, not autonomy. Thirteen tribes create at most 13×12/2 = 78 tribe-to-tribe interfaces, and each one received a named owner — a tribe lead whose job description included that edge. Inside a squad, nine people generate at most 36 possible pairwise links, most of which go unused because the work fits in one room. Now run the counterfactual ING avoided: 350 fully autonomous squads with no grouping layer yield 350×349/2 = 61,075 potential pairings. Autonomy alone would have been chaos with better vocabulary. Clustering is what made the system tractable — it converted an unownable graph into 78 ownable edges.

ING's 3,500 People, 350 Squads, 13 Tribes

In the same interview, Schlatmann described time-to-market falling from quarters to weeks and a sharply higher app-release cadence after the shift. Apply the honesty label these claims deserve: management-reported directional results, not audited experimental data. There is no control group of banks that stayed functional, and self-reported transformations flatter themselves. Trust the direction; discount the magnitude.

Here is the part the conference-version case study skips: 3,500 ÷ 13 ≈ 270 people per tribe — nearly double Dunbar's 150-person ceiling on stable relationships. ING shipped a structure it could already see was oversized, and the bank has kept restructuring ever since, including later steps away from pure squad orthodoxy. The lesson cuts both ways against the milestone myth. Waiting for a headcount or revenue threshold is backwards — ING sat at 3,500 people for decades because the binding constraint was interfaces per leader, not payroll. But splitting once isn't enough either: a boundary you draw and never re-audit drifts until it's fiction. Run the same check on your own grouping layer — total headcount divided by clusters, reviewed quarterly, with standing authority to redraw — and treat thirteen clusters, comfortably under the division-size ceiling argued earlier in this guide, as the winning configuration on tractability despite its known size flaw.

According to LoomStack's summary of the March 2026 preprint arXiv:2603.27438, five well-coordinated teams running agents now deliver roughly what fifty teams deliver without them. Apply the interface formula from earlier and the gap is stark: 10 working interfaces versus 1,225 for equivalent output. That result is the coffin nail for milestone-triggered reorganizations. If you still carry a trigger like "we go divisional at 500 employees," delete it — headcount measures what you spend, interfaces measure what breaks, and the two have officially decoupled.

Rule 1 — Count teams, not headcount. Schedule the structural review the day any single leader's org reaches 10 teams (45 interfaces), whether it employs 80 people or 800. The edge case that proves the rule: a 15-team org of 120 people and a 600-person org running 8 teams sit at 105 and 28 interfaces respectively — the small company is roughly four times deeper past the cliff, and no headcount dashboard will show it. Scaling output by adding headcount multiplies coordination load quadratically, per the same LoomStack summary, while smaller, well-coordinated units reach equivalent output with far less coordination overhead. ARR and employee-count milestones are noise; interface load is the signal.

Rule 2 — Earn the division. Split only when a second product or market genuinely needs three or more dedicated teams. If it needs one or two, run a platform team with a thin product overlay instead. A new P&L and a new executive layer carry fixed coordination overhead that a one- or two-team line typically cannot amortize; in most cases the overlay buys the market focus without minting a second mesh.

Five Rules for Going Divisional Without Regret

Rule 3 — Enforce the 15-team cap. The moment any division hits 15 teams (105 interfaces), spawn a sub-division or split the product line. According to Lucent Owl's total-cost-of-ownership analysis, complexity costs grow exponentially without active management — the cap is that management, applied on a schedule rather than on feel. A division that reproduces the original mesh has merely added executives to the same problem.

Rule 4 — Audit seams yearly with real dependency maps. Run the dependency audit described earlier on a fixed annual cadence, and redraw when more than roughly 30% of a division's active interfaces connect outside its boundary. That threshold means the line was drawn in the wrong place: redraw along the highest-traffic seams, never along reporting convenience or tenure-based politics. Traffic drifts; a boundary drawn once and defended indefinitely is a boundary that is now wrong.

Rule 5 — Never pass through matrix. Between 10 and 15 teams, the pressure to "do both" peaks, and dual-reporting is the most expensive available way to defer the decision: every affected team's interface count roughly doubles, because each relationship now terminates in two bosses. The comparison above already scored the three structures; the rule here is that deferral-via-matrix is itself a choice, and the worst-priced one on the board.

This quarter's action: count the teams reporting to each of your direct reports. Any count at 10 or above means the review is already late — the calendar never was the trigger.

Rule 4 — Audit seams yearly with real dependency maps. Run the dependency audit described earlier on a fixed annual cadence, and redraw when more than roughly 30% of a division's active interfaces connect outside its boundary. That threshold means the line was drawn in the wrong place: redraw along the highest-traffic seams, never along reporting convenience or tenure-based politics. Traffic drifts; a boundary drawn once and defended indefinitely is a boundary that is now wrong.

Rule 5 — Never pass through matrix. Between 10 and 15 teams, the pressure to "do both" peaks, and dual-reporting is the most expensive available way to defer the decision: every affected team's interface count roughly doubles, because each relationship now terminates in two bosses. The comparison above already scored the three structures; the rule here is that deferral-via-matrix is itself a choice, and the worst-priced one on the board.

This quarter's action: count the teams reporting to each of your direct reports. Any count at 10 or above means the review is already late — the calendar never was the trigger.

What to do next

Frequently Asked Questions

How many engineering hours per week does pure coordination burn once we're at 105 interfaces?

Using the planning heuristic of 1–2 hours per interface per week per side, 105 interfaces burns roughly 105–210 engineer-hours weekly — the full weekly output of two to five engineers, spent before anyone ships anything.

If we split our 15 teams into 3 divisions of 5, how many interfaces do we actually eliminate?

The mesh collapses to 30 intra-division interfaces plus 3 inter-division bridges — roughly 33 total, a 69% cut from 105.

Who should own the inter-division bridges after we restructure?

The 3 bridges belong to named division GMs, not standing committees, because a committee-owned interface gets scheduled while a GM-owned interface gets decided.

Why does every additional team cost more to absorb than the last one?

Because when team k joins it must connect to every team already standing, the sixth team creates 5 new interfaces while the sixteenth creates 15 — so each team added at scale costs three times more to absorb than one added early.

Is there a headcount or revenue milestone that signals it's time to go divisional?

No — a 90-person startup running 15 teams is further past the cliff than a 600-person company running 8, because leaders break somewhere between 45 and 105 direct interfaces, not at any milestone of size.

How much coordination overhead do parallel AI coding sessions create for a single engineer?

One engineer running five parallel AI sessions carries a five-person team's coordination surface, and five engineers each running five sessions approach a 25-person team's load — roughly 300 potential interaction paths managed by just five humans.

Quick answers