A pull request opens on Monday morning. It is 400 lines, touching the payment retry path and a handful of tests. By Wednesday it has eleven comments, nine of them about naming and whether a helper should live in a different file, and no approval. The author has rebased twice. The reviewer is waiting for the author to respond. Nobody is sure whether it is blocked.
That scene is common enough that we have stopped treating it as a people problem. It is a culture problem, and culture here means something specific. The team has never agreed what review is for, so every reviewer answers that question alone and every comment carries the same weight.
Decide what review is for
Google's engineering practices document gives the clearest statement of purpose we know. The standard of code review says reviewers should favour approving a change "once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect." The guide's own summary is that there is no perfect code, only better code, and a change that improves the system should not sit "for days or weeks because it isn't 'perfect'."
Once a manager adopts that standard openly, several things change. The reviewer who blocks on preference is now outside the team's agreed position, which gives you something to point at. The author who ships a change that makes the system worse has no cover either. And the question in every review becomes concrete. Does this change leave the system healthier than it found it?
Rank what you look for
Google's list of what to look for in a code review runs from design and functionality through complexity, tests, naming and comments, with style near the end. The order is the point. Design comes first, with the question "Do the interactions of various pieces of code in the CL make sense?" Then functionality, which asks whether the change does what the author intended and whether that is good for the users of the code. Style arrives late in the list, and the guide expects it to be settled by a style guide rather than argued.
Matt Coles makes a related point in Reviewing code you didn't write. For a large change, he suggests finding "the path where the behaviour lives and the state changes", reviewing that first, and only then reading the surrounding code. His example is a fetch_price() function with hand-written retry logic that duplicated the client library's own retries, something you could not see from the diff alone. Finding it took checking out the branch and following the callers.
The manager's job is to make this ranking explicit. If the nine naming comments on that payment retry change had been labelled as nits, and the two real questions about idempotency had been labelled as blocking, the author would have known what to do on Monday afternoon instead of Wednesday.
Label severity, lead with consequence
Google's guide on writing review comments recommends three labels. Nit for small things with little impact, Optional or Consider for suggestions the author may decline, and FYI for information that needs no action. Everything unlabelled is a request. The guide also asks reviewers to be kind, to explain their reasoning, and to comment on the code rather than the developer. Its contrasting examples are worth repeating. The reviewer who writes "Why did you use threads here" would, in the guide's better version, write "The concurrency model here is adding complexity to the system without any actual performance benefit that I can see."
Coles adds a habit we would make a team rule. Start a comment with the consequence. His example reads "The queue can deliver this twice, so we may charge the customer twice", which tells the author in one line both why the comment matters and how urgent it is. A comment that begins with the consequence is hard to mistake for a preference. Block, in his words, only when the change is "wrong or the design will be expensive to unwind".
Make turnaround a commitment
The single thing most likely to end the complaints about review is turnaround. Google's page on the speed of code reviews sets the ceiling at one business day to respond, prefers a quick first response over a fast complete review, and states that making the process faster resolves most complaints about it. It also protects focus. A reviewer in the middle of a focused task should finish it rather than interrupt themselves.
The guide's page on handling pushback describes what happens when a team raises its standard. Developers complain, sometimes loudly, and the recommended response is to make reviews faster, which "usually causes these complaints to fade away." We have seen that hold. A reviewer who responds within hours can afford to ask for the tidy-up now, and the guide warns that "as more time passes after a developer writes the original CL, the less likely this clean up is to happen."
Turnaround is a team commitment and therefore the manager's to protect. That means noticing the pull request that has waited two days and asking why, rotating review load so one senior engineer is not the only approver for the payment path, and asking authors for smaller changes. Google's guidance on small changes is blunt that 1,000 lines is usually too large, and that small changes are reviewed both faster and more thoroughly.
What the manager refuses
Three refusals make the rest work. Refuse to let review be used to relitigate decisions already taken in design; if the design was wrong, that is a conversation outside the pull request. Refuse to let preference block, since the standard says style guides are the authority on style and technical facts outrank opinions, so a disagreement with neither behind it is a comment rather than a block. And refuse to resolve escalations by seniority. Google's guide suggests the author and reviewer try to reach consensus, then talk face to face, then escalate to a lead or manager. When it reaches you, decide on the principle, say which one, and the pull request moves.
Review culture is set by what a manager tolerates in the comment thread. The engineers will argue about whatever you let them argue about.
Where this sits in the standard
Code review and quality standards is a competency in the Technical Judgment domain of the EMA Competency Framework. The code review and quality unit of the Body of Knowledge covers how to set a review standard a team will keep, and the psychological safety unit covers how to keep disagreement productive once the standard is in place.
In the examination this appears as a situation in which review has become a bottleneck and a source of friction, and you decide what to change first. See what EMA-I covers.