Skip to content
Published on

Teams Using Platforms Had 8% Lower Throughput, 14% Lower Change Stability — Why You Shouldn't Read DORA's Data as Causal

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
Share
Authors

Introduction — Unpacking the "90% Adoption" Number

By mid-2026, hardly anyone asks whether they should be doing platform engineering. The debate looks settled. DORA's 2025 report summarizes the core finding of its platform chapter this way — "Platform adoption is nearly universal: 90%." Organizations with a dedicated platform team sit at 76%, now described as the dominant organizational model.

But you have to look at what that number actually counted. The definition of a platform DORA used in its survey is spelled out in the appendix — a platform is "a set of capabilities shared across multiple applications or services," and a single company can have several overlapping platforms that get collectively referred to as "the platform."

Under this definition, a single company-wide Jenkins instance is a platform. A shared Kubernetes cluster is a platform. A common internal CI template is a platform. The 2024 report is even more blunt about this — it says this year's survey kept the definition of an internal developer platform "quite broad," and as a result 89% of respondents came back as using an internal developer platform.

So "90% adoption" does not mean "90% of organizations have a Backstage-style portal and golden paths." It's closer to "90% of organizations have something shared." Hold on to that distinction, because it's what makes the rest of the numbers legible.

And what comes next is the genuinely interesting part. The very same research program reported that the platform-using group did worse on throughput and stability.

What DORA 2024 Actually Found — the Good News and the Uncomfortable News

The 2024 DORA report devoted an entire chapter to platform engineering. Roughly 3,000 practitioners worldwide responded to that year's survey. Here is the report's own language, carried over directly.

On the good-news side:

  • Internal developer platform users had 8% higher individual productivity.
  • Team performance was 10% higher.
  • An organization's software delivery and operational performance is 6% higher when it uses a platform.

So far, this is the picture we'd expect. But the very next sentence continues like this — "However, these gains do not come without cost. Throughput and change stability decreased by 8% and 14% respectively, which was a surprising result."

The report even gave this passage its own subheading, "The unexpected downside." Breaking the numbers down again:

  • Throughput. About an 8% decrease compared with non-platform users.
  • Change stability. A 14% decrease. The report spells out what that means — "change failure rate and rework rate increase significantly when using a platform."

There's one more layer. Among respondents who said they were required to work "exclusively through the platform for their entire application lifecycle," throughput was 6% lower still. Mandating platform use made things slower.

And then the most uncomfortable combination — the report says it found a link where instability combined with a platform produces higher burnout levels. But it immediately qualifies that: "this does not mean that platforms cause burnout."

That sentence is the crux of this whole post.

The Three Hypotheses DORA Itself Puts Forward — the Third One Matters

This is where DORA earns some credit. When its own data cut against its own narrative, the report didn't hide it or hand-wave around it — it wrote "we don't fully know why either" and then laid out its hypotheses.

First, more machinery. The explanation is that more stages now have to pass before a change can ship. In the report's words, building and deploying through an internal developer platform typically increases the number of "handoffs" between systems — and implicitly between teams. Once code is committed, different systems responsible for testing, security checks, deployment, and monitoring pick it up in turn. Each handoff is an opportunity for time to slip in, which is why throughput drops even as "the net ability to get work done increases."

Second, forced exclusivity. This is the 6% decrease seen above. If a platform must be used even when it doesn't fit the job, the added delay becomes a straightforward cost.

Third — and this is the decisive one — the reverse-causation hypothesis. In the report's own words: teams with high change instability and high burnout tend to build platforms as an effort to improve stability and reduce burnout. And one more sentence — "under this hypothesis, platform engineering is symptomatic of organizations with burnout and change instability."

Worth sitting with. If this is true, the arrow points the other way. The platform didn't create the instability — the unstable organization created the platform. It's the same logic as "hospitals have a lot of sick people" not meaning hospitals cause disease.

And from this survey data alone, there is no way to distinguish the two directions. From a single point-in-time snapshot, "platform → instability" and "instability → platform" look like exactly the same correlation.

On the stability decline, the report similarly leaves multiple branches open. One is the optimistic reading — having a platform builds confidence that a bad change can be recovered from quickly, so teams push more experimentally and more often. Under this reading, a higher change failure rate isn't a bad sign, it's a byproduct of more experimentation. The other is the pessimistic reading — the platform provides automated test execution, but if application teams prioritize throughput instead of actually improving their tests, bad changes simply pass through and come back as rework.

