The Headcount Victory That Masks a Deeper Problem
Gartner called it back in 2023. By 2026, they predicted, 80% of large engineering organizations would have a dedicated platform engineering team. That forecast came true. Walk through any Fortune 500 tech company today and you’ll find them. Platform teams exist. They have budgets. They have roadmaps. They have Slack channels with thousands of members.
Here’s what also exists: a 40% adoption wall that nobody wants to talk about in quarterly business reviews. Your platform team built it. Your developers won’t consistently use it.
This isn’t a technology problem. The tools work. Backstage, the CNCF-graduated developer portal framework that Spotify open-sourced years ago, is running in production at over 3,000 companies. That’s real adoption at scale. But internal surveys from those same enterprises tell a different story. Active usage among eligible developers hovers around 50% or lower. People built it. People didn’t use it the way it was supposed to be used.
What the Data Actually Shows
The DORA State of DevOps Report 2025 gives us hard numbers on what mature internal developer platforms can deliver. Teams with them deploy 2.5 times more frequently. Their change failure rates drop significantly. These aren’t marginal gains. This is the difference between shipping once a week and shipping five times a week. It’s the difference between 20% of changes breaking production and 5%.
So the platforms that people actually use work. The problem is that most developers at most enterprises still aren’t using them consistently. They use them for discovery. They use them when onboarded to a new service. Then they revert to what they already know: checking a wiki that’s three years out of date, running commands they found in Slack threads, asking the one person who still remembers how that system works.
The math is clear. If a mature internal developer platform was actually being used by your entire engineering organization, you’d see it in your metrics. You’d know it. You wouldn’t be reading an article wondering whether you have an adoption problem. The fact that you are reading this means your team is probably in the 60% camp where adoption stalled.
Why Developers Walk Away
Platform teams have asked thousands of developers this question in interviews and surveys. The answers are consistent. The top two reasons developers bypass internal platforms aren’t “it’s not good enough.” They’re “it’s too much work to onboard” and “it doesn’t fit into how I actually work.”
Think about onboarding friction. Your platform team spent six months building a portal. They documented it, recorded videos, ran workshops. The first-time developer experience requires understanding your authentication system, your service mesh configuration, your templating language, your naming conventions, and your deployment pipeline. That’s five separate mental models before they write a line of business logic. Compare that to running a command they found three years ago that still works. The choice is obvious.
Integration friction runs deeper. Your platform team built something that lives in a portal. Your developers live in their IDE, their terminal, their CI/CD system, their Slack channel. They want to know if the platform connects to those places. Does it have a CLI that works offline? Does it integrate with their git workflow? Can they trigger deployments from their editor? If the answer to most of those questions is no, you’ve built a separate system that developers have to switch context to use. Context switching is a tax on productivity. Developers vote with their feet.
The Infrastructure Economics Have Shifted
Something else changed in 2025 that’s pushing platform engineering in new directions. HashiCorp’s acquisition by IBM in 2024 triggered licensing and pricing changes to Terraform that were significant enough to move the needle. Large organizations watched their Terraform costs climb. They looked around for alternatives. OpenTofu, the open-source fork that maintains compatibility with earlier Terraform versions, hit 4 million downloads per month by early 2026.
This matters because it signals something broader. Platform teams are increasingly making decisions based on total cost of ownership and operational lock-in, not just feature completeness. When your IaC tool costs climb unexpectedly, you start questioning other platform infrastructure decisions. You start asking harder questions about vendor dependencies. You start wondering if the portal you paid consultants to customize is worth the maintenance burden.
The best platform teams I’ve talked to in the past year have started treating their internal platform less like a product that needs adoption and more like infrastructure that needs to be invisible. They’re pushing intelligent defaults into CI/CD pipelines. They’re embedding platform capabilities into developer workflows at the point where they’re needed, not in a separate place where developers have to remember to look. They measure success by reduced toil in production, not portal login counts.
What Adoption Actually Requires
If you’re sitting on a 40% adoption platform and wondering how to move the needle, the solution isn’t building more features. It’s usually not even better documentation. The platform teams that have moved from 40% to 70% or 80% adoption did something different. They made using the platform easier than not using it.
That means embedding platform guardrails into your CI/CD system so developers can’t accidentally circumvent them. It means providing a CLI that works as smoothly as the shortcuts developers already use. It means going to where developers work, not asking them to come to you. It means ruthlessly cutting cognitive overhead from the onboarding experience.
The harder part is organizational. You need buy-in from the teams that depend on these platforms. You need developers who understand why the platform exists and what happens if adoption stays at 40%. You need platform engineers who are willing to be on-call for the abstractions they’ve built. You need leadership that treats low adoption as a strategy problem, not a marketing problem.
If you’re building or maintaining an internal developer platform right now, I’d be genuinely curious where your adoption actually sits and what you’ve tried to move it. The gap between what platform engineering can deliver in theory and what it delivers in practice is where the real work happens. It’s not glamorous. But it’s where platform engineering lives or dies.
