Why code review takes a week

When pull requests sit for a week, the diagnosis usually offered is cultural: the team doesn’t value review, people are protective of their own work, nobody wants to be the bottleneck. Then someone writes a policy document about review expectations, and nothing changes.

The diagnosis is usually wrong. Slow review is normally a scheduling problem wearing a motivation costume.

What a week of waiting actually looks like

A video streaming company with a 5-person dev team, working mostly synchronously and partly from the office, had PRs waiting up to a week before merge.

Nobody on that team was refusing to review. The structure of the day simply never produced a moment where reviewing was the obvious thing to do. Review is the task that always loses: it’s someone else’s work, it has no deadline attached to it personally, and there is always something in your own column that feels more urgent. Multiply that by everyone and PRs age.

Two changes

A fixed hour, every day, right after standup, for reviewing open PRs. Not “please review promptly.” A slot on the calendar with one purpose.

A WIP limit: no new PRs while old ones are still waiting. You don’t get to keep opening new work while the queue behind you grows.

Result: PR wait time dropped from about a week to one day, two at most.

Why each change is load-bearing

The fixed hour removes the decision. The reason review loses to other work isn’t that people rank it lower in principle — it’s that it competes, every time, against work with an owner and a deadline. Putting it in a fixed slot means it stops competing. Attaching it to standup, which already happens reliably, means the slot inherits an existing habit instead of needing a new one.

The WIP limit fixes the direction of pressure. Without it, the person producing PRs fastest imposes the most cost on everyone else and feels the least of it — their own work keeps flowing while the queue grows behind them. With it, the cost lands on the person creating it. Suddenly reviewing an open PR is the fastest way to unblock yourself, which is a much more reliable motivator than a policy asking people to be considerate.

Either change alone helps less than you’d hope. The hour without the limit means a growing queue gets one hour a day and still grows. The limit without the hour means everyone is blocked with no scheduled time to unblock anything.

What this costs

Nothing, in tooling terms. There’s no product to buy, no integration to build, no dashboard to configure. Which is precisely why it doesn’t get done: no vendor is going to suggest it, and it doesn’t look like engineering work.

It does cost something real: the WIP limit is genuinely uncomfortable at first. It feels like throttling your best contributor. What it actually does is make an existing cost visible — the queue was always there, it was just invisible because it lived in other people’s waiting time rather than in yours.

Reading this in your own team

Two diagnostic questions:

1. Is there a time in the week when reviewing is the expected activity? If the honest answer is “whenever people get to it,” you have the scheduling problem, not a culture problem.
2. What happens to someone who opens a fifth PR while four wait? If the answer is “nothing,” the pressure is pointing the wrong way.

If both answers are unsatisfying, you can test the fix in a week. It’s reversible, it needs no budget, and the metric — time from PR open to merge — is already in your git history.

The general shape

Slow code review is usually the absence of dedicated time, not the absence of willingness.

That pattern recurs well outside review. When a team consistently fails to do something everyone agrees is important, the first thing to check is whether there is a moment in the week when doing it is the obvious action — and whether the incentives point at the person creating the backlog or at everyone else.

Most delivery problems that look like discipline problems turn out to be calendar problems. They are also, fortunately, much cheaper to fix.

If your delivery has slowed and the cause isn’t obvious from inside, that’s what a dev team performance audit measures.