Code quality is important. Keeping a product clean is a must if we want to scale. We all know the stories about founders who've hacked their way to a product only to be stuck when they finally get some traction.

Code bases don't need to be pristine but must be maintainable. When auditing startups, we often encounter technical founders who obsess about quality assurance. They see it as their job to avoid building technical debt and harming the product's growth. That's a valid concern.

Our advice during these technical due diligence audits is always to make sure at least one other developer looks at the code.

Code reviews are the most common way to do that. Developers build a feature and ask others to review and approve the new code. This extra pair of eyes ensures bugs get caught, and less-than-stellar code snippets get rewritten before going live. Code reviews are a great way to share knowledge and keep quality high.

But in the case of these technical founders, we often see them play a gatekeeper role. They fear that code submitted by their less mature teammates might harm the overall product quality. As head of the Engineering team, they take it upon themselves to review and approve every single line of new code. It's easy to see how this becomes a bottleneck once the team starts scaling. At a certain point, the technical leader becomes a full-time reviewer. Features pile up, and functionality gets postponed because all progress needs to get past a single pair of eyes. That's not sustainable.

In an ideal scenario, all developers would take part in code reviews. Code styles and architectural principles would be documented and known throughout the entire team. Any dev can review and approve another developer's code in such an environment.

But most early teams are far removed from that utopia. A senior team lead with two junior developers is in a Catch-22. If they review everything, the team will never mature to the point where they can stop gatekeeping. They will never evolve toward the ideal scenario. If, on the other hand, they introduce 360-degree reviews, all of a sudden, code quality will definitely take a hit.

There are a few things teams in such a position can do to take small steps in the right direction.

Hire seniority

By hiring a second senior developer, the burden of review can be spread. This is a short-term solution for those teams whose leaders have become bottlenecks.

Automate as much as possible

Code review should be about big ideas. An implementation should be flagged because it will lead to performance issues down the line. The code review should not be about styling conventions or where to put curly braces. Linting tools and static analyzers can act as a first line of code review. These tools can automate all the small issues, so code reviews can be about big principles.

Document as you go

Let's say a reviewer flags new code because it goes against some architectural principle. In the case of early startup teams, these principles live in the head of the technical founder; rather than waiting for the day when you finally have the time to document all these principles, write them out as you go along. Or better: Explain the reason for the architectural principle to the junior engineer and have them write down the documentation. This builds documentation and a culture of documentation at the same time.

Have juniors review senior code

When technical founders finally get around to writing some code between all those reviews, they want to ship as soon as possible. But this is an opportunity to involve their less experienced team members. Create a culture where all code, including the tech leads, gets reviewed and questioned. Again, it's a great way of sharing knowledge and a step toward getting juniors comfortable reviewing code.

Delegate the simple reviews

Once you have a culture where everyone reviews code, start delegating straightforward reviews to junior developers. You might still want to keep an eye on code that touches the mission-critical batch processing engine, but you should start feeling comfortable handing front-end changes and new REST APIs to your junior colleagues.

Add reviewers as they level up

If the first tip was to hire for seniority, this one is about training for seniority. You want developers to work on ever more challenging parts of the code so you can turn juniors into seniors. The same logic applies to code reviews. Start by giving them straightforward bug fixes to review and gradually involve them in reviews of mission-critical components.

The ideal scenario might paralyze us. We don't have the people and processes to do 360-degree code reviews just yet, so it feels pointless to start.

By following these steps, you won't reach the mature team utopia overnight. That's a long road that starts with a bunch of small, consistent steps in the right direction.

But at least it's a start.

Alleviate the acute bottleneck by hiring for seniority. Then, automate or document the guidelines as you go and gradually build that culture of 360-degree code reviews.