The Coordination Tax: Brooks’s Law and Why Adding Engineers Made Your Team Slower

Last updated: September 16, 2026

By Kris Drouet, Engineering Executive, in partnership with KORE1

Eleven engineers in January. Nineteen by July.

The budget got approved in the spring, the recruiters did their job, and every seat went to someone good. If you have lived some version of that year, you can probably finish the story yourself. Pull requests that used to merge by end of day started waiting three days. Your two strongest seniors spent their afternoons walking new people through the payments module instead of changing it, and most evenings answering the Slack questions those afternoons generated, a cost that never appeared in anyone’s hiring plan. Sprint planning grew from an hour and a half to most of a Tuesday. And sometime in the fall the CEO asked a fair question in a tone that wasn’t entirely fair. What did eight salaries buy?

Throughput had dropped. I mean working changes reaching a customer, not tickets closed, and that number sat lower with nineteen people than it had with eleven.

Fred Brooks described this in 1975, drawing on his time managing IBM’s OS/360 development, and the sentence he boiled it down to is still one of the most quoted lines in software management. I have watched it play out in a lot of engineering orgs since. Two of them were mine. It is the kind of lesson you should only need once, and I needed it twice.

Disclosure first. It matters more than usual here, since I write these with KORE1, and KORE1 gets paid when companies hire engineers. This piece argues that some of the reqs sitting on your desk right now should wait. They published it anyway. If you haven’t read my Clarity Stack diagnosis for stalled engineering velocity, open it in another tab, because its first layer is where the coordination tax does its worst damage.

What Brooks’s Law Actually Says, and Where People Stretch It

Brooks’s law is Fred Brooks’s 1975 observation that adding manpower to a late software project makes it later. New people need training only the existing team can give, and pairwise communication grows as n(n-1)/2, so the extra coordination can cancel out the extra capacity.

The source is chapter two of The Mythical Man-Month, and the original is more careful than the version that gets passed around. Brooks names two costs. Training comes first, and he notes it “cannot be partitioned,” so its cost climbs in a straight line with every person you add. Intercommunication is the second part, and he calls it worse. If every piece of the work has to be coordinated with every other piece, “the effort increases as n(n-1)/2.” Three workers carry three times the pairwise coordination of two. Four carry six times. Then comes the line most readers skim past, about group meetings among three or four people making things worse still.

He also gave the famous analogy in plainer words than the internet does. “The bearing of a child takes nine months, no matter how many women are assigned.” Many software tasks behave that way, he wrote, “because of the sequential nature of debugging.”

And he labeled his own law a caricature before stating it. The exact words are “Oversimplifying outrageously, we state Brooks’s Law.” People quote the law and drop the warning, which is a bit like reading a warranty and skipping the part in small print.

People stretch it in one direction. In a 1999 IEEE Software column titled “Brooks’ Law Repealed?” Steve McConnell argued that the law is implicitly about a project’s final phases. Add two people to a twelve-month project at the end of month two and it doesn’t apply. He also pointed to NASA’s Software Engineering Laboratory, which recommended starting with a small senior staff and adding people once requirements and architecture were mostly done.

On the wording, McConnell wins. I’d still bet against anyone who takes that as permission to grow fast, because the mechanism underneath, training plus intercommunication, has no idea whether your project is late. It just sends the bill.

The Coordination Tax Is Brooks’s Mechanism Without the Deadline

The coordination tax is the share of an engineering team’s capacity that goes to keeping people aligned instead of building, which covers onboarding, review queues, design debates, handoffs, and rework from mismatched assumptions. It grows faster than headcount does, whether or not anyone is behind schedule.

For the team in the opening, the arithmetic looks like this. Every number is a ceiling. Most pairs never talk directly. The ceiling still matters, since you can’t know in advance which pairs are going to need to.

Going from eleven to nineteen is a 73% increase in people. In paths, it is 211%.

Brooks’s endnotes hold a number I almost never see quoted. He passes along an estimate from V. A. Vyssotsky of Bell Telephone Laboratories that a large project can sustain a manpower buildup of 30% per year, and that growing faster strains, even inhibits, “the evolution of the essential informal structure and its communication pathways.” One lab, one era, so hold it loosely. Still, the team in my opening grew 73% in six months. I have sat in board meetings where that pace was the plan.

So what does the tax look like on an ordinary Tuesday? Almost never one big cost. It arrives as several small ones that each look reasonable alone.

• Your most senior engineers turn into the onboarding program. It was never a decision. Questions flow to whoever answers fastest, and that is always the same three people.
• Eight new authors open pull requests against code only two reviewers really understand, so time to first review climbs even though no reviewer got any slower.
• How many people have to agree before a design doc moves? On a team of eleven I usually count three. At nineteen I have watched it reach seven, partly because every new stakeholder is also a new person who gets annoyed when left out.
• Merge conflicts and broken builds go up, mostly in the modules where the new people and the old ones overlap.
• A question that used to get answered at someone’s desk now needs a thread, and the thread needs a meeting two days out.
• Rework, the expensive line, which has its own section further down.

