The Headcount Paradox Nobody Talks About
By now, you’ve probably noticed that nearly every large engineering organization has a platform engineering team. Gartner called it back in 2023, predicting that 80% of enterprises would have dedicated platform teams by 2026, and they weren’t wrong. Walk into any Fortune 500 tech org and you’ll find someone whose business card says “Platform Engineer.” The problem is that while the headcount materialized right on schedule, developer adoption never quite showed up to the party.
This is where things get interesting. You can build the most elegant internal developer platform, staff it with brilliant engineers, and still watch three-quarters of your team ignore it in favor of their own scripts and workarounds. I’ve seen this pattern repeat enough times across different organizations to know it’s not a bug in execution. It’s a structural problem that most platform teams don’t adequately address until they’re already six months into wondering why adoption is stuck at 40% to 50%.
The teams that actually cracked this problem have something in common: they stopped thinking of adoption as a marketing problem and started treating it like a product problem. That distinction matters more than it probably should.
The Evidence Is Right There in the Data
The DORA State of DevOps Report 2025 dropped some genuinely compelling numbers. Organizations with mature internal developer platforms deploy 2.5 times more frequently and see significantly lower rates of change failures. That’s not marginal improvement. That’s the kind of lift that actually moves the needle on your incident response metrics and gets you out of Friday night firefighting sessions.
But here’s the twist: those numbers are dominated by the organizations that already achieved high adoption. The teams stuck in the middle, the ones with a platform that technically exists but that half their developers actively avoid, don’t see those benefits. They get the cost of maintaining the platform with almost none of the upside. It’s like paying for a gym membership and never going past the lobby.
Take Backstage. The CNCF Backstage project page shows over 3,000 companies running it in production, which is genuinely impressive for an open-source project. Except when you dig into the community discussions and internal case studies, you find that most of those deployments are running somewhere between 30% and 50% active usage among the eligible developer population. Three thousand successful implementations masking a massive adoption ceiling nobody seems comfortable discussing publicly.
Why Developers Are Choosing the Workaround
The 2025 Puppet State of DevOps survey asked a straightforward question: why aren’t developers using the platform? The top two answers were refreshingly honest. First, “too much cognitive overhead to onboard.” Second, “not integrated with our actual workflows.” Notice what’s absent from that list? Philosophical objections to the platform’s existence or fundamental disagreements about its value proposition.
Developers aren’t rejecting internal platforms because they’re fundamentally broken concepts. They’re rejecting them because the friction to adoption exceeds the perceived benefit. A developer’s immediate workflow runs in their IDE, their terminal, and their git client. If your internal platform requires context-switching through a web portal with three layers of navigation and authentication that doesn’t integrate with their usual tools, you’ve already lost half your battle before anyone even tries to use it.
I watched one organization spend eight months building an absolutely gorgeous Backstage implementation. Custom plugins, beautiful UI, integrated service templates, the whole production. Then they watched adoption plateau at 35% because developers still had to log into a separate system, navigate to the service catalog, find their component, and trigger a workflow when they could just run a shell script they’d written three years ago that lived in their home directory. The friction math didn’t work in the platform’s favor.
The winning organizations solved this by moving the platform to where developers already live. GitHub interfaces, IDE extensions, CLI tools that hook into existing command palettes. The adoption curve looks fundamentally different when you reduce context-switching from four steps to one.
The Infrastructure Decisions That Ripple Forward
Here’s something that doesn’t get enough attention in platform engineering discussions: your infrastructure tooling choices have downstream effects on adoption that go far beyond infrastructure itself. HashiCorp’s 2024 acquisition by IBM triggered pricing and licensing changes for Terraform that rippled through platform teams everywhere. A lot of organizations that built their internal platforms on top of Terraform-centric workflows suddenly faced uncomfortable conversations about licensing costs and contractual terms.
That shift pushed significant momentum toward OpenTofu, the open-source fork that hit 4 million downloads per month by early 2026. The technical reasons are solid, but the adoption story matters here too: when a platform team’s foundational tooling becomes a friction point, that friction propagates upward to every developer trying to use the platform built on top of it. Suddenly your onboarding story includes “and by the way, here’s why we switched away from the tool you saw in that blog post.” That’s not a selling point.
The lesson here isn’t about Terraform specifically. Platform decisions that feel like infrastructure concerns actually have direct effects on user experience and adoption. When you’re evaluating the tools and frameworks that will underpin your internal platform, that downstream adoption impact belongs on your evaluation rubric right alongside technical merit and operational overhead.
What Actually Moves the Needle
The platform teams I’ve watched reach 70% to 80% adoption share a few consistent patterns. They obsess over the first-use experience with an intensity that borders on fanatical. They measure activation metrics like they’re tracking production SLOs. They build integrations into existing workflow tools rather than asking developers to add new tools to their already-crowded stack. And they iterate based on actual usage telemetry, not just on feature requests from leadership.
They also tend to accept that 100% adoption probably isn’t realistic or even necessary. The goal isn’t unanimous adoption. The goal is getting adoption high enough that the platform’s positive effects become self-reinforcing. When enough developers are using the platform to drive meaningful deployments and incident response, when that becomes the cultural norm and the workarounds become the outliers, adoption stops being a problem you have to solve and becomes a natural emergent property of your engineering culture.
If you’re sitting in a 40% adoption situation right now, the good news is you’ve already done the hard part. Your platform exists. Your infrastructure is in place. What you’re missing is optimization for human friction, and that’s something you can actually fix. Start measuring adoption like you’d measure any user-facing product. Find three developers who actively avoid your platform and schedule honest conversations with them. Read their feedback as design requirements rather than excuses. That’s where the real work happens.