There is a school of thought that describes code reviews as the number one priority activity for all developers in a sprint since they are either:
a) A source of unrealised value
b) A source of bugs
While I'm not sure I subscribe to such as black and white view, I do agree with the sentiment.
But enough of the background.
We have a persistent problem where reviews sit on the queue for days at a time. Invariably the bottlenecks are caused by the lead developers as they're more in demand. Also, due to the important nature of their work, they tend to pair program so they don't require their own code reviews to be done as such. Hence there is no real incentive for them to do reviews as a quid pro quo.
The most often used complaint is that they will lose their train of thought while programming. There is some truth in this, but surely they could just review after lunch or first thing in the morning?
Are there any ways round this? On previous projects we have applied a SLA of one day which worked well for the most part but again, the rule tended to be broken by the pair programmers.
Developers take it in turns to do code reviews so the load is already being shared fairly.