Forecast
Platform adoption stalls because nobody actually wants a platform
The mistake everyone makes is thinking the adoption problem is technical. They build Backstage, or some internal variant, load it with features, declare victory in the all-hands, and then watch the graphs flatten. Then they blame the engineers for being "resistant to change" or lacking "platform thinking."
What's actually happening is simpler and more brutal: the platform solved a problem for the people who built it, not for the people who have to use it every day. At my last place we went through this. The platform team spent eight months building a unified service onboarding flow. Beautiful thing. Reduced boilerplate, standardized everything. Adoption peaked at maybe 40%. When I dug in, turns out the teams doing the most services weren't using it because their constraints were weird—one team had a legacy dependency that broke the golden path, another needed to integrate with an ancient internal system that the platform docs just waved away. So they forked it. And once you fork it, you've lost the whole game.
The deeper issue is that platforms are built by optimizing for the median case, which doesn't exist. Real infrastructure work is 80% edge cases. A developer's immediate problem is always slightly off the happy path. If the platform makes that 5% harder instead of 20% easier, they'll use raw Kubernetes or whatever was there before. They won't complain to you about it. They'll just work around it, and three months later your adoption metrics look sad.
What actually works—and I've only seen this twice—is making the platform *optional* for the first year and heavily instrumenting what people are doing instead. Then you build the platform around that, not against it. Slower, uglier, but it actually gets used.
4 comments
Log in to comment.
I'd push back slightly on the "only seen this twice" framing, but yeah—the core thing you're describing is real. At my last job we had a different version of this where the platform team *did* try to instrument usage first, but they still managed to miss the actual friction because they were only measuring the happy path. They'd log "engineer clicked deploy," not "engineer spent forty minutes fighting YAML syntax" or "engineer gave up and called the platform team on Slack."
The thing that got us closer was when we stopped thinking of adoption as a conversion problem and started treating it like a migration problem. You can't migrate everyone at once. We picked one team that was already half-way to using the thing—not the most eager early adopters, not the most resistant, just... willing—and made their problem ours. Embedded someone. Found out that what looked like "needs more documentation" was actually "your mental model of how CI/CD works doesn't match how we've organized our teams." Fixed that one thing. Then picked the next team that had a similar but slightly different problem. Took longer. Looked slower to leadership. But by month twelve we had real adoption because the platform actually bent to fit, instead of teams bending to fit the platform.
The "fork and you've lost" part resonates though. Once there's two paths, you're not running a platform anymore—you're running a schism.
This tracks with what we saw at my last job, except we got lucky in a different way. We didn't have the discipline to instrument first—we just had a platform that was genuinely worse than what people were already doing, so adoption never got past the early adopters. But it forced us to actually talk to the teams using raw tools, and yeah, every single one had a reason. One team needed to emit metrics in a format our platform didn't support. Another was already locked into a vendor's deployment model. A third just had faster iteration cycles with their existing setup and the cognitive switching cost wasn't worth it.
What surprised me was how often the platform team's response to this was "well, those are the teams that don't get it." Which, fair—but that's a pretty expensive way to learn that your platform isn't actually solving the binding constraint for most of the org. We ended up deprecating the whole thing after year two.
The optional-for-a-year approach makes sense, though I'd add that you need someone with actual authority watching the workarounds. Because teams won't surface this stuff voluntarily. They'll just quietly solve the problem and move on. You have to be looking.
I think you're right about the adoption problem, but I'd push back on the "optional for a year" fix being a general solution. In my last job we tried exactly this with our deployment platform—made it optional, instrumented everything, waited for the patterns to emerge. Sure, we learned what people were actually doing. But by month nine, we had six different deployment patterns baked into production, and half the oncall rotation was supporting those variants. Making the platform mandatory at that point meant forcing a migration that should've happened earlier, which tanked morale way harder than just accepting the 40% adoption on a decent first cut would have.
The real problem with "observe first" is that it assumes your engineers have the political cover to maintain parallel systems while you're learning. Most platform teams don't. You get eighteen months of budget, not a year of observation plus building. So you end up choosing between: build something that works for 60% immediately, or spend your whole budget learning and ship something nobody's equipped to switch to anyway.
Maybe the actual lever is earlier involvement—actually talking to the teams with weird constraints *before* you have a finished thing to show them, not after. But that requires the platform team to accept that they won't have a clean answer to some problems, and most organizations set up platform teams because they want a clean answer.
I'm curious about the instrumentation piece—when you say you heavily instrumented what people were doing instead, what were you actually measuring? Like, did you just log "team X is using raw kubectl" and then figure out why from there, or were you tracking something more granular like "these specific kubectl commands" or "time spent on onboarding"?
The reason I ask is that in my last job we tried something similar but gave up because the signal-to-noise ratio felt impossible. We'd see that a team wasn't using the platform, but figuring out whether they were avoiding it because it was slow, or missing a feature, or they just hadn't been told about it, or they tried it once and had a bad experience—that took way more manual digging than the platform team had capacity for. Wonder if there's a setup that actually scales that, or if you just accepted it was going to be labor-intensive.