--- title: "The Decision Rights Vacuum: Why Your 'Empowered Teams' Keep Escalating Everything" description: "Empowerment without explicit decision rights creates a hidden bottleneck at the top. Here's how to diagnose and fix the vacuum that's clogging your CPO's calendar." author: "Kody Everson" url: "https://theipp.org/insights/the-decision-rights-vacuum-why-your-empowered-teams-keep-escalating-everything-t" date: "2026-05-29T13:13:28.740Z" --- # The Decision Rights Vacuum: Why Your 'Empowered Teams' Keep Escalating Everything ## Summary Empowerment without explicit decision rights creates a hidden bottleneck at the top. Here's how to diagnose and fix the vacuum that's clogging your CPO's calendar. ## Main content Walk into almost any scaling product organisation and you'll hear the same vocabulary: empowered teams, mission-driven squads, autonomy with alignment. View the CPO's calendar in the same organisation and you'll see something else entirely: back-to-back reviews, approval meetings, tie-breaking sessions, and Slack threads where product managers are asking which of two reasonable options to pursue. The gap between the rhetoric and the reality has a name. It's a decision rights vacuum, and it is one of the most common - and least diagnosed - pathologies in modern product organisations. The vacuum is rarely caused by bad intent. Leaders genuinely want teams to own outcomes. Teams genuinely want to make calls. But somewhere between the all-hands slide and the Tuesday morning prioritisation meeting, the mechanism that would let autonomy actually function has been left unspecified. What gets called empowerment is, in practice, permission to propose. The decision itself still travels up the chain. ## What a Decision Rights Vacuum Actually Looks Like The symptoms are familiar once you know to look for them. Product trios run thorough discovery, build a recommendation deck, and then book time with the CPO to 'align' before committing. Teams describe themselves as autonomous but cannot remember the last time they made a non-trivial decision without senior sign-off. Roadmap reviews become decision events rather than information events. The CPO is the unblocker of last resort - and increasingly of first resort. The deeper signal is linguistic. Listen for phrases like 'we want to check before we...', 'we just need a steer on...', or 'we're 80% there but want to make sure leadership is comfortable.' Each of these is a small act of escalation dressed up as collaboration. Multiplied across twenty teams, they consume the entire executive bandwidth of the product function and crowd out the work only senior leaders can do: portfolio shaping, cross-cutting strategy, and the long-horizon bets that define competitive position. ## Why Empowerment Language Fails Without Decision Architecture Empowerment is a cultural claim. Decision rights are a governance artefact. The first cannot substitute for the second, and most organisations conflate them. Consider a team deciding whether to sunset a feature used by 4% of customers but generating disproportionate support load. This is not a trivial call. It touches retention risk, support economics, engineering opportunity cost, and brand perception. Without explicit decision rights, the team faces three questions simultaneously: Are we allowed to decide this? What evidence would justify the decision? Who carries the consequence if we're wrong? In the absence of pre-agreed answers, the rational move is to escalate. Escalation is not a failure of courage; it is a response to ambiguity. Marty Cagan's empowered team model assumes a specific scaffolding: clear product strategy, well-defined outcomes, and a CPO who coaches rather than approves. When organisations adopt the language without the scaffolding, they get the worst of both worlds - teams that feel responsible for outcomes but lack the authority to make the trade-offs those outcomes require. ## The Three Dimensions Decision Rights Must Specify A workable decision charter is not a RACI matrix. RACI tells you who is accountable in the abstract; it does not tell teams whether they can ship the thing on Thursday. Useful decision rights specify three things together. ### 1\. The class of decision Not all decisions are equal. Jeff Bezos's distinction between Type 1 (irreversible, consequential) and Type 2 (reversible, low-cost-to-undo) decisions is a useful starting point, but product work needs more granularity. Most organisations benefit from four classes: experimental changes (reversible within a sprint), feature-level commitments (reversible within a quarter, affecting one team), product-level commitments (affecting multiple teams or contracts), and strategic commitments (affecting portfolio shape, pricing, or positioning). Each class needs a different owner and a different evidence bar. ### 2\. The evidence threshold Empowered teams escalate when they don't know how much evidence is 'enough'. A mature decision charter specifies what counts as sufficient evidence for each decision class. For an experiment, a hypothesis and a measurable outcome may suffice. For a feature commitment, you might require qualitative validation with a defined number of customers, a quantified opportunity size, and a stated reversal plan. For a product-level commitment, you might require evidence of demand, technical feasibility, and a business case stress-tested against alternatives. Without these thresholds written down, every decision becomes a negotiation about whether the evidence is good enough - and the CPO becomes the judge. ### 3\. The reversibility plan The fastest way to lower the perceived stakes of a decision is to make its reversal explicit. If a team can articulate how they would detect the decision was wrong and what they would do about it, the decision becomes safer to delegate. Reversibility is not just a property of the decision; it is something teams design into the decision. Senior leaders who insist on reversibility plans rather than approval rights are quietly redistributing authority back to the teams. ## How CPOs Unintentionally Sustain the Vacuum If you are a CPO reading this and recognising the pattern, the uncomfortable truth is that you may be part of the problem. Decision rights vacuums are sustained by senior leaders who engage with escalations rather than redirecting them. When a team brings you a decision they should own, the well-intentioned response is to help. You ask sharp questions, you share context, you offer a view. The team leaves grateful. They also leave having learned that escalation produces value and that your engagement is available. The next decision will come to you faster. Over time, the equilibrium shifts. Teams optimise for your input because your input is reliably forthcoming. Breaking the pattern requires a different posture. When a team brings a decision that belongs to them, the productive response is not to answer it but to clarify why it is theirs to make, what evidence they should be weighing, and what reversibility looks like. This feels withholding. It is, in fact, the work. A CPO who absorbs decisions is teaching the organisation that empowerment is performative. ## Diagnosing Your Own Vacuum Three diagnostic questions cut through the noise. First, in the last month, what is the largest decision a product team made without senior approval? If you struggle to recall one, the vacuum is wide. Second, if you removed yourself from product reviews for a quarter, what would stop? If the answer is 'most decisions', authority has not actually been distributed. Third, can your PMs articulate, without looking it up, what they are allowed to decide alone, what requires their group product manager, and what requires you? If the answer is fuzzy, the architecture does not exist. A more quantitative diagnostic: track the ratio of decisions made in team forums versus those made in leadership forums over a month. ## Building the Charter The practical fix is unglamorous: write the decision charter down. A working version fits on two pages and specifies, for each decision class, who decides, what evidence is required, who must be consulted, and what triggers escalation. It is co-authored with the teams that will live by it, not imposed from above. It is reviewed quarterly because decision rights drift as the organisation grows. The charter should also specify the inverse: what senior leaders will _not_ decide. Naming the decisions the CPO refuses to make is more powerful than naming the ones they will. It removes the option of escalation as a relief valve and forces the design of better team-level decision processes. Pair the charter with a small ritual: at the start of any significant decision, the team names the class, the evidence threshold, and the reversibility plan before they begin work. This takes ten minutes and saves weeks of ambiguity later. Over time, the language becomes second nature, and the question 'should we escalate this?' is replaced by 'we've classified this as a feature commitment, here's our evidence and reversal plan, we're proceeding Tuesday.' ## The Outcome You're Actually After The point of fixing the decision rights vacuum is not to reduce the CPO's meeting load, though it does. It is to make outcome accountability real. Teams cannot be held accountable for outcomes they did not have the authority to shape. When every meaningful decision routes through leadership, the accountability for results routes there too - regardless of what the org chart says. Empowerment without decision rights is a form of accountability laundering: it gives leaders the comfort of delegation and the reality of control, while teams carry the language of ownership without its substance. The organisations that get this right look different from the outside. Their senior leaders spend their time on strategy, not approvals. Their teams talk about decisions in terms of evidence and reversibility, not permission. Their roadmap reviews are conversations about learning, not gates. And when something goes wrong - because something always does - the post-mortem starts with the team that made the call, not the executive who signed it off. That is what empowerment looks like when the architecture is actually there. ## Related pages - [Insights](https://theipp.org/insights.md) - [Product Profile](https://theipp.org/tools/product-profile.md) - [Standards](https://theipp.org/standards.md)