Reading wait time between review and merge

When teams talk about slow delivery, they often point at coding speed. In many assessments we run in Gyeonggi and Seoul, the longer stretches sit after someone has finished writing: waiting for a review, waiting for a second approval, or waiting for a quiet moment to merge.

Wait time is useful only when you define the clock. Start the clock when the author marks the change ready. Stop it when the change lands on the main branch. Everything between those two events is either active review, clarification, or idle queue.

Idle queue shows up as long gaps with no comments. Active review shows clusters of discussion. Clarification shows back-and-forth that never touches the code. Labeling those three separately keeps a lead from asking authors to “code faster” when the real delay is an overloaded reviewer list.

A practical habit: once a week, sample ten merged changes and mark each day of wait as idle, active, or clarifying. Patterns appear quickly—Friday freezes, single-reviewer bottlenecks, or changes that bounce for missing context rather than defects.

If your tracker already records ready-for-review and merged timestamps, you do not need new software to begin. A shared sheet and agreed labels are enough to start a grounded conversation in the next retrospective.