11 May 2026
Reading lead time without vanity charts
Lead time looks simple until you average unlike work. A hotfix that sits three days in review and a feature that waits overnight for a shared test environment are not the same story, yet many weekly dashboards blend them into one number that looks healthier than the release experience feels.
Start by splitting commit-to-deploy intervals by change class: hotfixes, standard features, and infrastructure changes. Then mark the waits that belong to people—reviews, approvals, frozen windows—separately from the waits that belong to machines—queue time, flaky suites, environment provisioning.
When we run a Delivery Performance Assessment, we ask for ninety days of history and rebuild those splits by hand before trusting any chart. Teams often discover that the longest waits sit between “tests green” and “approved for production,” not inside the build itself.
A practical next step: pick one application with weekly releases, label the last twenty deploys by change class, and plot only the human waits. That single chart usually sparks a clearer conversation than a polished multi-metric board.