Code Review Culture: What Healthy Teams Do Differently

TL;DR: Tooling defines your review process; norms define your review culture, and the norms decide whether review teaches or just gates. Healthy teams share five: review is scheduled work, everyone gets reviewed (especially seniors), comments carry reasons and severity, teaching is an explicit goal, and disagreements have an ending. The receipts are strong: DORA links faster review to ~50% higher delivery performance, and the research consistently finds review's real product is shared understanding.

Two teams, identical setups: same Git host, same required-review rule, same linter. On one, review is where the team gets smarter. Questions get answered with reasons, juniors review seniors, threads end in decisions. On the other, review is a toll booth: PRs age silently, feedback arrives as verdicts, and everyone has a story about the thread that hit forty comments and settled nothing. Same process. Different culture. And culture is the part no branch-protection setting can configure.

What is code review culture, actually?

The set of unwritten answers to questions the tooling never asks: Is reviewing someone's code real work, or a favor? Who's allowed to critique whom? What does a comment owe its reader? Does a review end when the author is unblocked, or when both people understand the change?

The research gives culture a concrete job description. Across Microsoft's interviews and observation, finding defects is what everyone says review is for. The measured outcomes lean toward knowledge transfer, team awareness, and alternative solutions. Google's study of ~9M reviewed changes likewise names education as a core purpose of review. And what reviews catch is mostly judgment territory: 75% evolvability defects (clarity, structure, maintainability), per Mäntylä and Lassenius.

Follow the chain. Review's main products are learning and shared understanding, and its main findings are arguable by nature. A practice like that runs on trust and norms, or it stops running and just processes approvals.

Nor is culture a "soft" concern you address after the metrics work. DORA's 2023 research found teams with faster code review show ~50% higher software delivery performance. The culture failures are precisely what makes review slow: PRs nobody feels responsible for picking up, threads that re-litigate settled questions, authors batching changes into giant PRs to face the gauntlet less often.

What do healthy review cultures do differently?

Five norms, observable in the data and in the room:

1. Review is scheduled work, not an interruption. Unhealthy teams treat reviewing as a favor stolen from "real work," so it happens late and shallow, and pickup time tells the story. Healthy teams budget it: review blocks on the calendar, review counted in capacity, and "I spent the morning reviewing" is a normal sentence.
2. Everyone gets reviewed, the seniors most visibly. The single strongest culture signal is what happens to the most respected engineer's code. Where seniors ship unreviewed while juniors run the gauntlet, review is revealed as status enforcement, and everyone recalibrates accordingly. Where the tech lead requests review, gets pushback, and visibly acts on it, one thread teaches more than any values doc. Google's norm of essentially every change reviewed, median one approver, no exceptions by rank, is a culture statement wearing a process costume.
3. Comments carry reasons and severity. "No" is a verdict. "No, because" plus a severity label is feedback. Healthy teams also automate the style layer into linters, which is a cultural act as much as a technical one: it declares that human attention is reserved for what machines can't judge, and it deletes the recurring nit-fight that poisons threads.
4. Teaching is an explicit purpose, said out loud. Once knowledge transfer is named as half the point, behaviors reorganize: reviewers explain instead of decree, authors route PRs to whoever should learn the area (not only whoever knows it), and "assign the junior as second reader" becomes normal. This is also your cheapest bus-factor program. Every taught review spreads ownership one change at a time, and a tiny team can't afford to skip that even once.
5. Disagreements have an ending. Healthy cultures define the exit before the fight: two rounds in the thread, then a synchronous call, decision posted back, done. Unhealthy ones let threads trail off. An abandoned thread teaches everyone that comments are decoration, which is how rubber-stamping becomes rational politeness.

Signs your review culture is sick

The symptoms hide in plain sight, in your PR data and your Slack:

• PRs age before first touch. Nobody owns pickup; everyone assumes someone else will. The queue's stuck PRs are a responsibility vacuum made visible.
• Approval speed doesn't vary with size. The five-minute approval on the thousand-line diff is theater, and fully rational where honest reviewing is unrewarded and unbudgeted.
• One person is the review bottleneck. All roads route through a single gatekeeper - a load concentration that burns them out and starves everyone else of the teaching.
• Authors fear the queue. Padding PRs to batch the pain, timing submissions around a reviewer's moods, pre-negotiating approvals in DMs. When authors optimize around review instead of through it, the culture has already failed; the metrics just haven't caught up.
• The same argument, every week. Tabs, naming, structure, refought per-PR because nobody encoded the decision into a linter or a written convention. Friction without memory.

How the norms actually move

Not with a values deck. Norms move when defaults move and when status moves, so change those:

1. Put review in the capacity math. If sprint planning assumes review is free, the culture will price it accordingly. Count it, and watch pickup behavior change within weeks. The cost of the slow queue was always real; counting it puts it on the books.
2. Have the seniors go first. One week of the most respected engineer visibly requesting review, receiving a blocking comment, and thanking the reviewer will do what no policy memo can.
3. Adopt a comment convention. Severity labels (blocking / suggestion / nit), reasons required, style questions redirected to the linter backlog. Write it down once; it referees forever.
4. Define the deadlock exit. Agree on the two-rounds-then-call rule before the next fight, not during it.
5. Watch the trend, not the villains. Pickup time, comment rate, and coverage are system health signals, never a leaderboard. The moment review metrics become an individual scoreboard, people optimize the score and the culture you were measuring evaporates.

The door: pick the norm your team is furthest from - for most, honest severity labels or the senior-goes-first move - and run it for two weeks. Culture is just the stuff everyone does without deciding to. Change one default, let it compound, and the toll booth starts turning back into the place your team gets smarter.