The Headcount Trap
In 2023, Gartner made a prediction that looked pretty straightforward: by 2026, 80% of large engineering organizations would have a dedicated platform engineering team. If you’re reading this in 2026, you’ve probably noticed that prediction came true. Most enterprises did build those teams. They hired the senior architects, the infrastructure specialists, the developer experience evangelists. The org charts shifted. Budgets got allocated. Slack channels were created with the kind of naming convention that suggested someone was very serious about this.
So why am I sitting here, having just spent two hours talking to a platform team lead at a Fortune 500 company who told me they have 47 people working on their internal developer platform and somehow fewer developers using it this quarter than last? The answer isn’t complicated, but it is humbling. Building the team is the easy part. Getting developers to actually use what you built turns out to be a completely different problem.
The real story isn’t the presence of platform teams. It’s their impact. And right now, at most places, that impact exists at about 60% of where it should.
The Productivity Paradox That Nobody Talks About
Here’s where things get interesting. The DORA State of DevOps Report 2025 found something concrete: teams with mature internal developer platforms deploy 2.5 times more frequently and have significantly fewer failed deployments compared to teams without them. That’s not marketing speak. That’s measurable, empirical advantage. The kind of data that should make every engineering leader sit up straight.
Except here’s the trap nobody advertises: that 2.5x advantage only exists if developers actually use the platform. If your teams bypass it 40% of the time, you’re looking at very different math. You’ve built something powerful and then watched half your organization decide to go around it because the friction of using it exceeded the friction of not using it.
I’ve watched this play out enough times to recognize the pattern. A team builds something genuinely useful, thoughtfully designed, architecturally sound. And then they’re shocked when adoption plateaus at around 55-60% despite months of evangelism, lunch-and-learns, and carefully crafted documentation.
Why Backstage Adoption Looks Good on the Slide Deck
The CNCF Backstage project page will tell you that over 3,000 companies are using Backstage in production as of late 2025. That number is real. Spotify built something genuinely elegant, the open-source community embraced it, and it solved real problems. But there’s a quieter statistic that doesn’t make it into the conference talks: at many of those organizations, active usage among developers hovers below 50%.
I talked to someone at a well-known tech company whose Backstage rollout hit 52% adoption and then just stopped climbing. Not because the software was bad. Not because the team didn’t try hard enough. They hit a wall that’s surprisingly common: the people who benefited most from centralized developer tooling were already finding workarounds, and everyone else looked at their existing workflow, looked at learning Backstage, and made a rational decision.
What keeps coming up in community discussions is that companies deploy Backstage, Platforms.sh, and homegrown solutions at respectable scale, but the gap between “deployed” and “actually used daily by the developers who benefit most” stays stubbornly large. It’s like building a beautiful transit system but watching people drive anyway because parking is still easier.
Cognitive Overhead Beats Architecture Every Time
Last year’s Puppet State of DevOps survey landed on something specific: developers cite two reasons most often for bypassing their internal platform. First, learning it requires too much cognitive lift for the perceived benefit. Second, it doesn’t integrate with how they actually work. Not how they’re supposed to work. How they actually work.
This distinction matters more than it sounds. A developer can understand why a platform exists in theory and still choose to skip it in practice because the mental model doesn’t map to their daily workflow. You’re asking them to change their muscle memory, their deployment ritual, years of habits and workarounds that do work, even if they’re not optimal.
I watched a platform team spend six months building something with the workflow abstraction they thought developers should want. When adoption stalled, they finally asked developers what they actually wanted. Turns out developers wanted something closer to what they were already doing, just with less clicking and fewer environment variables to manage. The team had to rebuild significant pieces because they’d optimized for elegance instead of continuity.
The hard truth: your internal platform will lose to anything simpler, even if it’s objectively worse, as long as it’s faster to use and requires fewer context switches. Cognitive overhead is a feature killer that no amount of documentation can overcome.
The Terraform Moment and What It Reveals
When HashiCorp’s acquisition by IBM closed in 2024, the ripple effects on Terraform licensing and pricing were immediate. Platform teams who’d standardized on Terraform for infrastructure-as-code suddenly found themselves asking uncomfortable questions. Pricing changed. Licensing got stricter. Open-source alternatives became more interesting. OpenTofu, the community fork, crossed 4 million downloads per month by early 2026.
This migration wave reveals something important: when your platform depends on tooling you don’t control, and that tooling changes in ways that feel adverse, adoption becomes a liability instead of an asset. Teams that had finally gotten developers to use standardized infrastructure tooling suddenly had to decide whether to stick with it or migrate. Some did migrate. Some splintered. Some maintained multiple paths.
Adoption isn’t just about usage. It’s about trust, continuity, and the confidence that the tooling you’re asking people to build habits around won’t suddenly shift underneath them. The platform engineering teams doing best right now aren’t pretending they control the entire landscape. They’re building with open-source first, making intentional technology choices that won’t become licensing nightmares, and being honest about dependencies.
The Path Forward Is Smaller Than You Think
After years of watching internal platforms either stick or get quietly abandoned, I’m convinced the adoption problem isn’t about features or architecture or team size. It’s about matching the cognitive and friction cost to the real benefit developers perceive. That balance point is usually smaller than platform teams think it should be.
The teams making real progress in 2026 are ruthlessly prioritizing the workflows that matter most instead of trying to be everything to everyone. They’re meeting developers where they actually work instead of insisting developers come to them. They’re measuring adoption not by who has access but by who actively uses the platform as their first choice, not their backup plan. They’ve also abandoned the idea that quarterly launch events and documentation blogs create adoption. Adoption happens when using the platform is legitimately easier than not using it.
If you’re building a platform or living inside one that’s stuck below 60% adoption, the next move probably isn’t more features. It’s probably a hard conversation about whether developers actually want what you’ve built, or whether they want something smaller and faster that does 60% of what the platform does.
What’s your platform adoption story? Where’s the friction actually coming from at your organization? I’d genuinely like to hear it.