A decision rights map names, for every recurring decision type in the business, one owner, one or more contributors, and an escalation path. Done well, it removes 30 to 60 percent of executive load inside a quarter. Done poorly, it becomes a RACI artifact nobody reads. The difference is how it is built and how it is used in the cadence.
What decision rights actually are
Decision rights are the explicit answer to "who decides what". They are not org charts, not job descriptions, and not approval workflows. An org chart tells you who reports to whom. A decision map tells you who is allowed to commit the company to a course of action and on what conditions.
The reason this is a discipline in its own right is that companies grow faster than their decision architecture. A founder makes every decision at 8 people. At 80 people, the same instinct produces a queue at the CEO's door and a leadership team that has learned not to decide anything alone.
Symptoms that you have no decision rights
- The CEO calendar is 70 percent recurring meetings the CEO did not call.
- Decisions are re-opened in the next meeting because nobody is sure the last one "really decided".
- Functional leaders cc the CEO on emails that should be theirs to resolve, and the CEO replies.
- The same three issues appear on the issues list every week for a quarter.
- Two leaders make conflicting commitments to the same customer or partner inside a month.
- New hires ask "who owns this" and get three different answers from three different people.
If three or more of these are true, the problem is not the people. The problem is that the system has no answer to who owns the decision.
A four-role decision model
We use a four-role model that is deliberately simpler than RACI and deliberately more actionable than RAPID:
- Owner. One person. Makes the decision, signs their name to it, and lives with the outcome. Not a committee, not a function.
- Contributors. A small named set. Their input is required before the decision is made. Their disagreement does not block the decision; it is recorded.
- Informed. People who need to know after the decision is made so they can act on it. Receive a written decision note, not a meeting invite.
- Escalation. One named role that overrides if the owner is conflicted, absent, or the decision exceeds a defined threshold (dollar, headcount, customer tier).
One owner per decision. That is the rule that does almost all of the work. If two people own a decision, neither does.
Mapping decision types to the org
You do not need to map every decision. You need to map the recurring ones that show up in the cadence. A good first pass covers 25 to 40 decision types across the company. Examples worth naming explicitly:
- Pricing for a non-standard deal above $X.
- Hiring or replacing a director-level role.
- Killing a product feature or a sales territory.
- Approving a refund or contractual concession above a threshold.
- Adding a vendor that crosses a dollar or data threshold.
- Changing the cadence stack or the scorecard.
- Signing a partnership or LOI.
- Promoting an individual contributor to a manager role.
Each decision type gets one row in the map: name, trigger, owner, contributors, informed, escalation, and the cadence in which it is reviewed.
Drafting your first decision map
The fastest path to a usable map is a two-hour working session with the leadership team and one operator scribe. The structure:
- Forty-five minutes. List every recurring decision the team can name from the last 90 days. Aim for 40 plus.
- Forty-five minutes. Group them into 20 to 30 decision types. Kill duplicates.
- Thirty minutes. Assign one owner per type, live, by name. Disagreement is the signal that decision rights were never explicit.
The output is a single page (yes, one page) that becomes the working draft. The team uses it for two weeks before any further refinement. If you want a sense of how this pairs with the rest of the operating stack, see the coordination pillar on the framework page.
Operating the map without policing it
A decision map dies when it has to be policed. It works when it is woven into the cadence so the team uses it without thinking about it.
- Every issue raised in the weekly is labeled with its decision type before it is discussed. If the owner is not in the room, the issue is routed, not debated.
- Every decision over the threshold produces a one-paragraph decision note: what was decided, who decided, who contributed, who needs to know.
- Every quarterly reviews the map itself: which decision types have shifted, which owners are overloaded, which thresholds are now wrong.
This is the part that makes it stick. The map is alive in the cadence or it is dead in a slide deck.
Five mistakes that kill adoption
- Building it in HR. Decision rights are an operating artifact, not an org design exercise. Build it in the operating team.
- Trying to cover every decision. Map the 30 that recur. Let the rest self-resolve.
- Two-owner compromises. The instinct to soften conflict by naming two owners reproduces the original problem.
- No escalation path. A map without an explicit escalation route turns into a deadlock when the owner is unavailable.
- Treating it as permanent. Decision rights age. Review them quarterly or they will silently break.
A 45 day rollout
- Days 1 to 7. Run the two-hour drafting session. Publish the one-page map.
- Days 8 to 21. Use the map in every weekly. Capture every place the map was unclear or missing.
- Days 22 to 35. Revise. Add the missing decision types. Sharpen ambiguous owners.
- Days 36 to 45. Lock the v2 map for the quarter. Pair it with the cadence stack so each decision type has a home meeting. See the cadence stack for how the two interlock.
See where your decision architecture is leaking into the CEO calendar.
The ASCEND assessment scores coordination on owner clarity, escalation paths, and re-litigation rate. Free, ten minutes, no signup.