Brooks’s Law is a principle in software development and project management that was first articulated by Fred Brooks in his 1975 book The Mythical Man-Month: Essays on Software Engineering. The law is succinctly stated as:
“Adding more manpower to a late software project makes it later.” — F. Brooks (1975)
Brooks’s Law suggests that simply adding more people to a project that is behind schedule will not help to speed it up; in fact, it is likely to cause further delays. This is because onboarding new team members requires time and effort from the existing team to bring them up to speed, and the added complexity of increased communication overhead can outweigh the benefits of additional labor.
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.
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.
- Conway’s Law
- Parkinson’s Law
- Law of Triviality
- Goodhart’s Law
- Brooks’ Law
- Hackman’s Law
- Larman’s Laws of Organizational Behavior
- 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.
Comments and Feedbacks
Reference
Read More
Related posts
Recent Posts
