The Coordination Tax: Why Adding Engineers Makes You Slower (And What Actually Scales)

Fred Brooks wrote The Mythical Man-Month in 1975, and the principle now known as Brooks's Law has a core argument: adding people to a late software project makes it later. Fifty years on, most engineering organizations still operate as if developer headcount equals output. It doesn't. It never did. And now the math is worse for large teams than ever.

Here's why.

The Formula Nobody Internalizes

The number of communication channels in a team grows as n*(n-1)/2, where n is the number of people. This is combinatorics, not opinion.

• 2 people = 1 channel
• 5 people = 10 channels
• 10 people = 45 channels
• 15 people = 105 channels
• 20 people = 190 channels

Each "channel" is not an abstraction. It's a standup slot. A Slack thread. A "quick sync" that takes 30 minutes. A PR review dependency. A shared Google Doc with conflicting comments. A Jira ticket where the "Definition of Ready" requires three cross-functional approvals before anyone can move.

Go from a 5-person team to a 10-person team and you haven't doubled your capacity. That's a 4.5x increase in coordination overhead for a 2x increase in headcount.

This is why a team of 10 often ships slower than a team of 4 working on the same problem. The 10-person team spends more aggregate hours per week in meetings, waiting on reviews, resolving merge conflicts, and aligning on decisions than the 4-person team spends on the entire project.

What Coordination Cost Actually Looks Like

The formula is clean. The mess is in the details. Coordination cost shows up in places that don't get tracked in your project management tool.

Context switching. Every time an engineer stops coding to answer a Slack message, attend a standup, or review someone else's PR, they lose 15-25 minutes of recovery time rebuilding the mental model of whatever they were working on — on top of the interruption itself. A 10-person team generates more interrupts per person than a 3-person team. The math guarantees it.

Decision latency. On a small team, technical decisions happen in real time. "Should we use Postgres or DynamoDB?" gets resolved in a 5-minute conversation between the two people who are going to implement it. On a 10-person team, that same decision requires a meeting, a Slack thread, maybe an RFC document, and a week of calendar-tetris before you can get the right people in the same room. The decision quality isn't better. It's just slower.

Knowledge diffusion. When one person on a 3-person team learns something, the other two know about it by end of day. When one person on a 15-person team learns something, it takes a documentation effort, a presentation, or three separate conversations before the knowledge reaches everyone who needs it. Most of the time, it doesn't reach everyone. People build on stale assumptions.

Integration overhead. More people means more parallel workstreams, which means more merge conflicts, more API contract mismatches, and more "it works on my branch" problems. The integration cost grows superlinearly with team size. This is why large teams spend so much time on CI/CD infrastructure, feature flags, and trunk-based development practices — they're paying engineering effort to manage the coordination cost of their own size.

Brooks's Law in the Modern Stack

Brooks was writing about IBM mainframe development. The specifics have changed. The principle hasn't.

