The Decision Authority Map: Who Decides What

A decision authority map is a list of the decisions your team makes, with the one person who owns each type of decision. It ends the most common cause of stalled work, which is nobody being sure who gets the final say.

An org chart shows who reports to whom. It does not show who can approve a vendor contract, change the on-call rota, or cancel a feature. Those are decision rights, and they rarely line up neatly with job titles. The map writes them down. It is the companion to a decision log: the log says what was decided, and the map says who was allowed to decide it.

What is a decision authority matrix?

A decision authority matrix is the map in table form. Each row is a type of decision. The columns say who decides, who recommends, who must be consulted before the call, and who is told afterwards. Most teams use four roles:

• Decides: the one person who makes the final call. Exactly one name per row.
• Recommends: the person who does the work of proposing an answer.
• Consulted: the people whose input is required before deciding.
• Informed: the people who need to know once it is decided.

Here is a starting matrix for an engineering team. Replace the roles with names.

Decision	Decides	Recommends	Consulted	Informed
Add a new production dependency	Tech lead	Engineer proposing it	Security	Team
Change a public API	Staff engineer	API owner	Teams that call it	Support, docs
Ship a feature behind a flag	Engineering manager	Product manager	Design	Team
Roll back a release	On-call engineer	Nobody, act first	Nobody	Team, support
Change the on-call rota	Engineering manager	Team	Everyone on call	Team
Pick a new vendor under the team budget	Engineering manager	Tech lead	Finance	Director
Pick a new vendor over the team budget	Director	Engineering manager	Finance, security	Team
Hire into an open role	Hiring manager	Interview panel	Recruiter	Team
Reverse a past architecture decision	Whoever owned the original	Engineer proposing it	Affected teams	Everyone in the original thread

Notice that the rollback row has no consultation. Some decisions must be fast, and the map should say so. Without that row, an on-call engineer at 3am will wait for permission they do not need.

How to build your map

1. List the decisions your team made in the last three months. Pull them from chat, tickets and meeting notes. Aim for twenty to thirty.
2. Group them into types. "Approved the new logging vendor" and "picked the error reporting tool" are both "pick a vendor under the team budget."
3. For each type, write down who made the call in practice. Not who should have. Who did.
4. Mark the rows where the answer was unclear, or where two people both thought it was theirs. Those are the rows to settle first.
5. Agree each row with the people named in it. A map nobody agreed to is a wish list.
6. Publish it where the team works, and link it from the decision log.

Building from real decisions matters. A map drawn from the org chart describes how decisions ought to flow. A map drawn from the last quarter describes how they do flow, which is where the problems are.

Who decides when the owner is off

Most maps fail on the first day the owner is on holiday. Decisions either stop for a week or get made by whoever is loudest. Add one more column: the stand-in owner. For each row, name who may decide while the owner is away, and any limit on what they may decide.

A useful rule of thumb: if a decision can be easily undone, the stand-in may make it. If it is costly to undo, the stand-in may make it only when waiting would cost more. If it cannot be undone, it waits. The guide to reversible vs irreversible decisions explains how to sort decisions this way.

Signs your team has a decision authority problem

• The same decision gets made twice, by two people, in different threads.
• Work waits for a meeting so that someone senior can nod.
• People ask "can I just go ahead?" in chat, and nobody answers.
• Decisions get reversed by someone who was not in the room.
• Senior engineers are copied on everything because nobody knows who else to ask.

Any one of these is common. Three or more means the rights are unclear, and a map will save the team time in its first month.

Shadow authority

Shadow authority is when someone decides things they are not formally responsible for, because people have always checked with them. It is often a long-serving engineer whose opinion carries weight on every technical choice.

Shadow authority is not always bad. That person usually knows the system best. The problem is that it is invisible, so it slows everything down, and it disappears without warning when the person leaves or goes on leave. The fix is to make it visible: either give the person the formal right on the map, or agree that the formal owner decides and the expert is consulted.

Map, matrix, DRI or RACI?

These all try to answer the same question. A DRI (directly responsible individual) names one owner for a project or area. RACI assigns four roles across tasks. A decision authority map focuses on recurring types of decisions. Most teams do well with a map for decisions and a DRI for each project. See the guide to the directly responsible individual for how DRI and RACI compare.

The map, the log and a few rules about process together make a decision governance framework. For the full picture of where decisions should live, start with the guide to a system of record for decisions.

How often to update the map

Review it once a quarter, and any time someone joins, leaves or changes role. The fastest check is to compare the map with the decision log: if the log shows decisions made by people the map does not name, the map is out of date.

Where StandIn fits

When a team runs on StandIn, anyone can ask what shipped, what's blocked, and who owns a call, and get an answer sourced to the person who did the work. If the owner of a decision is away, their StandIn answers from what they wrote down and points to the person who can decide. It never guesses who owns something. See how this works for engineering leaders.