How to Map Decision Authority on Your Team

To map decision authority on your team, list every recurring decision your team makes, assign exactly one accountable owner to each, name who that owner must consult or inform, and classify the decision as reversible or irreversible so the level of review matches the stakes. Then write the map down where decisions are actually recorded, not in a slide deck that goes stale. The output is a living table that answers "who can decide this, and who do they need to check with" in seconds.

Most teams already have an implicit authority map living in people's heads. The problem shows up when someone is out, when a new hire has to guess who signs off, or when a decision gets re-argued because nobody remembers it was already made under someone's authority. This guide is the concrete, step-by-step version. If you want the conceptual background, the decision authority map framework and our overview of decision authority mapping cover the why; this post covers the how.

The five steps to map decision authority

Here is the full sequence before we go deep on each. You can complete a first pass in a single ninety-minute working session with your leads.

• Inventory: list the recurring decisions, not the one-offs.
• Assign: give each decision exactly one accountable owner.
• Sort: classify each as reversible or irreversible to set the review bar.
• Record: put authority next to the decision where it is made.
• Maintain: update at the moment of decision, not on a review cycle.

Step 1: inventory your recurring decisions

Start with the decisions that come up more than once, because those are the ones that cost you when authority is unclear. Skip genuine one-offs. Gather your team and brainstorm the categories where "who decides?" actually gets asked: architecture and tech choices, hiring approvals, budget over a threshold, roadmap trade-offs, incident response calls, vendor selection, and public commitments to customers.

Aim for fifteen to forty line items. Fewer than fifteen and you are probably describing categories, not decisions. More than forty and you are drifting into one-offs. Write each as a specific question: "Can we adopt a new database?" is mappable; "engineering stuff" is not. A clear inventory is the foundation, and a fuzzy one guarantees a fuzzy map.

Step 2: assign one accountable owner each

Every decision gets exactly one accountable owner. Not a committee, not "the team" — one name who is answerable for the call. This is the single most important rule, because shared accountability is no accountability. The owner can and should consult others, but the buck stops with one person.

Use a lightweight version of the RACI idea, trimmed to what teams actually use: an owner who decides, consulted parties whose input is required before the call, and informed parties who need to know after. The table below shows the shape.

Decision	Owner (decides)	Must consult	Inform after
Adopt a new database	Principal engineer	Platform lead, security	Whole eng team
Approve a backfill hire	Eng manager	Finance, recruiting	Team lead
Ship a customer-facing API change	Product owner	API owner, support	Account teams

If two people both think they own a decision, you found a conflict worth resolving now instead of during an incident.

Step 3: sort by reversible vs irreversible

Classify each decision as reversible or irreversible, because that classification sets how much review is warranted. Reversible decisions — the ones you can undo cheaply — should have a single fast owner and minimal consultation. Irreversible ones deserve named reviewers and a written rationale. Spending the same governance weight on both is how teams get slow and resentful at the same time.

This is Amazon's one-way vs two-way door idea applied to your authority map. Most decisions are two-way doors and should move fast. For the deeper treatment of why this distinction matters and how to handle the tricky middle, see reversible vs irreversible decisions. Mark each row in your map so the owner knows which speed applies before they act.

Step 4: record authority where decisions live

The map is worthless if it lives in a slide deck nobody opens. The authority for a decision should be attached to the decision itself, captured at the moment the call is made: what was decided, who owned it, who was consulted, and under what authority. That way "who approved this?" is answerable months later without reconstructing anyone's memory. This is exactly the problem that who-approved-this decision tracking solves, and it is where a static org chart falls apart.

This is where StandIn fits. StandIn is a system of record for decisions: teams declare what they decided along with the owner and authority, and that declared record is what an AI representative later answers from — so when someone asks "who can approve a new vendor?" they get the mapped owner, traceable to the source, not a guess. Because the authority is declared rather than inferred from scattered activity, the map stays honest. If a decision has not been made, the representative says so instead of inventing an answer. The map and the record become the same artifact, which is the only version that stays current. For teams operating across regions, keeping this record consistent also underpins decision accountability on distributed teams.

Common Questions

Who should own decision authority mapping?

The team lead or manager should own the mapping exercise, but the map itself should be built collaboratively with the people who actually make the decisions. Ownership of the process sits with one person so it gets done; ownership of each individual decision is distributed across the team per the map. A chief of staff or ops lead often facilitates the first pass.

How often should a decision authority map be updated?

Update it continuously, not on a calendar. The most reliable approach is to record authority at the moment each decision is made, so the map is a byproduct of normal work rather than a quarterly audit. If you rely on periodic reviews, expect the map to drift out of date within weeks as roles and ownership shift.

What is the difference between a RACI chart and a decision authority map?

A RACI chart maps roles to tasks and often covers execution responsibility; a decision authority map focuses specifically on who has the power to decide and under what authority. Decision authority maps also typically capture whether a decision is reversible, which changes the review bar. In practice a decision authority map is a decision-focused, lighter-weight cousin of RACI.

How do you handle a decision nobody owns?

Assign an owner before you need one. An unowned decision is the most expensive kind, because it gets re-argued or stalls under pressure. When mapping surfaces a gap, escalate it to the nearest manager to name an owner immediately rather than leaving it ambiguous "for now."

Mapping authority is only half the work; keeping the map alive is the other half. StandIn turns your authority map into a living decision record so the answer to "who decides this?" stays current and traceable long after the whiteboard is erased.