Platform Adoption Without a Mandate

TL;DR - The paved road works, one team loves it, and three other teams built their own thing anyway. The reflex at that point is to ask leadership to make the road mandatory, and it is the single most expensive mistake available to a platform team, because a mandate does not produce adoption. It produces compliance, which looks identical on a dashboard and is worth almost nothing, and it destroys the only honest signal you had about whether your platform is any good. Every team that routes around you is doing it for one of four reasons - they never knew, it does not fit, switching costs more than it saves, or they tried it once and got burned - and each reason has a completely different cure. None of the cures is a policy. Win the moment of creation, pay the switching cost yourself, treat breakage as your bug rather than their problem, and measure repeat use rather than teams onboarded. Then, if you still need a mandate, use it only where a road already exists and a date is genuinely non-negotiable.

I build platforms for a living, and the conversation I have most often is not about technology at all. It goes like this: we built the thing, it is genuinely good, the team we built it with is happy, and six months later a third of the organisation is still doing it their own way. What do we do?

The answer people are hoping for is a mandate. Someone senior sends an email saying all new services must use the platform, an architecture review board acquires teeth, and the adoption number goes to one hundred percent by the end of the quarter. I understand the appeal completely. It is also the point at which a lot of platform teams quietly stop being a product team and become a policy team, and they rarely come back from it.

This post is the sequel to building your first golden path. That one is about getting your first user. This one is about the much longer middle game: the road exists, some people use it, others do not, and you have no authority to compel anyone. Which, for the record, is the normal situation and not a sign that something has gone wrong.

A mandate is a loan against your own feedback

Start with what a mandate actually buys you, because it does buy something. It buys consistency by decree, quickly, without you having to improve anything. If you are decommissioning a datacentre with a hard date, that is exactly the instrument you want.

Here is what it costs, and the cost is not obvious for about nine months.

• You lose the only honest measurement you had. Before the mandate, adoption was a signal: people used the road when it was the best available option, and did not when it was not. After the mandate, usage tells you nothing about quality. You have taken your one working feedback instrument and pegged it to one hundred percent, permanently. This is the same category of self-inflicted blindness as a dashboard that goes green while nothing about how you ship has changed.
• Your users become hostages, and hostages do not file useful bugs. A developer who chose your tool tells you when it is annoying, because they want it to get better. A developer who was assigned your tool tells their manager it is slowing them down. All the friction you would have heard about directly now travels sideways, arrives as politics, and reaches you as a complaint about the platform team rather than a bug report about a template.
• Compliance is easy to fake and nobody will tell you they are faking it. Teams adopt the template and immediately fork it. They wrap your CLI in a script that undoes three of its defaults. They use the pipeline for the deploy step and nothing else. On paper: adopted. In practice: a variant you now implicitly support and did not choose, which is precisely the sprawl mechanic that eats a paved-road portfolio.
• You spend credibility you cannot re-earn. A platform team that asks for authority is telling the organisation it could not win on merit. Even when the request is granted, everything after it is coloured by it, and the next genuinely voluntary thing you build starts from a worse position.

The deeper problem is that a mandate answers the wrong question. It answers “how do we get the number up?” when the question that matters is “why did a professional engineer, looking at our road and their alternative, pick the alternative?” That person is not being difficult. They did an expected-value calculation with information you do not have, and you have a chance to go and read it.

Routing around the road is data, not disobedience

Every non-adopter I have ever interviewed falls into one of four buckets. They look the same from the outside - a team not using the platform - and they need four different responses. Diagnosing which one you are looking at takes about twenty minutes per team and is the highest-return work available to you.

