For me currently there are 2 code review stories to tell, both significantly different from each other.
In the large organisation we have an established git work flow. The master branch reflects production code and sits on top of a series of staging environments. After a release, each project branches off the master - for better or for worse projects don't have much visibility of other projects (except of course when something goes wrong because of stuff from pulled in from other projects) Within each project, each developer branches off their own project branch to develop their code. Once developed a team member (peer) reviews the code (ownership of this process belongs to the project manager) The code is then run through our own project staging environment before being merged into the project branch. The project branch is then merged to other project branches as the new developments move up the staging environments towards Master.
The other story is one with a very small team where everyone (designer, coders, ops) knows the problem being addressed intimately. There is only one staging environment and the work flow is not very rigid. Code is peer reviewed as it is being staged ready for production.
From my point of view, the question I find myself asking more often than not is 'what is the purpose of the code review ?'
In a previous team while running my own programming house (largest team size was 8) code reviews were both an opportunity to learn and share knowledge. The culture was one where everyone, from product manager through marketers to designers and coders was encouraged to engage as fully as possible with the problem areas. There were standards (naming conventions, DB access patterns, where different code files were located, commenting, etc etc) and code reviews were then meaningful in the sense of ensuring adherence to those standards, challenging colleagues to explain their thinking, generating discussion and helping knowledge sharing and learning.
If I was to recommend anything, I'd encourage establishing a work flow and making code reviews part of the general culture of product development that you want to create. It is great to learn from outside influences of course, but I'd argue you should adapt those influences to suite your own unique needs.