The Forecast That Became Partially True
Back in 2023, Gartner made a prediction that felt almost inevitable at the time: by 2026, roughly 80 percent of large engineering organizations would have built out dedicated platform engineering teams. If you’ve been in this space for the last three years, you know they nailed the structural part. Most orgs with headcount to spare spun up platform teams. Hired the people. Carved out the mission statements. Put it on the org chart. And yet here we are in early 2026, and something crucial is missing from the victory lap.
The platforms exist. The teams exist. What doesn’t exist, in most cases, is actual developer adoption at scale. You can have the most elegantly designed internal developer platform on the market, and if developers aren’t using it, you’ve built an expensive monument to good intentions. I’m not using that loosely. I’ve walked through enough codebases and sat through enough platform launch meetings to recognize the pattern, and it’s becoming the defining tension of platform engineering in 2026.
The Math That Should Motivate You (But Probably Doesn’t Motivate Your Team)
The DORA State of DevOps Report 2025 produced some genuinely striking numbers. Organizations that had successfully operationalized mature internal developer platforms deployed code 2.5 times more frequently than those without them. Change failure rates dropped meaningfully. The velocity difference is real and measurable. This is not aspirational thinking. This is empirical data from teams doing the work.
The complication is distribution. Those mature platforms are concentrated in a subset of organizations that solved the adoption problem early. Most large enterprises haven’t reached that inflection point. You end up with a bifurcated industry: one set of engineering orgs extracting genuine competitive advantage from their platforms, and another set where the platform sits in a stable state of partial adoption, consuming resources without proportional return. The second group is significantly larger than the first.
Why does this matter to you personally? Because if you’re building or running a platform team right now, the difference between “we built it” and “people actually use it” is the difference between career momentum and organizational quiet frustration. The platforms that matter are the ones that change developer behavior, not the ones that live in documentation.
Backstage, OpenTofu, and the Adoption Ceiling Nobody Talks About
Consider the trajectory of Backstage. The CNCF Backstage project page will tell you that over 3,000 companies have deployed it in production environments as of late 2025. That’s a genuine success story for open source infrastructure. But dig into community surveys and conversations happening in platform engineering spaces, and you’ll find something more telling: internal surveys consistently show that active usage among eligible developers sits below 50 percent at most large enterprises running Backstage.
This is the adoption ceiling. You can get past it, but most don’t. The reasons are consistent when you talk to teams that have tried and stalled. Developers find the cognitive overhead of onboarding too high. The platform doesn’t integrate cleanly with their actual workflows. It becomes another tab in the browser, another dashboard to check, another layer between them and the work that matters. When a developer can accomplish their task faster by going around the platform than by learning it, they go around the platform. Every time.
Then there’s the licensing complexity that emerged around Terraform. When HashiCorp was acquired by IBM in 2024, the pricing and licensing model shifted in ways that pushed platform teams toward alternatives. OpenTofu, the open-source fork, hit 4 million downloads per month by early 2026. This matters because it fragmented the ecosystem right when standardization would have been more useful. Platform teams now have to make architectural choices based partly on license philosophy rather than pure technical merit. That friction compounds the adoption problem because now you’re asking developers to learn platform-specific tooling that might change again.
The Two Reasons Developers Actually Bypass Your Platform
A Puppet survey in 2025 drilled down on why developers actively choose not to use internal platforms. The top two reasons were mechanical and honest. First: onboarding introduced too much cognitive overhead. Learning a new system requires mental energy, and if the payoff isn’t immediate and obvious, developers rationally decide to spend that energy elsewhere. Second: the platform wasn’t integrated with workflows developers already use every day. It was a separate thing they had to navigate, not a natural extension of how they already worked.
The cognitive overhead problem is worth unpacking because it’s not about bad documentation or unclear UI. It’s about architectural friction. Your platform probably has excellent documentation. The problem is that the person reading it is context-switching from their actual task to understand a new abstraction layer, in a context where they don’t have time to develop fluency. They need to ship something. So they ask a colleague who already knows the platform, or they reach for a workaround that already worked six months ago.
The workflow integration problem is subtler. It means that using your platform requires a mode shift from how developers normally work. Maybe they’re used to thinking in terms of containers and they’re trying to reason about your platform’s service abstraction model. Maybe they’re accustomed to a certain workflow in their editor or terminal and your platform requires them to move to a web interface. These aren’t dealbreakers in isolation, but they accumulate. Each friction point increases the probability that a developer will decide the platform’s value proposition isn’t worth the adaptation cost.
What Actually Works (And What Platform Teams Often Miss)
The platform engineering teams that have moved past the 40-50 percent adoption ceiling share some consistent characteristics. First, they treat adoption metrics as seriously as they treat technical metrics. They measure not just whether the platform is deployed, but whether it’s actually changing developer behavior. They track usage patterns, not just deployments. They instrument their platforms to understand which features are adoption bottlenecks and which are friction points.
Second, they’ve usually made some hard decisions about scope. The most successful platforms often started narrowly focused on solving one acute developer pain point exceptionally well, then expanded from there. They didn’t try to be everything to everyone. They picked a problem that was universal enough to matter but concrete enough to solve visibly in weeks, not quarters.
Third, they have product management discipline. Platform engineering is infrastructure, but it’s not pure infrastructure anymore. It’s a product for internal customers with specific needs and preferences. Teams that hire someone whose job is explicitly to understand developer experience and bridge the gap between platform capabilities and actual adoption needs tend to hit higher adoption rates. This person often comes from a product background rather than an engineering background, and that perspective matters more than most platform leads want to admit.
And they’re honest about integration costs. Instead of asking developers to integrate the platform into their workflows, they ask how to integrate themselves into the developer workflows that already exist. This sounds like a small semantic shift, but it changes everything about architectural decisions.
Where This Leaves You
If you’re running a platform team in 2026 and sitting at that 40 percent adoption wall, the problem is well-understood now. The ceiling exists because of specific, addressable reasons, not because the concept of internal developer platforms is flawed. The platforms that work deploy faster, fail less often, and give engineers more time to think about problems that matter. The data is clear on that.
The work is understanding your specific adoption ceiling. Is it cognitive overhead? Workflow integration? Perceived lack of value? The answer is different for every organization, and the only way to find it is by watching how your developers actually behave with your platform, not how you think they should behave. Start there. Talk to the developers who aren’t using it. Ask them directly. Their reasons will be more valuable than any vendor pitch.
What’s your platform adoption looking like right now? If you’ve hit this wall or found a way past it, I’m genuinely interested in what you’ve learned. The patterns are still forming in this space, and the people doing the real work are the ones who’ll define what platform engineering actually becomes in the next cycle.