Interview prompt. A travel platform in Expedia's mould reports elite DORA metrics - deployments multiple times a day, lead time for changes under an hour, change failure rate about 5%, time to restore under an hour. The business says delivery is slow and cannot plan around it. Reconcile those two statements.

What the interviewer is testing

Whether you know what lead time for changes actually measures. It is measured from commit to production. Everything before the commit — discovery, specification, design, prioritisation, dependency on another team, a security review, a procurement decision — is outside the metric entirely.

A team can be genuinely elite on all four DORA metrics while the time from "the business asked" to "the business got it" is five months. Both statements are true and they are about different intervals, and the candidate who sees that has answered the question.

The clarifying questions that change the answer

• What is the business measuring? Almost always time from request to availability, or predictability of a date. Neither is a DORA metric.
• Where does work wait? Measure the queue before the commit: time in backlog after prioritisation, time waiting for a dependency, time in review or approval, time waiting for a decision.
• What is the batch size of a request? A quarter-sized feature delivered in 40 deployments still arrives at the end. High deployment frequency with large work items gives fast deployments and slow delivery.
• Is the failure rate concentrated? A 5% change failure rate spread evenly is noise; the same rate concentrated in one high-value path means the business experiences delivery as unreliable regardless of the average.
• Is anyone counting abandoned work? Items started and dropped consume capacity and never appear in any delivery metric.

A strong answer's arc

Measure the whole interval, then attribute the wait. Flow metrics complement DORA rather than replacing it: flow time from request to delivery, flow efficiency (hands-on time divided by total elapsed time), flow load (work in progress) and flow distribution across features, defects, debt and risk.

Flow efficiency is the number that usually ends the argument. Teams that measure it commonly find it in the range of 10 to 25%, meaning most of an item's life is spent waiting rather than being worked on. If DORA says the last hour was fast and flow efficiency says the preceding six weeks were waiting, the business is right and the engineering metrics were never measuring the complaint.

Then fix the dominant wait, which is usually one of three: work in progress above what the team can flow, an approval or dependency with no deadline, or batch size. Each has a different intervention, and only the third is an engineering change.

Common weak answers

• "The business does not understand our metrics." The metrics do not measure what the business asked about. This answer is the failure the question is designed to find.
• "Add more deployment automation." The deployment is already an hour. Optimising the fastest part of the system is the clearest sign of measuring the wrong interval.
• "Give them a roadmap." Predictability is a legitimate ask and a roadmap without measured flow time is a guess, which is how the trust was lost in the first place.

What a strong answer adds

Two things. The organisational read: the waits that dominate flow time usually sit between teams or between functions, so the fix is a decision-rights or dependency change rather than a pipeline change, and an engineering leader who only owns the pipeline cannot fix it alone.

And the predictability point, which is what the business actually asked for. Flow time has a distribution, and quoting its 85^th percentile — "features of this size reach production within 6 weeks, 85% of the time" — is a commitment that can be planned around, because a percentile already contains the variance a mean hides. A mean is not a commitment and an elite deployment frequency is not a date.

The trade-off to state plainly: cutting work in progress is what shortens flow time, and it costs the appearance of progress. Ten items at 20% flow efficiency look busier than four items at 60% and deliver later. Prefer fewer items in flight unless the queue is genuinely waiting on an external party, in which case reducing load changes nothing and the dependency is the thing to fix.