Late Projects Aren’t the Only Ones Paying

The best evidence I know of comes from Microsoft, and it isn’t a survey. In a 2008 paper, Nachiappan Nagappan, Brendan Murphy, and Victor Basili built organizational metrics for Windows Vista, measures like how many engineers had touched each binary, how many of those engineers had since left the company, and how scattered ownership was across the org chart. Then they used those people measures to predict which binaries would turn out failure-prone, across more than 3,400 binaries and roughly 50 million lines of code. Average precision came in at 87%, and recall at 84%. Both beat models built on code churn, complexity, test coverage, dependencies, and pre-release bug counts.

Read that twice. The org chart predicted the bugs better than the code did.

The authors cite Brooks, too. More engineers touching the same code means more paths to keep in sync, and more chances for design mismatches and broken builds. Deadlines never enter into it. A binary’s ninth contributor raises its risk on a calm week just as much as on a late one.

J. Richard Hackman, who studied teams for decades, much of that time at Harvard, said it more bluntly in a 2009 Harvard Business Review interview. As a team grows, the links that need managing go up “at an accelerating, almost exponential rate,” and managing those links is what gets teams into trouble. His rule of thumb was “no double digits.” He meant it.

Ten isn’t magic to me. I have run a very functional team of twelve and a miserable team of six. But once a single team passes about nine, I stop asking whether coordination cost went up and start asking who is paying it.

Layer 1 Breaks First When Headcount Jumps

The first layer of the Clarity Stack is a shared definition of done. Can the team describe, in roughly the same words, what success on the current initiative looks like? On a team of eleven that definition often lives in shared memory. It rarely gets written down. The four engineers who have been around longest carry it, and everyone else absorbs it by sitting near them.

Hiring breaks that transmission. Each new engineer learns what done means secondhand, from whoever reviewed their first handful of pull requests, and each reviewer hands down a slightly different version. By the time a team has nearly doubled, there is no single definition left. There is a family tree.

I ran my usual test on a lending platform team that had grown from fourteen engineers to twenty-six in about three quarters. I asked each engineer alone. What does success on this quarter’s biggest initiative look like? The six people who predated the hiring push gave me close to one answer. The eight newest gave me four, and when I matched each answer to the person who had onboarded that engineer, the pairs lined up almost perfectly. Those eight were good hires. They were faithfully reproducing four slightly different versions of their onboarding buddy.

Rework starts there. Having four definitions of done means work gets built to one, reviewed against another, sent back, and rebuilt. Under the hood it shows up as reopened tickets and pull request threads that end with “let’s just sync live.” On your calendar it shows up as the sync.

The fix is boring. It has to land before onboarding, not after. Write the definition for the current initiative in a sentence a new hire can read on day one. Then have whoever onboards them point at that sentence instead of explaining done from memory, because memory is exactly the channel that drifted.

Four Checks That Tell You Whether You’re Paying It

First, rule out plain exhaustion. A team coming off a long crunch shows several of the same symptoms for a completely different reason, and the treatment runs close to the opposite. I wrote up four tests that tell slow teams from exhausted ones in another piece. If yours is simply tired, close this tab and go cut scope.

Otherwise, pull these four. None takes more than an afternoon, and each one compares the quarter before your hiring push against your most recent full quarter.

Review wait against pull request size. Put median hours from opened to first review next to median lines changed. Wait time climbing while pull requests stayed the same size says reviewer attention is the constraint, and the new authors are feeding a queue that didn’t grow with them. KORE1’s diagnostic flags anything past 18 hours.

Whose calendar absorbed the hiring? Export the calendars of the three engineers who review the most code and count the uninterrupted two-hour blocks, before and after. Paul Graham described why that count matters in his 2009 essay “Maker’s Schedule, Manager’s Schedule,” where he points out that for someone who builds things, “a single meeting can blow a whole afternoon.” A hiring push quietly moves your best builders onto a manager’s schedule. No title change, no raise.

Then count the yeses. Take the last twenty changes that reached customers and count how many different people had to review, approve, or answer a question before each one shipped. On the lending team, the average had crept from a little over two to almost five. Four or more is the threshold where the diagnostic starts looking for a missing owner, and the count itself is n(n-1)/2 made visible.

Last comes the done test, run only on the newest third of the team. Six engineers is plenty. If their answers cluster by onboarding buddy, you have found the Layer 1 leak from the previous section.

There’s a free fifth. Compare this year’s engineering headcount with last year’s. Growth well past Vyssotsky’s 30% deserves a hard look at the other four. Show me the data on all of them before anyone opens a new req.

If you would like these as a worksheet, KORE1 turned the Clarity Stack tests into a free engineering velocity assessment your leadership team can work through in a week, with the same six-engineer done test built in. And if you’d rather someone outside the building did the counting, the two-week engineering velocity diagnostic measures wait time, scope survival, and the yes count from your repository and calendars, then ends in a written call on whether the constraint is a process change or a seat.

When Adding Engineers Does Speed You Up

