Code review is the highest-frequency leadership ritual most teams already have. Most teams underuse it.
I have watched reviews become gatekeeping theater: nitpicks, style wars, vague “this feels off,” and silent approvals that teach nothing. I have also watched reviews become the reason a team leveled up in a quarter.
Review for the next PR, not only this PR
A useful comment answers: what should this author do differently next time?
- “Extract this boundary because X will change.”
- “This retry will double-write under Y condition.”
- “Name this after the business event, not the table.”
- “Add the failure mode to the doc so support can reason about it.”
If your comments only clean the current diff, you are editing. Editing is useful. Teaching is compounding.
Tone is a delivery feature
Harsh reviews create hidden queues. People delay PRs, over-polish, or avoid ownership. Kind reviews without standards create junk.
The standard I aim for: direct, specific, respectful, and tied to production risk or maintainability. No vibes. No dominance games.
Teach with alternatives, not only objections
“Don’t do this” is weak teaching. Better:
- name the risk
- offer one alternative
- explain when the alternative is wrong too
That third part matters. Absolute rules create cargo cults. Judgment creates engineers.
Leaders should review the reviews
If you lead, sample how your seniors review. Are they transferring mental models or just defending taste? Are juniors getting patterns they can reuse? Are the same comments repeating without becoming docs?
Repeated review comments are unpaid interest on missing documentation.
Leadership takeaway
Every PR is a classroom. Companies that treat review as bureaucracy stay stuck at current skill level. Companies that treat review as teaching raise the average quality of every future change.
That is growth you cannot buy with a hiring surge alone.