If anything, modern software amplifies the problem. In 1975, coordination happened through memos and scheduled meetings. Today it happens through Slack (always-on interrupts), GitHub (async review queues that create blocking dependencies), Jira (status theater that consumes hours per week), and Zoom (meetings that could have been a message, scheduled in 30-minute blocks because that's the calendar default).

The tooling that was supposed to make large-team coordination easier has instead made it continuous. There's no downtime from coordination anymore. An engineer on a 10-person team is never more than a notification away from a context switch.

The Reframe: AI Multiplies Throughput Without Adding Nodes

Here's where the landscape has shifted in a way Brooks couldn't have predicted.

AI development tools — Claude, Cursor, Copilot, and the ecosystem around them — do something that no previous productivity tool has done: they multiply an individual engineer's output without adding a communication channel.

A senior engineer with strong AI tooling and domain expertise now covers work that used to require separate people: backend implementation, frontend builds, test generation, documentation, data transformation logic, and debugging common patterns. Not by working faster on the same tasks, but by offloading the solved problems — boilerplate CRUD, standard UI components, unit tests for edge cases — that previously justified adding headcount. The routine work gets absorbed by tooling. The engineer focuses on architecture, product decisions, and the novel problems that actually require human judgment.

And here's the critical difference: AI doesn't attend standups. It doesn't need context on the product roadmap. It doesn't have opinions about the database schema that require alignment meetings. It doesn't go on vacation, get sick, or leave for a competitor. It adds zero communication channels to your team graph.

A 2-person team with AI tooling has 1 communication channel. In our experience shipping production apps in compressed timelines, that team matches or exceeds the throughput of a traditional 5-8 person team — not because the engineers are better, but because they spend almost no time coordinating.

A 10-person traditional team has 45 communication channels and maybe 40% of its theoretical capacity actually producing code, after you subtract the coordination tax.

The math now favors small teams by an even wider margin than Brooks originally described.

A Concrete Example

Consider a typical product build: a customer-facing web app with authentication, a dashboard, a data pipeline, and an admin panel.

The 10-person approach: 2 frontend engineers, 2 backend engineers, 1 DevOps engineer, 1 QA lead, 1 designer, 1 PM, 1 tech lead, 1 engineering manager. 45 communication channels. Daily standups (150 person-minutes per day before anyone writes a line of code). Sprint planning. Backlog grooming. Design reviews. Code reviews across 4 engineers. QA handoff meetings. Retros. Probably 12-16 weeks to ship v1.

The 2-person approach: 2 senior full-stack engineers with AI tooling. 1 communication channel. They talk when they need to, which is maybe 2-3 times a day. No standups because they already know what the other person is doing. No backlog grooming because the scope fits in their heads. Code review is fast because there are only 2 reviewers and both have full context. 4-6 weeks to ship the same v1.

The 2-person team isn't cutting corners. They're spending a higher percentage of their hours writing and shipping code. They make decisions in minutes instead of days. They don't lose context because there are only two contexts to maintain.

This isn't theoretical. It's the pattern behind every "small team ships impossibly fast" story. AI tooling has pushed the threshold even further. The minimum viable team for a serious product build is now 1-2 people, not 5-8.

The Bus Factor (and Why It's Overrated as a Scaling Argument)

"What if someone gets hit by a bus?" is the first objection to small teams, and it's a fair one. In a 2-person team, losing one person is a 50% reduction in capacity. In a 10-person team, it's 10%.

But the typical organizational response — adding redundant headcount — is the most expensive and least effective form of risk mitigation. You're paying full salaries to park people as insurance, and you're adding communication channels that slow down the entire team every single day as the cost of that insurance.

The better mitigations are cheaper: keep the architecture simple, write decision logs, maintain clean codebases that a competent engineer can onboard into quickly. AI tooling actually helps here too — it serves as a resident historian that can explain any part of the codebase on demand, dramatically reducing the onboarding cliff.

The bus factor is a real risk. It's just not a risk that requires 10 people to solve.

Why Organizations Still Default to Headcount

If the math is this clear, why do companies keep hiring large teams?

Legibility. A VP who manages 50 engineers looks more important than one who manages 5. Organizational incentives reward headcount growth, not output efficiency. Nobody gets promoted for keeping the team small.

Risk perception. The bus factor concern above, scaled across every decision-maker who prefers the appearance of safety over actual shipping velocity. Redundancy through headcount feels safe on an org chart.

Estimation failure. Teams consistently underestimate what a small, senior, well-tooled team can do — and overestimate what a large team can do. The 10-person team looks safer on a spreadsheet. It's not safer in practice.

The hiring treadmill. Once you have a large team, you need managers to manage it, recruiters to backfill attrition, and HR processes to keep everyone aligned. This infrastructure justifies its own existence. Shrinking is politically harder than growing, even when growing is making you slower.

What Actually Scales

Headcount doesn't scale. Individual throughput multiplied by coordination efficiency scales.

That means: invest in senior engineers who can own entire features end-to-end. Give them the best AI tooling available. Keep the team as small as you can tolerate. Accept that a 3-person team shipping every week will outperform a 15-person team shipping every quarter.

The companies that figured this out early — the ones running 2-3 person teams with AI-augmented workflows — are building the same products in a fraction of the time and a fraction of the budget. Not because they found better engineers. Because they didn't dilute those engineers' time with coordination overhead.

Brooks was right in 1975. The math hasn't changed. What's changed is that a single engineer's unencumbered output — the numerator in the productivity equation — just got multiplied by 3-5x. The coordination cost — the denominator — stayed exactly the same.