Hiring isn’t the villain here. Hiring into a shape that can’t absorb people is.

The cleanest growth I have been part of came after a decoupling project, when we moved a set of tightly wired mortgage systems onto a Kafka event backbone. Before that rebuild, adding a downstream consumer meant editing the producer, which meant a meeting with the pricing team. Afterward it meant subscribing to a topic with a registered schema. That meeting went away. Engineers who joined the platform later could build against the event contract without ever sitting down with the people who owned the producer. The full rebuild is in the Kafka pub/sub decoupling case study, but the lesson here isn’t about Kafka. The contract did the coordinating, so people didn’t have to.

That generalizes. In my experience, new engineers make a team faster when most of these are true.

• The work splits along a boundary that already exists in the system, a service with a stable API or an event contract, not a line somebody plans to draw next quarter.
• Timing. Early in a project, or right after the architecture settles, which was McConnell’s point and NASA’s.
• They arrive already fluent in the stack and the domain. A senior Kafka engineer joining a Kafka platform pays a fraction of the ramp a generalist pays.
• Is the work queue-shaped? Test automation backlogs, data migration scripts, and adapters against a documented third-party API divide cleanly. Design work doesn’t.

The fluency point is where a staffing partner earns its fee or doesn’t, so here is the honest version. KORE1 averages 17 days to hire for IT roles, which gets someone into the seat. It does nothing about ramp. Ramp shrinks when you hire for the exact stack and domain, and retention protects it, because an engineer who leaves in month eight makes you pay the training half of Brooks’s tax twice. That is why KORE1’s 92% twelve-month retention rate matters more to me than the speed number. When a workstream truly separates from the core system, a scoped project staffing engagement built around that boundary usually charges the core team far less coordination than one more seat in the middle of it. If contractors are part of the plan, size contractor pods and ramp waves to reviewer hours before the first start date.

If the real problem is one team owning too much, split it before you grow it. I worked through where those lines tend to go in Team Topologies in practice.

Before You Open Another Req

Does Brooks’s Law Still Hold With AI Coding Assistants on the Team?

Half of Brooks’s law has changed. AI assistants help a new engineer read an unfamiliar codebase faster, which trims the training cost, but they do nothing about how many people have to agree on what gets built.

The communication half gets heavier. More code shows up for review, sooner, from people who understand less of the surrounding system, and it lands on the same two reviewers as before. Faster typing doesn’t shrink n(n-1)/2.

So What Is the Formula Everyone Quotes?

Brooks gave it as n(n-1)/2, where n counts the people who need to coordinate with each other. Five people have 10 possible pairwise paths, ten have 45, and twenty have 190.

Real teams never use every path. Use it as a ceiling rather than a count of real conversations.

Our Project Isn’t Late. Can Brooks’s Law Still Apply?

Strictly speaking, no, since Brooks wrote it about late projects and McConnell argued it mostly bites in the final phases. The coordination cost underneath it applies to any team that grows fast, late or not.

The Vista research backs this. That study never measured a deadline. Its authors measured who touched the code and how ownership was spread, and those numbers predicted where the failures would be.

Realistically, How Long Before a New Engineer Stops Costing the Team Time?

About a quarter for a mid-level engineer joining a mature codebase, in my experience, and longer in regulated domains like lending, where the business rules take as long to learn as the code does.

Seniors who already know the stack can be net positive within a month or so. Juniors take longer. They also pull more senior time while they learn, which is fine when you planned for it and painful when you didn’t. Count the hours of whoever answers the questions, not just the new hire’s. That person is paying the tax, and their name is rarely on the headcount plan.

Why Did Our Standups Get So Long After We Grew?

A standup’s total cost grows with the square of the team, because each new engineer adds an update and also sits through everyone else’s.

Run the numbers at a minute and a half per update. Eight engineers make a twelve-minute standup, 96 person-minutes a day. Nineteen engineers make a 28-and-a-half-minute standup that burns about nine engineer-hours a day before anyone asks a follow-up question. Splitting the meeting helps. Splitting the team helps more.

What Is a Sane Team Size, Then?

Five to eight engineers per team is where I have watched coordination stay cheap. Past nine, decide where the team splits before you add anyone else.

That lines up with Hackman’s “no double digits,” which is roughly where I put the ceiling too.

Count the Paths Before You Count the Chairs

Headcount is the easiest lever an engineering leader has, which is exactly why it gets pulled first. It’s visible, it’s fundable, and it looks great in a board deck. Brooks’s IBM lesson holds. The people you add arrive with conversations attached.

So before the next req, run the four checks. If review wait and the yes count are both climbing, your constraint is coordination, and another engineer will make it worse for at least a quarter. Write down done. Find who is paying the tax and take something off their plate. Split the team if it needs splitting, then hire into the shape you built.

Connect with me on LinkedIn if the checks turn up something you didn’t expect. I enjoy arguing about org charts. And when the answer really is a seat, a senior engineer who already speaks your stack or a team for a workstream that truly stands apart, talk with KORE1 about the hire that fits that shape before anyone writes the job description.