The ZeroBlockers Framework

Good process serves you so you can serve customers. But if you're not watchful, the process can become the thing. You stop looking at outcomes and just make sure you're doing the process right.

Jeff Bezos

Best practices emerge from the underlying principles of what you are trying to achieve coupled with the context in which you are operating.

Why we work the way we do

Most of the management practices used in modern product organizations were designed for a different kind of work. Frederick Taylor's scientific management, the assembly line, the budgeting cycle, the matrixed manager were all created to optimize repetitive industrial production, where the right answer was already known and the challenge was to scale efficient delivery of it.

Carlota Perez identifies five great surges of technological development since the industrial revolution. Each surge has a financial-capital phase, where the new technology is exploited using management practices borrowed from the previous era, followed by a deployment phase where new management practices emerge that fit the actual shape of the work. Software has been in the financial-capital phase for most of its history. We took the practices that worked for manufacturing physical goods and applied them to a domain where the right answer is not known, the work is not repetitive, and the cost of building the wrong thing is paid in market share rather than in scrap material.

AI is the latest surge, and it follows the same pattern. Steam, electricity, and the internet paid off only after organizations redesigned how they worked around them. AI has collapsed the time it takes to build software, and organizations are discovering, again, that the operating model lags the technology. Teams can produce more than the organization was designed to absorb, and the strain shows wherever the old design still stands.

ZeroBlockers is an attempt to redesign those practices for what software development actually is: creative, iterative, learning-oriented work where the team is the unit of delivery rather than the function.

The context of modern product development

Most features fail, and AI makes failing faster

Fewer than a third of the ideas tested at Microsoft improved the metric they were meant to move, and roughly a third made the product worse. Bing, Booking, Google Ads, and Netflix report similar rates (Kohavi, Deng and Vermeer). New features require customers to change their behavior, and we cannot predict how people will behave until the product is in their hands. That has not stopped us locking in scope at the start of a project. Before AI, we built the wrong things slowly. Now teams can build ten times as many, and every one lands on your customers.

Work is waiting, not working

Most of the time between an idea and a satisfied customer is spent in a queue: waiting for a business case, a decision, a design, a dependent team, a test cycle, a release window. Dependencies between teams grow combinatorially as an organization scales. Three people share three communication paths; ten share forty-five. Managing those dependencies with coordinators, syncs, and trackers pays the tax. Removing them ends it.

The operating model was built for scarce engineering

Approval, funding, planning, and governance were designed to ration a slow, expensive build. AI removed the scarcity. A team can now build three versions of a feature in the time it used to take to write the business case for one. Every step that still assumes building is the bottleneck has become the bottleneck. Teams that ship daily are governed by checkpoints built for quarterly delivery, funded annually, and aligned by a planning cycle that produces a quarter's worth of drift in six weeks. Managers already spend 53% of their time on administration and about 10% on strategy. More work in flight means more to coordinate, and less time to decide where it should all be going.

The challenges with changing how we work

To empower teams we need to incorporate more upfront research and design work to identify opportunities and evaluate solutions. This means that we need to change how we structure teams and remove the sign-offs and handovers that lock in solutions before we have finished our design.

But these sign-offs and handover processes weren't created to frustrate development teams. They deliver a lot of benefits.

1. Business case preparation forces people to do research and due diligence planning. This gives leadership confidence that they are only funding high quality initiatives.
2. Business cases also allow senior leadership to ensure alignment with the business strategy.
3. Business case budgets and timelines provide a framework for governance to validate that teams are delivering efficiently and effectively.
4. Stage gates within the development process ensure high-quality work and efficient use of specialists.
5. Functional structures provide a way to scale the organization and take advantage of economies of scale.

In order to empower product teams we need to deliver the same benefits as our current way of working but without the drawback of locking in solutions that will not deliver the expected benefits.

How ZeroBlockers works

The ZeroBlockers framework starts from first principles: what are we trying to achieve, and which practices deliver the same benefits as the current way of working without locking in solutions before we know they work. The six changes below build on each other. Each one creates the pressure that forces the next, so the order matters.