Here's a relatively small example: if you want to minimise lead time (which is almost always true) then one thing you don't want is for potentially releasable w

Here's a relatively small example: if you want to minimise lead time (which is almost always true) then one thing you don't want is for potentially releasable work to sit waiting for anything. That includes code reviews, if you have them on the route to production. So the right thing to do is usually for a PR being ready for a code review to be a drop-everything event for the person who's going to review it. As in, whatever you're working on right now, context switch out and do whatever is needed to get that code either over the line or bounced back ASAP so the person who wrote it doesn't context switch out. This idea gets a lot of pushback because we have it ingrained (not unfairly, either) that context switches are expensive for the reviewer. But the safe assumption is that they're less expensive than delaying another piece of work that's already got a lot of embodied but unrealised value. The intuitive assumption is that person waiting on the code review can pick up another piece of work and make a start on it so they're kept busy, but that falls into the trap of having too much work in progress. The result is then (usually) that the returned code review is now waiting for whatever they picked up. This is one reason why the intuitive way of working tends to having throughput that's barely ok, and latency that borders on ridiculous.