Why We Need A Brooks' Law For Teams

Brooks' Law showed us that adding people to a late project makes it later due to the exponential increase in communication overhead. But modern organizations face a more complex challenge: managing portfolios of interconnected products with dozens of teams sharing resources, infrastructure, and dependencies. And these dependencies also grow exponentially.

Because everything is interconnected, when one project slips, companies spend a huge amount of time and money replanning all of the different interlinking dependencies to get the plan back in order. Usually just in time for another project to slip.

The solution isn't to manage dependencies with more project managers and scrum masters - you can't manage your way out of exponential growth. Instead, we need to remove them.

Like Toyota's "One Piece Flow" philosophy that eliminated manufacturing backlogs, we must systematically chip away at dependencies until we have "zero blocking dependencies from idea to satisfied customers".

This Week’s Updates

Enabling the Team

Why We Need A Brooks' Law For Teams by Rory Madden
Brook's Law states that "Adding manpower to a late software project makes it later". We have the same issue with the number of teams working in parallel.

Management Values I Didn’t Expect To Learn by Ted Goas
Moving into design management got Ted focusing on team health, player-coach leadership, sliding scale delegation, and avoiding bottlenecks so managers become bridges between ICs and executives instead of blockers.

Product Direction