Platform engineering stopped being a bet in 2025. Google’s DORA research found that 90% of organizations now run at least one internal platform, and 76% have a dedicated team behind it. For a practice that was still being explained from first principles a few years ago, that’s a fast, decisive win.

It’s also not the full story. A separate survey of 518 practitioners found that 29.6% of platform engineering teams can’t say, in any form, whether their platform is actually succeeding. Another found that over 40% of teams still can’t demonstrate measurable value a full year after standing one up.

Adoption solved the “should we build this” question. It didn’t solve the “is it working” one. The two numbers aren’t contradictory. They’re describing two different stages of the same decision, made at two different speeds. Deciding to build a platform and getting executive buy-in for it moves fast, especially once a handful of competitors have already done it. Building the muscle to actually measure whether that platform earns its budget back moves much slower, and most organizations are still only partway through that second, slower project.

Six findings below walk through that gap: how fast platform engineering actually grew, why so many teams never built a way to measure it, what happens after a company picks a platform tool, and why AI is making the quality of that platform matter more, not less. None of this argues platform engineering was the wrong call. It argues that adoption and proof are two separate projects, and most companies have only finished the first one.

Platform engineering adoption passed 90% in a single research cycle

A few years ago, platform engineering was a Gartner prediction. Now it’s close to a default. The speed of that shift matters because it means most platform engineering teams were built under pressure to move fast, not to build in measurement from day one.

DORA’s 2025 research found 90% of organizations now run an internal platform

DORA’s 2025 research, Google’s annual study of software delivery performance, found that adoption of internal platforms has become “nearly universal”: 90% of organizations report running at least one, and 76% have a dedicated platform engineering team maintaining it. Both numbers describe a practice that moved from niche to standard in a short window. Most engineering leaders reading this already work somewhere with a platform engineering team, whether or not they’d call it that.

DORA defines an internal platform broadly: a curated, self-service layer covering infrastructure provisioning, CI/CD, and the golden paths that let a developer ship without filing a ticket to another team. That breadth matters here. A company with a thin internal wiki and a shared Terraform repo can honestly answer “yes” to having a platform, even though its maturity has almost nothing in common with a company running a dedicated portal, a product roadmap, and a team of platform engineers.

The 90% figure says adoption is nearly universal. It says nothing about how far along any individual team actually is.

Most of that adoption happened without anyone deciding how to prove it worked

Standing up a platform engineering team and deciding how to measure its success are two different projects, and the first one almost always gets funded before the second. A team under pressure to ship self-service tooling rarely pauses to design a measurement framework before the first golden path goes live. That sequencing gap is where the next five findings start.

It’s a familiar pattern in engineering organizations generally, not unique to platform engineering. Teams fund the thing that’s visibly on fire first and backfill the instrumentation later, if at all. What makes it costlier here is scale: a platform touches every team that builds on it, so a measurement gap at the platform layer doesn’t stay contained to one project. It compounds across every team the platform was supposed to make faster.

Almost a third of platform engineering teams can’t say whether any of it is working

Adoption numbers answer whether platform engineering happened. They don’t answer whether it’s any good. The data on that second question is far less flattering.

29.6% of platform engineering teams don’t measure success in any form

The 2026 Platform Engineering Maturity report, based on a survey of 518 practitioners using the CNCF’s maturity model, found that 29.6% of platform engineering teams don’t measure success at all. No adoption rate, no developer satisfaction score, no deployment metric tied back to the platform specifically. The number is an improvement on 2024, when it sat closer to 45%, but it still means almost a third of platform investments are running entirely on faith.

That improvement is worth taking seriously on its own. Cutting a measurement gap from 45% to 29.6% in a single year is real progress, and it suggests the industry is slowly correcting the sequencing problem rather than settling into it permanently. The pace of that correction still lags the pace of adoption by a wide margin, which is exactly why a company evaluating its own platform engineering program today shouldn’t assume the rest of the industry has already solved measurement just because it’s finally talking about it.

The teams that do measure often can’t tell if the numbers improved

A further 24.2% of practitioners in the same survey said they don’t know whether their metrics have gotten better over time, even though they do track something. Measuring once and never establishing a baseline produces a number without a story attached to it. Between the teams measuring nothing and the teams measuring something they can’t interpret, a majority of platform engineering programs can’t currently answer the question a budget conversation eventually asks: is this working.

