Lead time looks simple on a chart: the gap between the first commit that belongs to a change and the moment that change reaches production. In practice, teams stretch or compress that gap by how they define “start,” how they batch merges, and whether hotfixes count.
For CI/CD workflow analytics, the useful move is to split lead time into coding, review, queue, and deploy segments. A Busan product team we worked with discovered that their “slow releases” were mostly overnight queue waits on a shared runner pool — not developer idle time.
Before you set a target number, ask three questions: Does the clock start at branch creation or at merge to main? Do you exclude changes that never intended to ship? Are failed deploys counted until the successful retry? Honest answers make the metric usable for release planning instead of a scoreboard nobody trusts.
If you only track one number, track the median of the deploy segment separately from review wait. Those two levers are owned by different people, and mixing them hides the conversation you actually need.