Free Decision Authority Map Template

A decision authority map is a one-page document that names, for every recurring class of decision your engineering team makes, exactly who has the authority to make it, who must be consulted before it is made, and who only needs to be informed after the fact. It is the document teams reach for the third time they discover that the architecture decision they shipped was technically made by nobody — three people each thought one of the others had signed off, and the rollback is now everyone's problem.

This template is the version that has actually worked on real engineering teams. It is not a RACI matrix dressed up in different language. RACI is a project artifact. A decision authority map is a standing artifact — you write it once, you update it twice a year, and it is supposed to outlast any individual project. The unit of analysis is the class of decision, not the task.

When to use it

• A senior engineer just left and three different people are claiming they were the de facto owner of a system area.
• You have more than one team and a recurring pattern of architecture decisions being made twice.
• A leader is bottlenecking the team because everything escalates to them by default.
• An incident review keeps stalling because nobody can say who should have approved the change.

The template structure

This is the structure of the template. Copy it into a Notion page, a Linear doc, or a markdown file in your repo — it works in any of them.

DECISION AUTHORITY MAP — [Team Name]
Last reviewed: [date]   Next review: [date]   Owner: [name]

┌─────────────────────────────────────────────────────────────────────┐
│ DECISION CLASS              │ DECIDER │ CONSULT │ INFORM │ NOTES    │
├─────────────────────────────────────────────────────────────────────┤
│ Architecture                                                        │
│   New service / repo        │ [name]  │ [names] │ [team] │          │
│   Cross-service contract    │ [name]  │ [names] │ [team] │          │
│   Database schema change    │ [name]  │ [names] │ [team] │          │
│   Choice of new dependency  │ [name]  │ [names] │ [team] │          │
│                                                                     │
│ People                                                              │
│   Hiring (IC, same team)    │ [name]  │ [names] │ [team] │          │
│   Hiring (lead / staff+)    │ [name]  │ [names] │ [team] │          │
│   Performance / PIP         │ [name]  │ [names] │ [team] │ Private  │
│                                                                     │
│ Money                                                               │
│   Tooling < $X/yr           │ [name]  │ —       │ [team] │          │
│   Tooling >= $X/yr          │ [name]  │ [names] │ [team] │          │
│   Vendor switch             │ [name]  │ [names] │ [team] │          │
│                                                                     │
│ Operations                                                          │
│   Incident severity declare │ on-call │ —       │ [team] │          │
│   Rollback in production    │ on-call │ —       │ [team] │          │
│   Postmortem owner          │ [name]  │ —       │ [team] │          │
│                                                                     │
│ Process                                                             │
│   Sprint cadence change     │ [name]  │ [names] │ [team] │          │
│   On-call rotation change   │ [name]  │ [names] │ [team] │          │
└─────────────────────────────────────────────────────────────────────┘

ESCALATION PATH
  Default escalation: [name]
  If unavailable:     [name]
  For people issues:  [name]

DECISIONS THAT ARE NOT ON THIS MAP
  Anything not listed is decided by the engineer doing the work. If a
  decision keeps surfacing here that is not listed, add it.

How to use it well

• Name people, not roles. "Tech lead" is not an answer. The point of the document is to remove the lookup step. If the role changes hands, you update the document — that is the only correct trigger to update it.
• The decider column is one person. Two names in the decider column means there is no decider. Use the consult column for the second name.
• Decisions not on the map default to the engineer doing the work. This is the most important sentence in the document. It says the map is permissive, not restrictive.
• Review it twice a year. Once a year is too rare for a team that is growing. Quarterly is too often and the document becomes ceremony. Twice is right.
• Pin it where new hires will see it in their first week. Onboarding hub, team README, top of the team Notion. Not buried in a wiki.

What to skip

Skip the temptation to break decision classes down to the atomic level. If you find yourself writing "deciding which logging library to use in the auth service" you have gone too deep — that is covered by "choice of new dependency." The map should fit on one screen. If it doesn't, the categories are too granular and nobody will read it.

Skip the urge to add a fifth column for "accountable." This is RACI creeping back in. Accountability lives with the decider; if you want to separate them you are inventing process that no engineer will actually follow when the decision is hot.

Frequently asked questions

Is this template free?

Yes. The structure above is the template — copy it, paste it into Notion or a Markdown file, and you have the document. The downloadable Notion version below is also free; the email is so we can send you the rest of the engineering governance pack.

Can I edit it?

Yes. The categories listed are the ones that recur on most engineering teams, but every team has its own peculiarities. Add an Infra row if you have a platform team. Add a Security row if you have a serious compliance posture. Cut anything that doesn't recur.

Do I need to give my email?

Not to use the template. The ASCII block on this page is the whole thing. The email gate is only on the formatted Notion file — useful if you want a polished version, optional if you don't.