It sat there for six weeks. Not because it was bad. Because everyone assumed someone else was going to look at it. That's not a people problem. That's a systems problem.
The pull request was a refactor — nothing glamorous, nothing urgent. It cleaned up some authentication logic that had been accumulating technical debt for about two years. The code was solid. The tests passed. The description was clear. It just needed someone to read it and approve it.
Six weeks later, it was still open. The engineer who wrote it had moved on to other things. The team had shipped three features in the meantime. Nobody had looked at the PR.
When I finally reviewed it, I found two things: the code was good, and it was now slightly out of date because the codebase had moved around it. Not broken — just no longer quite fitting the way it had when it was written. We merged it anyway, with a small update. But the six weeks had cost something.
The engineering culture question here isn't about individual responsibility. It's about what the system incentivizes. If your team's metrics are about shipping features, reviewing PRs is invisible work. It doesn't show up in the sprint velocity. It doesn't get celebrated in the retrospective. It just happens, or it doesn't.
The fix isn't to tell people to review PRs more. The fix is to make PR review visible and valued. Some teams do this with explicit review rotation — you're on review duty this week, it's your job, it counts as your work. Some teams do it with SLAs — PRs older than 48 hours get flagged automatically. Some teams do it by making the PR queue a standing agenda item in standups.
None of these are perfect. All of them are better than hoping someone will notice.
There's a systems thinking principle here that applies beyond code review: if something important keeps not happening, the problem is usually not that people don't care. The problem is that the system doesn't make it easy or visible or rewarded. Fix the system, not the people.
The PR that sat for six weeks was a symptom. The cause was a team that had implicitly decided that shipping was the only thing that counted. That's a reasonable decision in some contexts. It has costs. The cost in this case was six weeks of drift and a slightly awkward merge.
I've been thinking about this in the context of systems thinking more broadly — the way invisible work accumulates until it becomes visible as a problem. The PR queue is one version of this. Technical debt is another. Documentation is another. All of these are things that don't feel urgent until they are, and by then the cost is higher than it would have been.
The maker mindset I try to bring to engineering is: what are the things that aren't getting done because they're not visible? What would it take to make them visible? Usually the answer is simpler than you think. A dashboard. A rotation. A standing agenda item. Something that makes the invisible work show up somewhere that people look.
The PR got merged. The authentication logic is cleaner. The team is now doing weekly PR review rotations. It took one conversation and about fifteen minutes to set up. We should have done it two years ago.