Is Brooks's Law still true today?

Yes. The 1975 logic—ramp-up time, communication overhead, and indivisible tasks—still holds, and remote work has arguably made it sharper. Modern tools like AI coding assistants shorten early onboarding, but they don't erase the coordination cost of a larger team. Brooks's Law remains one of the most reliable patterns in software project management.

Does Brooks's Law apply to remote teams?

It applies more, not less. A colocated office quietly closes many communication paths through hallway conversations and shared context. Distributed teams have to maintain every one of those links deliberately, so each new hire adds more coordination overhead than they would in person—the core of Brooks's Law for remote teams.

How many communication channels does a team of 10 have?

Forty-five. The communication channels formula is n(n−1)/2, so a 10-person team has 10 × 9 ÷ 2 = 45 possible links. A 5-person team has only 10. That jump—roughly 4.5× the connections for 2× the people—is why coordination cost rises so much faster than headcount.

How do you avoid Brooks's Law?

Add people before a project is late, keep teams small (three to six engineers per pod), document decisions so they don't require meetings, and give each pod a clear goal so people can act autonomously. The aim is to reduce communication paths and protect senior engineers' focus, not just to hire faster.

Brooks's Law for Remote Teams: When More People Backfire

You're behind on a launch, so you do the obvious thing: add more engineers. Three weeks later, you're further behind. That's not bad luck—it's Brooks's Law for remote teams, and it's one of the most durable patterns in software.

Fred Brooks coined the rule 50 years ago: adding manpower to a late software project makes it later. It sounds like a paradox. More hands should mean more output. But every person you add doesn't just write code—they create communication links, need onboarding, and pull your most productive people away from the work to train them. On a distributed team, where a 30-second hallway question becomes a half-day Slack thread, those costs multiply fast.

This guide breaks down why Brooks's Law for remote teams hits harder than it did in 1975, what the communication math actually looks like, and how to grow your headcount without stalling the very project you're trying to rescue.

What Brooks's Law Actually Says

Brooks's Law comes from Fred Brooks, the IBM manager who ran the massive OS/360 project and later wrote the 1975 classic The Mythical Man-Month. After watching big teams miss deadline after deadline, he distilled the pattern into one sentence: "Adding manpower to a late software project makes it later."

The reasoning rests on a simple truth about how software gets built—the mythical man-month assumes people and time are interchangeable, and they aren't. You cannot trade one for the other freely, because many tasks can't be split. Brooks put it bluntly: while it takes one woman nine months to make one baby, "nine women can't make a baby in one month." Some work is sequential by nature, and no amount of staffing collapses it.

Brooks pointed to three forces that turn extra people into a net loss. First, ramp-up time: new hires aren't productive on day one and must learn the system before they contribute. Second, communication overhead: every additional person adds coordination links the whole team has to maintain. Third, task divisibility: you can't always carve work into clean, independent chunks. The crucial caveat is that Brooks's Law applies to projects that are already late—the trap is reaching for headcount as an emergency fix.

The Communication Overhead That Compounds Remotely

Here's the part most managers underestimate. Communication overhead doesn't grow in a straight line as you add people—it explodes. The communication channels formula is simple combinatorics: a team of n people has n(n−1)/2 possible connections.

Run the numbers and the curve gets ugly:

5 people → 10 communication paths
10 people → 45 paths
15 people → 105 paths
50 people → 1,225 paths

Double a team from 5 to 10 and your output might roughly double, but your coordination surface more than quadruples. Triple it to 15 and you've gone from 10 links to 105. Every one of those paths is a place where context gets lost, decisions get re-litigated, and two people quietly build the same thing.

Now layer remote work on top. In a colocated office, many of those paths close themselves—you overhear a conversation, you catch someone at their desk, alignment happens by osmosis. Distributed teams have none of that ambient context, so every link has to be maintained deliberately through a message, a doc, or yet another call. That compounding coordination cost is the engine behind Brooks's Law for remote teams. And the data shows where that time goes: according to Microsoft's Work Trend Index, meetings, chat, and email consume 57% of the workday, leaving just 43% for focused solo work. Unproductive meetings alone cost U.S. businesses an estimated $375 billion a year. Add people without a plan and you're not buying velocity—you're buying coordination tax.

