You can assess delivery evidence and operating risk without reading source code. That does not replace a technical code, security or architecture review when one is needed. A polished process demonstration cannot prove that an implementation is correct.
This article offers six practical conversation prompts. They are an editorial checklist, not six DORA metrics or a validated score of individual developer quality.
What DORA Measures in 2026
The official DORA metrics guide, updated January 2026, identifies five software-delivery performance metrics:
| Metric | Measurement |
|---|---|
| Change lead time | Time from commit to production |
| Deployment frequency | Deployments in a period or time between them |
| Failed deployment recovery time | Recovery from a deployment failure requiring intervention |
| Change fail rate | Share of deployments requiring immediate intervention |
| Deployment rework rate | Share of unplanned deployments caused by a production incident |
These describe delivery outcomes for an application or service. They are not a universal code-quality grade or an individual performance ranking. Compare context and trends rather than imposing a daily deployment quota. Historical “elite/high/low” bands from a particular report should not become timeless minimum requirements for every team.
DORA delivery metrics and code review answer different questions. Nothing here establishes that process measurement is categorically better than inspecting code.
Signal #1: Recovery and the Rollback Test
Ask: “If this release causes a problem, how will we restore the service?”
Look for a tested procedure, an accountable person and evidence about recovery time and data effects. A rollback button is useful only when the old application remains compatible with changed data and dependencies.
A forward fix, feature flag or traffic switch can be a deliberate recovery method. “We will push a fix” is not automatically wrong; an untested assumption that someone will improvise is the concern.
Amazon’s rollback-safety guidance explains compatibility and upgrade/downgrade testing. It does not establish a universal five-minute recovery requirement.
Signal #2: Testing the Important Risks
Ask: “What could this change break, and what evidence checks that?”
Ask for tests of the critical calculation, permission boundary or customer journey, plus appropriate manual exploration. Existing tests may cover a change without a new test file. A large refactor can need regression evidence; a small configuration change can still carry high risk.
DORA’s test-automation guidance supports fast, reliable automated feedback alongside relevant manual testing. Counting tests, changed lines or coverage alone does not establish effectiveness. Ask whether a test would catch a meaningful failure and whether failures are acted on.
Signal #3: Deployment Frequency in Context
Ask: “What was deployed, how often, and what caused trouble?”
Record actual releases and their scope. Frequent small changes can improve feedback, but frequency does not prove they are safe or useful. A rarely changed informational site and an active transaction platform have different release demand.
Discuss avoidable batch size, manual steps and waiting alongside customer requirements. Do not assume monthly deployment means incompetence or demand extra releases to improve a metric.
Signal #4: Change Lead Time
Ask: “For a recent change, how long was commit-to-production, and where did it wait?”
Keep this distinct from idea-to-delivery time, which includes discovery, prioritization and implementation. If both are useful, measure both under different names.
Follow actual changes through review, testing and deployment. A slow interval can reflect a bottleneck, an intentional release constraint or work waiting for business approval. Ask for the evidence before assigning the cause.
Signal #5: Trade-Off Transparency
Ask: “Which limitations or uncertainties did we accept, and when should we revisit them?”
Look for a record tied to business consequences: expected data sizes, supported devices, reliability assumptions, omitted scope and future migration costs. A useful answer states what would trigger more work.
Not every implementation must contain a deliberate shortcut. An engineer saying a bounded task is complete is not proof that they are hiding debt. Seek specific acceptance evidence and remaining risks rather than requiring a confession of problems.
Signal #6: The Failure Demonstration
Ask: “In a safe test environment, what happens if this dependency fails or the user retries?”
Pick a relevant scenario: invalid input, a delayed payment response, a lost connection or a duplicate submission. Check user messages, retry behavior, data integrity and operational visibility.
Do not assume a failed payment should simply tell the user to retry: first establish whether the charge succeeded and how duplicate processing is prevented. A generic error in a demo is work to investigate, not a complete diagnosis of the application.
Use a Small Evidence Log
For each review, record the application, time window, metric definition, denominator, important releases and unresolved actions. Use trends alongside customer and business outcomes.
For example, if one of 12 deployments requires immediate intervention, the observed change fail rate is 1/12 ≈8.33%. That invented example is not an industry benchmark, and a small sample is noisy. Recovery from one failed deployment says little about every future incident. A month with zero deployments has no deployment-failure-rate denominator; do not label it a perfect 0%.
Review recovery after an incident, tests when behavior changes and trends on a cadence appropriate to the system. A monthly meeting is an operating choice, not a mandatory DORA practice.
What These Conversations Can and Cannot Prove
They can surface missing evidence and help assign improvement work. Confidence, defensiveness or needing time to investigate cannot by themselves establish code quality, dishonesty or competence. Define the business need and follow through on unresolved risks.
When the risk warrants specialist examination, include technical review, security assessment or a recovery exercise. Public website checks cannot inspect private source, test quality or internal deployment practices.
Use the broader 50-question checklist to explore operations, and distinguish source escrow from direct access for continuity. If you need help interpreting the evidence, request an independent review.
