Decisions stall for a boring reason more often than a hard one: no one is sure who gets to make the call. Two people think it is theirs, or everyone thinks it is someone else's, and the choice just sits. A decision rights map fixes that by writing down, ahead of time, who decides what. This is a spoke off the broader decision authority map, focused on the one question of rights: who gets to decide.
What a decision rights map is
A decision rights map is a short table that pairs each recurring decision your team makes with a single person who owns it. Not a group. One accountable name per decision. Around that name, it notes who must be consulted first and who needs to be told after. That is the whole shape: one decider, some consulted, some informed.
The map does not try to cover every choice a team ever faces. It covers the decisions that come up again and again, the ones that stall or get relitigated. Those are where clear rights pay off.
What one row looks like
Before the steps, here is a single row so the shape is concrete. Take the decision "which features go in the next release." The decider is the product lead. Consulted: engineering lead and design lead, because they hold the effort and the tradeoffs. Informed: sales and support, because they act on what ships but do not shape it. When the product lead is out, the engineering lead holds the call for anything urgent, and anything that can wait, waits.
That one row already ends most of the friction. No one wonders whose call it is. No one is surprised by what shipped. And the decision does not freeze the week the product lead takes a holiday. Build the rest of the map the same way, one decision at a time.
Build it in five steps
1. List the decisions that actually recur
Start with the choices your team makes over and over: what ships, who gets hired, how money is spent, what the roadmap says, when to call an incident resolved. Aim for a page, not a book. If a decision comes up once a year, leave it off. You want the ones that create friction now.
2. Assign one decider to each
For every decision on the list, name a single person who gets to make the final call. The hard part is resisting the urge to write two names. Shared ownership of a decision usually means no ownership. If two people truly must agree, that is a sign the decision should be split into two smaller ones, each with its own owner.
3. Mark who must be consulted
Consulted is not the same as deciding. These are the people whose input the decider has to hear before choosing, because they hold context or bear the consequences. Keep the list short. If everyone is consulted on everything, you have rebuilt the slow committee the map was meant to replace.
4. Mark who must be informed
After the call is made, who needs to know? These people do not shape the decision, but they act on it, so they cannot find out by accident weeks later. Naming them turns the announcement into a habit instead of a scramble.
5. Decide what happens when the decider is away
This is the step most maps skip, and it is the one distributed teams need most. For each decision, write down who holds the call when the owner is offline or out. A map that only works when everyone is present is not a map, it is a bottleneck with a nice layout. Name the backup, and name the few decisions important enough to wait for the real owner rather than pass down.
How to use it once it exists
Put the map where the team already looks, and point to it the moment a decision starts to drift. When someone asks "whose call is this?", the answer should be a link, not a debate. Read it aloud in the meeting where a stalled decision is finally moving, so people learn the map by using it.
Review it a few times a year, and whenever the team changes shape. Roles move, people leave, new decisions start to recur. A rights map that does not keep up quietly becomes wrong, and a wrong map is worse than none, because people trust it.
Common mistakes
The first is mapping too much. A map with a hundred rows never gets read. Cover the decisions that stall, not every choice imaginable. The second is confusing consulted with decider, which recreates the gridlock you were trying to end. If someone consulted can quietly veto a call, they are really a second decider, and you are back to shared ownership. The third is leaving the away column blank, which means every one of your carefully assigned rights disappears the day the owner takes a holiday. A right that only holds while one person is online was never really assigned.
Where StandIn fits
A rights map tells you who owns a decision. It does not answer questions on that person's behalf while they are away. That is the piece StandIn adds. You write one short brief at the end of your day, and while you are off, it answers your teammates from what you wrote, names who owns a call and who approved it, links the source, and says so when the answer is not on record. The map sets the rights. StandIn keeps them working when the owner is offline.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.