Code review is one of the highest-leverage engineering rituals. Strong code review cultures produce better code, faster onboarding, more mentorship, and lower defect rates. Weak code review cultures produce bottlenecks, conflict, and bugs in production. As an EM, your job is to shape the culture deliberately.
What healthy code review looks like
- Reviews complete within 1 business day for non-urgent changes, faster for urgent
- Reviews focus on substance — design, correctness, testability, maintainability
- Comments are kind, specific, and actionable
- Junior engineers get more substantive feedback than senior engineers
- Disagreements escalate cleanly when needed
- Reviewers respect the author’s ownership
The five common dysfunctions
1. Review paralysis
PRs sit for days. Authors lose context, reviewers feel overwhelmed, velocity dies.
Fix: set explicit SLA (1 business day). Track median time-to-review as a team metric.
2. Bike-shedding
Reviews focus on indentation, variable names, and brace placement instead of design.
Fix: automate everything that can be automated (linters, formatters). Establish that style is not for human review.
3. Snark and ego
Comments are dismissive, sarcastic, or condescending. Authors dread submitting PRs.
Fix: model and enforce kind direct communication. Address bad behavior directly with the offender. Reset team norms publicly.
4. Rubber-stamping
Reviewers approve without reading. Quality drops; bugs ship.
Fix: sample reviews; surface defects that should have been caught. Track team defect rates.
5. The bottleneck reviewer
One senior person reviews everything; everyone waits on them.
Fix: distribute reviews. Make sure 3+ engineers can review any given area.
Establishing standards
Document what good code review looks like at your team. Examples of explicit standards:
- “Every PR has an associated test or rationale for skipping”
- “PR descriptions explain the why, not the what”
- “Reviews focus on design, correctness, and tests”
- “Style is enforced by CI; do not comment on it”
- “Suggestions vs blocking comments are clearly distinguished”
Speed targets
The two key metrics:
- Median time-to-first-review: <4 hours during business day
- Median time-to-merge: <1 business day for typical PRs
Slower than this and the team is in friction. Track at the team level; expose to engineers.
How to give good feedback
Adapted from Google’s code review style guide:
- Be kind. “Could we…” beats “You should…”
- Explain why. “This is hard to read because X” beats “this is hard to read”
- Suggest alternatives. “Consider extracting this to a helper” beats “this is too complex”
- Distinguish severity. “Blocking: this will crash on null” vs “nit: typo in comment”
How to receive feedback
As a manager, model receiving feedback well. Engineers watch:
- Acknowledge the comment before defending
- Ask questions to understand
- Adjust if the feedback is right
- Disagree in writing if the feedback is wrong; never argue in tone
The senior IC review burden
Senior engineers often disproportionately review. Address:
- Distribute reviews across the team
- Mentor junior engineers to review (with guidance)
- Time-box senior reviewer load
- Recognize review work in performance reviews
Cross-team reviews
For changes that affect another team, require explicit reviewer from that team. Build cross-team relationships before you need them.
The CODEOWNERS file
Most modern Git platforms support CODEOWNERS — automatic review assignment based on path. Use it. It removes “who should review this?” friction.
Frequently Asked Questions
Should the EM review code?
Sometimes. As a quality check on critical paths, as a coaching opportunity, or to stay technical. But not as a bottleneck — your reviews should not be required for normal PRs.
How do I handle an engineer who gives bad feedback (snarky, vague, or wrong)?
Address it directly in 1:1. Show specific examples. Coach toward better patterns. Make it clear that review behavior is part of performance.
How do I scale review culture as the team grows?
Document the standards. Onboard new engineers explicitly to them. Designate reviewer leads in subteams. Run periodic “code review jam” sessions where the team reviews and discusses real PRs together.