A single snapshot metric, collected once at launch and never revisited, functions less like measurement and more like a receipt. It proves the platform existed at some point. It says nothing about whether the second quarter was better than the first, or whether a given investment actually moved anything. Treating a baseline as a starting point rather than a finished deliverable is the specific habit separating the 24.2% from a platform engineering team that can actually show its work.

Most platforms don’t prove their value inside the first year

Even among teams that do take measurement seriously, the timeline to actual proof is longer than most budget cycles expect. That mismatch creates its own kind of risk, independent of whether the platform is any good.

35.2% of teams show measurable value within six months

The same maturity report found that 35.2% of platform engineering teams deliver measurable value within six months, specifically when they prioritize provisioning, giving developers self-service infrastructure, ahead of other platform capabilities. That’s a meaningful signal: the fastest path to proof runs through the most concrete, most immediately useful capability a platform can offer, not the most sophisticated one.

Provisioning wins the race to proof for a simple reason: it replaces a ticket with a self-service click, and that difference is immediately visible to the people it affects. A developer doesn’t need a dashboard to notice that a server used to take three days and now takes ten minutes. Capabilities further from that kind of direct, felt relief, like internal documentation or a golden-path template library, take longer to show up in any metric a team can point to.

40.9% still can’t demonstrate value after a full year

On the other end, 40.9% of platform engineering teams still can’t show measurable value a full twelve months in. Not every slow team is failing. Some platforms genuinely do need longer to mature, especially in complex, highly regulated environments. But a budget renewal rarely waits that long for proof, and a platform that can’t show early wins is the one most likely to get quietly defunded before it reaches its real payoff.

Fast, well-instrumented ROI is possible. Forrester’s research on Cortex’s enterprise customers, a vendor-commissioned study worth reading with that context in mind, found a 20% improvement in developer productivity and a 25% reduction in deployment time among the platform vendor’s own customers. The gap isn’t that proof is impossible. It’s that most platform engineering teams aren’t instructed to produce it.

Choosing a platform and getting engineers to use it are different problems

Picking a tool is the easy half of platform engineering. The harder half, actually getting a platform engineering program adopted, starts after the decision is made, and the data on that half tells a less settled story than the adoption numbers suggest.

Backstage wins 89% of head-to-head choices among teams picking a tool

Spotify’s Backstage dominates the decision stage. A DX survey of 180 companies found that among organizations choosing a platform tool over SaaS alternatives, 89% pick Backstage over Port, Cortex, Humanitec, or a homegrown build. That’s a share-of-choice number, not a usage number. It describes what gets selected, not what gets used once the selection is made.

Backstage’s pull is easy to understand even without the number: it’s open source, it’s free of a per-seat SaaS bill, and it came out of Spotify’s own platform engineering team solving the exact problem most companies now face. None of that guarantees the rollout goes well once a company has made the choice. Picking the most popular option removes the selection risk from the project. It leaves the rollout risk, the training risk, and the ongoing-investment risk exactly where they were.

28% of Backstage deployments sit in maintenance mode, not active use

The same survey found that 72% of organizations running Backstage describe it as actively developed, while the other 28% describe it as sitting in maintenance mode: deployed, technically live, but no longer receiving meaningful investment. A platform that stalls after launch still counts in every adoption statistic. It just stops counting for anything that matters to the developers it was supposed to serve.

Maintenance mode is a specific, recognizable failure pattern, not a vague decline. It usually starts with the team that built the platform getting reassigned once the initial rollout ships, followed by plugin updates slipping, followed by developers quietly routing back around the platform the same way they routed around whatever it replaced. None of those steps shows up as a dramatic failure. Each one just makes the next one slightly more likely.

The obstacles blocking platform engineering aren’t technical

Ask a platform engineering team what’s actually in their way, and infrastructure rarely tops the list. That reframes where a struggling platform engineering program should look for the fix.

Developer adoption is the single most-cited obstacle, at 45.3%

The 2026 maturity report found developer adoption is the top obstacle platform engineering teams report, cited by 45.3% of respondents. Building the platform is a technical project. Getting engineers to actually route through it instead of their old workarounds is a change-management project, and most platform engineering teams are staffed and incentivized almost entirely for the first kind of work.

