Code review is the queue nobody staffs

Google's public engineering practices devote an entire document to the speed of code reviews, and its core instruction is blunt: when review latency is slow, velocity, quality and morale all degrade, so reviews should come back within one business day at the outside. The document treats review turnaround as a system property to be engineered. Most organizations we read treat it as weather: everyone complains, no one owns it, and it varies with the season.

The diagnostic numbers are sitting in your version control already: time from review requested to first response, and from first response to merge, by team, in trend. Pull them and two patterns usually fall out. A small set of overloaded approvers, often the same senior engineers the meeting audit found, gating a wide surface through ownership files nobody has pruned. And a daily rhythm where reviews happen in one afternoon batch, which silently adds a day to every change requested after lunch.

The fixes match the causes: widen ownership deliberately, make first-response time a team norm with the same standing as build health, and treat any file requiring one specific human's approval as the bus-factor finding it is. The tradeoff is real reviewer time made explicit, on calendars, instead of extracted invisibly. Review latency multiplies into every lead-time number you track. Staff the queue like you mean it.