As developers we are, the mindset should remain always open and sceptical at the same time.
Open, because we don't know when a developer may surprise us, and sceptical about our own ideas because we often forget that in software engineery there's not a single correct way to implement a solution. The rationale behind our solutions could make sense for us and make none for others. Behind a code smell there could be a great idea. Maybe, the developer didn't find the way to express it properly.
Due to we (humans) are terrible at communicating, don't make false assumptions, be willing to ask to the code owner about the code you are reviewing. If he/she failed at coding the idea under the company' standars, as lead developer be willing to guide him/her too.
Here the subjective approach. The objective approach, IMO, is very well explained in this question.
In addition to the link above, the set of objectives to be achived (maintainability, readability, portability, high cohesion, loose coupling, etc.) are not necessarily the Ten Commandments. You (the team) should be able to adapt these objectives to a point where the balance between quality and productivity makes the job confortable and "habitable for developers".
I would suggest the usage of static code analysis tools for measuring the progress of the quality according to these objectives. Tools like SonarQube provide us with Quality Gates and Quality Profiles that can be customized according to our priorities. It also provides us with a issue tracker, where developers can be targeted with issues related to code smell, bugs, doubtful practices, etc.
These kind of tools can be a good starting point, but as I said keep yourself sceptic. You could find some rules in Sonar to be meaningless for you, so feel free to ignore them or remove them from your quality profile.