The company where I work has senior engineering staff whose main responsibility is to provide technical guidance. This includes doing code reviews and creating a good review culture by example. We're judged by the overall project outcome in the same way that the managers are.
Even with that structure I found it challenging to develop a good reviewing style that picked up the important stuff without getting bogged down in silly details that lead to arguments. Reading John Ousterhout's "A Philosophy of Software Design" was really helpful. He focuses on module decomposition, quality of public interfaces, and documentation among other things.
So often an ivory-tower group with gate-keeping authority into the code base can derail a project and frustrate developers to the point they quit. Comments about module decomposition seem pointless to someone under the gun to deliver by a demo date. The poor developer is reviewed badly and their career suffers, because they were essentially powerless to deliver on time because their null-pointer-checking didn't appeal to some obstructionist reviewer.
So I won't submit to a committee review before my code is accepted. Its a recipe for anguish and failure.
What I'm describing is not a committee review any more than having Linus Torvalds review Linux kernel changes or Ben Pfaff review Open vSwitch changes. I can write code just fine myself, but it's more effective to focus on making others productive because the whole project gets more work done that way.
Module decomposition is usually something I try to pick off in design, but when accepting pull requests from outside it's a critical consideration. We're not blocking creativity but trying to ensure that the code base not only remains high quality and that the design morphs appropriately over time as we meet new requirements. By making this a review point you can help create a culture where engineers think about it before submitting. That in turn makes it easier to justify dates to managers.
Even with that structure I found it challenging to develop a good reviewing style that picked up the important stuff without getting bogged down in silly details that lead to arguments. Reading John Ousterhout's "A Philosophy of Software Design" was really helpful. He focuses on module decomposition, quality of public interfaces, and documentation among other things.