• They never knew it existed. Depressingly common, and always larger than the platform team’s estimate. You announced the road once, in a Slack channel, eight months ago, to an audience that has since turned over by thirty percent. The engineer who scaffolded that new service in March searched the internal wiki, found a 2023 page, and followed it. There is no resistance here at all. There is a distribution problem, and you fix it with plumbing rather than persuasion.
• It genuinely does not fit. Their workload is a batch job and your road is built for long-running HTTP services. They have a latency budget your default sidecar blows on its own. They need a runtime you do not support. This team is not a laggard, they are a requirements document with legs, and the correct answer is either to widen the road deliberately, to build a second one, or to say honestly that they are off-road and supported in a different way. What you must not do is force a bad fit, because you will own the outage.
• Switching costs more than it saves, from where they stand. The most common bucket among competent teams, and the one platform people are worst at hearing. They believe you. They agree the road is better. They also have twelve running services, a quarter of committed roadmap, and a migration that costs them three weeks to gain a benefit that mostly shows up in somebody else’s numbers. Their calculation is correct.
• They tried it and got burned. The path broke during their onboarding, they filed a ticket, it sat for a week, and someone eventually explained that they were holding it wrong. This is the expensive one, because it is not a fact about your tool any more, it is a fact about your team, and one bad first experience gets retold at lunch for two years.

Ask directly, and ask the engineer rather than the manager: what did you consider, and why did you pick the other thing? Developers are refreshingly willing to answer that question when it is not loaded, and the answer is worth more than any survey. This is the same unglamorous user research that should have started in a platform team’s first 90 days, except that now you have a product in the world and the answers are about something real.

Count repeat use, not teams onboarded

Before you can fix adoption you need a number that is not lying to you, and most adoption metrics are lying. “Teams onboarded” counts a one-off event forever. “Services on the platform” counts the migration your VP sponsored. “Portal accounts created” counts nothing at all, which is one of several reasons a portal is not the same thing as a platform.

The three numbers I actually trust:

• Share of new things created on the road. Of all services, jobs and environments created in the last quarter, what fraction came off the template? This is the leading indicator, because new creation is where switching costs are near zero. If new work is not choosing you, nothing else you measure matters.
• Repeat use by the same team. Did the team that adopted it in March use it again in June without anyone from your team in the room? Adoption is retention, not signup. A team that used the path once and quietly stopped is the clearest bug report you will ever receive, and it never gets filed.
• Unassisted first success. What fraction of first-time users got to production without a single message to the platform channel? This is the pillar’s hello-world-in-a-day test turned into a running metric, and it is the one that predicts everything else. A road that requires a guide is not a road.

One number I would deliberately not put on a dashboard: percentage of the estate migrated. It is a portfolio fact, it moves slowly, it is dominated by decisions made years ago, and staring at it pushes teams toward mass-migration programmes at exactly the moment they should be winning new work instead. Borrowing the test I keep coming back to about numbers that have never changed a plan: if the migration percentage moves three points, does anyone do anything differently? Usually not.

Do the switching-cost arithmetic, then pay it yourself

For the third bucket - the team that agrees with you and still says no - there is an equation, and platform teams almost never write it down from the other side of the table.

Adoption cost is paid now, by them, in engineering time they had allocated to something their own manager is asking about. The benefit arrives later, is spread thinly, and a meaningful slice of it accrues to you: consistency, supportability, one fewer snowflake to reason about. That is a genuinely bad trade for a team under delivery pressure, and no amount of enthusiasm from a platform engineer changes the arithmetic.

You have three honest moves.

• Make the cost near zero by moving it to yourself. The strongest adoption tactic I know is unglamorous: open the pull request for them. Write the migration, run their tests, show the diff, and let them review it. A twenty-line PR from the platform team, with the tests green, converts teams that six months of evangelism did not. This is expensive per team and it does not scale beyond a few, which is exactly why you spend it on the teams whose adoption unblocks the most others.
• Wait for the moment when the cost is naturally zero. Nobody migrates a running service for elegance. They will happily start a new one on the road, or move when they are already rewriting, already splitting a service, already forced onto a new runtime. Adoption is opportunistic. Keep a list of who is about to start something and be there that week, rather than running a campaign against a calendar of your own invention.
• Make the benefit land on them, visibly and soon. “It is more consistent” is a benefit for you. “You stop maintaining your own pipeline, your on-call gets the standard runbook, and your service shows up on the dashboard on day one” is a benefit for them. If the road cannot pay a team back inside a quarter, be honest that it is not ready to be adopted broadly yet, and go and make it pay back faster.