The same numbers support two opposite stories. That isn't a flaw in the data so much as it's the inherent limit of what this kind of data can say in the first place.

One more thing — the 2024 report contains a useful finding that doesn't get cited often. Plotted against platform age, the curve traces a J-shape — performance rises early in a platform initiative, then dips, then recovers as the platform matures. The report calls this the typical transformation-initiative pattern of "realizing early gains, then hitting difficulty." It also states that productivity gains persist over the long run. If an organization is tempted to disband its platform team because year-two numbers look bad, showing them this J-curve might help.

The findings on what actually drives the gains are also specific. Developer independence — defined as "the ability for developers to accomplish their work throughout the entire application lifecycle without depending on enabling teams" — is associated with a 5% productivity gain at both the individual and team level. By contrast, having a dedicated platform team had negligible effect on individual productivity and only a 6% gain at the team level. And not collecting feedback on the platform is explicitly flagged as having a negative effect.

In 2025, DORA Dropped the Word "Effects"

The 2025 report came out in September 2025. The sample was 4,867 people (the report calls it "nearly 5,000"), paired with over 100 hours of qualitative data.

The most notable part of this report isn't the platform chapter — it's a footnote. Footnote 20, carried over directly:

Last year, we used the language of "effects." This year, we want to speak in the language of "comparisons." While we try to set up conditions under which we can speak causally, we don't want to give the false impression that we understand the underlying causal structure. We will occasionally use causal language, but ultimately what we are doing is making comparisons.

And it cites Gelman and Hill's Regression and Other Stories as the basis for that — that what's observed is an observational pattern, and "the safest interpretation of regression coefficients is in terms of comparisons."

This is not a common move. A research program that surveys thousands of people a year and sells the resulting report voluntarily dialed down the strength of its own language. And yet the articles and conference slides that cite this report almost without exception translate it back into causal terms — "platforms improve organizational performance" — even though the original text pins it down explicitly as "comparisons."

The content of the platform chapter is equally honest. The 2025 report summarizes the 2024 finding this way — platforms have a positive effect on organizational performance and productivity, but "these gains came with tradeoffs: increased software delivery instability and reduced throughput."

And in the 2025 data, this pattern didn't go away. The report states — "consistent with prior research, better platforms are associated with a small but reliable increase in software delivery instability, meaning higher change failure rates and more rework."

DORA's interpretation leans optimistic this time — it suggests this rise in instability "may be a hallmark of a healthy, fast-moving system," a kind of risk compensation where a platform makes recovery from failure fast and cheap, so teams experiment more and tolerate more minor failures. That's a plausible reading. But it, too, is an interpretation, not a measurement.

How Was "Platform Quality" Actually Measured

The headline finding of the 2025 report is this — high-quality internal platforms amplify the effect of AI adoption. More precisely, when platform quality is low, the effect of AI adoption on organizational performance is negligible; when platform quality is high, it's strong and positive. This is the finding that Google Cloud's blog promoted as "a direct correlation between high-quality internal platforms and the ability to realize value from AI."

So how was "platform quality" measured? The report body explains it this way — platform quality is measured as a single score representing the count of 12 characteristics respondents said their platform has.

The appendix lists the items. They're attached to the question "To what extent does your platform exhibit the following characteristics?"

- The platform helps build and operate reliable applications and services
- The platform helps build and operate secure applications and services
- The platform's UI is clear and clean
- The platform provides the tools and information needed to work independently
- The platform behaves the way I expect it to
- The platform helps follow required processes (code review, security approval, etc.)
- The platform gives clear feedback on the work I do
- The work done on the platform is well automated
- The platform team acts on the feedback I give
- The platform is easy to use
- The platform effectively abstracts the complexity of the underlying infrastructure

Reading through this, it's clear these are all subjective perceptions. "The platform is easy to use," "it behaves the way I expect" — these aren't measured metrics, they're what a developer felt. There's nothing wrong with that in itself. Developer experience is inherently subjective, and asking about it is legitimate.

