How to Write a Decision Authority Map for Your Team

A decision authority map is the document that tells the team, in one page, who can decide what. It's the artifact that separates teams who move fast from teams who wait for the boss. Writing it the first time takes about two hours. Keeping it current takes 15 minutes per quarter. The cost of not having one is roughly a sprint per quarter to escalation overhead.

What the map covers

For each category of decision your team makes, the map names:

• The primary decision-maker.
• The deputy (or deputies) who can decide if the primary is unavailable.
• The escalation path if a deputy isn't comfortable deciding.
• The categories of decisions that require sign-off from someone outside the team.

Inventory the decision categories

Common categories for an engineering team:

• Code review approval (per surface).
• Deploys and rollbacks.
• Revert decisions during incidents.
• Scope changes mid-sprint.
• Hiring (typically EM-level, separate authority).
• Vendor/tool selection.
• Architecture decisions (per surface).
• External-facing communications.

List the categories that apply to your team. Don't import a generic template — your team has specific decisions that recur. Name those.

Assign primaries by surface, not by title

Architecture decisions for payments go to the payments tech lead, not "the senior engineer." Surface ownership is how authority should map. If you can't name the surface owner, that's the gap to fix first.

Name deputies in each timezone

Every primary needs a deputy in each of the team's timezones. The deputy can decide if the primary is unavailable for more than 4 working hours. Without a deputy, the authority map fails the moment the primary takes vacation.

If you don't have a qualified deputy in a zone, that's a structural problem — either the surface needs to be split or you need to hire/promote into the gap.

Define the escalation path

For each category, name what happens when the deputy doesn't want to decide alone. Usually: escalate to the EM. Sometimes: escalate to a cross-team forum. Rarely: escalate to a VP.

Make the escalation path explicit so engineers don't have to guess. Guessing produces both under-escalation (decisions get made wrongly) and over-escalation (the EM becomes a bottleneck).

Keep it short

Authority maps that exceed one page get ignored. One page, scannable, with the structure: category → primary → deputies → escalation. Anything not on the map defaults to surface-owner discretion.

Brevity is what makes it usable. Long maps become wiki pages nobody opens.

Put it where the team will find it

Pinned in the team channel. Linked from onboarding. Referenced in 1:1s when you delegate. Not buried in a wiki section called "Process." If new hires don't see it in week one, the map isn't doing its job.

Review quarterly

Every quarter, scan the map: who left, who joined, which surfaces changed, which deputies aren't actually deciding. Update. 15 minutes of review prevents the map from rotting silently.

Common failure modes

Failure: writing it as aspiration. Names the people who should be deciding rather than who is. Always reflects the current reality first; aspirations go in a separate doc.

Failure: too many categories. 20-category maps overwhelm. Group adjacent decisions. 8-12 categories is the sweet spot.

Failure: not telling people they're a deputy. Map names them; nobody told them; first time work routes through them they hesitate and escalate. Inform the named deputies; confirm they accept the role.

What to do tomorrow

Sketch your first authority map today, even if incomplete. Five categories with primaries named is enough to start. Share with the team. The conversation it triggers will surface the gaps faster than trying to write the perfect version privately.

Frequently asked questions

Should ICs see the authority map?

Yes. The whole team. Hidden authority maps defeat the purpose. The point is everyone knows who decides what.

What about decisions that span multiple surfaces?

Name a single tiebreaker — usually the EM or principal engineer. Multi-surface decisions without a tiebreaker stall indefinitely.

How is this different from a RACI?

RACIs are heavier and tend to live in process docs nobody reads. Authority maps are one page, action-oriented, and focused on "who decides" rather than "who's responsible/consulted." Use whichever your team actually reads.