I try my best to review every pull request at work, but ultimately any time I spend reviewing code is essentially time I'm spending on Hacker News as far as management is concerned. Time spent on code review can't be logged against any defects or stories, so when the metrics get printed, it looks like I'm pulling less weight than I should be. Sure, I can game the system a bit by logging time against something that I didn't actually work on, but just the fact that I'd have to be dishonest to do something means I'm less inclined to do it.
See if there are any processes in place which would disincentive developers from doing code review. Are the deadlines too tight? Is performance graded against some metric like tickets closed?
And where's your tech lead in all of this? I feel that part of the job of a good tech lead is to be a technical mentor, and that involves reading the code your team is writing.
If one expects a review with any timeliness, "@mention" the person(s) you think are qualified to review. Include the urgency of integrating the patch. The default assumption is urgency is low.
The reviewee is free to punt (if they're especially busy, or it's a case of mistaken identity as to the correct expert), but he or she is expected to fill-or-kill their intent to review in a day or so.
Some advantages:
* Not overbearing nor complicated
* Leaves room for non-urgent work
* Targeted (avoiding tragedy of the commons)
* Dynamic and nuanced (not slavish to a strict taxonomy of assignment and priority)