No. 089Strategy & Enterprise

Guardrails, Not Gates

Govern by setting clear, ideally automated, boundaries and paved roads, and review only what crosses them, instead of making every change queue for approval.

Gates make every change queue for approval; guardrails let teams move freely inside clear boundaries and save review for what crosses them.

To an executive

Approval boards become queues as the organisation grows. Clear limits that teams can check themselves keep delivery fast while still controlling the risks that matter.

To an engineer

Replace review gates with rules teams can see and automated checks in the pipeline. Provide supported templates so the compliant way is the easiest way.

The idea

Most architecture governance starts as a gate: a review board or design authority that every significant change must pass. Gates work while the organisation is small. As teams multiply, the board becomes a queue, and the queue becomes the slowest part of delivery.

A guardrail is a boundary that teams can see in advance and stay within on their own. "Services expose APIs through the gateway." "Customer data stays in EU regions." "No new database engines without an ADR." The best guardrails are checked automatically, in a pipeline or a policy engine, so nobody has to wait for a meeting to learn they are fine.

Guardrails pair with paved roads, sometimes called golden paths: supported templates, platforms and tooling that make the compliant way the easiest way. Spotify describes its golden paths as the recommended, well-supported route for common tasks; teams may leave the path, but they lose the support. Governance attention then goes to the cases that cross a boundary, not to every change.

No one person coined this. It grew out of platform engineering, policy-as-code and decentralised practice such as Andrew Harmel-Law's advice process, where anyone may take an architectural decision if they first seek advice from those affected and from experts.

Why it works

Most changes are routine. If nearly every review ends in approval, the review mostly adds delay. Writing down what makes a change routine lets those changes flow.

Rules that run beat rules that are read. A wiki standard drifts from practice. A pipeline check or cloud policy is applied every time, to every team.

The easy path wins. Teams follow the least effort. If the paved road is quicker than going it alone, most teams take it unprompted, and the estate converges.

Scarce expertise goes where it matters. Architects stop reviewing the tenth standard service and focus on decisions that cross domains or carry regulatory risk.

Where it applies

Review boards and design authorities that have become a bottleneck for a growing portfolio.
Cloud landing zones and platforms, where policy-as-code enforces region, network and identity rules before deployment.
Regulated environments, where automated checks produce the evidence of consistent controls that auditors ask for.
Federated operating models, where business units own delivery but the enterprise still needs shared standards.

How to apply

List what your gates actually catch. Sort recent review findings into those a rule could have caught and those that needed judgement.
Turn the rule-shaped findings into guardrails. Write each as a short, testable statement and automate it where you can, as a fitness function or cloud policy.
Build or name the paved road. Offer templates, reference architectures and platform services that satisfy the guardrails by default.
Define what crosses the line. Make explicit which decisions still need advice or review: new technology, cross-domain data flows, material third-party dependencies.
Record and revisit. Capture exceptions as decision records and review guardrails periodically, so they track risk rather than habit.

Example scenario

A bank's design authority met fortnightly and reviewed every new service. Teams waited up to a month, and most submissions were approved with minor comments about logging and network zoning.

The enterprise architects turned those recurring comments into a dozen guardrails enforced in the deployment pipeline and the cloud landing zone, and published a service template that met them. Standard services stopped going to the board. The design authority now meets on demand for the handful of decisions that introduce new vendors, move customer data across domains or touch critical functions.

Questions to ask

Which of the decisions this board reviews could a written, testable rule settle instead?
What would a team have to do to step outside the paved road, and who needs to hear about it?
How long does a typical change wait for governance, and what risk does that wait actually remove?

When not to use it

Genuinely one-way decisions, such as signing a multi-year sourcing contract, deserve a deliberate review whatever your guardrails say.
Immature practice, where nobody yet knows what "good" looks like; write guardrails after you have seen enough cases to know which rules hold.

How it misleads you

Guardrails can quietly become gates with better branding: a hundred mandatory rules, a platform that is the only permitted road, and an exception process slower than the old board. Keep the set small, explain the reason for each rule, and treat a steady stream of exceptions as a sign the guardrail or the road is wrong.