> One way I've seen this enforced is this: Have your "best" devs, the people who put out 2x the amount of solid, testable, well documented code as anyone else,

> One way I've seen this enforced is this: Have your "best" devs, the people who put out 2x the amount of solid, testable, well documented code as anyone else, you know those that carry the sprint, spend half their time reviewing. Your overall sprint velocity may go down a bit, but your code quality will go up. Problem with this is your best devs will soon become your best former devs. Becoming a "mandatory reviewer" sucks. Especially at scale. You're a bottleneck, you get pressured by other devs and occasionally management to let code that you don't like through, and if things go wrong you get assigned at least partial blame for not catching it during the review process. I'm speaking from a background of seeing this implemented at a major AWS service with designated "component owners", who were 1-3 developers with a final (and mandatory) review for all code merged into subcomponents. This was for a service with 400+ developers working on it. > There's a magic to slowing things down, too - require reviews on every change, require tests to run and pass, run UI tests on each PR. Let people discuss good and bad code they see. Yeah this is the way to do it. Automate everything. Unfortunately there's no real "good code" vs "bad code" easy metric, but you should at least have automated testing, linting, compiling, etc to ensure people aren't merging total garbage to shared branches.