A team of sixteen expert developers thought AI made them 20% faster. The stopwatch said they were 19% slower. The real story is stranger than either number.
Picture your last big program.
A steering committee. Five workstreams. A programme manager whose entire job was stopping those workstreams from contradicting each other. Weekly syncs for blockers. Monthly syncs for the blockers the weekly syncs missed. And somewhere underneath all of it a handful of people actually building the thing. That structure wasn’t stupid. It was the right answer to a real problem.
The problem just left. The structure stayed.
The math from 1975 that nobody reran
Fred Brooks worked this out fifty years ago, and the arithmetic hasn’t softened since. Communication channels grow by n(n−1)/2. Which means:
- 3 people → 3 channels
- 6 people → 15 channels
- 10 people → 45 channels
You doubled the team. You quadrupled the conversations.
Every channel is time not spent building. It’s why adding people to a late project makes it later — newcomers need weeks to ramp, paid for out of the time of the people already drowning. So why did anyone build big teams? One honest reason: volume. Boilerplate. Test scaffolding. Migrations. Documentation. Work that wasn’t hard — there was just a mountain of it, and hours were the only shovel.
That mountain is gone. The org chart built to move it isn’t.
Now the part the vendor blogs skip
Here’s where most articles on this topic get written by people selling the conclusion. So let’s use the study that argues against the easy version. Researchers at METR ran a randomized trial. Sixteen experienced developers. 246 real tasks. Codebases they’d worked in for years. Before starting, the developers predicted AI would make them 24% faster. The stopwatch said they took 19% longer. Then having just lived through the slowdown they estimated they’d been 20% faster. A 39 point gap between what skilled professionals felt and what actually happened. Fair caveats, because they matter: one study, early 2025 tools, mature codebases. METR itself calls the result historical, and a later follow-up showed some evidence of speedup.
But the lesson survives every caveat:
Feeling fast is not evidence of being fast.
Which brings us to the thing everyone gets backwards.
Small teams don’t win because everyone types faster. They win because the coordination tax disappears.
One of those claims is contested. The other is arithmetic.
The trap: shrinking the pyramid
Cut headcount but keep the structure junior-heavy and you make it worse. More generated code arriving for review. More defects to catch. Your best people demoted from directing architecture to babysitting output.
The bottleneck doesn’t vanish. It relocates.
What works is the inversion: a compact group of senior people owning every decision that carries consequence architecture, integration, review, accountability for what ships — while the volume gets absorbed by tooling. Small enough that coordination never becomes a job title. Senior enough that judgment isn’t the thing being automated.
When you do still need the big team
- Three cases, honestly: —Genuinely parallel domains. Clean boundaries between products. That’s not one big team it’s several small ones.
- Regulatory and 24/7 surface. Compliance and always-on operations are staffing requirements, not efficiency problems.
- Scale of surface, not scale of build. Hundreds of integrations need hands regardless of how fast anyone codes.
What almost never justifies it anymore is the original reason: absorbing volume.
The question worth asking
Not “how do we do this with fewer people?” That’s a cost question, and it produces the worst version of this idea — the same broken structure, understaffed. Ask this instead:
How much of our headcount exists to do the work — and how much exists to coordinate the people doing the work?
In most large programs, the honest answer is uncomfortable.
Fewer people. Less coordination. More shipped.
In that order — because the third one is a consequence of the second, not the first.
Ready to replace coordination with accountable delivery?
SÔRS CO embeds senior, forward-deployed pods inside your team — bringing the engineering, architecture, AI, and delivery expertise needed to turn strategy into production.
Every engagement begins with the outcome you’re buying. We commit to the numbers that matter, contribute from the first sprint, and ship measurable progress — never status decks.
Walk out with next steps, not a proposal.
Your turn: split your last program’s headcount into two columns — people doing the work, and people coordinating the people doing the work. We’d bet the second column is bigger than anyone budgeted for. Tell us we’re wrong.
