coordinationestablished · medium operational burden

Paved Road Governance

Also known as: golden-path, paved-path

Intent

Guide teams with a well-supported default path rather than mandates, keeping autonomy while reducing variance.

Problem

Strict standards slow teams and invite workarounds, while no standards cause sprawl and security gaps. Central teams cannot review every choice.

Forces

•Teams want autonomy and speed
•Security and compliance need consistency
•Central support capacity is limited
•Standards must remain attractive to be adopted

Solution

Overview

A paved road, popularized by Netflix, is a supported default that makes the right thing the easy thing. Governance shifts from approval gates to product management of the path.

Governance becomes product work. The platform team has users, a backlog, and success metrics such as time to first production deploy and the percentage of services on the supported path. Surveys and office hours keep the path aligned with real needs.

How it works

Teams start from a template that wires in the required controls.

$ platform new service --template=java-api
  -> repo with CI/CD, SBOM scan, SLO dashboard, secrets mgmt
  -> deploy via standard pipeline in under 1 day
Off-road: allowed with a short exception record
  (owner, reason, extra controls, review date)

Guardrails complement the road. Automated policy checks, such as image scanning and required tags, apply to everyone and catch off-road deviations without manual review. This combination keeps consistency high while still letting teams with unusual requirements make justified exceptions.

Pitfalls

Mandating the road without making it better, which breeds shadow IT
Treating the platform as a project instead of a product with users and a roadmap
Having no exception process, so off-road work is invisible
Measuring only adoption rate, not time to first deploy or satisfaction

Key takeaways

Make the paved road the easiest path, not the only one
Run the platform as a product with feedback
Allow documented exceptions with owners
Measure adoption and developer experience

✓ When to Use

•Many teams building similar services
•Platform team exists to maintain the path
•Compliance requires consistent controls

✗ When Not to Use

•Very few teams or products
•Platform has no capacity to support the road
•Workloads are too diverse for one default

Pros

+Faster delivery through ready defaults
+Consistent security and observability
+Preserves team autonomy through opt-out

Cons

−Requires sustained platform investment
−Path may lag teams' needs
−Off-road teams may be under-supported

Cost Profile

Infrastructure

Medium - shared platform tooling

Operational

Medium to high for platform team

Cognitive

Low for adopters

Failure Modes

Path is slower than going off-road, so adoption collapses
Platform team ships without user feedback
Off-road usage becomes unmanaged risk

Real-World Examples

Alternatives

Related Patterns

platform-engineering
team-topologies

Competency Domains

economics evolutionsecurity compliance