Decision Rights

Most slow architectural decisions are not slow because the analysis is hard. They are slow because nobody knows whose call it is, so everyone consults everyone, and the decision waits for an agreement that was never actually required.

Decision rights fix that by naming, for each class of decision, who decides — with the explicit understanding that the decider consults and then decides, rather than waiting for unanimity.

Why it improves quality as well as speed

Accountability concentrates attention. A named decider who will own the consequences engages differently from a committee where responsibility is diffuse.

It also makes disagree-and-commit possible. Someone who did not prevail can say so on the record and then support the decision, because there is a legitimate decider rather than a consensus that was overridden. Suppressed disagreement resurfaces at the first difficulty and is far more damaging.

Implementation patterns

• Classify by reversibility and blast radius, and assign rights accordingly. A choice contained within one team is that team's; one affecting other teams, customers or the organisation's risk position is not.
• Push rights down by default. Most decisions are not architectural, and centralising them creates a queue.
• Name a person, not a group, for anything expected to be decided rather than discussed.
• Publish the escalation path, so a decision that genuinely needs a higher authority moves quickly rather than stalling.
• Separate consultation from approval. Consult widely, approve narrowly. The failure is treating everyone consulted as holding a veto.
• Record who decided, alongside what and why, so the decision can be revisited with the right person.

Industry example

The recurring case is a conflict between a delivery commitment, a security requirement with a longer lead time, and a platform preference. All three positions are legitimate, and the architect who quietly picks one has made a business decision without authority.

The resolution is to present costed options and identify who decides — someone accountable for both the revenue and the risk, usually one level above all three parties. The architect's contribution is making the decision makeable, and frequently producing the third option nobody had considered.

The same structure applies to error budget exceptions, where a launch is proposed with the budget exhausted: the decision belongs to whoever owns both reliability and revenue, with conditions attached and a record kept so a pattern of exceptions becomes visible.

Failure scenarios

• Consensus as the default, which makes every participant a veto holder and every decision slow.
• Rights held centrally for decisions with local consequences, producing a bottleneck teams route around.
• A named decider with no context, deciding badly because consultation was skipped in the name of speed.
• No escalation path, so genuinely contested decisions stall indefinitely.
• Decisions made by whoever is most persistent, which is the default in the absence of stated rights.

Trade-offs

Explicit decision rights concentrate power, which can be resented and can produce worse decisions if the decider is poorly chosen or does not consult. Consensus, for all its slowness, distributes judgement and builds commitment.

The workable balance is consensus-seeking with a decider — consult genuinely, decide explicitly, record the disagreement — which preserves most of the commitment benefit without the unbounded timeline.

Interview question

"Two teams disagree about an architectural approach and the debate has run for a month. Walk me through how you resolve it — and tell me what you would change so the next disagreement takes a week."