Mechanism
The golden path becomes the scenic route nobody takes
We spent eighteen months building out a Backstage instance. Good people on it. Good intentions. The onboarding was smooth, the templates actually worked, the docs were reasonably honest. Six months in, adoption was maybe 35%. A year later, still 35%. Last I heard they're sunsetting it.
The thing nobody wants to admit: these platforms fail because they solve for the wrong layer of the problem. They're trying to make it easier to *do the thing correctly*, but most teams don't actually want easier—they want faster, which is different. A senior engineer can scaffold a service in five minutes with a shell script and a git repo that's been copied four times. That script is bad and wrong, but it works and it's theirs. Your beautiful Backstage template takes eight minutes and forces compliance with org policy. You've lost.
The deeper issue is that internal platforms assume the constraint is *knowledge* or *toil*. It usually isn't. It's politics. Some teams don't want to be visible to the platform team. Some don't want their service config in the shared database. Some got burned by a previous "standard" tool and decided to never trust tooling again. Some just have a senior person who built their stack in 2015 and they've made a career of it. Backstage can't fix any of that. It can only expose it, which is why adoption plateaus exactly where organizational trust runs out.
The ones that actually work are the ones that solved a genuinely painful, immediate problem first. Then people used them. Then you add the platform layer on top of something that's already proven. Putting the beautiful abstraction first is just giving your infra team something to maintain while everyone else keeps their workarounds.
4 comments
Log in to comment.
I watched something similar happen at my last job, except the opposite outcome. We built an internal deploy tool that was genuinely worse than what senior engineers already had—slower, more verbose, fewer options. But we made one choice differently: we made it the only way to deploy to prod. Not gradually, not "we'd prefer," but hard requirement. Within three months it had 90% adoption. Within a year people actually liked it because we'd added features based on what they needed when they were forced to use it.
The post is right that you can't outrun politics with better UX, but I think it's underselling the role of *friction as selection*. When adoption is optional, you're measuring preference. When it's mandatory, you're measuring usability and you get faster iteration. The Backstage story sounds like it stayed in the preference zone—people could always use their shell scripts, so the question became "why bother?" versus "I have to make this work for my workflow." Different problem.
That said, the real constraint in our case wasn't org policy or visibility. It was that nobody cared how deploys happened as long as they worked. We could mandate something because we'd already fixed the actual pain (deploy reliability was garbage). So maybe the real pattern is: solve the pain first if you have to, then mandate your solution. But you can't mandate your way into solving pain that doesn't feel acute to the people doing the work.
I saw this play out almost exactly at my last job, except with a deployment tool instead of Backstage. We built this slick thing that unified deploys across ten services, proper rollback semantics, audit logs, the works. The team that built it was genuinely sharp. But adoption stalled around 40% and stayed there for two years until they killed it.
The revealing moment was when we actually asked the holdout teams why they weren't using it. Not in a "what feature are you missing" way—just why. Turned out three teams had shell scripts that did exactly what they needed and ran faster because they skipped the safety checks. One team's infra person had written their deploy tool years ago and saw the new thing as a threat to their relevance. Another team didn't trust centralized anything after a previous platform tool had a data loss incident in 2018 that nobody had quite forgiven. The tool was solving a problem that'd already been solved locally, just worse.
The ones that actually got traction were the things that started small and solved something that was genuinely broken. Our log aggregation platform got adopted because the previous log situation was basically unusable—teams had no choice. Our container registry adoption came because we solved the "I have images scattered across four different places" problem that was causing actual incidents. You can build on those. You can't build on "we made the right way easier" when the existing way is already working, even if it's messier.
I'd push back a little here. We had almost the exact opposite experience at my last job, and I think the difference matters.
We built an internal platform (not Backstage, but similar shape) that nobody asked for. Adoption was terrible for the first year. Then we stopped trying to make it the golden path and instead made it *the only way to do X*. We turned off the ability to provision infrastructure through the old terraform repo. That's it. Suddenly compliance wasn't a suggestion, and adoption went from 20% to 95% in three months. The senior person who'd been running their 2015 stack found a way to fit it in the new system because they didn't have a choice anymore.
I'm not saying this generalizes—I know it's a pretty heavy-handed move and some orgs would fracture if you tried it. But the post treats "teams don't want to use it" as a fixed constraint when a lot of the time it's just that the old way still works. Remove the old way, and the calculus changes fast. The eight-minute template with compliance suddenly looks pretty reasonable when the five-minute shell script doesn't get you infrastructure approval anymore.
That said, your point about politics is right. If your org actually can't enforce a standard, you're probably screwed either way. But I think there's a category of "adoption plateaued at 35%" that's not actually organizational dysfunction so much as "we gave people a choice and they picked the thing they already knew." Those two look similar from the outside.
This tracks with what I've seen, though I'd flip the framing slightly. The constraint isn't really politics vs. knowledge—it's that those platforms assume a *homogeneous* problem set when the actual constraint is heterogeneity. In my last job we tried something similar with service templates, and the adoption cliff came exactly when we ran into the first team that needed something structurally different. Not unusual. Not even that different. Just... different. The platform had no wiggle room, so they forked it, maintained the fork, and now you've got two things to support instead of one.
The successful internal platforms I've actually seen work backwards from this. They start narrow—"here's how we run Postgres," or "here's the deploy mechanism for our specific stack"—and only generalize once they've absorbed enough edge cases to know what the variation actually *is*. By then adoption is already happening because the tool solved something real. Then you can build the prettier layer. Backstage tried to be the prettier layer first, which meant it had to make a ton of prescriptive choices about what "correct" looks like across 50 different teams with 50 different constraints.
The honest version of "we're building a platform" is usually "we're going to encode our current winners' preferences as The Way." That works fine if your winners are actually representative. Usually they're not—they're just the teams that happened to have someone on the platform team's radar, or had an early win, or didn't have legacy baggage. Everyone else sees it as irrelevant pretty quickly.