The Headcount vs. Adoption Gap Nobody Wants to Talk About
Gartner’s 2023 prediction has come true, but not in the way most people hoped. Yes, roughly 80% of large engineering organizations now have a dedicated platform engineering team. The budgets materialized. The org charts got redrawn. The job descriptions went out. But something went sideways between the hiring and the actual usage, and if you’ve been paying attention to real-world deployments over the past year, you already know what I’m talking about.
Walk into most enterprises right now and you’ll find a well-intentioned platform team, probably understaffed, maintaining an internal developer platform that the majority of engineers still aren’t using. The numbers vary depending on who you ask and how you measure, but the pattern is consistent: adoption hovers somewhere between 40 and 60% in the places where people bother to measure it at all. Meanwhile, the platform teams are somewhere between frustrated and exhausted, wondering why their carefully built abstraction layer isn’t getting the traction they expected.
This isn’t a failure of platform engineering itself. The concept works. The data backs it up. According to the DORA State of DevOps Report 2025, organizations with mature internal developer platforms deploy 2.5 times more frequently and see significantly lower change failure rates than their counterparts. That’s not marginal improvement. That’s the kind of performance delta that actually affects business outcomes. So the disconnect isn’t about whether platforms are valuable. It’s about why developers won’t use them.
The Real Reasons Developers Walk Around the Platform
I’ve spent enough time in post-mortems and team retrospectives to know that when developers avoid something you’ve built, it’s rarely because they’re being difficult. More often, it’s because you’re asking them to add steps to their workflow. The Puppet State of DevOps 2025 survey confirmed what seasoned platform engineers already suspected: the top two friction points are cognitive overhead during onboarding and misalignment with actual developer workflows. Not features. Not aesthetics. Not even bugs. The problem is friction.
Picture a backend engineer on a team that’s spent three years optimizing their local development loop. They have bash scripts they wrote themselves. They have muscle memory around a particular deployment process. They know which Slack channels to post in when things break. Then someone hands them a new platform and tells them it’s going to make their life better. Learning curve. New mental model. New commands. New documentation. New support channels. The promise is easier deployment. The reality, on day one, is more cognitive work.
This is the gap that kills adoption, and it’s genuinely hard to close because closing it means understanding your developers’ actual workflows, not the ones you think they should have. It means integration work that’s often unglamorous and never feels done. It means your platform team is now doing archaeology on dozens of teams’ local processes instead of just building features.
Why Backstage’s Growth Doesn’t Match Its Usage Numbers
Backstage is one of the most serious attempts to solve the internal developer portal problem at scale. Spotify built it out of necessity, donated it to the CNCF, and now over 3,000 companies claim to be running it in production. That’s real traction. But if you dig into the community conversations and internal surveys that circulate in platform engineering circles, you start seeing something interesting: many of those 3,000 installations have sub-50% active usage among developers who could be using them.
The CNCF Backstage project page will tell you about the ecosystem. It’ll show you plugin counts and enterprise adopters. But it won’t tell you that in many organizations, Backstage became the source of truth that only platform teams and a handful of early adopters actually consult. Everyone else kept using their own internal wikis, their curl commands, their tribal knowledge.
This doesn’t mean Backstage is bad. It means that software solving a problem elegantly is only half the equation. The other half is adoption, and adoption requires solving problems your developers actually experience, in the exact moment they experience them. Backstage’s architecture is solid. Its plugin model is thoughtful. But if it doesn’t intercept developers at the point where they’re already struggling, they’ll work around it.
The OpenTofu Moment and What It Reveals About Tooling Decisions
When HashiCorp was acquired by IBM in 2024, the licensing and pricing changes that followed sent ripples through platform teams everywhere. Terraform, which had become the de facto standard for infrastructure-as-code in platform engineering stacks, suddenly looked less certain. The open-source fork, OpenTofu, went from interesting alternative to viable replacement in the eyes of many organizations. By early 2026, OpenTofu exceeded 4 million downloads per month. That’s not radical fragmentation. That’s a significant portion of the IaC market voting with their feet.
What’s instructive here, for the broader platform engineering conversation, is that developers and platform teams will migrate away from tooling they don’t feel they own. They’ll invest time and energy into alternatives, even less mature ones, if it means regaining control over their destiny. This instinct extends beyond licensing. It shapes how teams think about adopting new platforms. If your developers feel locked into something by corporate decree, adoption will suffer. If they feel like they chose it, even in hindsight, engagement changes.
What Actually Moves the Needle on Adoption
So what does work? Based on what I’ve observed across teams that have actually shifted adoption rates meaningfully, it comes down to a few principles that sound simple but require discipline to execute. First: meet developers where they are. If your team uses GitHub heavily, your platform integrations should be in GitHub. If half your deployments happen from CI/CD, your platform needs a first-class CI/CD story. Don’t ask developers to learn a new tool for basic tasks they already have solved.
Second: make the platform’s value obvious within the first interaction. Not the fifth one. Not after reading the documentation. Not after attending a training session. The platform should demonstrate why it exists during onboarding, not after it. This means ruthlessly cutting away anything that doesn’t directly serve an immediate need.
Third: platform adoption is a long game. The teams that have moved from 30% adoption to 70% adoption typically didn’t do it with a big launch. They did it with consistency, good observability into what’s blocking adoption, and the willingness to change the platform based on feedback rather than shape the feedback to fit the platform.
If you’re building or managing a platform right now and your adoption numbers are sitting at that stubbornly familiar 40 to 50% range, you’re not alone. You’re also not at an impasse. The gap between where you are and where you want to be usually comes down to understanding what’s actually getting in developers’ way, and having the organizational flexibility to address it. What’s blocking adoption on your platform? I’d genuinely like to hear what you’re seeing in the field.