The Headcount Paradox: We Built It, But They Didn’t Come
Here’s something that keeps me up at night, and I suspect it’s keeping your VP of Engineering up at night too. Gartner called it back in 2023: by 2026, roughly 80 percent of large organizations would spin up dedicated platform engineering teams. They nailed that forecast. Walk into any sufficiently complex engineering org today and you’ll find them. Dedicated team, budget line, Slack channel, the whole setup. The problem is that none of this actually guarantees developers will use the thing.
We’ve created a curious inversion of the usual tech adoption curve. Instead of building something and watching people gradually discover its value, we’ve built the whole infrastructure, hired the teams to maintain it, established governance around it, and then watched developers find creative ways to bypass it. I’ve been in rooms where a platform team proudly demos their new microservices deployment workflow to an audience of engineers who are already three commits deep into their own ad-hoc bash script approach. The disconnect is real.
The irony deepens when you look at the data. Teams with genuinely mature internal developer platforms see deployment frequency that’s roughly 2.5 times higher than those without them, and their change failure rates drop accordingly. The DORA State of DevOps Report 2025 hammers this home with the kind of consistency that makes you wonder why adoption isn’t at 95 percent instead of hovering around 60 percent. But it is, and understanding why requires getting uncomfortable with some uncomfortable truths about how we actually build platforms.
The Cognitive Tax: Why Your Platform Feels Like Homework
I watched a senior engineer spend forty-five minutes last month trying to onboard onto our internal platform. Not trying to deploy something. Not trying to solve a problem. Just trying to understand how to get set up. At the end of it, they looked at me and said, quietly, “I could have written a deploy script in this time.” They weren’t wrong. That’s the moment you realize your platform has a problem that no amount of documentation can fix.
The Puppet State of DevOps 2025 survey uncovered the two reasons developers cite most often for skipping their internal platforms entirely: the cognitive overhead of onboarding, and the simple fact that the platform doesn’t integrate with how they already work. These aren’t minor usability quibbles. These are deal-breakers. A platform that requires developers to learn new abstractions, new terminology, and new workflows before they can ship code isn’t a platform. It’s a tax on velocity.
What makes this particularly frustrating is that it’s fixable, but fixing it requires platform teams to do something counterintuitive: listen to the people who aren’t using the platform. Not the power users. Not the early adopters who find the whole thing delightful. Listen to the people who looked at your beautiful abstraction layer and decided it was faster to kubectl apply their way through the problem. Those developers aren’t lazy. They’re efficient. And if your platform made them less efficient, that’s not a developer problem. It’s a platform design problem.
Backstage, OpenTofu, and the Age of Pragmatism
The CNCF Backstage project page shows you a framework already running in production at over 3,000 companies. That sounds impressive until you do the math. Internal surveys from the community reveal that actual active usage among eligible developers sits somewhere south of 50 percent at most large enterprises. You’ve got this developer portal framework that half your developers have basically ghosted. The platform exists. The infrastructure exists. Technically, adoption exists too, but it’s a statistical ghost.
What’s been more interesting to watch is the migration pattern around Terraform and its various cousins. When HashiCorp got acquired by IBM in 2024, the licensing and pricing shifted in ways that spooked a lot of platform teams. Enter OpenTofu, the open-source fork that hit 4 million downloads per month by early 2026. This tells you something important: developers and platform teams will vote with their feet when they feel squeezed. More importantly, they’ll move toward tools that feel like they’re built with them in mind, not around them.
The lesson here isn’t about specific tools. It’s that the successful platforms in 2026 are the ones that understand their users well enough to get out of the way. Backstage works when it’s not trying to be everything. OpenTofu succeeded because it respected the workflow people were already using. Platforms that enhance existing practices beat platforms that demand new ones. Every time.
What Actually Works: The Unsexy Secret
The platform teams that are winning right now are doing something that sounds almost embarrassingly simple. They’re starting with the workflows developers are already using and adding incremental value on top. No big abstractions. No mandatory rearchitecture. Just one small thing that makes the thing they’re already doing slightly better. Then another small thing. Then another.
This approach feels glacial to platform engineers. There’s no big reveal moment. No architectural elegance to write a conference talk about. But it works because it respects the reality that developers are not waiting around for your perfect platform. They’re shipping code today with the tools they have. If you want them to switch to something new, you need to be so clearly better that the switching cost is worth it, and you need to make that obvious immediately.
The organizations I know that have cracked adoption above 70 percent share a characteristic: they measure what matters. Not platform team throughput or configuration management efficiency or any of the usual platform metrics. They measure developer satisfaction with deployment velocity. They measure time to first commit in a new service. They measure the number of decisions developers have to make before code can ship. And then they obsess over making those numbers better. When you lead with what actually matters to developers, adoption stops being a marketing problem and starts being a natural outcome.
The Conversation Worth Having
If your platform adoption is stuck in the 40 to 60 percent range, the numbers suggest you’ve got one of the best-resourced team problems in engineering. You have the budget, the headcount, the executive support, and the infrastructure. What you might not have is alignment between what you’ve built and what developers actually need. That’s worth investigating with genuine curiosity rather than defensiveness. Your developers aren’t being difficult. They’re being rational actors in a system that hasn’t yet made the new tool obviously better than the old approach.
I’d love to hear what you’re seeing on your end. Are you running a platform team? Are you the developer sitting here thinking all of this sounds familiar? Have you figured out something that actually moved the needle on adoption? Drop me a line. The platform engineering conversation is only interesting if we’re actually being honest about where we are and what’s not working.