Ah the fallacy of "I'm too busy developing to code review."
Well code reviews are development - just because it's inherently not your feature doesn't affect that.
Ultimately everyone suffers. It's not straightforward at all to get a culture of prioritising code reviews first but it is necessary.
Hence code reviews are priority 1 if assigned - only support issues can bump them. It's the reciprocation of reviews - being necessary for any task to be promoted through the release pipeline - is the motivation in and of itself. A good team should understand the importance of reviewing each other's work - not even having to wait for a formal code review to do it.
Your development task is not complete until it's in production.
There is never really "no time" to do something; just a misappropriation of what is available. As you are experiencing the overall slowing of the process is part of what causes "too busy." As such part of it causes its own problems.
Some of this may depend on the size of your team but if you're having daily standups no one really likes those. I'm a senior developer but I still stand up and go to talk to people working on stuff I'm going to review to see how it's going - especially if it's something I'm familiar with. Anyone you would consider senior should also be doing this - part of the role is to be interested in the overall process as well as developing more junior people. I also personally find it helpful to break from what I'm doing as slapping away at a keyboard isn't the most important part of development - it's thinking about what you're going to do. If that is the mode of operation your developers are in then they need to be rethinking that as well.