Brooks's Law

When a schedule slips, the first suggestion is almost always the same one: put more people on it. The arithmetic forms in your head before anything else does — divide the remaining work by the number of people and you get the time required. If two people need four months, four people ought to need two.

That arithmetic got tested at scale on IBM's operating system project in the 1960s. The schedule slipped, a large number of engineers were added, and the schedule slipped further. Frederick Brooks, who managed the project, wrote up the experience in a 1975 book arguing that the mistake was the mental model itself — the idea that people and months are interchangeable. The unit used for budgeting, one person working for one month, quietly convinces everyone it can be traded in both directions.

Before that, this outcome was always explained locally. A team added people, fell further behind, and the conclusion was that the new hires weren't strong enough or the manager hadn't organized the work. Brooks's law says the result comes from structure rather than from any particular team. Hire well, manage well, and adding people to a late project still makes it later for a while. The question worth asking is not whether the new people are good but whether the team has the hours to absorb them right now.

More people means more hands, but it also means three costs growing at the same time, and on a late project the second set outweighs the first.

1. Somebody has to teach. During the ramp-up time before a new person carries their own weight, someone explains the code structure, the deploy process, and the reasoning behind past decisions. The person able to give that explanation is the person with the least time to spare. For the first few weeks after a hire joins, the team's output goes down rather than up.
2. Communication paths grow with the square of the team. Three people have three pairs to keep in sync; eight people have twenty-eight. The headcount went up two and a half times while the number of connections went up more than nine. Meetings get longer, the same decision gets explained twice, and two people edit the same file on the same afternoon. None of that shows up as anyone doing less work; it shows up as the same work being done twice or undone.
3. Some work refuses to be divided. Certain steps have a fixed order, so extra people don't shorten them. If the payment module's design has to be settled before any screen can sit on top of it, putting three more engineers on the design doesn't finish it in three days. Nine people cannot produce one baby in one month.

All three costs get worse the later the project already is. With slack in the schedule, someone can afford the hours spent teaching. On a team that's behind, the person who would teach is the person holding the deadline. That's why the same hire helps at the start of a project and hurts near the end.

The phrase comes up in three kinds of rooms.

1. Meetings under deadline pressure. The date won't move and the work hasn't shrunk, so staffing up looks like the only available lever. Someone who knows this law reaches for a different one, usually cutting scope. Shipping two features instead of three lands faster than adding two engineers.
2. Headcount planning. Once you accept the law, when you hire matters as much as how many you hire. Three people joining a month before a quarter's deadline contribute nothing to that quarter, and they subtract from it by taking time from whoever trains them.
3. The reverse case — deciding when adding people is fine. Three conditions make it fine: the project is early enough that learning time still fits, the work splits off cleanly, or the new person can work without routing through anyone already loaded. Documentation and test environment work usually qualify, as does a second surface that shares almost no code with the one under pressure.

The decision shows up most often during crunch, the stretch of long hours right before a release, which is exactly when all three costs are at their highest.

"Two more engineers won't get this done this month. That's Brooks's law."

Staffing up can't save this deadline, and a proposal to cut scope usually follows.

"We need to hire for next quarter now. Someone joining a month before the deadline is a cost, not a help."

A request to move the hiring timeline forward.

"This piece splits off cleanly, so we can put more people on it."

A judgment that this particular work is one of the exceptions.

At Pagedeck the phrase came up midway through a sprint building permission management for enterprise customers. A launch date was written into a contract and the work was running about a week behind. Someone proposed borrowing two engineers from another team.

Theo argued against it, and his reason had nothing to do with their ability. Explaining the permission model would take two days, and the only person who could explain it was the one person with no days to spare. He proposed dropping the audit log screen from this release and moving it to the next cycle instead. That decision held the date. The two borrowed engineers joined at the start of the following cycle, when there was time to bring them in properly.

The most common misreading turns the law into a ban on hiring. The sentence is absolute enough to sound like a rule. But its scope is specifically projects that are already late. Growing a team early, or hiring now against next quarter's plan, isn't what it describes. Read as a ban, it pushes teams to defer hiring until they're behind and then hire in a panic — which is precisely the behavior the law warns about.

The second misreading is that better tooling made it obsolete. Documentation is organized, a development environment is a day's work, so surely onboarding costs less than it used to. Setup time really has collapsed. But that's one of the three costs. Learning why past decisions were made, and learning who to ask about what, takes as long as it ever did, and communication paths still grow with the square of the team. On a team spread across locations and time zones, that cost is larger now, not smaller.