An engineer who’s shipped a workaround successfully for two years doesn’t abandon it because a new internal tool launched with an announcement in Slack. The old path still works, it’s familiar, and switching to the new one carries a real short-term productivity cost while the engineer learns it. Closing that gap takes the same deliberate change-management effort any new internal tool needs, not just a changelog entry and an assumption that adoption follows automatically from availability.

Lack of shared vision and system complexity round out the top three

Close behind, 44.3% cited a lack of shared vision across the organization, and 43.9% cited system complexity. Both are organizational problems wearing technical clothing. A platform without a shared definition of what it’s for will accumulate scope from whoever shouts loudest, and a platform without a product owner accountable for saying no tends to sprawl into exactly the complexity that eventually turns developers away from it.

The three obstacles reinforce each other more than they operate independently. A team without a shared vision has no principled basis for saying no to a feature request, which is how a platform engineering program accumulates the complexity that eventually makes it harder to adopt, which then shows up as the top-ranked obstacle a year later. Fixing any one of the three in isolation rarely holds if the other two are left exactly where they were.

AI raises the stakes on platform quality instead of lowering them

It’s tempting to assume AI coding tools reduce how much a platform’s quality matters, since developers increasingly lean on an assistant rather than internal documentation. DORA’s own research found close to the opposite, and the industry seems to agree: a GitLab survey of 3,266 DevSecOps professionals found 85% agree that agentic AI succeeds best inside a platform engineering approach, not bolted onto fragmented tooling.

DORA found AI only pays off on top of a high-quality platform

DORA’s 2025 research found that when platform quality is high, AI adoption has a strong, positive effect on organizational performance. When platform quality is low, that same AI adoption has close to no effect at all. AI amplifies whatever foundation it’s layered onto.

A weak platform doesn’t get fixed by adding AI on top of it. It gets a faster, more confident version of the same weak foundation. An AI assistant generating code faster than a team’s platform can safely test, secure, and deploy it doesn’t produce faster software. It produces a faster-growing backlog of code nobody has verified is safe to ship, sitting on top of infrastructure that was already struggling to keep pace before AI entered the picture.

Only 21.6% of platform engineering teams have a dedicated product manager to drive that quality

Despite that stake getting higher, only 21.6% of platform engineering teams in the 2026 maturity survey have a dedicated Platform Product Manager, the role most directly responsible for prioritizing the quality work AI now depends on. The rest rely on distributed product thinking spread across engineers who already have a full-time job building the platform itself, which is a thinner layer of ownership than the stakes currently call for.

Quality in this context isn’t an abstract engineering value. It’s concretely the automated testing, security scanning, and deployment guardrails a platform enforces before AI-generated code reaches production. Without someone whose job is specifically to prioritize that layer of the platform, it competes for the same engineering time as every other feature request, and it tends to lose precisely when AI adoption is accelerating fastest and the enforcement layer matters most.

What this means for teams investing in platform engineering

None of the six findings above are an argument against investing in platform engineering. Adoption happened for real reasons: self-service infrastructure genuinely reduces cognitive load, and a well-run platform engineering team genuinely moves faster than a central ops queue ever could. The argument is narrower than that.

The gap worth closing isn’t adoption. It’s the measurement layer most teams never built, which is exactly the kind of system-level question Landskill’s own research on developer productivity metrics was written to answer: pairing deployment frequency with stability metrics instead of optimizing either one alone, so a platform’s speed gains don’t get credited without also checking what they cost in reliability.

A platform’s job is also expanding past pure self-service. Security and compliance increasingly need to live inside the platform as a built-in guarantee rather than a step each team remembers to bolt on separately, the same enforcement-layer argument that applies once platform engineering teams and security teams share ownership of the same pipeline. A platform that only ever solved for developer speed was already an incomplete platform before AI made the speed-versus-safety trade-off this much sharper.

Teams planning or already running a platform engineering investment have a narrower, more answerable question than “should we do platform engineering.” The six findings above suggest the better one is whether the measurement plan, the product ownership, and the six-month proof point already exist, or whether they’re being assumed into existence alongside the infrastructure. Talk to Landskill about where your own platform engineering investment sits on that gap.