How to explain the benefits of code reviews to non-tech people?

Here’s how we would explain to a non-technical CEO why code reviews are essential.

First, you will lose engineers without a culture of mentorship and learning.

One of the ways to build a great place for engineers to work is to shape an environment that supports mentorship. Learning and exploring on the job is no longer a “perk” but a requirement. Engineers are deeply curious, and code reviews are a great way to facilitate a learning culture.‍

Second, you will fast-track the effectiveness and productivity of new engineers.

The difference between an effective and ineffective onboarding is six months or more of lost productivity. Unproductive onboarding means wasted financial resources and time, slower time to market, and ultimately, losing pace with your competitors.‍

Third, engineering effectiveness and velocity will be lower without code reviews.

Think of code reviews as a means to 10X not one developer but many. It’s a great way — in our view, perhaps the best way — to continuously improve the quality of the entire team, not just an individual. This is because coding is fundamentally a craft, not a competition– a rigorous skilled activity that requires learning from more experienced experts and one that requires deep knowledge and concentration. The greater the investment in growth and learning, the higher their effectiveness will be.

Gartner says the productivity difference between low and high-performing engineering teams is 53%. To us, that estimate merely scratches the surface.

How can the rest of the organization’s non-tech employees, such as Product and Sales, assist in making code reviews more effective?

Trust the process

But skipping the step of a code review almost always makes things worse later — and sometimes, not all that much later.

Trust us: no user is happier with a buggy version of the code than with a more complete version in the next release.

Protect review time

As discussed above, code review “return on investment” is extremely high, and so organizations need to protect that time.

Organizations who estimate and plan engineering activities should include a buffer of 10% to 50% for code reviews beyond code writing, depending on the complexity of the code being written, the coder’s skill level, and the reviewer’s skill level.

Cement its importance

If the CEO celebrates feature completion, does the CEO also celebrate code quality, developer mentorship, and code reviews? Does the annual performance process reflect reviews too?

Remember, an ounce of prevention is worth a pound of cure. Investing sooner in code reviews through celebration and recognition means avoiding more expensive outcomes later like technical debt and developer attrition.

Originally published at



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store