Why Decision Rights Matter More Than Reporting Lines
A reporting line tells you who manages whom. It does not tell you who decides pricing, who approves customer exceptions, who chooses vendors, who determines the product roadmap, or who allocates engineering capacity.
When decision rights are unclear, three things happen:
- Escalation becomes the default. People push decisions upward because they don't know if they're authorized to make them. Leaders get pulled into operational decisions that should be resolved two levels down.
- Decisions are slow. Multiple people think they need to approve the same thing. Or nobody thinks it's their call, so the decision waits until someone is frustrated enough to force it.
- Conflict is interpersonal instead of structural. When two people clash over a decision, it looks like a personality conflict. Usually it's a structural failure: two roles that both reasonably believe they own the same decision.
Test: pick the 10 most important recurring decisions in your organization. For each one, can you name exactly one person who decides? If not, you have a decision rights problem.
The Framework: Decide / Input / Informed
RACI matrices (Responsible, Accountable, Consulted, Informed) are popular but overengineered for most teams. The distinction between "responsible" and "accountable" confuses people, and a RACI for 20 decisions across 15 roles produces a 300-cell spreadsheet that nobody reads.
A simpler framework: for each decision, name three things.
Decide
Exactly one person. This person has the authority to make the final call. They don't need consensus. They don't need approval from their manager (unless it's a decision their manager has explicitly retained). They own the outcome.
Input
People whose perspective the decider should seek before deciding. This is not a veto. Input means "I will be consulted," not "I can block." Keep this list short: 1-3 people, not a whole department.
Informed
People who need to know the decision was made and what it is. They don't need to be consulted beforehand, but they need to know the outcome in order to do their own work.
The critical rule: exactly one person decides. If two people share the "Decide" role, nobody decides. Shared ownership of a decision is the same as no ownership.
How To Run A Decision Rights Mapping Session
This is a structured exercise you can run with a leadership team in 90 minutes. It surfaces misalignment that people have been working around for months.
Before the session
- List the 10-15 most important recurring decisions for the team, function, or company. Focus on decisions that are actually contested or slow, not routine ones that work fine.
- Invite the people who are involved in these decisions: the leaders who think they own them and the leaders who are affected by them.
The exercise (90 minutes)
- Present each decision individually. Read the decision aloud: "Who decides the quarterly product roadmap priorities?" (5 min setup)
- Each person writes down independently who they think currently decides, who gives input, and who is informed. No discussion yet. (10 min)
- Reveal and compare. For each decision, have people share their answers. Misalignment will be visible immediately: two people think they decide, or nobody thinks they decide, or the "decider" doesn't know they're the decider. (30-40 min)
- Resolve. For each contested decision, the group agrees on one decider, a short input list, and an informed list. The most senior person in the room should break ties, this is a leadership call, not a consensus exercise. (30-40 min)
After the session
- Document the results in a simple table. Share it with the full team.
- Review the table in 90 days. Some assignments will need to change once people live with them.
What to expect: the first time you run this exercise, you'll find that 30-50% of the decisions on the list have unclear ownership. That's normal. The exercise doesn't reveal a problem you created; it reveals a problem you've been working around.
Worked Example: Decision Rights For A Product Team
| Decision | Decide | Input | Informed |
|---|---|---|---|
| Quarterly roadmap priorities | VP Product | PM, Eng Lead, Sales Lead | Full product team, CS |
| Sprint scope for a cycle | PM | Eng Lead, Designer | VP Product |
| Technical architecture choices | Eng Lead | PM (for timeline impact) | VP Product, VP Engineering |
| UX patterns and design system | Designer | PM (for user impact) | Eng Lead |
| Feature cut or scope reduction | PM | Eng Lead, Designer, VP Product | Sales Lead, CS |
| Hiring an engineer for the team | Eng Lead | PM, recruiter, VP Engineering | VP Product, team |
| Hiring a product manager for the team | VP Product | Eng Lead, recruiter, Designer | Team |
| Launch timing | PM | Eng Lead (readiness), Marketing (go-to-market) | Sales, CS, VP Product |
| Customer-facing pricing changes | VP Product | PM, Sales Lead, Finance | CS, Marketing, Eng Lead |
Notice that the PM decides most operational product decisions (sprint scope, feature cuts, launch timing) while the VP Product decides strategic ones (roadmap priorities, pricing). The Eng Lead owns technical decisions. Nobody has to escalate routine calls. Everyone knows who to go to.
Common Decision Rights Failures
Nobody owns the decision
The decision drifts because everyone assumes someone else is handling it. Common for cross-functional decisions like "who owns the customer handoff between sales and CS?" If nobody is named, nobody acts.
Two people think they own it
Both the VP of Product and the VP of Engineering believe they decide technical investment priorities. They each make plans, discover the conflict, and escalate to the CEO. This happens every quarter. The CEO resolves it each time instead of assigning clear ownership once.
The decision requires four approvals
Purchasing a $500 tool requires approval from the manager, the director, the VP, and finance. The approval chain exists because of a past incident (someone bought an expensive tool without checking), but it now delays every small purchase by days. Set a dollar threshold: below $X, the manager decides alone.
Escalation is the operating model
Decisions routinely go up two or three levels because middle managers don't feel authorized to make them. This is either a cultural problem (leaders don't tolerate mistakes) or a structural one (authority was never explicitly delegated). Fix it by naming what each level is authorized to decide and making it clear that using that authority is expected, not risky.
Input becomes veto
The decider is named, but in practice, the "input" people can block the decision by refusing to agree. If input is treated as consensus, you don't have decision rights, you have a committee. The decider must be empowered to listen to input and still decide, even when the input disagrees.
Sources And Further Reading
- Jay R. Galbraith, Designing Organizations: An Executive Guide to Strategy, Structure, and Process.
- Gary L. Neilson, Karla L. Martin, and Elizabeth Powers, "The Secrets to Successful Strategy Execution," Harvard Business Review.
- Roger Martin, Playing to Win: How Strategy Really Works.
- Patrick Lencioni, The Advantage.
Continue Reading
Decision rights clarify who decides. Role clarity clarifies who does the work and who owns the outcome.
Next guideRole Clarity
How to diagnose overlapping accountabilities, audit handoffs, and decide when to create, clarify, or merge roles.