In most organizations, decision rights are vague, contested, or silently ceded over time. Nobody redesigned them explicitly — they just evolved through a combination of personality, default behavior, and whoever cared most about any given issue.

The result is a pattern where important decisions either get made by default (whoever cares most, or whoever is loudest) or they don't get made at all because everyone assumes someone else is handling it.

Both are corrosive. Both are fixable.

The Design Principle That Matters Most

Decision forums should be defined by two variables: consequence and reversibility.

Consequence: How significant is this decision? Does it affect many people, significant resources, or the direction of the organization? High-consequence decisions need broader input and more careful process.

Reversibility: Can this decision be undone if it's wrong? A reversible decision that turns out wrong costs time. An irreversible decision that turns out wrong can cost much more.

The intersection gives you the right decision process:

  • High consequence, hard to reverse: slow down, get more input, make sure the right people are involved, document the reasoning
  • High consequence, easy to reverse: move fast, make the call, track the outcome, correct if needed
  • Low consequence, easy to reverse: decide at the lowest appropriate level and move on

Most organizations treat all significant decisions as high-consequence and hard to reverse. They aren't. Most real decisions in product and engineering — scope choices, technical approaches, prioritization calls — are reversible with enough effort. Treating them as irreversible adds cost without proportionate benefit.

Resolving Overlapping Authority

When two forums claim ownership of the same decision type, or when a decision falls in the seam between two functions, the natural response is to have a conversation and hope it's resolved. It usually isn't — not permanently.

Resolve it by escalating to the next level of common authority and having them make a ruling. Not negotiate a compromise — make a ruling. Which forum owns this, explicitly? The ruling gets documented and becomes the new default.

Example: the product council owns roadmap priority, the engineering architecture forum owns technical direction, and exec staff owns resource allocation. A platform rewrite touches all three. Product wants it because enterprise deals are blocked. Engineering wants to decide the architecture. Exec staff has to decide whether to pull capacity from new features. The ruling might be: product council decides whether the rewrite enters the roadmap, architecture forum decides the technical approach once approved, and exec staff decides the capacity tradeoff if the rewrite displaces committed revenue work. Same decision space, three different decision rights.

This sounds simple because it is simple. It's also almost never done, because making a ruling means someone loses authority. The leadership instinct is to find a process compromise that keeps everyone comfortable. That produces ambiguity, not clarity.

The Test

Ask each person on your leadership team: what is the most recent decision you made that you're not 100% sure you should have made? And: what is the decision you're involved in right now where you're not sure if it's yours or someone else's?

The answers to those two questions will tell you more about your decision rights map than any document you could write.

Fix the gaps they reveal. Then update the document to match.