Good code review vs productivity black hole

A junior developer came to me once, frustrated and a little embarrassed. Their feature was done. Tests passing, code clean. But the PR had been sitting for four days without a review. Meanwhile, the sprint review was coming up, and they were about to look like they’d missed their commitment, for work that was finished.

The product manager had already flagged it to me as a missed deadline. The developer wasn’t unreliable. The review process was.

That’s code review when it breaks: invisible, demoralizing, and corrosive to the kind of trust a team takes months to build.

What code review is actually for

Before getting into what goes wrong, it’s worth being clear on what a pull request review is and why it exists, since it’s misunderstood in both directions.

When a developer finishes a piece of work, they open a pull request asking to merge it into the main codebase. Before it’s merged, another engineer reviews the changes. The review catches bugs, yes. But it also spreads knowledge: reviewers learn about parts of the codebase they don’t touch, and authors get a second perspective that often improves the design. Over time, consistent reviews are what keeps a codebase coherent as a team grows.

When done well, code review makes teams faster. It reduces the rate of bugs reaching production. It makes onboarding faster because the codebase stays legible. Done poorly, it becomes a bottleneck that erodes both momentum and morale.

How review delays cascade

The developer in that story picked up new work while waiting. By the time feedback arrived, they’d fully context-switched. Going back to the PR felt like restarting a task they’d mentally closed. The energy was gone.

That’s the pattern: a PR sits, the author moves on, the feedback lands late, re-engagement is expensive, and the quality of the response to the feedback suffers. Multiply that across a team and you end up with a PR queue nobody owns, a growing backlog of unreviewed work, and engineers who quietly stop caring about quality because they’ve learned nobody will look at it on time anyway.

The insidious part is that none of this shows up on the roadmap. Sprint velocity looks fine. The burndown chart looks fine. The damage is in the gaps.

What a functional review process looks like

Small pull requests. This is the single highest-leverage change most teams can make. A 500-line PR takes four times as long to review as a 125-line one and produces worse feedback. Large PRs get rubber-stamped or ignored because reviewers can’t hold the whole thing in their head. Split the work, merge more often.

Explicit ownership and time expectations. Someone is always on review rotation. If you can’t get to a PR within 24 hours, you say so and hand it off. This is not politics. It’s the same coordination any other blocked ticket would get.

A shared standard for what feedback looks like. Reviewers should distinguish between blocking issues (the code is wrong and needs to change), non-blocking suggestions (this would be better but isn’t a dealbreaker), and optional notes (just thinking out loud). Mixing these up is how reviews become demoralizing: an author can’t tell whether a comment requires action or is just one person’s preference.

When I managed the developer with the stale PR, I told them to raise it in standup. Code review is part of the sprint. A blocked PR is a blocker, same as anything else. Just asking “can someone get to this today?” is usually enough. Most of the time, reviews stall not because nobody cares, but because nobody asked.

What managers should actually track

EMs don’t need to review every PR. But they need to know whether the process is healthy.

Average time from PR opened to first review. Average time from first review to merge. How many PRs have been open more than three days. Those numbers tell you whether work is actually flowing or quietly piling up.

Bring it into retrospectives. Ask in 1:1s whether people feel blocked waiting for reviews. Redistribute the load if one senior engineer is doing 80% of the reviewing and burning out.

And then pay attention to the reviews themselves. I’ve seen senior engineers blast through reviews and miss critical context. I’ve seen junior engineers write detailed, thoughtful reviews that showed more care for the codebase than anyone expected. How someone reviews tells you a lot about how they think and how much they’re invested in the team’s output. It’s worth watching.