Significance Trigger

A review board that inspects every change is arithmetically impossible at any meaningful change volume, and attempting it produces a queue. Teams then route around it, and the organisation ends up with a rigorous process covering a fraction of the estate and no visibility into the rest.

Significance triggers solve this by defining, in advance and publicly, which changes require review. Everything else is the team's to decide.

The principle behind the trigger set

Review what crosses a boundary the team cannot see beyond. A decision whose consequences are contained within one team is that team's to make; a decision whose consequences land on other teams, on customers, or on the organisation's risk position is not.

A workable trigger set

• A new persistent data store. Data decisions are the least reversible in most systems.
• A new external interface to customers or partners — a contract you cannot unilaterally change.
• Regulated or personal data crossing a boundary — a new store, a new region, a new third party.
• A new failure domain, or a change to an existing one, since availability consequences cross teams.
• A dependency added to a critical path, which lowers the availability ceiling for everyone downstream.
• Spend above a threshold, or a commitment constraining future options.
• An irreversible decision — tenancy model, identity scheme, shard key.

What should explicitly not trigger review

Internal architecture, framework choices, module structure, testing approach. Anything already enforced by an automated guardrail — re-checking a scaling control by hand is pure queue. Anything following a published pattern the team has conformed to.

Industry example

Organisations shipping many changes daily converge on a three-layer model: preventive guardrails automated for severe irreversible actions, a paved road making the compliant path the fast path, and review reserved for a narrow trigger set.

The reason is arithmetic. Prevention scales with automation; review scales with headcount. As change volume grows, only the first can keep up, so the review layer must shrink to what genuinely needs human judgement or the whole system fails.

The failure mode when this is not done is consistent and predictable: a six-week queue, teams scoping projects to avoid triggers, and an ungoverned shadow estate that has none of the controls the board exists to provide.

Failure scenarios

• Triggers defined by process stage rather than by significance — "all projects above a size" rather than "changes with these properties".
• Triggers not published in advance, so teams discover them late and experience governance as an ambush.
• Trigger creep, where each incident adds a new trigger until everything qualifies again.
• No bounded turnaround, which causes routing around more than the review itself does.
• A comment list instead of a verdict, leaving the team unable to proceed or to argue.

Trade-offs

A narrow trigger set means some poor decisions pass unreviewed, and occasionally one of those becomes an incident — which creates pressure to widen the triggers. Resisting that pressure requires being able to point at what the wider net would cost in queue time and in routed-around decisions.

The honest position is that a lighter process covering nearly all of the estate provides more assurance than a rigorous one covering a third, and that comparison is what most governance conversations actually need.

Interview question

"Your review board has a six-week queue and teams are avoiding it. Give me the list of things you would stop reviewing, the triggers you would keep, and how you would justify the ones you dropped after the first incident that slips through."