If none of those three is available for a given team, the honest conclusion is that they should not migrate right now. Write that down, put a date on when to revisit, and move on. A deliberate not-yet is a much better artefact than a stalled campaign.

Win the moment of creation

Here is the structural insight that matters more than any tactic in this post: almost all adoption is decided in the first ten minutes of a new thing existing, and most platform teams are not in the room for those ten minutes.

An engineer starting a new service has a decision to make and about four minutes of patience. Whatever is closest to hand wins. Today, what is closest to hand is usually git clone of the last service they built, because that definitely worked. Your road only wins if it is the thing they hit first.

• Be the default at scaffold time, not an alternative to it. One command, in the docs a new joiner actually finds, in the repo template, in the onboarding checklist. If choosing the road requires knowing the road exists, you have lost most of the population already.
• Delete the old on-ramps. As long as the 2019 wiki page still describes how to hand-roll a pipeline, people will keep following it, and they will be right to, because it is written down. Archive it, redirect it, or put a banner on it. Stale documentation is a competing product with excellent SEO inside your company.
• Get into the moment mechanically. A repo-creation hook that offers the template. A bot that comments on the first infrastructure pull request in a new repo. A new service entry point that is one command rather than a page of prose. These feel like small conveniences and they are worth more than a quarter of evangelism.
• Never make the first five minutes a negotiation. No access request, no ticket, no intake form, no “book time with the platform team to get started”. Every gate between an engineer’s intent and a running hello-world is a place where the old copy-paste route wins, and it wins silently.

The same logic runs through the security version of this argument: a control developers cannot satisfy by default is a tax they will route around, and the fix is a road rather than a rule. Adoption obeys the same physics as compliance. Whatever is easiest at the moment of decision is what your estate will be made of.

Trust is the actual product

For the fourth bucket - the team you burned - and honestly for everyone else too, the thing being adopted is not a template. It is a promise that when this breaks, it is your problem.

That promise is made and broken in a handful of ordinary moments.

• When the road breaks, it is a platform incident. Not a support question, not user error. If the pipeline fails for a reason the developer did not cause, that is your outage, and it should be treated with the seriousness of one, including a note afterwards about what changed. The postmortem instinct applies to platform surfaces too: the interesting question is which default failed, not who ran the wrong command.
• Honour the escape hatch you advertised. Golden path one shipped with a documented way to do the unsupported thing. If, in practice, using it triggers a lecture in a design review, developers learn that the escape hatch is decorative and that the road is a mandate wearing a nice hat. Then they stop telling you when they leave it, and you lose the map of where your platform ends.
• Change the road the way you would change a public API. Breaking a template, changing a default, moving a config key: deprecate, announce, give a window, provide the migration, and where possible do the migration yourself. Teams adopt fast when the last three changes cost them nothing. One surprise breakage undoes a year of that.
• Answer fast during someone’s first week on the road. The response time that matters is not your average. It is the response time for a team that is mid-adoption and blocked, because that is the experience that becomes the story other teams hear. Everything else can queue.

None of that is technology, which is why it so often loses to technology on a roadmap. The steady state of a platform team is X-as-a-Service, and a service is a promise about behaviour, not a bundle of artefacts.

Distribution is part of the product

Platform teams consistently under-invest in the boring machinery that tells people the road exists and is still being cared for. It feels like marketing, and marketing feels like something other people do. But a paved road nobody can find is functionally identical to a paved road that was never built.

The whole apparatus is cheap.

