DORA 2024 found 90% of organizations have adopted at least one platform engineering practice. The gap between adoption and value is a sociotechnical problem, not a technical one.
The DORA 2024 research report contains a number I keep coming back to: 90% of organizations have adopted at least one platform engineering practice (https://dora.dev/research/2024/dora-report/). When nine out of ten organizations have adopted something, adoption is no longer the interesting question. The interesting question is why so many of them are not getting the value they expected. And the DORA findings give a specific, counterintuitive signal about where the value gap is opening up.
AI adoption improves developer throughput but hurts delivery stability, according to DORA's 2024 findings. More output, more instability. That combination tells you something specific about how AI tools are being deployed in most software organizations: they are being layered on top of existing platform infrastructure without the governance and coordination structures needed to handle the additional complexity they introduce. The tools accelerate individual developer output. The surrounding system was not designed for what that acceleration makes possible. So delivery pipelines destabilize. Incidents increase. The throughput gains get partially offset by stability costs that were not in the business case.
This is a sociotechnical systems problem, and I want to be precise about what that means. Trist and Bamforth (1951) developed the original sociotechnical systems insight studying British coal mines: you cannot optimize the technical component of a work system without jointly optimizing the social and organizational component. The longwall mining method failed not because the technology was wrong, but because it broke the social structures, the small team autonomy and mutual accountability, that had made the previous system work. Deploying better technology into an unchanged organizational structure produced worse outcomes than the less sophisticated system it replaced.
Developer platforms follow the same pattern. A platform that is technically excellent but that engineers do not trust, that duplicates what teams were already doing with their own scripts and automation, or that imposes compliance overhead without delivering proportionate value, will not produce the outcomes the platform team was trying to achieve. The gap between what the platform was designed to do (the specification) and what engineers actually do when they use it (the practice) is a sociotechnical gap. You cannot close it by improving the platform's technical capabilities alone. You close it by understanding how engineers experience the platform, what they are optimizing for in their daily work, and where the friction is actually coming from.
DORA's data adds a finding that makes this gap actionable in an interesting way. High-quality internal platforms correlate with higher AI value capture. Organizations that have invested in building well-designed, trusted, low-friction developer platforms are better positioned to benefit from AI tools layered on top of them. The causality is probably bidirectional, since organizations that are generally better at platform thinking are also better at other organizational capabilities, but the practical implication is clear. AI tools do not compensate for weak underlying infrastructure. They amplify the quality of what already exists. Good platforms get better with AI tools. Weak platforms get more chaotic. This is the sociotechnical principle restated for 2026: the social and organizational system determines whether the technical investment produces value.
The developer experience (DevEx) dimension matters here in a way that I think the engineering community understands intuitively but the IS research community has been slower to formalize. Developer experience is not a soft concern about morale. Research in this area has suggested that developers working in low-friction environments, with consistent tooling, fast feedback loops, and documentation that matches reality, produce more and catch more defects than developers working in high-friction environments. The friction is not just annoying. It is a productivity tax. Developers working in high-friction environments develop workarounds, avoid certain paths in the system, and make decisions based on what the tools allow rather than what the problem requires. Platform adoption without developer experience investment tends to produce the worst outcome: new official tooling that engineers use for compliance and old unofficial workflows where the real work happens. Shadow IT inside the platform.
What does this cost at scale? Gartner forecasts global IT spending at $6.31 trillion in 2026, with AI investments growing at more than 35% year over year (https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-forecasts-worldwide-it-spending-to-grow-9-8-percent-in-2026). A meaningful portion of that AI investment is going into AI developer tools: code assistants, automated testing, security scanning, documentation generation, and code review. If DORA is right that AI accelerates throughput but hurts stability without proper controls, and if proper controls depend on having a high-quality underlying platform, then a significant share of the AI investment in developer tooling is being absorbed by organizations that are not positioned to capture its value. The tool works. The infrastructure needed to make the tool work reliably is not there.
The IS concept I keep returning to here is IT capability, which Bharadwaj (2000) distinguished carefully from IT investment. Any organization with a budget can make an IT investment. IT capability is the organizational ability to mobilize IT infrastructure, human IT resources, and IT-enabled intangibles in ways that serve organizational goals. Developer platforms are infrastructure. The capability to build, maintain, and improve those platforms in ways that actually match how engineering teams work is something different, and harder. It requires understanding engineering workflows at a level of detail that most IT governance structures are not designed to produce. It requires feedback loops between platform teams and the engineers they serve. It requires the discipline to measure whether the platform is actually reducing friction rather than just tracking deployment metrics.
As an IS researcher, the finding that worries me is not the 90% adoption figure. That number is actually good news: it means the industry has accepted that centralized developer infrastructure is the right organizational model for software development at scale. What worries me is that DORA is measuring the performance outcomes of platform adoption and finding that AI is destabilizing those outcomes. If organizations read that finding as a reason to add more technical controls on top of AI tools, they will likely make the problem worse by adding more friction to an already friction-heavy system. The right read is that the human and organizational side of platform design, the team structures, the feedback mechanisms, the trust and visibility between platform teams and product teams, needs as much investment as the technical side. That has been true since 1951. It is still true now.
---
claims_checked:
- "90% of organizations adopted at least one platform engineering practice": "https://dora.dev/research/2024/dora-report/"
- "AI adoption improves throughput but hurts delivery stability (counterintuitive finding)": "https://dora.dev/research/2024/dora-report/"
- "High-quality platforms correlate with actual AI value realization": "https://dora.dev/research/2024/dora-report/"
- "AI investments growing 35%+ YoY": "https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-forecasts-worldwide-it-spending-to-grow-9-8-percent-in-2026"
- "Total IT spending 2026: $6.31 trillion": "https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-forecasts-worldwide-it-spending-to-grow-9-8-percent-in-2026"
claims_unverified:
- "DevEx research correlation with productivity: described as general research finding without citing a specific paper; a specific DevEx study was not fetched for this rewrite"
- "Shadow IT inside the platform framing: my own theoretical inference, not directly cited from a published study"
- "Bharadwaj 2000 IT capability definition: well-established academic reference, not linked to a fetched URL"
sources_used:
- "https://dora.dev/research/2024/dora-report/"
- "https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-forecasts-worldwide-it-spending-to-grow-9-8-percent-in-2026"
word_count: 1060
About the author
Share
More notes
Related notes