Not a long time ago (three days ago actually), I opened a pull request (PR), tagged the appropriate reviewers, and moved on, assuming it would quickly get picked up and reviewed. Later (today), I came back to find the PR in the same state I left it. Everyone I tagged thought "someone else" would get to it, but shocker, nobody did. The fix wasn't even that complex; it was just never anyone's "job".

I've seen it over and over again, and it's a problem I'm hoping to fix here and not just for a single PR but for the whole team.

It's generally a best practice to have every change go through a PR process of some kind with a human-in-the-loop and automated tools. The automated half is the "easy" part because it's trivially easy these days to set up static and dynamic code analysis tools to run automatically. When I push a change, a bunch of containers magically spin up and start checking my code. They do it (mostly) without fail. The human half is where it's a lot messier.

"Code Review" is never on someone's Kanban board, but the six tickets we have to get done by next Friday are. If I tag three people to have a look at my code (or worse, a whole team), all of them might see the notification, but because they don't have "review Scott's code" above their "this is on fire" task, they all just go back to their own work assuming "someone else" will look at it. If you don't believe me, think of all the "group projects" you've done where tasks fall through the cracks when "nobody" is assigned to them.

Make "review" your next "default" task

I always like to look at how we can "reframe" our thinking about things that are seen as chores but are critical to our day-to-day lives. What's worked for me here is to not treat review as an "interruption" to my work and instead treat it as the default action every time I transition between tasks.

I want you to think about the moment you finish a ticket. I believe (apparently nobody's done research on this?) that most of us reflexively reach for the next tasks in the "Open" column. Maybe you look at your PRs to see if someone has approved them or asked for changes but ultimately you're just looking for the next thing that makes you look good in whatever metrics your team tracks. This isn't helping your team's metrics.

I changed this so when I perform a task switch, my default is to check what's waiting on my review and not what I do to improve some vanity metric for myself but for the team. Spending that switch on a review costs me so little and even gives me a much-needed break from "creation" mode.

It's a practice that can really cause your team's productivity to skyrocket. If everyone on the team has the same "reflex," the diffusion-of-responsibility problem reduces (if it doesn't completely go away) so PRs are merged faster and it removes everyone's blockers.

My tracker

The trouble with checking for reviews before doing something else is that it's not a "no-friction" situation. You have to open your browser, navigate to the correct page, and actually remember to do it. Then there might not even be anything for you to review, which makes you feel like you did it for nothing. That friction adds up, and you silently stop checking.

I wrote before about customizing my Claude Code status line, and I ended that post by saying my next step was to add my pending reviews to it.

I'm glad to say that my work status line now includes a count of the pull requests requesting my review. It looks like this:

PRs to review: 3

I didn't need to do much (or, in this case, my LLM didn't); I used GitHub's gh CLI to search for PRs where my review is requested using review-requested:@me. I have a script that runs that search in the background every 5 minutes, and then it automatically gets added to my Claude status bar along with the URLs to the PRs so I can just click on them when I'm ready.

That number lives in my status bar the whole day, and when it's above zero, that's my signal to finish up what I'm doing and do some reviews. I don't need to open up GitHub "just in case" because I already know. I've actually caught several pull requests so fast that they were approved and merged less than 15 minutes after I was assigned to the request.

Why this is important to your delivery metrics

PR "age" is a deliver-speed "problem" and it's one of the big four DORA metrics. The time between a PR being created and waiting for its review (first, second, or tenth) is time that is counting against your "Change lead time" metric. If it sits for three days untouched, you've burned three days of lead time when it could be a simple 5-minute "LGTM" approval, and it's going to add up.

The first-response tends to be the most expensive because it's when you're waiting for someone to "step up" and take ownership of its review. Once they've done the first one, they can quickly be contacted again to get it reviewed. Getting a person to review it within hours instead of days pulls those numbers down automatically.

What you can do

First, add the count and maybe the URLs somewhere you'll see it several times an hour. For me it was my Claude Code status line, but I'm also playing around with a floating native app (using Native PHP of course) so it's even more in my face. For you, it might be an automatically refreshing website on a dedicated monitor, but find some place where it will help you stop deciding if you should check and instead just react to an always visible number.

Then push to make it a team norm. "Check PRs before you start new work" is a simple "rule" you can ask your team to follow (forcing is obviously harder), but it turns the tracker from a personal habit to a review-first culture.