Review Latency
The time between a change being ready for review and the review happening, which is usually the largest component of lead time.
In most teams, changes spend far longer waiting for review than being written or reviewed. It is frequently the single largest contributor to lead time, and it is invisible unless measured.
The costs are not only delay: while waiting, the author context-switches to other work, the branch diverges from trunk, and by the time feedback arrives the author has lost the context needed to act on it efficiently.
What reduces it: small changes, which are the strongest lever — a 50-line change is reviewed quickly and thoroughly, a 500-line change is skimmed after a long wait; an explicit team expectation, such as review within four hours; notification and rotation so review is assigned rather than volunteered; and pairing or mobbing, which removes the wait entirely by making review synchronous.
What makes the review itself worth the latency: reviewers focused on correctness, design, security and readability rather than formatting, which belongs to a formatter; automated checks running first, so human attention is not spent on what a linter catches; and comments that distinguish blocking concerns from suggestions.
The framing that improves both speed and quality: review is a knowledge-sharing mechanism as much as a defect-detection one, which is why it should be spread across the team rather than concentrated in one gatekeeper.