Usage Can Be Mandated, Adoption Must Be Earned
Same platform, same software. Spotify hit 99% adoption. Many others got stuck around 10%.
Standing up a platform team feels like the hard part:
- ✅ Hire the engineers
- ✅ Pick a tool
- ✅ Build the golden paths
- ✅ Announce it at the next all-hands
Job done!
Then six months pass. Half the org still files tickets the old way. The platform team spends sprints defending why the new thing matters instead of shipping. A VP asks why the investment hasn’t moved a single velocity number.
Standing up the team was never the hard part. It’s getting people to want what got built and that part rarely shows up on the roadmap.
One Platform, Two Outcomes
Spotify’s Backstage is the internal developer platform most of you know, partly because Spotify open-sourced it and partly because it’s become the most widely adopted platform of its kind. Backstage’s public adopters list runs past 280 organizations, and a 2025 DX survey of 180 companies put Backstage at 89% market share against SaaS competitors and 67% overall penetration. What you hear less often is how differently adoption goes depending on who’s running the rollout as Helen Greul, who then led engineering for Spotify’s platform team, pointed out.
At Spotify, Backstage usage was never mandatory. Greul describes the rollout as roughly a year of deliberately unglamorous work. Spotify’s own adoption playbook fills in the mechanics: central-team engineers ran lunch-and-learns (a term I hadn’t heard since the early 2000s), embedded with adopting squads for a sprint or two, built hack days around the platform, held quarterly show-and-tells, and sent weekly digest emails showing teams how their own usage metrics had changed. Spotify also tracks time to a new engineer’s 10th merged PR as an onboarding-speed indicator. About two years into consolidating golden paths, Greul told The New Stack that number had dropped from months to weeks.
The result, she reckons, was near-universal: about 99% of Spotify’s engineering org adopted Backstage voluntarily. Her explanation wasn’t the tooling: “With a product that’s built for developers, with empathy for developers, they recognize the value, and it’s just easier for them to use what’s already available than spinning something weird on the side.”
Then the same interview turns to what happens elsewhere. Greul said many other companies adopting Backstage get stuck around 10% adoption; hitting a road bump where the rollout isn’t as easy as hoped and adoption stalls before clearing proof-of-concept. They start from the same open-source project and the same golden-path philosophy Spotify did, even though what Spotify runs internally today is a heavily customized instance built on top of it.
What differs most is how it got introduced.
Greul’s account doesn’t explain why those rollouts stall at 10%, just that many do. But it aligns with the wider pattern: PlatformEngineering.org’s 2025 survey found more than a third of organizations with platform teams still lean on mandates and top-down pushes to drive adoption — the same forcing move Spotify deliberately chose not to make.
Product Thinking, Not Rollout Thinking
PlatformEngineering.org’s 2025 maturity baseline (published January 2026), drawn from the State of Platform Engineering Report Vol. 4’s survey of 518 practitioners, shows the same pattern at industry scale. More than a third of organizations with platform teams still rely on mandates and top-down pushes to drive adoption; fewer than one in five have reached the point where developers voluntarily contribute back instead of just tolerating the platform. The organizations that break past that ceiling share a handful of habits and none of them about the technology.
Three track closely to what Spotify was already doing on instinct.
I’ve sat on both sides of this, often within the same year. As a product leader with a platform team, I’ve had to decide whether an internal tool was worth building at all while watching a team ship something technically sound that nobody touched because we skipped the interviews and went straight to the build. On the engineering side, I’ve also been the one who found a new platform live one morning. No lunch-and-learn, no case made for why the old way was going away–just suddenly new. I’m not always the old curmudgeon stuck in my ways, but my team and I probably just kept doing what we were doing because nobody had mandated the change yet.
No Version of This Is Fast
Earning genuine, voluntary adoption doesn’t just happen. Spotify’s timeline was roughly a year of deliberate onboarding before adoption cleared 90%. That’s inside a company with an unusually strong inner-source culture already in place. Most organizations don’t start from that baseline, which means the honest estimate runs longer, not shorter.
That’s where some leaders watching a platform investment and wanting a faster answer get twitchy. There isn’t a shortcut that turns a mandate into genuine adoption faster than the slow way does. A mandate can move the usage number in a quarter, but it can’t make the platform the thing developers reach for instead of route around. Chasing the fast number optimizes for exactly the wrong thing: a platform team that reports high usage while still fielding the same “why do I have to use this” conversations eighteen months in.
The teams that land this take the slower path because they’re measuring the outcome they actually want: teams choosing the platform, not being required to use it.
Standing up a platform team is never the finish line. The finish line is habitual usage when nobody’s watching and there’s no version of that earned in a single quarter.
Before the next platform investment gets greenlit, ask whether anyone on the team is accountable for developer satisfaction the way a product manager is accountable for customer satisfaction. If the answer is no, start there before writing another line of infrastructure code.
