The Paved Road Problem: driving workflow adoption across teams you don't control

Your new pipeline is faster, safer, and better documented than the six the teams are using today. You announced it. You wrote the migration guide. Three months on, two teams tried it, one rolled back, and the rest are quietly still on their own scripts. Nothing is broken — you just have no power to make anyone move, and it turns out that “it's better” was never a reason anyone acts on. Building the better thing was the easy half. Getting teams you don't control to adopt it is the real problem.

Why “it's better” isn't a reason anyone moves

A platform, enabling, or tooling team has one structural handicap: it builds things for teams it has no authority over. In the Team Topologies vocabulary, you are a platform team and the teams you're trying to reach are stream-aligned teams — the ones shipping product. Your relationship to them is X-as-a-Service: they consume what you offer through a clean, self-service interface. Crucially, they are your internal customers, not your reports. You can't tell a customer what to do; you can only make something they'd choose.

That reframes the whole job. Shipping the workflow was the easy half. The hard half is that a competing “workflow” already exists on every team — the pile of bash, the copy-pasted CI file, the thing that already works for them. “Mine is better” asks them to pay a migration cost today for a benefit that's diffuse and future. Most won't. Not because they're wrong, but because the switching cost is real and concrete while the pull is weak and abstract.

The mandate reflex — and why it backfires

When pull is weak, the instinct is to reach for push: get a VP to declare the new workflow mandatory. It feels decisive. For teams you don't control, it reliably fails in three ways.

A decree you can't enforce breeds resentment. People push back against mandates, even reasonable ones. The moment adoption is framed as compliance rather than value, you've turned a potential advocate into someone hunting for the exemption.

It relocates the work into the shadows. This is the shadow-IT lesson, and it's well documented: banning the workaround doesn't stop the building, it moves it somewhere you can't see — strictly worse than the visible version. Teams keep their old scripts, wrap a thin veneer of “compliance” over them, and you lose the very visibility a platform is supposed to give you. In one survey of security professionals, 73% admitted using unsanctioned SaaS in the prior year — people who knew the policy and the reasoning and routed around it anyway.

It produces adoption theater. You can hit “100% of new services use the golden path” on paper while developers work around it at every opportunity. Adoption that comes from value is real; adoption that comes from policy is an illusion. The number looks great and means nothing.

The paved road — the better default, not the only road

The pattern that solves adoption-without-authority has a name and a lineage: the paved road (Netflix), the golden path (Spotify), and the paved path (Google). All three describe the same move — make the supported way so much easier than rolling your own that leaving it becomes the expensive choice.

Netflix coined the framing. A paved road is “a set of tools and practices that are formally supported by centralized teams” who act as force multipliers, turning specialized knowledge into reusable building blocks. The governing sentence — the whole pattern in one line — is Netflix's own: they “don't mandate adoption of those paved roads but encourage adoption by ensuring that development and operations using those technologies is a far better experience than not using them.” By the company's reports, over 90% of Netflix engineers stay on the paved road, because going off-road takes more effort, not less.

Spotify gave it the other common name. A golden path is “the opinionated and supported path to build something” — a backend service, a website, a data pipeline. It grew from a real pain: as Spotify scaled, teams learned how to do things through hallway rumor (“rumour-driven development”), and that fragmentation became the bottleneck. The path is explicitly optional: “if you are an adventurer you can of course leave the Golden Path… but then you will not have the same support.”

Paved road, not the only road. The road is opinionated and strongly supported; the ditch is still open, just unpaved. You win adoption by making the supported path so much easier that leaving it is the expensive choice — not by fencing the ditch.

The control spectrum: nudge, gate, net, checkpoint

Google Cloud's platform team published a taxonomy that stops people from conflating “paved road” with “mandate.” It splits control into four mechanisms — and adoption lives almost entirely in the first row:

The other three exist so you don't have to gate the everyday path: reserve hard gates for the rare things that can hurt other people, and let everything else be a nudge. Google's own warning: “a platform with too many guardrails feels like a maze of restrictions.”

Run it like a product, treat teams like customers

Every adoption play below descends from one frame: your platform is a product, its users are customers, and adoption is the only real measure of success. Team Topologies makes this concrete with the Thinnest Viable Platform — the smallest set of APIs, docs, and tools that measurably accelerates other teams. Not the biggest platform you can build; the thinnest one that actually helps.

Camille Fournier, who ran platform engineering at scale, punctures the most seductive trap here: the captive audience. When you're “the only option,” it's tempting to assume adoption is guaranteed. It isn't — that assumption is exactly how “platform teams end up with several overlapping half-finished products.” Her framing of the actual job: the product work is not “tell everyone they have to use it.” It's finding “what will make it easy for them to migrate,” paired with real incentives — a higher SLO, easier access to compute — that make moving obviously worth it.

The adoption plays — 12 moves that drive pull

No single play carries adoption; these stack. The first eight create the pull that makes teams want the road, the next three move existing work over once the road is genuinely better, and the last is the rare hard edge you reach for only after pull is real. The table is the catalog; the figure shows where each play sits on the adoption journey.

That's the pattern and the plays — the working model. If you just need to act, stop here: build a genuinely-easier default, run it like a product, and let teams pull. The rest is proving it took, and the ways it fails.

How to know it's working — measure usage, not installs

The fastest way to fool yourself is to count the wrong thing. Portal logins and “templates available” are vanity metrics; they tell you nothing about whether the road is carrying traffic. Three signals matter more.

Active usage — unique developers actually running the workflow (CLI commands, API calls, pipeline runs), not who installed it once. A rising count means the platform is in the daily flow; a flat one means shelfware with a landing page. Percent of services on the golden path is the headline adoption number and the best leading indicator of whether delivery metrics will improve — and because you win by pull, the honest version is the voluntary rate: if the path is optional and 80%+ choose it, you've succeeded; under 50%, the problem is the path, not the people. DevEx signals (from the authors of SPACE) predict whether people want to stay: feedback loops, cognitive load, and flow state — measured with focused surveys plus system signals, not gut feel.

Where paved roads fail — the anti-patterns

What to actually do Monday

If you're a platform team staring at low adoption: stop trying to push, and go make the road worth choosing. Pick one lighthouse team and build the golden path around their real Day-2 pain. Turn it into a one-command template. Make it the default for new work, with a documented off-ramp. Market it like a product and measure the voluntary percent on the path, not the logins. Reserve the mandate for the security and compliance floor — and even there, pave it so compliance is the easy default.

The whole pattern reduces to one uncomfortable truth: you don't have authority over these teams, and the fix is not to get more authority. It's to build something so obviously better to use that authority becomes irrelevant. Netflix said it in a sentence a decade ago, and it still holds — don't mandate the road; make it a far better experience than the alternative, and let people choose it.