The Decision Authority Map: Who Decides What

A decision authority matrix is a table that maps each type of decision to the people who decide, recommend, must be consulted, and are informed. It eliminates the ambiguity of who holds final authority, prevents decisions from stalling or being relitigated, and gives distributed teams a single reference for who owns what.

What a decision authority map is

An org chart shows reporting lines. It does not show who can approve a vendor contract, sign off on a pricing change, or kill a feature. Those are decision rights, and they rarely line up cleanly with titles. A decision authority map makes those rights explicit. It is the first artifact in any decision governance framework, because every other control depends on knowing who is actually accountable.

Without it, two failure modes appear. Decisions stall because nobody is sure they are allowed to make the call, or decisions get made twice because two people each believed it was theirs. Both waste time and erode trust. In a co-located office, an informal hierarchy fills the gap; people learn over coffee who really signs off on what. Distributed and async teams have no such backchannel, so the implicit map never forms and authority becomes a daily source of friction. The map turns that tacit knowledge into something explicit, searchable, and onboardable.

A good map is also a speed tool, not just a control. When authority is unambiguous, the person who holds it can move without waiting for permission, and everyone else knows not to relitigate. The map removes both the bottleneck of unclear authority and the drag of repeated debate.

The authority matrix template

A workable matrix assigns one role per decision type per person. The four roles are Decide (final authority, exactly one per row), Recommend, Consult, and Inform.

Decision type	Decides	Recommends	Consulted	Informed
Pricing change	CEO	Head of Product	Finance, Sales	All staff
Vendor contract <$25k	Dept head	Requesting team	Finance	Ops
Ship/kill a feature	Product lead	Eng lead	Design, Support	GTM
Hire (backfill)	Hiring manager	Recruiter	Finance	Team

The non-negotiable rule: exactly one Decide per row. If two names appear, you have not finished the map; you have documented the conflict.

How to build yours

1. List recent real decisions. Pull the last 30 to 50 consequential decisions. This grounds the map in reality, not theory.
2. Group them into types. Collapse the list into 10 to 20 recurring decision categories.
3. Assign one Decider per type. Force a single accountable owner. Escalate disputes rather than leaving them blank.
4. Add the supporting roles. Fill in Recommend, Consult, and Inform sparingly; over-consulting slows everything.
5. Set thresholds. Many rights are dollar- or risk-bounded. Encode the threshold directly in the decision type.
6. Publish and version it. Store it in your decision record so it is visible and changes are tracked.

Because the map will change, keep it in the same place as your decisions and treat updates as governed decisions themselves, captured in the decision audit trail.

Authority when owners are offline

A static map breaks the moment the owner is on a flight or in a different time zone. Distributed teams need explicit representation rules: who may act on the owner's behalf, within what limits, and what they must defer. The safe default is silence over speculation. A delegate who is unsure should record the open question and wait rather than guess and bind the organization to a decision the owner would not have made. This is the bridge from authority mapping to real accountability in distributed teams.

Write representation rules into the map itself rather than leaving them to memory. For each high-stakes decision type, name the standing delegate and state the cap on their authority, for example "may approve spend up to half the owner's limit, must defer anything irreversible." When the delegate acts, that action is recorded against the owner's authority so the trail stays complete.

Authority anti-patterns to fix

Most broken authority maps share a handful of recurring flaws. Scan your map for these before you publish it.

1. The phantom decider. A senior leader is listed as Decider on dozens of rows they never actually touch. The map looks tidy but real decisions route elsewhere, so it is fiction. List the person who genuinely makes the call.
2. Consult sprawl. Half the company is marked Consulted on routine decisions. Consultation is expensive; reserve it for parties whose input materially changes the outcome.
3. Authority without a threshold. "Dept head decides vendor contracts" with no dollar cap invites both overreach and paralysis. Bound the right explicitly.
4. Title-based authority. Assigning rights by job title rather than by who is closest to the decision pushes calls upward and slows everything. Push authority down to where the context lives.
5. The unowned escalation. When two deciders disagree, the map is silent on who breaks the tie. Name a tie-break owner for every contested type.

Common Questions

How is a decision authority matrix different from RACI?

RACI maps responsibility for tasks. A decision authority matrix maps the right to make a specific type of decision. They overlap but are not the same; a person can be responsible for executing work yet hold no authority to decide it.

What if two people genuinely share a decision?

Shared authority usually masks an unresolved escalation path. Pick a single Decider and name the other as Recommend or Consult, or define an explicit tie-break owner. Co-deciders without a tie-break produce deadlock.

How often should the map be updated?

Review it quarterly and on any reorganization. Authority drifts as teams grow, so an unreviewed map quickly becomes fiction. Treat each change as a governed decision with its own record.