The paved road

Why does making one route easy work better than forbidding all the others?

A platform team wants every service in the company to emit structured logs, ship with health checks, and deploy through a reviewed pipeline. There are two ways to get there. Write a policy saying it is mandatory and audit for violations. Or build one route that does all of it automatically, make it the fastest way to start a service, and let people use something else if they insist.

The first sounds firmer. It has authority behind it, and it covers every case rather than hoping people opt in. Yet organisations that try it tend to end up with elaborate exception processes and a quiet population of services that were never registered. Why would the weaker-sounding option produce more compliance than the stronger one?

Start with the engineer, not the policy. Someone needs a new service running by Thursday. They will choose whatever path gets them there, weighing effort now against consequences later — and consequences later are heavily discounted, by everyone, always.

Now ask what a prohibition changes about that calculation. It adds a cost to the forbidden path, but the cost is probabilistic and deferred: it lands only if someone notices, and noticing happens weeks later in a review. Meanwhile the effort saved is immediate and certain. So the rule is competing on unfavourable terms with the thing it is trying to stop.

And there is a second effect, easier to miss. A prohibition tells you what not to do without telling you what to do instead. If the compliant route is not obvious, the engineer must construct one — and the version they construct will satisfy the letter of the rule in whatever way is cheapest, which is rarely the way the rule intended. The rule generates work and the work generates variation, which is the opposite of what standardisation was for.

Now consider the other approach. Instead of raising the cost of the alternatives, lower the cost of the desired route until it is the cheapest thing on the menu. The engineer's calculation now points the right way with no enforcement at all: the compliant path is not a tax on getting the service running, it is how you get the service running fastest. Compliance stops being a behaviour someone must be persuaded into and becomes a by-product of self-interest.

Is that just a nicer way of pressuring people? No. A prohibition needs continuous energy — audits, exceptions, escalation, someone whose job is chasing. An easy path needs energy once, to build it, and then runs on the users' own motivation. One is a force applied against a gradient; the other changes the gradient.

But push on it, because the model has a real weakness. What happens when the paved road does not fit? Someone needs a GPU, or a database the platform does not offer, or a latency budget the standard sidecar cannot meet. If the road is the only supported thing, that team is stuck, and stuck teams build shadow infrastructure that nobody supports and nobody can see — which is worse than a documented deviation.

So the design has to include the exit. The usual formulation is that the road is paved, not walled: leaving it is permitted, and what you give up is the automatic parts — the pre-wired observability, the inherited compliance evidence, the platform team's on-call knowledge of your setup. That is an honest trade rather than a punishment, and it makes deviation visible, which is the thing an audit was trying to achieve and usually fails at.

There is one uncomfortable implication. This model only works if the road is genuinely good. A mandate can survive being unpleasant, because it does not depend on being chosen. A paved road that is slow, poorly documented, or a version behind will simply lose, and losing looks exactly like adoption failure — which is why platform teams are pushed toward treating internal users as customers rather than as subjects. The approach converts a governance problem into a product problem, and product problems are still hard.

Three clarifications.

First, this is not an argument against rules. Some things must be prohibited outright, and the test is whether a single violation is tolerable. Storing card numbers in plaintext, exfiltrating customer data, deploying unreviewed code to a regulated system — these need hard gates, because "mostly nobody does it" is not an acceptable outcome. The paved road handles the large class of practices where broad adherence is what matters and the occasional justified exception is fine. Using a gate where a road would do makes people creative; using a road where a gate is needed makes an incident.

Second, the road's power comes from what it removes, not from what it provides. A template that generates a service with logging, tracing, health checks, a pipeline, and a dashboard already wired is not offering features — it is deleting a week of undifferentiated setup. If the road merely offers the same work in a blessed style, the calculation does not move.

Third, roads decay. The gradient that made the road attractive is relative to the alternatives, and the alternatives improve constantly. A paved road left unmaintained becomes the slow option within a year or two, at which point adoption falls and the team's instinct is to reach for a mandate — which is how organisations end up with a mandatory bad road, the worst configuration available.

• Platform engineering and the internal developer platform, which is the paved road built as a product.
• Policy as code, for the small set of things that genuinely need a gate rather than a gradient.
• How to measure a road's health — adoption rate, time to first deploy, and where teams leave it.

Every term the collection defines is gathered in the glossary.