Skip to main content
Category: Laws
Type: Project Management
Origin: Software Engineering, 1975, Fred Brooks
Also known as: The Mythical Man-Month
Quick Answer — Brooks’s Law states that adding manpower to a late software project makes it later. Formulated by Fred Brooks based on his experience leading IBM’s OS/360 project, this principle reveals why schedule delays in complex projects cannot be solved by simply throwing more resources at them—new team members require training and create coordination overhead that outweighs their short-term contribution.

​
What is Brooks’s Law?

Brooks’s Law is a fundamental principle in software project management that describes the counterintuitive relationship between team size and project schedule. The law states that adding more people to a late project delays it further—not because the new people are incompetent, but because of the inherent costs of onboarding, communication, and coordination.
“Adding manpower to a late software project makes it later.” — Fred Brooks
The core insight is that software development is not like manufacturing. In a factory, adding workers usually increases output proportionally. But in complex knowledge work, the communication overhead grows non-linearly with team size. Each new person must be trained, integrated into workflows, and coordinated with existing team members—creating work that diverts attention from actual progress.

​
Brooks’s Law in 3 Depths

  • Beginner: Understand that adding people to a struggling project often makes things worse, not better. The initial enthusiasm of new hires is offset by training and coordination costs.
  • Practitioner: Before adding resources to a delayed project, calculate the “ramp-up time” for new members and the coordination overhead. Often, reducing scope or improving processes is more effective.
  • Advanced: Recognize that Brooks’s Law applies most strongly to projects with high interdependence. Highly modular projects can absorb new members more easily. Also understand when the law can be circumvented—adding people to “feature farms” with low coupling.

​
Origin

Fred Brooks (born 1931) is an American software engineer and computer scientist who managed IBM’s OS/360 operating system project in the 1960s. The OS/360 project was one of the largest software projects of its time, and despite being technically successful, it ran significantly over schedule and budget. In 1975, Brooks published his experiences and insights in “The Mythical Man-Month: Essays on Software Engineering.” The book became a cornerstone of software engineering literature, and Brooks’s Law has since been cited in countless project post-mortems and management discussions. The “man-month” in the title refers to a unit of work representing one person’s effort for one month. Brooks argued that this unit is a dangerous myth when applied to interdependent tasks—because people and months are not interchangeable.

​
Key Points

1

Communication overhead grows with team size

Every new team member adds communication channels with all existing members. With n people, there are n(n-1)/2 possible communication paths. A team of 10 has 45 channels; a team of 20 has 190.
2

New members require ramp-up time

Before new developers can contribute productively, they must learn the codebase, tools, processes, and domain. During this period, they consume more resources than they produce.
3

Work splits imperfectly

Many software tasks are interdependent and cannot be parallelized. You cannot simply divide a complex system into independent pieces and assign them to different people without coordination.
4

The best remedy is often scope reduction

When behind schedule, the most effective interventions are reducing features, improving processes, or addressing root causes—not adding more people.

​
Applications

Project Planning

Build realistic schedules by accounting for coordination overhead. Recognize that doubling the team rarely halves the timeline.

Hiring Decisions

Resist the temptation to “throw people at problems.” Evaluate whether new hires can be onboarded quickly enough to help.

Crisis Management

When projects are behind, investigate root causes first. Adding resources without fixing underlying issues compounds problems.

Team Structure

Design teams for autonomy and minimal interdependency. Conway’s Law suggests system architecture mirrors team communication patterns.

​
Case Study

​
The OS/360 Project

IBM’s OS/360 operating system project in the mid-1960s was groundbreaking in scale—millions of lines of code, hundreds of developers, and ambitious goals for compatibility across IBM’s computer line. When the project fell behind schedule, IBM’s management responded conventionally: they added more programmers. Brooks observed that this only made things worse. New programmers had to be trained on the massive codebase, existing team members spent time mentoring rather than coding, and the increased coordination burden slowed everyone down. The project ultimately shipped, but years late and far over budget. Brooks later wrote that the most valuable thing he learned from OS/360 was that “the bearing of a child takes nine months, no matter how many women are assigned.”

​
Boundaries and Failure Modes

When the principle doesn’t apply:
  • Highly modular projects: If work can be cleanly divided into independent modules, adding people can help. The key is whether tasks have true dependencies.
  • Early project phases: Adding people to a project just starting may be less costly, as there is less context to learn.
  • Purely sequential tasks: If work is purely additive (like data entry), more people does increase throughput.
Common misuses:
  • Using Brooks’s Law to justify understaffing: The law doesn’t say you should never add people—it says adding people to a late project is counterproductive. Adequate staffing from the start is still important.
  • Ignoring the law in emergencies: Some managers panic and add people anyway, learning the lesson repeatedly.
  • Applying it to all domains: Brooks’s Law was specifically about software; its applicability to other fields varies.

​
Common Misconceptions

Wrong. The law specifically addresses late projects. Adding people to a project that is on schedule but needs acceleration can work if the work is decomposable.
Wrong. The principle applies to any complex, interdependent knowledge work—not just software. Creative projects, research teams, and complex organizational initiatives all exhibit similar dynamics.
Wrong. While tools have improved, the fundamental challenge of communication overhead and ramp-up time persists. Modern agile methods actually emphasize more communication, making the law even more relevant.

The Mythical Man-Month

Brooks’s seminal book on software project management that introduced this law.

Conway's Law

The observation that system design mirrors the communication structure of the organization.

Parkinson's Law

The observation that work expands to fill the time available for its completion.

Critical Path Analysis

A project management technique for identifying the sequence of tasks that determines project duration.

Agile Methodology

Development approaches that emphasize iterative progress and team collaboration.

Scope Creep

The uncontrolled expansion of project requirements beyond the original goals.

​
One-Line Takeaway

Remember: adding people to a late project creates more delay—focus on reducing scope, improving processes, or fixing root causes instead of throwing resources at schedule problems.