A team of three has three pairs of people who might need to talk to each other. A team of five has ten. A team of ten has forty-five. The work a team can do grows roughly with its head count, while the number of possible conversations grows roughly with its square.
That gap is the arithmetic under the most quoted sentence in software management. Fred Brooks, who managed IBM's OS/360 software project during its design phase, wrote it in The Mythical Man-Month (1975): "Adding manpower to a late software project makes it later." He named it Brooks's Law, and he introduced it with a disclaimer that usually gets left off: "Oversimplifying outrageously."
Brooks's Law is the observation that adding people to a software project that is already behind schedule tends to delay it further, because the newcomers need training from the people already on the project and add communication paths that grow faster than the team does.
What Brooks actually argued
The law closes a chapter whose real target is a unit of measure. "Cost does indeed vary as the product of the number of men and the number of months," Brooks wrote. "Progress does not." People and months trade evenly only when a task "can be partitioned among many workers with no communication among them." That holds for reaping wheat or picking cotton, he said, and is "not even approximately true of systems programming."
He sorted work into three kinds. Some tasks can't be split at all because each step waits on the last: "The bearing of a child takes nine months, no matter how many women are assigned." Debugging, he argued, is often like that. Some tasks can be split but need the pieces coordinated, so adding people helps less than the head count suggests. And some tasks are so interconnected that the effort of communicating "may fully counteract the division of the original task."
Then he worked an example. A task is estimated at 12 man-months and given to three people for four months, with a milestone at the end of each month. The first milestone takes two months instead of one. Assuming only that first stretch was misjudged, nine man-months of work remain and two months to do them, so the manager adds two people. If one of the original three spends a month training them, "3 man-months will have been devoted to work not in the original estimate." The work, split three ways, now has to be split five ways, some finished work is lost, and testing grows. Brooks's verdict: the product is "just as late as if no one had been added." By then things look bad enough that the manager is tempted to add still more people. "Therein lies madness."
Two costs, both paid by the people who already know
Brooks divided the added burden into two parts.
Training. "Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work." Training can't be divided up, so it grows with every person added. In his example it is done by "one of the experienced men," which means it comes out of the scarcest time on the project, at the moment the project can least afford it.
Intercommunication. "If each part of the task must be separately coordinated with each other part, the effort increases as n(n-1)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two." Meetings of three or four people to settle things together, he added, make it worse.
Look again at the four things on the training list. A strong hire usually brings the technology with them. The goals, the strategy and the plan of work are specific to this project, and they live in the heads of the people already on it. An engineer who joins on Monday knows the framework and doesn't know why the API is versioned the way it is, or which approach the team ruled out in March. A coding agent added to a late project has the same split: fluent in the technology, starting from zero on the other three, and starting from zero again in each new session unless something gives it the project's context.
Brooks's own remedy was a record
Brooks returned to communication in a later chapter, "Why Did the Tower of Babel Fail?" Judged as an engineering project, he wrote, Babel had a clear mission, plenty of manpower, abundant materials, enough time and adequate technology. It failed in "communication, and its consequent, organization."
His remedies were telephones, regular meetings, and one he gave a section of its own: "A formal project workbook must be started at the beginning." The workbook put a structure over every document the project produced, from objectives and specifications to standards and memos. Its purpose, in his words: "The problem is not to restrict information, but to ensure that relevant information gets to all the people who need it." On OS/360, every programmer got a copy.
It got heavy fast. Within six months the OS/360 workbook was about five feet thick, and daily changes averaged two inches, some 150 pages to file. The team moved it to microfiche. Along the way Brooks named the two questions a reader brings to an updated page. On first seeing a change: "What has been changed?" On consulting it later: "What is the definition today?"
He also recorded a dissent. David Parnas, then at Carnegie-Mellon, proposed that a programmer is most effective when "shielded from, rather than exposed to" the details of the parts other people are building. Brooks called it "definitely sound design" but warned that depending on every interface being defined perfectly "is a recipe for disaster." The useful point survives the disagreement: a newcomer doesn't need the whole record, just the part that bears on the work in front of them.
Brooks's workbook, rebuilt around decisions
Brief keeps the part of Brooks's workbook that goes stale fastest and costs the most to pass along by hand: the team's decisions, with their reasons, connected to the features and work they govern. Here is how Brooks's needs map onto it.
| What Brooks needed | How OS/360 met it | How Brief meets it |
|---|---|---|
| Train newcomers in goals, strategy and plan | An experienced engineer's time | brief_get_onboarding_context at session start, or brief decisions search |
| Get relevant information to everyone who needs it | A copy of the workbook in every office | Decisions captured where they're made, readable by every person and agent |
| "What is the definition today?" | The continually maintained document | brief ask --mode check against current decisions |
| "What has been changed?" | Change bars in the margin and a change summary | Supersession links that mark which decision replaced which |
Training without taking a senior engineer off the work. Brief's agent setup docs tell a coding agent to call brief_get_onboarding_context at the start of every session. It returns the team's decisions, features, personas, velocity, recent work and customer insights, which covers most of Brooks's goals, strategy and plan of work, delivered before the agent writes a line. A person joining the project can run brief decisions search "billing" from the terminal and read what was settled and why, without booking an hour with whoever was in the room at the time. The training still happens. It just stops coming out of the experienced engineer's month.
One record in the middle of the pairs. The n(n-1)/2 count assumes that when two people settle something, everyone else learns it through more conversations, pair by pair. Brief changes how that decision travels. In Slack, mention @Brief in the thread where the call was made and Brief reads the surrounding thread, proposes a structured decision, and shows a preview to confirm or edit. From the terminal, brief decisions create --decision "Bill annually by default for new teams" --rationale "Churn on monthly plans was twice annual in the last two quarters" does the same. After that, the other people on the project reach the decision through the record, so a ten-person team needs ten paths to one place where it used to need forty-five between pairs. The discussion that produces a decision still takes the conversations it takes. What drops is the cost of passing the result along.
"What is the definition today?" for the part you're touching. Before building, an agent or engineer can run brief ask --mode check "We plan to add monthly billing to the self-serve flow", and Brief validates the approach against the decisions already on record. That is closer to Parnas than to the five-foot binder. Nobody reads the whole workbook. They ask about the piece in front of them, and the check runs against everything the team has settled.
"What has been changed?" without losing what it changed from. When the billing default changes next year, Brief tracks that the new decision replaces the old one. The old decision stays as history, so a newcomer can see why the system was built the first way, and it's marked as no longer governing, so nobody builds against it by mistake. The supersession post covers how that link works.
Where Brooks still wins. None of this repeals the law. Work that has to happen in sequence still takes as long as it takes, and splitting three people's work five ways still costs what Brooks said it costs. A record covers decisions and the reasons for them. It doesn't cover the tacit knowledge of how a flaky test suite behaves or which service to restart first, and it only holds what the team actually captured. Brooks's own advice for the late project in his example was to reschedule or cut scope, and that is still the advice. What a decision record does is make each added person, and each new agent session, cheaper to bring up to speed, so that a team which has to grow can grow without the people who know the most spending their month repeating it.
If your project slipped tomorrow and you added two people, how much of what they need could they read on day one, and how much would they have to ask someone who's already behind?
Objections
What is Brooks's Law?
Brooks's Law is Fred Brooks's observation, from his 1975 book The Mythical Man-Month, that "adding manpower to a late software project makes it later." New people need to be trained by people already on the project, and every person added creates more pairs who may need to coordinate, so the added effort can outweigh the added capacity.
Is Brooks's Law always true?
No, and Brooks didn't claim it was. He introduced it with the words "oversimplifying outrageously." His argument depends on how much training newcomers need, how much the work can be split without coordination, and how much of it has to happen in sequence. Work that splits cleanly into independent pieces with little to learn behaves more like his example of reaping wheat, where people and months trade evenly.
Does Brooks's Law apply to AI coding agents?
Brooks's two costs both show up with agents. An agent knows the technology but starts without the project's goals, strategy and plan unless something provides them, and that gap returns in each new session. Several agents working on connected parts of a system also need their work coordinated. Giving agents the team's decisions at the start of a session reduces the training cost. It doesn't change the sequential parts of the work that Brooks said no amount of added effort can speed up.
How does Brief help with Brooks's Law?
Brief keeps a team's decisions and their reasons in one shared record. Coding agents load that context at session start with brief_get_onboarding_context, people search it with brief decisions search, and anyone can check a planned approach against existing decisions with brief ask --mode check. Decisions can be captured from a Slack thread with an @Brief mention or from the terminal, and Brief tracks when one decision replaces another. Newcomers can read the record without pulling experienced people away from the work, though the project's sequential constraints stay the same.