Decision Rights Matrix

Three teams escalate the same kind of disagreement in a month: the team says a design is ready, a staff engineer elsewhere says it is not, and nobody can say who decides. Each escalation adds a week to one team's lead time, and in all three cases the design that eventually shipped was the one originally proposed. The organisation paid three weeks for no change in outcome, because the right to decide was never assigned.

A decision rights matrix assigns it. Not a review step, not a board, not a template: a short published rule that a team can apply themselves, before asking anyone, to find out whose agreement they actually need.

Why it matters

The default state is worse than either extreme. If the architect decides everything, there is a queue and the measure of it is visible — median wait, and the number of teams that ship without asking. If teams decide everything, bad irreversible choices land and surface later. Ambiguity has the costs of both: the queue exists and nobody is accountable for what comes out of it.

The mechanism that makes ambiguity expensive is asymmetric cost. A reviewer who can block without owning the consequence pays nothing for delay, so delay is free to them and expensive to the team shipping. Attaching a named owner and a date transfers that cost back.

It also keeps the architecture function small. The measure of a healthy architecture practice is how few decisions reach it, and that number is only controllable if most decisions are explicitly somebody else's.

Implementation patterns

The shape that holds up is three classes, published on one page:

• Team-local and reversible. The team decides. No review. Recorded in a decision record so it is findable in a year. Framework choices inside a service, internal module structure, anything undone in a sprint.
• Crosses a contract others depend on. The affected teams decide jointly, with a deadline — 5 working days is a common figure — after which a named arbitrator decides. API shapes, event schemas, shared data models.
• Hard to reverse or binds the organisation. The architect owns it and is accountable for it. Data models, public APIs, vendor commitments, anything with a security or regulatory footprint.

Supporting practice: the decision record names which class was claimed. That one field makes the classification auditable after the fact rather than negotiated before it. And the arbitrator must be a person, not a group, because a group has no deadline.

Industry example

Amazon's long-standing internal distinction between one-way and two-way doors — irreversible decisions needing care, reversible ones needing speed — is the version of this idea most widely described in public, including in Jeff Bezos's 2015 and 2016 shareholder letters. It supplies the axis (reversibility) but not the assignment, which is the part that stops escalations.

Spotify's published engineering material from the mid-2010s went further on assignment, pairing autonomous squads with a small number of explicitly centralised decisions, and the frequently reported failure mode is instructive: the autonomy was copied widely and the short list of centralised decisions was not, so organisations ended up with duplicated infrastructure choices and nobody empowered to converge them. Copying the autonomy without copying the decision rights imports the cost and not the benefit.

Failure scenarios

• Reclassification. A team that does not want to wait records an irreversible decision as team-local, ships it, and nobody notices until the first incident or the first external review.
• The arbitrator is a committee, so the deadline has no meaning and the class collapses back into an unbounded wait.
• No deadline at all. "Decide jointly" becomes "wait for the quietest participant", which is the state the rule was written to fix.
• The matrix grows. Seven classes with sub-conditions is unusable at the moment of choosing, so people ask the architect instead and the queue returns.
• The same two teams generate every escalation. The rule is working and the boundary is wrong; improving arbitration here treats the symptom.

Trade-offs

Explicit decision rights buy predictable lead time and cost some design quality at the margin: a team deciding alone will occasionally make a choice a wider review would have improved. That is the purchase, and it is usually worth it for reversible decisions and usually not for irreversible ones, which is why the classification is by reversibility rather than by importance.

The second cost is political. Writing down who decides makes visible a power distribution that was previously deniable, and the people who benefited from ambiguity will object. Expect the argument to be about the classification of specific decisions rather than about the principle.

When not to use it

Below about 3 teams, do not build this. With one or two teams the decisions are made in the same room by people who can see each other, and a published matrix is ceremony. The signal that you need one is escalations repeating: the same category of disagreement reaching the same person more than twice.

Also skip it when the real problem is capability rather than authority. If teams genuinely cannot make a good call on a class of decision, assigning them the right does not help; the fix is a reference implementation, a paved path, or a guard rail in the pipeline that makes the wrong choice hard to make.

Interview question

Q: You are the only architect supporting eleven teams. Design the decision-rights rule you would publish in your first month, and tell me how you would know after a quarter whether it worked.

What a strong answer covers: three or four classes, keyed on reversibility and on whether a contract others depend on is affected · a deadline and a named arbitrator for the shared class · recording the claimed class in the decision record so misclassification is detectable · the measures that would show it worked: escalations per month, median time from design-ready to build-started, and the number of decisions reaching the architect trending down · the failure mode to watch for, which is reclassification rather than disagreement · and the organisational read, that a persistent cluster of escalations between the same two teams is a boundary problem to be fixed by moving work, not by better arbitration.

Quick check

Quiz: What single element turns "the affected teams decide jointly" from a rule into an indefinite wait? — The absence of a deadline with a named person who decides when it expires.

Flashcard: Name the three decision classes and who holds the pen in each. — Team-local and reversible: the team, no review, recorded · crosses a contract others depend on: the affected teams jointly, with a deadline and a named arbitrator · hard to reverse or binds the organisation: the architect, accountably.