• A changelog with a human voice, monthly. What changed, what got faster, what broke and what you did about it. Written for developers, not for your VP.
• Peer stories rather than platform-team claims. “We shipped in a day” from an engineer on another stream-aligned team is worth ten of your slides. Ask them to say it in the channel other engineers actually read.
• Documentation that answers why, not only how. The team deciding whether to adopt needs the reasoning: why this base image, why this deploy model, what this road is not for. Docs that only cover the happy path convince nobody who has already been burned by a different tool.
• A regular open hour, on the calendar, that you keep even when nobody comes. Half the value is that it exists as a visible offer. The other half is the three genuinely surprising bug reports you get per quarter.
• Say what the road costs. Teams increasingly ask what running on the platform does to their budget, and “we do not know” is a bad answer. Attribution built into the template makes the road look like the professional option rather than an opaque one.

When this is the wrong answer

The honest off-ramps, because there are situations where everything above is either premature or naive.

• You do not have a road yet. If the paved road is half-built, undocumented, and maintained by one person between incidents, teams are routing around it because it is not ready, and no adoption strategy fixes that. Go and finish path one properly with a single design partner. Adoption work applied to an unfinished product is just a louder way to fail.
• The date is genuinely non-negotiable. Datacentre exit, an end-of-life runtime, a certificate authority disappearing, a regulator with a deadline. Here a mandate is correct and kindness is a decision to be made about how, not whether. Give the date early, provide the migration, fund the teams doing it, and take the pain of the last twenty percent yourself. Just never mandate a destination that does not exist yet: a deadline attached to an unbuilt road is how you get twelve improvised variants in a fortnight.
• The requirement is a security or compliance baseline. Some things are not optional and should not be framed as adoption at all: signed images, no long-lived credentials, audit logging. Mandate the outcome, ship the road that satisfies it by default, and pair every control with a compliant path and an expiring exception process. The mandate is on the property, never on the product.
• You are eight engineers with four services. There is no adoption problem at this size, there is a conversation. Agree one way of doing things over coffee, write it in a README, and skip the entire apparatus. Building an adoption programme here is the same category error as running Kubernetes for three services.
• The road really is worse. Sometimes the teams are right. Your template is heavier than the problem, your abstraction leaks, your pipeline takes eleven minutes to do what their four-line script does in forty seconds. If the people routing around you are your strongest engineers, that is not a culture problem, it is a review. Take the boring, obvious option seriously and consider that the correct outcome might be a much thinner road, or buying the substrate and owning less of it.

And one guardrail for the other direction: voluntary adoption is not the same as infinite patience. If a road is excellent, well distributed, cheap to switch to, and a team still refuses on taste alone, that is a conversation for their manager and yours, and the cost of the variant should be made explicit in it. Refusing to ever ask for a decision is its own failure mode. The rule I keep is simple: earn it first, escalate second, and never escalate something you have not made easy.

The bottom line

Adoption is not a persuasion problem, and it is definitely not a compliance problem. It is a product problem, arriving in the most useful form a product problem can take: a group of professionals evaluated your work against their alternative and told you, with their behaviour, what they thought. A mandate is the option that hides that answer while making the chart look better.

So go and find out which of the four things is actually happening. Fix distribution with plumbing. Widen the road, or admit the workload does not belong on it. Pay the switching cost yourself for the teams that unblock the most others. Be the default at the moment a new thing is created, and delete the old on-ramps that compete with you. Treat the road breaking as your incident. Publish a changelog like you mean it. And measure repeat, unassisted use, because that is the only number a mandate cannot manufacture.

Then ask the question that tells you where you really stand: if the mandate disappeared tomorrow, how many teams would stay? If you like the answer, you did not need it. If you do not, the mandate was never the thing holding your platform up.

If your paved road is good and half the org is still going around it - or someone has just proposed making it mandatory and you are not sure that is the right call - that is exactly the kind of problem I help teams work through. Let’s talk.