The Risk of NOT Empowering Teams

90% of product features fail to deliver their expected business value. That’s not a typo. According to research by Ron Kohavi, a former VP at Microsoft and technical fellow at Airbnb, most of what we ship doesn’t work the way we think it will.

And yet, in most organisations, we continue to fund features up front, build roadmaps based on assumptions, and ask teams to deliver predefined solutions to problems that have never been properly validated. As results fail to materialise, many organisations respond by tightening control rather than questioning their approach. They create more detailed business cases, add more approval layers, and hire more coordinators to manage the complexity.

While empowering teams certainly introduces risks, the risks of maintaining traditional top-down control are far more dangerous. The reason for this comes down to two fundamental realities about today's market: we don't really know what customers want, and we cannot effectively manage dependencies at scale. Organisations that fail to grasp these realities are building elaborate systems of failure.

The Customer Knowledge Illusion: Why We're Wrong About What Customers Want

The Assumption Trap

Executives, stakeholders, and product leaders all believe they understand their customers. They’ve been in the market for years, they’ve seen the data, they’ve heard the anecdotes. But that confidence is dangerous. Real customer behaviour reveals needs customers didn't even know they had, constraints they didn't mention, and priorities that shift based on context.

The truth is that our products are designed to change people’s behaviour, and we can’t predict that upfront. But that doesn’t stop us from locking in solutions in a business case, months before we get to test out the ideas with real customers.

The Rising Expectations Reality

Even if we did nail the customer need in the business case we run into another problem. Planning cycles that take years to execute cannot keep pace with expectations that shift in months. By the time a feature conceived in a quarterly planning session reaches customers, their needs have evolved beyond what we thought we were solving.

Why Empowered Teams Help

Empowered teams work differently. Instead of executing a predefined roadmap, they start by understanding real customer problems. They’re responsible for discovery and delivery. They iterate toward outcomes, not outputs.

This means they can adjust course when assumptions prove false. They can test, learn, and adapt before investing months into development. Empowerment isn’t about trust for the sake of culture, it’s a risk mitigation strategy for navigating complexity and uncertainty.

The Dependency Management Myth: Why More Coordinators Make Things Worse

The Exponential Problem

Dependencies don't grow linearly with team size, they grow exponentially. Teams can become dependent on other teams through shared code, shared environments, shared people or shared approvals. And each of these items can move independently.

This means that whenever a project slips, it has cascading effects on the rest of the projects in the portfolio. And it can be incredibly difficult and time consuming to move all of the necessary jigsaw pieces to get back to a coherent plan. And when you do, it is usually just in time for another slippage that requires everything to be replanned again.

This is Brooks' Law applied to modern product development: adding more teams to a complex product development effort makes it slower, not faster.

Why Coordination Fails

Organisations facing delivery challenges typically respond by adding coordination roles. They hire project managers to track dependencies, program managers to coordinate across projects, and scrum masters to facilitate team interactions. When that's not enough, they add scrum of scrum masters, chief product owners, release train engineers, and portfolio managers.

Each role is created to solve problems created by the previous coordination layer. Project managers struggle with cross-team dependencies, so we add program managers. Program managers can't align with business strategy, so we add portfolio managers. Teams lose sight of customer needs, so we add product owners. Product owners conflict with each other, so we add chief product owners.

The false security of detailed project plans provides an illusion of control while customer problems remain unsolved. Every layer adds delay, abstraction, and bureaucracy and because decisions are centralised, teams lose context, ownership, and accountability. The result is organisations spending more on coordination than creation. Teams of highly skilled engineers, designers, and product specialists spend their days in alignment meetings, dependency reviews, and status updates.

The Compound Cost of Control

The consequences of maintaining traditional top-down control extend far beyond delivery delays and frustrated teams. Organisations caught in this cycle face declining product performance as features miss the mark with customers. Market share erodes as more agile competitors respond faster to customer needs and at the same time development costs spiral upward.

This creates an innovation death spiral where the very systems designed to reduce risk actually amplify it, threatening long-term organisational viability in increasingly competitive markets.

The Alternative: Removing Dependencies Through Design

The solution isn't better dependency management - it's dependency elimination through intelligent organisational design. Instead of coordinating handoffs between teams, we need to design teams that don't need handoffs. Instead of managing dependencies, we need to remove them until we get to zero blockers.

That was a really easy sentence to write, but it is an incredibly difficult thing to do in practice. There are multiple different types of dependency in practice: structural, alignment, technical and knowledge, and each of them was put in place for a good reason. You need to go back to first principles and uncover the real value that each dependency is providing before we can safely replace them with non-blocking alternative options.

The challenge is that people are busy focusing on the business problems that they do not have the capacity to identify solution from first-principles for process problems as well. I know this first hand as it took me over five years to research and identify all of the changes required when empowering teams and how other companies are solving these problems. We can’t, and we shouldn’t, expect every middle manager to invest as much time re-inventing the wheel.

The Path Forward

This is where frameworks can help. It is almost heresy in the agile world to be in favour of frameworks because the existing frameworks on the market embed top-down planning, rigid processes and all of them advocate for new managers to manage dependencies.

People have confused frameworks with bad practices. But that is just a problem with our current frameworks, not with frameworks as a concept.

The risks of not empowering teams compound over time, creating an innovation death spiral that's difficult to escape. Customer knowledge gaps widen as decision-making becomes more centralised and removed from customer reality. Dependency overhead grows exponentially as organisations try to coordinate their way out of complexity problems.

That’s why we’ve released the ZeroBlockers Framework because we believe there needs to be a guide for people who want to embed truly empowered product teams in their organisations and get the benefits of increased innovation, faster responsiveness and lower costs. Check it out today and let me know if you have any thoughts or feedback.