The Simple Version
Adding engineers to a software team increases the amount of coordination required, and coordination takes time away from building. Past a certain size, each new hire slows the team down before they speed it up, and many teams never recover the lost ground.
Why This Feels Wrong
Engineering looks, from the outside, like a parallelizable problem. If one person can build a feature in ten days, ten people should build it in one. This intuition is so persistent that it has its own name: the assumption that software development scales like digging a trench.
It doesn’t. Digging a trench is a task with no dependencies between workers. Software is the opposite. Every piece of a codebase touches other pieces. Decisions made in one corner propagate through the whole system. Adding more people doesn’t divide the work cleanly; it multiplies the number of relationships between people who all need to understand what each other is doing.
Fred Brooks named this in 1975 in The Mythical Man-Month, and the core observation has not aged: adding manpower to a late software project makes it later. The book predates the internet, version control, and cloud infrastructure, and it is still correct.
The Math of Coordination
Here’s why the problem compounds so fast. If you have four engineers on a team, the number of possible communication pairs between them is six. Add two more, and you have fifteen pairs. At ten engineers, you have forty-five. The formula is n(n-1)/2, where n is the number of people.
None of those pairs communicate equally, and most communication is informal, which makes it invisible to managers until something breaks. Two engineers working on adjacent systems will make assumptions about each other’s choices. When those assumptions diverge, you get a bug, a rewrite, or a three-hour meeting nobody scheduled. Silent bugs are the ones that actually ruin you because the coordination failure that caused them often isn’t visible until the damage is done.
This is before accounting for onboarding. A new engineer on an existing team typically takes three to six months to become net positive, meaning they produce more value than they consume in code review time, documentation, questions, and the attention of senior engineers pulled away from shipping.
Hire four engineers at once and you’ve just created a situation where your most experienced people are spending half their time teaching instead of building, for the better part of a year.
Why Companies Keep Doing It Anyway
The incentives point in the wrong direction. Hiring looks like action. It signals investment to boards and investors. It is measurable in a way that productivity is not. A VP of Engineering who responds to a missed deadline by hiring aggressively looks like they’re solving the problem. One who says “we need fewer meetings and cleaner interfaces between systems” sounds like they’re stalling.
There’s also a real phenomenon where companies mistake correlation for causation. The teams at large tech companies that ship the most are often large. But those teams grew because they were already shipping, and the growth was managed over years, not quarters. The causality runs the other way: good teams attract resources, and bad teams use hiring to paper over dysfunction.
This is partly why the engineer who costs $300K is often the cheaper hire. One senior engineer who already understands your system is worth more than four new graduates who each need months of ramp time and generate coordination overhead for everyone around them.
When Hiring Actually Helps
None of this means you should never hire. It means you should hire for the right reasons at the right time.
Hiring works when the bottleneck is genuinely a lack of hands on clearly separable work. If you have three distinct product areas that share no infrastructure, three separate teams each owning one area can operate nearly independently. Conway’s Law, the observation that software systems tend to mirror the communication structure of the organizations that build them, cuts both ways: you can design teams and systems together so that coordination costs stay low.
Hiring also works when you do it slowly enough that each new person is absorbed before the next arrives. Amazon’s famous two-pizza rule, the idea that no team should be larger than can be fed by two pizzas, is an approximation of this principle. It’s not really about pizza. It’s about keeping teams small enough that everyone can maintain a mental model of what everyone else is doing.
The practical implication: if your team is behind, the question worth asking is not “how many engineers do we need” but “what is actually slowing us down.” In most cases the answer is meetings, unclear ownership, technical debt requiring constant workarounds, or a specification that keeps changing. More engineers make all of those problems worse.
The Counterintuitive Management Move
The teams with a reputation for shipping fast are almost always smaller than you’d expect. Basecamp, now 37signals, has been explicit about this for years: they’ve deleted features and gotten better at it partly by keeping teams small enough to move without asking permission.
WhatsApp served 450 million users with 55 engineers before its acquisition by Facebook. Instagram had 13 employees when it sold for a billion dollars. These are extreme cases, but they illustrate that output per engineer often drops as headcount grows, not because the new engineers are worse, but because the system around them becomes harder to navigate.
The honest version of the advice for any manager facing a deadline is this: resist the impulse to hire your way out of the problem. Audit the work instead. Kill the features nobody needs. Shorten the feedback loops. Fix the processes that require three people to sign off on a decision one person could make. Then, if you still need more people, hire one at a time and wait for each person to find their footing before hiring the next.
That approach feels slow. It is slower than the fantasy version of hiring. It is faster than the version where you double your team and spend a year untangling the mess.