The problem is that the outcome variable is equally subjective. In the appendix's "How we assessed outcomes" section, organizational performance is measured with a question like this — "Over the past year, how has your organization performed on the following, relative to its goals?" And the items are overall organizational performance, overall profitability, achievement of organizational and mission goals, customer satisfaction, operational efficiency, and product/service quality.

In other words, this is not an audited financial statement. It's a Likert-scale answer to how a respondent feels their company's profitability compared with its goals. Productivity, code quality, and individual effectiveness are all explicitly labeled "self-assessed" in the appendix as well.

So the actual content behind the sentence "high-quality platforms improve organizational performance" comes down to this — people who rate their own platform highly also tend to rate their own company highly. That's still a meaningful finding. But it's a long way from a causal claim. The company might have been doing well enough to afford investing in a platform, or someone who simply views their company positively might have answered every question generously (this is what's called common-method bias).

The sampling method is also worth a look. As the report's methodology chapter states directly, DORA gathers respondents through two channels — an "organic" channel through blogs, email, and social media, which includes snowball sampling via asking the community to spread the survey, and a supplementary panel channel. This is not a probability sample. People within DORA's social-media and community reach — people already engaged in DevOps discourse — are oversampled. The bias in the qualitative interviews is even more pronounced — as the report states itself, 76 of the 78 interview subjects were based in the United States, which the report attributes to the interviewers' language abilities and scheduling constraints.

Finally, the publisher of this report needs to be named. The 2025 DORA report is published by Google Cloud (the copyright notice reads "Google LLC," under CC BY-NC-SA 4.0), with IT Revolution, GitHub, GitLab, SkillBench, and Workhelix credited as research partners. Companies that sell cloud and developer tooling sponsored research that concludes with "invest in platforms and AI." Both things are true at once — DORA's methodology is among the more rigorous in this industry, and this conflict of interest exists. Both need to be kept in mind.

How to Read Vendor Research — the Puppet 2026 Case

Having a point of comparison sets a baseline. Let's look at Puppet (Perforce)'s State of DevOps Report: Platform Engineering Edition 2026, published in 2026. The headline numbers are:

  • 73% of organizations with mature platform engineering said their maturity drives AI success, versus 44% at less mature organizations.
  • 66% of organizations are applying AI to infrastructure workflows, but only 31% reported fully autonomous operations — rising to 44% in a standardized internal developer platform environment.
  • 79% of platform-mature organizations reported mature governance, versus 14% at immature organizations.
  • 81% of mature organizations said they trust AI, versus 48% at immature organizations. That rises to 92% in a standardized IDP environment and 94% at organizations with formal governance, versus 51% under ad hoc governance.

The numbers themselves are accurate — I checked them against the source page directly. The question is what they can actually tell us.

Start with the sample. Open the methodology page and it says this — "This research was conducted via a 20-minute online survey among 820 global IT decision-makers (ITDMs), purchase influencers, and DevOps practitioners."

Purchase influencers are explicitly included in the sample. A company that sells infrastructure automation products asked people who influence purchasing decisions whether platform maturity is a good thing. That doesn't automatically make the numbers wrong. But this sample is a lot closer to "what purchasing people believe" than to "how developers actually experience platforms."

And the entire "Limitations" section on the same page is this one sentence — "Results reflect self-reported practices and perceptions."

One sentence. While DORA footnotes its causal language, cites Gelman, and dials down its own strength of claim, here the limitations of an 820-person survey get handled in a single line. That's a practical signal for reading vendor research — the length of the limitations section is a fairly good proxy for how much you should trust the study.

There's something to be careful of on the content side too. In the sentence "79% of platform-mature organizations reported mature governance, versus 14% at immature organizations," who judged both maturity and governance? The same respondent. And if the maturity model itself includes governance as a component of maturity, this correlation is closer to a definition than a finding. I was not able to fully verify Puppet's maturity-model definition all the way through, so I won't assert that it is. But whenever you meet a sentence shaped like "mature organizations are also good at X," it's always worth asking — is X already baked into the definition of maturity?

The same goes for "73% said maturity drives AI success." That's not a measurement of AI success — it's a measurement of what people believe. The two are different things.

What This Data Can and Can't Say

Let's pull this together.

What can be said:

  • Something shareable enough to be called a platform now exists at nearly every organization (90% under the broad definition). Dedicated platform teams are also the dominant model, at 76%.
  • People who say they use a platform tend to rate their own productivity and team performance higher (8% and 10% as of 2024).
  • At the same time, people who say they use a platform reported lower throughput and change stability (8% and 14%). This pattern held in the same direction in 2025.
  • People who rated their own platform as high-quality reported a stronger association between AI adoption and organizational performance.
  • Developer independence is a signal that keeps showing up. Productivity was 5% higher when work could be completed without depending on enabling teams.

What can't be said:

  • "Adopting a platform drops throughput by 8%." The direction of the arrow is not settled. DORA itself explicitly left the reverse-causation hypothesis open.
  • "High-quality platforms improve organizational performance." DORA specifically chose to avoid this exact phrasing in 2025. This is a comparison, not an effect.
  • "Platform maturity drives AI success." This is a report of what people who rate themselves as mature believe.
  • "Our company will also see an 8% gain." This isn't a probability sample, and your company isn't in it.

One more thing worth adding — all of these numbers are standardized differences on Likert scales converted into percentages, not something measured with a stopwatch. "8% decrease in throughput" doesn't mean deployment counts were literally counted and came out 8% lower; it means responses to throughput-related questions came out that much lower.

So What Do You Do on Monday

This post is not "don't do platform engineering." With adoption at 90%, that would be a useless piece of advice. But reading these studies carefully does yield a handful of things you can actually act on.

Measure your own data. This is the first and most important item. Your company is not in DORA's sample. And a survey's "throughput" is not the same thing as your CI logs' deployment counts. Fortunately, the latter can be counted directly. Actually measuring per-team deployment frequency and change failure rate before and after platform onboarding gives you evidence far better than anyone else's Likert scale.

Don't force exclusivity. This is the most actionable item in the data. Respondents required to use the platform exclusively reported a 6% drop in throughput. A golden path should be the easiest route, not the only route. Let the platform be bypassed, and treat the moments when a bypass is needed as inputs to your roadmap.

Count your handoffs. DORA's first hypothesis explains the throughput drop as a rise in handoffs. This is verifiable. Actually map how many system and team boundaries a change crosses from commit to production, and how much wait time sits at each boundary. If wait time dwarfs execution time, that's your 8%.

Use developer independence as a metric. This signal recurs consistently. "Can this task be finished without an enabling team" can be asked without a survey, and can also be counted directly from your ticketing system — the ratio of "please do this for me" tickets landing on the platform team is effectively the inverse of independence. This is also why the 2024 report flagged collecting feedback itself as a success factor, and not collecting it as a negative one. This topic is covered separately, from a tooling angle, in Building an IDP with Backstage Part 1 — The Software Catalog Is Everything.

If instability rose, work out which direction it went. DORA leaves both interpretations open — more experimentation producing more minor failures (healthy risk compensation), or bad changes simply passing through untested (a consequence of neglected testing). This is verifiable inside your own organization. Look at recovery time and user impact for failed changes. If recovery is fast and users never noticed, that points to the former; if rollbacks are long and customers opened tickets, that points to the latter.

Don't be surprised by a year-two dip. The J-curve is a predicted pattern. But it also shouldn't become an excuse for every slump — write down in advance when recovery should show up, and check honestly at that point.

Closing

There's one thing this post is trying to say. The most frequently cited evidence for platform engineering in our industry is a survey. Self-reported perception, gathered from a non-probability group, at a single point in time. And the people who built that survey know this far better than we do — which is why, in 2025, they stopped using the word "effects" altogether.

And yet every time that report gets carried into a conference slide or an internal proposal, it turns into a causal sentence. "According to DORA, platforms improve organizational performance by 6%." The original text says no such thing.

At the same time, the opposite overcorrection is also worth guarding against. "It's just a survey, so it's meaningless" is equally wrong. 5,000 practitioners consistently reporting in the same direction is information in itself. The fact that the platform-instability association reproduced across both 2024 and 2025 is also information. It just doesn't tell you what caused what.

The most honest posture seems to be borrowing DORA's own — we are making comparisons, we don't know the causal structure, there are multiple hypotheses, and one of them may have the arrow pointing the other way. On top of that, what we can actually do is count what's countable inside our own organization, instead of quoting someone else's survey numbers.

References

Discuss on Twitter • View on GitHub