Brooks’s Law

Written by

Sergio Caredda

Posted on

September 7, 2024

Edited on

September 7, 2024

Key Implications of Brooks’s Law:

1. Training and Onboarding Overhead:

When new people are added to a project, they need to be trained and brought up to speed on the project’s goals, current status, codebase, and practices. This requires time from the existing team members, temporarily reducing their productivity.

Example: If a software development team is working on a complex project and new developers are added, the original team members will need to spend significant time mentoring and assisting the new hires, which can slow down overall progress.

2. Communication Overhead:

As the number of people involved in a project increases, the number of communication channels between them also increases exponentially. This added communication overhead can lead to miscommunication, coordination problems, and decision-making delays.

Example: In a small team of three, there are three communication channels (one between each pair). However, in a team of six, the number of communication channels jumps to fifteen, significantly increasing the complexity of coordination.

3. Diminishing Returns:

Beyond a certain point, adding more resources to a project leads to diminishing returns in productivity. Instead of speeding up, the project may slow down as the team becomes bogged down by increased coordination and management tasks.

Example: In a software project that is already late, adding more developers might initially seem like a good idea. However, the effort required to manage the larger team and integrate their contributions might result in the project taking even longer to complete.

4. Parallelization Limits:

Certain tasks within a project cannot be easily divided or parallelized. These tasks must be completed sequentially, and adding more people does not help in such situations.

Example: In software development, tasks like system integration or final testing often need to be done sequentially. Adding more developers won’t make these tasks go faster.

Brooks’s Law in Organization Design

While Brooks’s Law was originally articulated in the context of software engineering, it has broader applicability in various fields of project management and organization design. Modern agile practices, which emphasize small, cross-functional teams and iterative progress, often implicitly acknowledge the principles behind Brooks’s Law by focusing on maintaining manageable team sizes and avoiding overstaffing as a solution to delays.

The law also somehow reflect the principle already outlined in Parkinson’s Law, but it’s consequences are more extensive, as they affect the entire system’s productivity and its capability to improve. The cause for Brooks’ Law can be tracked both in team dynamics, but also in the design of the team itself.

Not only technical problems but management problems as well come from the complexity. This complexity makes overview hard, thus impeding conceptual integrity. It makes it hard to find and control all the loose ends. It creates the tremendous learning and understanding burden […] — F. Brooks (1975)

As teams grow in size, their complexity grows, thus we need to invest more in managing this complexity (Pugliese, 2023), and we create coordination mechanisms that ultimately produce even more complexity.

The flow that originates this can be simply described in the following flow diagram.

Fig. 2: Brook’s Law and Complexity (Pugliese, 2023b)

Let’s review the steps:

Adding new resources or roles to a team or an organization has the Opposite Effect of reducing Systemic Knowledge in the Organisation.
This second factor is needed to be able to deliver Value.
This issue originates the need for more Coordination Effort (note: the main consequence of Brook’s Law is that we need more effort in coordination to deliver the same value that a smaller team would be delivering).
More coordination effort translates in an increased number of coordinators…
This becomes a self-replicating problem circle, which pushes even more the organizational complexity.

The above flow is the most critical outcome of Brooks’ law that every OD practitioner should be aware of, and should counteract. How? By focusing on three aspects:

Ensure that Systemic Knowledge is kept spread in the organization, avoiding as much as possible silos creation and information power boundaries.
Ensure that Roles are designed only if there is a real need in terms of delivery of work.
Carefully design communication systems, as one of the elements behind Brooks’ law is the insurgence of too many communication lines.

Criticism and Nuances

Scalability: Some argue that Brooks’s Law might not hold in all cases, particularly in large-scale projects where tasks can be more effectively divided among additional team members. However, even in such scenarios, the law’s core caution about communication overhead and onboarding remains relevant.
Agile and Lean Approaches: Agile methodologies challenge some of the assumptions behind Brooks’s Law by advocating for smaller, self-organizing teams that can scale their processes in a more controlled manner.

The “Laws of Organisation Design” Collection. This article belongs to a series focused on the different principles and laws that govern organisational behaviours, decision-making and group work, and that should be taken into account in organisation design projects.

The Laws of Organisation Design

Conway’s Law and Intentional Design
Parkinson’s Law
Law of Triviality
Goodhart’s Law
Brooks’s Law
Hackman’s Law
Larman’s Laws of Organizational Behavior
De Geus’s Law 🆕
Metcalfe’s Law 🆕
The Law of Constraints 🆕
The Pareto Principle 🆕

Law of Requisite Variety
Law of Alignment

Conclusion

Brooks’s Law serves as a cautionary principle in project management, warning against the naive assumption that more manpower can always resolve project delays. It highlights the importance of understanding the underlying causes of delays, the potential downsides of adding more resources, and the need for careful management of team dynamics and communication as projects scale.