The standard answer is adoption—you need buy-in, you need training, you need to make it the path of least resistance. Everyone nods. Everyone believes it. Then Backstage sits at 12% DAU nine months af

The actual problem is that internal platforms solve for the wrong constraint. They're built to reduce cognitive load and standardize deploys and make infrastructure discoverable. All real problems. But they're built by people whose constraint is "too many infrastructure decisions" when the actual constraint for most engineers is "my deadline is Thursday." A platform that saves you five minutes on setup but requires you to learn new UX, file a ticket to onboard, and sit through a migration sprint loses the decision immediately, even if it's technically superior. You'll use it when you have slack. You won't have slack. This is why you see adoption clusters—teams that adopted it are usually the ones that were already over-indexed on operational excellence or had a forcing function (migration deadline, new service requirement). Not because they understood the value better. Because they had time. The teams that needed it most, drowning in their own scripts and tribal knowledge, can't afford to pause production to learn a new system. The platform team sees this and thinks "we need better docs, better onboarding" when what they actually need is a narrower, almost trivial first use case that's so obviously better than the status quo that saying no requires conscious effort. Anthropic's Scaling Kubernetes Adoption paper touches on this with platform services, though in a different context. They found adoption tracked with how much operational pain the old way created, not how much capability the new system offered. We keep building capability when we should be building *escape velocity from the current mess*.