Decision Rights Boundary

A team wants to introduce a new message broker. Another team wants to change its test framework. One of these is an enterprise decision and the other is not, and the difference is not cost, difficulty or how many systems are touched.

Architecture scope follows the reach of the consequence. The test framework affects one team; if the choice is wrong they change it and nobody else pays. The broker gives every on-call rotation something new to be paged about, the platform something to patch, back up and monitor, and the next team a precedent to cite.

Why it matters

Getting this line wrong is the most common cause of both governance pathologies, in opposite directions.

Drawn too wide, every meaningful choice queues for a review board, teams learn to route around governance, and the architecture function becomes a consultancy people must book. The cost is lead time, and it is paid on every change.

Drawn too narrow, the estate accumulates one-way doors nobody reviewed: three message brokers, five languages, two identity systems, and a customer identifier with four incompatible formats. The cost is paid years later by people who did not make the decision, which is precisely why the feedback loop is too weak to correct itself.

Implementation patterns

The test is three questions, answerable in a minute by the team itself:

• Who pays if this is wrong? If the answer includes people outside the team, it is not a local decision.
• How long does it outlive the team that made it? Data models, wire formats and identifiers survive reorganisations; frameworks and internal structure usually do not.
• What does reversal cost? Under roughly 5 days of one team's time, decide locally even if it is consequential - the mistake is cheap.

Supporting practices: publish the list of triggers rather than the word "significant" (crosses a domain boundary · adds a datastore or language to the estate · touches regulated data · is hard to reverse) · make self-assessment the default with spot checks rather than pre-approval · and require a decision record for anything above the line, so the cross-cutting view survives without a gate.

Industry example

The paved-road model used across large engineering organisations is this line made operational: a default path teams may take without asking, and a narrow set of decisions that require a conversation. The distinction between them is exactly decision rights, and the published accounts of platform teams consistently report that the failure mode is not teams making bad local choices - it is unclear boundaries, where teams do not know which category they are in and ask about everything or nothing.

Amazon's widely discussed distinction between one-way and two-way doors is the same test reduced to its reversibility component: decide two-way doors fast and locally; reserve deliberation for what cannot be undone.

Failure scenarios

• Cost thresholds as the trigger. A \(2000 SaaS subscription holding customer data has wider reach than \)200000 of hardware inside one team, so money-based gates review the wrong things.
• Difficulty as the trigger. Hard problems get escalated and easy far-reaching ones do not, which inverts the intent.
• Unwritten lines. When "significant" is undefined, nervous managers escalate everything and confident ones escalate nothing.
• Boundaries that never move. A line drawn at 50 engineers applied at 500, where "enterprise" should have split into domains.
• Decision rights without decision records, so the organisation cannot learn what was decided or why.

Trade-offs

When not to use it

In a very small organisation, nearly every decision binds everyone, so the distinction is academic and the whole company is the review. Formalising it at fifteen engineers is ceremony.

In a very large one, "enterprise" is too coarse: most cross-team decisions should be settled inside a domain, and applying a single central line produces a bottleneck. The concept then repeats fractally, with a boundary at each level. The line is drawn where the blast radius of a mistake stops, and it moves as the organisation grows - which means it has to be revisited, not set once.

Interview question

Q: A team wants to adopt a new programming language for one service. They argue it is their service and their on-call. What do you ask them, and under what conditions would you agree?

What a strong answer covers: that on-call ownership is not the whole consequence - hiring, the platform's build and base images, security patching, and the precedent for the next team all land outside the team · asking who maintains the service if the team is reorganised, since languages outlive teams · the reversibility question and the honest answer that a rewrite is expensive · conditions under which yes is right: a genuine workload fit the current stack cannot meet, a bounded service at the edge of the estate, an agreed support model and a named exit trigger · and a written decision record either way, so the next team inherits reasoning rather than precedent.

Quick check

Quiz: Why is "involves more than one system" a poor test for an enterprise decision? Because most changes touch several systems - a team owning four services integrates them all day and the consequence stays inside the team. Reach of consequence, not number of systems, is what separates the categories.

Flashcard: What three questions place a decision on one side of the line? — Who pays if it is wrong · how long it outlives the team that made it · what reversal costs. Under roughly 5 days of one team's time to reverse, decide locally.