A decision authority matrix is a simple map of who can decide what on your team. For an async team spread across time zones, the matrix only helps if people can retrieve it in the moment, not dig it out of a doc nobody opens. The version that works is one you can ask: "who can approve a schema change," and get a named answer back from a record that person stands behind.
Most teams write the matrix once during a planning offsite and never look at it again. The chart goes stale, the names drift, and the next time a real decision is blocked, everyone falls back to guessing or pinging whoever is awake. The fix is not a prettier chart. It is making the matrix queryable.
What is a decision authority matrix?
A decision authority matrix is a table that lists each type of decision your team makes and names who has the authority to make it, who must be consulted, and who only needs to be informed. It answers one question cleanly: when this kind of call comes up, who owns it.
This is close to RACI, the responsibility chart that marks who is Responsible, Accountable, Consulted, and Informed for a given task. RACI maps tasks; a decision authority matrix maps decisions. They overlap, and many teams use the two together. If RACI is new to you, the short version is below in the template.
Why do async teams need it written down?
In a room, decision rights are negotiated in real time. Someone says "I'll make the call on this," people nod, and the team moves. Async teams cannot do that. By the time a question reaches the person who should answer, eight hours have passed and the work is stalled behind them.
When authority is unclear, two failure modes show up. Either nobody decides, because everyone assumes someone else owns it, or two people decide differently and the team finds out a week later when the work collides. Both come from the same root: the authority was in someone's head, not in a record anyone could check.
Writing it down fixes the first half. Making it queryable fixes the second. A static chart still requires you to know where the chart lives and trust that it is current. A queryable matrix lets you ask in the flow of work and get the current owner, by name.
There is a subtler cost to unclear authority that async teams feel keenly: speed. Every decision that has to wait for someone to figure out who owns it loses a day in the time-zone shuffle. Clear, retrievable authority is not just about avoiding conflict. It is about removing the pauses where work sits idle while people sort out who is allowed to move it forward.
A simple decision authority matrix template
Copy this and fill it in per decision type. Keep it short. A matrix with forty rows is a matrix nobody reads.
| Decision type | Decider (owns the call) | Consulted (gives input) | Informed (told after) |
|---|---|---|---|
| Schema or migration changes | Backend lead | Affected service owners | Whole eng team |
| Shipping behind a feature flag | Feature owner | QA, on-call | Product |
| Rolling back a release | On-call engineer | Eng lead | Whole team |
| Adding a new third-party dependency | Tech lead | Security reviewer | Eng team |
| Changing an external API contract | API owner | Consuming teams | Support, docs |
Two rules keep it useful. The "Decider" column should name one person or one role, never a committee, because shared authority is the same as no authority. And every row should map to a real decision your team has actually argued about, not a hypothetical.
How do you keep the matrix from going stale?
A chart goes stale because updating it is a separate chore from doing the work. The matrix lives in one doc, the work lives everywhere else, and the two drift apart within a quarter.
The way out is to tie authority to the record people already keep. When the backend lead declares a schema decision, that declaration is the proof of who owns schema calls right now. The matrix stops being a static chart you maintain and becomes a question you ask: who has been declaring decisions in this area, and who did the team agree owns it.
Two steps make that work. Auto-indexing makes each person's decisions findable and pointable. Declaring is the human step where someone vouches for a call as their own. Together they mean the answer to "who decides this" comes from real, recent records, not a chart that was true in January. And when no one owns a decision type yet, a queryable record says so, which is your signal to assign it before it blocks someone.
How does this connect to handoffs?
Decision rights are the first thing lost in a handoff. The person leaving knew who to ask; the person arriving does not. A queryable authority matrix carries that knowledge across the gap, so the new person asks the record instead of learning by getting it wrong. Our best practices for async handoff cover how to hand off authority, not just tasks, and our piece on engineering team handoffs and context loss shows where this knowledge usually slips.
You can see how indexing and declaring make authority retrievable in how StandIn works.
Frequently Asked Questions
What is the difference between a decision authority matrix and RACI?
RACI maps who is Responsible, Accountable, Consulted, and Informed for tasks. A decision authority matrix maps the same idea onto decisions specifically. Most teams use a blend of the two.
How many rows should the matrix have?
As few as possible. List only the decision types your team has actually disagreed about. A long matrix is a sign you are mapping hypotheticals instead of real friction.
Who owns keeping the matrix current?
Ideally no one, as a separate chore. If authority is tied to the decisions people declare, the matrix stays current as a byproduct of normal work rather than a quarterly cleanup.
What happens when two people think they own the same decision?
A queryable record surfaces the conflict early, because you can see who has been declaring decisions in that area. You resolve it once and record the answer, instead of discovering the overlap after the work collides.
Can a tool decide for us when the owner is offline?
No, and it should not. A trustworthy record points you to the named owner or tells you no one owns it yet. It never invents authority that a person did not declare.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to retire your daily standup?
Distributed teams use StandIn to start every shift with full context, no standup required. Engineers publish a 60-second brief. The next shift wakes up knowing exactly what to work on.