If you’re the relevant code reviewer, I believe unblocking your teammate should be your highest priority at the next reasonable stopping point in your work.
That’s a strong opinion I developed before AI coding tools. It’s heavily influenced by Google’s guidance on review speed, which puts team delivery ahead of maximizing each developer’s individual output. AI changes the conversation, but the problem I’m describing existed well before it.
Slow reviews create more work
I can produce a high volume of work. If I’m waiting for a review, I’ll usually keep going. I branch off the pending change, build the next piece, and then branch again.
By the time I receive feedback on the first PR, I might be two to four branches deep.
Now a correction to that first change needs to propagate through everything above it. Depending on the feedback, that can involve conflicts, changes to downstream behavior, and another round of verification. What could have been a straightforward correction has become a substantial amount of toil.
So the delay has two costs. The original change waits to get into production, and the work built on top of it becomes more expensive to correct.
Eventually, there’s a strong incentive to stop.
I can keep building and accept that I’m creating more work for myself when the feedback arrives. Or I can wait for the review. When continuing carries enough annoying correction work, waiting starts to look reasonable.
That’s a frustrating situation to put someone in when they’re ready to make progress.
The individual incentives are awkward
There’s a clear incentive to finish your own project. You deliver something, people can see it, and you look productive.
Reviewing somebody else’s code takes time away from that. The benefit goes to their project and the team, while your own work appears to slow down.
A tech lead, code steward, or someone invested in the architecture may already see review as central to their role. For other engineers, that connection can be weaker.
And code review can be uniquely difficult in an unfun way. You’re reconstructing somebody else’s thinking, looking for problems, and deciding which concerns matter enough to raise. It’s demanding work, and the result is often less visible than shipping your own feature.
I think this helps explain why reviews get deferred even on teams where everyone agrees they’re important.
The team benefits from rapid reviews. The individual incentives don’t necessarily make rapid reviews the obvious choice.
Send useful feedback as soon as you can
My own approach is to treat a review request as unblocking work.
I’m fairly interrupt-driven unless I’m doing something that requires deep focus. When a request comes in, I find the next comfortable stopping point in what I’m doing, then work on the review.
Google makes a similar allowance for focused work: respond promptly at a reasonable break rather than interrupting yourself mid-task. Its guidance also distinguishes response speed from the time required to complete the whole review. Speed of Code Reviews
That distinction matters. You can give someone useful feedback before you’ve finished evaluating every part of the change.
Google’s review checklist covers design, functionality, complexity, tests, naming, comments, style, consistency, and documentation. My first concerns are usually design and functionality. I want to understand what the change is trying to do and whether its approach makes sense.
If there’s a blocker there, I want to deliver that feedback immediately. The author can start addressing it while I continue the review.
In an ideal situation, a review might take me ten or fifteen minutes, but I could give you the feedback you need to move forward at minute three or four. Holding that feedback until I’ve collected every remaining comment adds waiting time.
Be clear that the review is still in progress. Early feedback gives the author something useful to act on; approval still requires completing the review.
Managers need to make this an expectation
I believe team velocity should be the priority. Selling that expectation to a team is something I haven’t solved particularly well as an IC.
You can review promptly yourself. You can explain the cost of delays and try to influence how the team works. But you’re asking people to prioritize work whose benefit may be less visible than their own delivery. Influence without authority can be an uphill battle.
As an EM, you have the authority to make unblocking work an explicit expectation. You can make it part of what the team considers productive work, rather than leaving it to whoever happens to care most about the codebase.
If people are expected to prioritize reviews, that expectation needs to be reflected in how their work is evaluated. Otherwise, you’re asking them to slow their visible individual progress while continuing to reward that progress.
Rapid, useful code review is part of delivering software together. I want the person reviewing my code to take that responsibility seriously, and I think I owe my teammates the same.