Delivery leadership says releases are too slow and wants the engineering team to "move faster". Lead time from commit to production is 21 days. How do you investigate, and what do you expect to find?
Show the full answer Hide the answer
Do not accept the framing
"Move faster" assumes the constraint is how fast code is written. That is almost never where the twenty one days went, and starting an engineering productivity initiative on that assumption spends a quarter improving a number that is already small.
Split the number before doing anything else
Resolve elapsed time into work time and wait time, and name each wait. Ticket state transitions plus commit, pull request and deployment timestamps usually contain enough to do this without new instrumentation. You want a table like:
| Step | Work | Wait | Waiting on |
|---|---|---|---|
| Refinement | 1 d | 6 d | Backlog |
| Build | 4 d | — | |
| Code review | 0.5 d | 3 d | Reviewer availability |
| Test | 2 d | 5 d | Shared test environment |
| Release | 0.5 d | 9 d | Fortnightly release window |
Flow efficiency here is 8 / 21, about thirty eight percent, and that is on the better side of typical. Fifteen to twenty five percent is common.
What you expect to find
Three candidates dominate in practice, and none of them are coding speed:
- A release window. A fortnightly window adds an average of five days and up to ten to every change, regardless of when it was ready. It is a policy, and changing a policy is faster than changing an organisation's skill.
- An environment queue. One shared test environment across six teams serialises testing. Ephemeral environments remove the queue entirely.
- Batch size. Large changes wait longer at every step, take longer to review, and fail more often — so they also generate rework, which the table above does not even capture.
Act on the largest queue only
The classic error is optimising a step that then waits longer at the next queue, which changes the total by exactly zero. Attack the biggest wait, re-measure, and find the new biggest wait. In the example, moving from fortnightly to on-demand release removes up to nine days on its own — more than any plausible improvement to the four days of build work.
What to say to leadership
Show the split. The conversation changes from "your engineers are slow" to "our release policy and our environment capacity cost us fourteen of the twenty one days, and both are ours to change". That is a fundable proposal rather than a performance complaint.
The follow-on
Once lead time falls, watch change failure rate. If it rises, the release window was doing real work — as a batch inspection — and that work now needs to be done by the pipeline: progressive rollout, automated verification and a rehearsed rollback. Removing a control without replacing its function is how "we went faster and broke more" happens.