01 · DIAGNOSTIC FRAMEWORK

Turn the symptom into a testable decision.

Long lead time and unstable production rarely come from one tool. Follow work through queues, reviews, tests, deployment and recovery to find the actual constraint. The sequence below is designed to preserve definitions, expose alternative explanations and lead to a decision that can be validated.

  1. Define the delivery unitChoose commit, pull request, change set or release and keep the unit consistent across repositories and deployment systems.
  2. Build the event timelineJoin commit, review, CI, test, approval, deployment, alert and incident timestamps.
  3. Separate work from waitMeasure queue time, rework loops and blocked time rather than only average pipeline duration.
  4. Segment before comparingSeparate emergency fixes, platform work, product changes, services and teams with different risk profiles.
  5. Test at the constraintChange review policy, test selection, environment provisioning or rollout for one bounded workflow.
02 · EVIDENCE

Ask for the minimum data that can change the answer.

Begin with read-only access and a field-level purpose. Reconcile samples before scaling extraction, preserve event time and source provenance, and record missingness rather than silently filling it.

Code and reviewCommits, pull requests, reviewers, comments, approvals, rework, ownership and dependency changes.
Continuous deliveryBuilds, tests, flaky failures, artifacts, environments, approvals, deploys, rollbacks and feature flags.
ReliabilityAlerts, incidents, severity, affected service, detection time, mitigation, recovery and post-incident actions.
Business contextUser impact, release intent, risk class, compliance gate, product metric and support volume.
03 · PROOF OF CONCEPT

Validate the claim before changing the operation.

Instrument one value stream and remove one verified queue

Select a service with representative volume and rebuild four to eight weeks of delivery history. Confirm that the timeline reproduces known releases and incidents. Then change one bottleneck—such as redundant approval for low-risk changes or serial tests that can run safely in parallel—and compare elapsed time, failure rate, rework and operational load against a pre-set baseline.

04 · FAILURE MODES

What makes the diagnosis look right and still fail.

  • Measuring coding time onlyMost lead time often sits in queues, handoffs and environment waits.
  • Comparing unlike servicesA regulated monolith and a low-risk stateless service should not share an unqualified target.
  • Chasing deployment frequency aloneSmaller releases help only when customer value and reliability remain intact.
  • Blaming review countReview delay may reflect ownership ambiguity, oversized changes or unavailable environments.
  • Using incident totals without exposureNormalize failures by changes, service traffic or risk class.
05 · SOURCE TRAIL

Primary and official references

These sources define the measurement, control or operating context. They do not replace validation on the company’s own data.

  1. DORA, The Four Keys
  2. Google, Site Reliability Engineering book
  3. CISA, Secure by Design
06 · FAQ

Questions enterprise teams ask first.

Which delivery metrics should we start with?

DORA’s deployment frequency, lead time for changes, change failure rate and recovery time are a strong start; add business and workload context.

Can repository data identify the root cause?

It reveals code and review behavior but usually needs CI/CD, observability, incident and team-context data.

What is a good first PoC?

Choose a high-volume, reversible constraint with reliable timestamps and a clear safety guardrail.

Should teams be ranked by DORA metrics?

No. Use the measures to improve a system. Rankings invite gaming and ignore architecture, risk and workload differences.