Why Onboarding Drags the Whole Team Down

The second cost of adding developers to a late project is the one nobody schedules for: ramp-up. A new engineer doesn't ship meaningful work for months, and getting them there pulls your best people off the critical path.

The numbers are sobering. A survey of 80 engineering organizations found that onboarding ramp-up time—the stretch before a new hire is fully productive—averages three to nine months, and sometimes approaches a year. During that window, your senior engineers aren't building; they're answering questions, reviewing tentative pull requests, and explaining how the system fits together. On a late project, that's exactly the time you can't afford to lose.

The trend is improving, but slowly. According to DX's 2026 benchmark of 400 companies, the median "Time to 10th PR"—a proxy for early ramp—fell from 91 days for developers who don't use AI to 49 days for those using AI daily. As of April 2026 the dataset average sits at 33 days, down from 39 the prior quarter. AI assistants genuinely help new hires find their footing. But notice what that metric measures: shipping ten small changes, not deep system understanding. The hardest part of onboarding—learning why the code is shaped the way it is—still happens human-to-human, and it still consumes the team's most experienced people. Multiply that across several hires landing at once and you can see why Brooks's Law for remote teams punishes late-stage staffing so reliably.

Brooks's Law for Remote Teams: The Coordination Tax

Put communication overhead and onboarding together and you get the modern version of the problem. Brooks's Law for remote teams isn't just "more people, more channels"—it's that distributed work amplifies every coordination cost while removing the cheap, informal fixes a shared office used to provide.

Healthy distributed teams seem to know this instinctively. The pattern that works is the small, autonomous pod—distributed team coordination built around units of roughly three to six engineers with overlapping working hours, coordinating with each other asynchronously rather than in one giant standup. Below that size, communication is cheap and trust is high. Friction tends to creep in as a single team pushes past fifteen people: standups multiply, review cycles slow, and velocity quietly drops even as headcount climbs.

Meetings are where the tax gets paid. The instinct when a remote project slips is to "sync more"—but extra meetings fragment focus and slow decisions instead of speeding them. Workers already report losing around 31 hours a month to unproductive meetings. Pile more bodies into those calls and you don't get clarity; you get meeting toil and a calendar that eats the workday. The deeper risk is silent: when coordination is expensive, people stop coordinating, and two engineers ship duplicate work neither knew the other was doing.

How to Scale Without Triggering Brooks's Law

Brooks's Law isn't a reason to stay small—it's a reason to grow deliberately. Here's how high-functioning remote teams keep scaling engineering teams without paying the full tax:

Add people early, not late. Brooks's Law specifically punishes reinforcements thrown at a project that's already behind. Staff up before the crunch, while there's slack to absorb onboarding.
Keep pods small and high-context. Two pizzas, not a banquet. Three to six engineers with clear ownership keeps the communication paths low and the trust high.
Cut the number of links, not just the meeting count. Give each pod a crisp commander's intent—the goal and the guardrails—so people can decide on their own instead of routing every question through a sync.
Make async the default. A decision written down once can be read by ten people without ten conversations. Documentation is how you flatten the n(n−1)/2 curve.
Protect your senior engineers' focus. Onboarding is real work—staff it intentionally instead of letting it silently drain your critical path.

This is also where your tooling earns its keep. When you do meet, the goal is to make each touchpoint count so a decision is made once and never re-litigated. Coommit is built for exactly that: video, an interactive canvas, and a contextual AI in one workspace, so the call, the diagram, and the action items live together. Instead of a decision evaporating the moment the meeting ends, Coommit's AI captures what was agreed and who owns it—closing communication paths instead of opening new ones.

The Bottom Line

Brooks's Law for remote teams is a 50-year-old warning that landed squarely in the distributed era. Adding people to a late, fully remote project doesn't just fail to help—it actively sets you back, because the communication overhead compounds and onboarding eats your best engineers' time. The fix isn't to fear growth; it's to grow on purpose: small pods, clear intent, async by default, and meetings that produce decisions instead of more meetings. Headcount has never been the lever for speed. Coordination is. Master that, and you can scale your remote team without watching Brooks's Law play out in your own sprint board.