An internal DORA survey is now the main way to keep measuring software delivery, and it only works as evidence if the company governs it the way an independent researcher would. Jennifer Riggins reports in a recent article that Google will not run the annual DORA survey this year, and this piece extends one claim from her reporting.
Riggins reports that the independent benchmark is gone and the questions remain
Riggins writes that the DORA team at Google Cloud announced in September 2026 that it would not field the survey behind its annual report. She quotes Lauren Peate of Multitudes on why that hurts: DORA was independent of any developer productivity vendor. She also notes that reports from measurement vendors draw on organizations that invest in such tooling, which tend to score better than the industry as a whole, so they cannot serve as an accurate benchmark.
Her article then points to what is left. The survey questions are published on dora.dev under open licenses. Nathen Harvey, until recently the DORA lead, tells her that teams should run an internal survey, pick the questions that matter to their business, take a baseline, make a change and measure again. Harvey also says a mix of qualitative surveys and telemetry gives the best picture.
A self-run DORA survey keeps the questions and loses the independence
Peate’s point about independence does not disappear when a company forks the survey. It moves inside the company. In a self-run survey, the people who choose which questions to keep, when to field them and how to read the answers are often the same people whose platform investment or AI rollout is being judged. That is the conflict Riggins describes in vendor reports, reproduced at the scale of one organization.
This matters more in 2026 than it did when DORA was a yearly ritual. Many engineering organizations are using delivery metrics to justify spending on AI coding tools. An internal survey designed after the tools are bought, with questions chosen after the first results come in, will tend to confirm the purchase. Nobody has to act in bad faith for that to happen. Choosing questions with the answer already in view is enough.
DORA’s answer ranges were built to compare populations and they blur one team’s progress
The 2025 DORA survey questions ask about software delivery in ranges. Lead time for changes, defined as the time from commit to code running in production, is answered with one of six options from “Less than one hour” to “More than six months”, plus “I don’t know or NA”. Deployment frequency and recovery time are asked the same way. Ranges like these work well across tens of thousands of anonymous respondents, because the aggregate distribution carries the signal.
Inside one team the same ranges become coarse. If an intervention cuts lead time from six days to two days, every honest respondent still picks “Between one day and one week”, and the survey reports no change. The reverse also happens: a few people whose lead time sat near a boundary can cross it and produce an apparent shift that is mostly noise. A small internal sample cannot average these effects away.
DORA’s own guide to its software delivery performance metrics, written by Harvey, supports a narrow use. It says the metrics are best suited to one application or service at a time and that blending them across teams or whole organizations can be problematic. Read with the ranges in mind, the practical conclusion is that the survey items describe how people experience delivery, and pipeline telemetry has to supply the precise numbers. Harvey’s recommendation in Riggins’s article to mix surveys and telemetry is the minimum requirement.
Four controls make an internal DORA survey count as evidence
First, freeze the question subset and its exact wording before the baseline. If wording changes between waves, the comparison is between two different instruments. Record which questions were dropped and why.
Second, write down the expected outcome before the intervention starts. The 2025 questionnaire itself asks teams how often they first define a specific, measurable improvement outcome before an initiative, and gives the example of reducing change failure rate below 10%. A company that runs DORA internally can hold its own initiatives to that question.
Third, separate ownership of the survey from ownership of the initiative it measures. A person outside the reporting line of the AI rollout or platform program should hold the raw responses, and respondents should see the full response distributions alongside any summary slide.
Fourth, keep the results away from targets and team rankings. The DORA guide lists setting metrics as a goal, with a link to Goodhart’s law, and competing between teams among its common pitfalls. Once a team is rewarded for a survey answer, the answer stops measuring delivery.
Small teams and missing benchmarks are where an internal survey breaks down
The controls have limits. In a team of five, an anonymous survey is not very anonymous, and people answer questions about failure rates and burnout differently when they can be identified. Below a group size where individual answers can be inferred, structured conversations are more honest than a questionnaire. The DORA guide itself warns against focusing on measurement at the expense of improvement and suggests starting with conversations and its Quick Check.
The second limit has no internal fix. A company that surveys only itself learns whether it improved, and loses any reliable sense of where it stands against the industry. Riggins’s reporting on vendor benchmarks suggests the available substitutes skew positive. Leaders should treat any external comparison from a vendor report as an upper bound on what typical teams achieve, and say so when they present it.
Why This Matters for Engineering Leadership
For more than a decade, engineering leaders could point to an outside study when a board asked whether their delivery practices were sound. That reference point is now paused, at the moment when AI spending makes the question sharper. Riggins cites Atlassian’s State of Teams 2026 report, in which 89% of executives believed AI had increased the speed of work and only 6% could connect that speed to organization-wide return on investment. Closing that gap needs measurement that a skeptical reader would trust. From an AI governance view, the rule is the same one applied to any internal audit: the people being measured should not also design, field and interpret the measurement. An internal DORA survey can meet that standard, but only if leaders set the controls before they see the first result.
FAQ
Is Google still running the DORA survey?
No. Jennifer Riggins reports that the DORA team at Google Cloud announced in September 2026 that it would not run the annual survey this year.
Can a company run the DORA survey itself?
Yes. The survey questions are published on dora.dev, and Nathen Harvey recommends picking the questions that matter to your business, taking a baseline, making a change and measuring again.
Why can an internal DORA survey miss real improvement?
DORA asks about lead time and deployment frequency in ranges. A lead time that falls from six days to two days stays inside the same range, so the survey shows no change.
What should an internal DORA survey be paired with?
Delivery telemetry from your own pipelines. The survey shows how people experience the work, and telemetry shows the precise numbers the ranges hide.
Should teams get DORA metric targets?
No. DORA’s own guide lists setting metrics as a goal and competing between teams as common pitfalls, and cites Goodhart’s law.
Who should own an internal DORA survey?
Someone outside the reporting line of the initiative being measured, with question wording fixed before the baseline is taken.
