Brooks's law
This is a named pattern with documented cases and a sound logic behind it, not an effect anyone has measured. Treat it as a lens that keeps proving useful rather than as a law.
Fred Brooks managed the development of OS/360 at IBM in the 1960s, the operating system for the System/360 family and one of the largest software undertakings there had been. The project fell behind schedule. Brooks responded the way nearly every manager responds, by adding programmers, and later concluded that the additions had delayed the project further. A decade on he collected what he had learned in The Mythical Man-Month, published in 1975, and stated the law with a warning built into the sentence: oversimplifying outrageously, adding manpower to a late software project makes it later.
The first mechanism is ramp-up. A new person does not arrive productive. They have to learn what has already been built, what was tried and abandoned, and where the bodies are buried, and the only people who can teach them are the ones already carrying the project, which is to say the people with the least time. So the immediate effect of adding someone is that the most loaded people slow down, and if the newcomer introduces errors while learning, the contribution can run negative for a while.
The second mechanism is arithmetic. If everyone on a task needs to stay aligned with everyone else, the number of conversations grows with the square of the team. Three people need three channels. Five need ten. Ten need forty-five. The work grew linearly and the coordination grew quadratically, which is how a team can get bigger and slower at the same time. The third factor Brooks named is that some work does not divide: his line was that nine women cannot produce a baby in one month, and the month a manager hopes to buy with headcount assumes the work partitions cleanly, which late, tangled work rarely does.
Brooks was careful about the law's status. He called it an outrageous oversimplification in the same breath as stating it, and he joked that his book was called the Bible of software engineering because everybody quotes it, some people read it, and a few people go by it. The genuine exceptions follow from the mechanisms rather than contradicting them: adding people early, when ramp-up is affordable, works. Adding people to work that splits into independent pieces works. Adding one experienced person who needs little teaching can work. And large open source projects absorb thousands of contributors without collapsing, because the work is partitioned, the coordination is asynchronous, and nobody is onboarding anybody under deadline.
Later empirical work on software teams has supported the mechanisms: studies of large code repositories find that new contributors take months to reach full productivity and that output per person falls as teams grow past a small size. The law's precise strength varies with the team, the work and the timing, which is the honest reason it grades as an argument rather than a measured law. Its two cousins in this library describe the neighbouring failures: effort per person falling as groups grow, which is the Ringelmann effect, and the shape of the team ending up inside the product, which is Conway's law.
The reflex this law exists to interrupt is the one every leader has felt: the project is late, the board is asking, and headcount is the lever that looks like action. Budget approved, offer sent, problem visibly addressed. The law says the visible action and the actual effect point in opposite directions, because the new person's first weeks are paid for by the people who had no time, and the coordination the new person adds never leaves.
The discipline it suggests is to price the addition honestly before making it. A new person costs their salary, which the budget shows, and they cost hours from the people already carrying the project, which no budget shows. On a late project the second cost lands exactly where it does the most damage. So the questions worth asking before any rescue hire: does this work genuinely split into a piece someone can own without daily coordination, is there anyone free enough to teach, and is the person arriving experienced enough to need little teaching? Three yeses and the addition can help. Any no, and the honest alternatives are the unglamorous ones, cutting scope, moving the date, or letting the team you have finish the thing.
It also says something about when to staff. The time to add people is before the crunch, when ramp-up is cheap and the channels can settle, which is precisely when adding people feels least urgent. Staffing decisions made under deadline pressure are the ones this law eats.
And it gives a name to something founders discover expensively: a team of five that ships is not a worse machine than a team of fifteen that coordinates. Past a certain point, the meetings are the product.
Adding people to a late project makes it later. Splitting pin-making among ten workers raised output from twenty pins a day to forty-eight thousand. Both are about headcount and the design of work, and they point opposite ways. What separates them is whether the work divides into pieces that can be owned without daily coordination. The pin factory's eighteen operations handed off cleanly. Brooks's programmers had to keep talking. Before any rescue hire, the question is which of the two you are in.
Brooks says adding people to a late project makes it later, because the new person's first weeks are paid for by the people with no time and the coordination never leaves. Attention residue says splitting one person across several things does not give you fractions of a person, because each switch leaves part of their mind behind. Same arithmetic error from two directions: hours divide, and neither coordination nor attention does. Brooks is the cost of adding heads. Residue is the cost of splitting one. A plan that staffs a rescue with three people at a third each has made both mistakes in one line, and the tax shows up in quality rather than time, which is why nobody's budget will ever show it.
Little's Law says the time to finish equals what is open divided by what gets finished, so there are only two levers: cut the count of open work, or raise the rate of finishing. Brooks says the most tempting way to raise the rate, adding people to a late project, lowers it instead, because new people consume the time of the people who have none. Put together they explain why late organisations stay late: the lever that works is the one that looks like giving up, and the lever that looks like action makes the division worse on both ends at once.
Source: Brooks, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975; the law is stated in chapter 2. The anniversary edition of 1995 adds his own twenty-year reassessment. The OS/360 origin and his oversimplification caveat are Brooks's own account, in the book and the publisher's edition.
Fred Brooks, 1975
Essays from the man who ran the project that taught him the law, still in print fifty years later, which the Lindy entry would tell you is not an accident. Read it for the man-month chapter and stay for the rest.
Draw your own card. It does not take long, and it rewards taking your time.