Why We Need a Brook's Law for Teams

You used to be fast, nimble and reactive. But now even simple changes takes weeks or months to deliver. Yes, your organisation has grown, but you were careful to only hire smart, capable engineers, experienced product managers, and dedicated designers. So what went wrong?

The counterintuitive truth is that adding more teams often makes product development slower, not faster.

Brooks' Law: The Original Insight

To explain why productivity decreases when you add more members to a team, Brooks highlighted the exponential increase in communication paths. In a three-person team, you have three communication paths. Add just two more people, and you now have ten possible communication paths. Double the team size to ten, and you're got forty-five different communication paths that people need to align on to ensure everyone is in-sync. The complexity doesn't grow linearly, it explodes exponentially.

But Brooks' law was limited to a single team. Today's product development reality is far more complex.

Brooks' Law in Modern Product Development

Modern organisations manage portfolios of interconnected products with dozens or even hundreds of teams sharing resources, infrastructure, and dependencies. The communication overhead Brooks identified within projects now exists between teams, across departments, and throughout entire organisations.

Dependencies, just like communication paths within teams, don't grow linearly with number of teams; they grow exponentially. While there is a single communication path between two team members there can be multiple dependencies between two teams:

• Structural dependencies - teams rely on other teams to deliver a feature (e.g. separate front end and back end teams)

• Governance dependencies - teams need sign offs before they can work

• Technical dependencies - teams share code, environments and tools

• Knowledge dependencies - centralised subject matter experts become bottlenecks

With so many initiatives, or projects, in parallel, when one project slips it can cause cascading effects throughout the portfolio. Product managers scramble to replan roadmaps trying to fit all of the jigsaw puzzle pieces of people availability, code dependency, environment availability and path to production windows. By the time everyone aligns on a new plan, another project has slipped, requiring the entire exercise to start over.

These cascading delays and the impact of never ending replanning is what is leading to the longer lead times and ballooning costs.

Introducing the Law of Exponential Dependencies

The benefit of giving a name to a concept is that you can impart a lot of information quickly. In software development circles, everyone understands Brooks Law and the impact it can have on a late project. All of the nuance of a complex topic distilled into a clear statement.

We need a new law for highlighting the negative effects of the exponential growth of dependencies between teams as organisations scale. I couldn’t find anything, so I’ve come up with one.

Dependencies as a problem is well known. The issue is that most companies go about solving it the wrong way. They try to “manage” the dependencies with ever increasing numbers of middle managers like project managers, program managers, portfolio managers, release train engineers, scrum masters, scrum of scrum masters, product owners, chief product owners and more. And yet development continues to get slower and more expensive. You can’t manage your way out of an exponential growth in dependencies.

The ZeroBlockers Vision

Organisational change is incredibly difficult and it cannot be achieved in a single big-bang transformation. When Toyota revolutionised automobile manufacturing it wasn’t the result of an single change they made; it was the result of creating a culture of continuous improvement. But continuous improvement on it’s own is not enough - it needs a guiding vision. In Toyota’s case it is One Piece Flow.

One piece flow

In auto manufacturing, the machines at each step of the assembly line are incredibly expensive. The old way of improving efficiency was to create large backlogs in front of each machine so that they never had to stop working. Each machine therefore would produce the maximum number of widgets (or car development steps) per day. But these backlogs hid errors and flaws. When the flaws were eventually discovered you didn’t just have to fix one item, you needed to fix every item in every backlog. The sooner you spot a problem the higher the quality of the product as a whole and the lower the cost of rework.

One Piece Flow refers to an unrealistic, but directionally positive, goal of having no backlogs at all. One piece can go from start to finish through the manufacturing line. In short, the vision is a challenge to everyone in the company to think of ways to reduce backlog sizes without sacrificing productivity.

And it worked.. over time. Toyota consistently chipped away at backlog sizes which simultaneously increased the quality of their cars and reduced costs.

We need something similar to help us chip away at the ever increasing cost of software development.

Making Progress Toward Zero

In the same way that Toyota couldn’t reduce all backlogs to zero overnight, it is not feasible to remove all blocking dependencies in our software development flows. But if we have a goal, where all suggested improvements are benchmarked against removing dependencies, we can replicate Toyota’s success.

Teams can use this zero-blocking vision to guide practical decisions today. When designing team boundaries, ask: "How can we minimise the dependencies this team has on others?" When building technical architecture, prioritise loose coupling and clear interfaces. When designing governance processes, default toward empowerment rather than control. When structuring support teams, think platforms and self-service rather than collaboration and consultation.

My hope is that in the future people will be as aware that adding more teams into a portfolio will slow down all of the teams in the same way that they understand that adding more people to a late project will make the project slower. When everyone understands that dependencies are the enemy of velocity, every architectural decision, every team structure, and every process becomes an opportunity to move toward the goal. Once the problem is acknowledged then the solution can be achieved.