Under pressure for lenient code review - What to do?

This is actually a super interesting scenario, that tech leads run into all the time. I will offer you some potentially controversial food for thought.

As the tech lead, you have responsibility to 3 parties here:

1. Your engineering colleagues, for upholding the standard.
2. Your juniors, for teaching them the standard (and helping them deliver that standard).
3. Your superiors, for delivering the project on time.

The bravest thing to do here, in my opinion, is to uphold the standard, delay the project, and take the blame for the delay yourself on behalf of your junior, and promise to do better next time.

Doing this isn't part of any job description nor is it part of expectation for a tech "lead", but it is a part of what a leader of people would do, if that is something you aspire to. Leaders take responsibility for the mistakes of those in their care.

To me, this code review issue is simply a symptom of how you may have run the project as a whole. I suspect you haven't really fulfilled responsibility #2 throughout the project, and this isn't likely the first code review this junior has submitted that's subpar in quality. Could you have helped the junior earlier in the project, and mentored them to the point where at least their code was not visibly below standard? Could you have sat down earlier in the project, and pair programmed with this junior engineer to help them understand what the coding standard was?

Again, I think what you did was fine and no one is expecting you to do the "bravest" thing here and most of us will probably choose the "easier" paths instead. But from what you've described, you essentially chose to fail responsibility #1 to fulfill #3. You can make that choice, but in my experience, your reputation with your engineering colleagues and how you treat your juniors is the thing goes a long way to help you have a successful career, as they are the ones who will voluntarily vouch for you come during performance / promotion / job switching times.

Hope this was helpful, and if not, at least thought provoking! I'm happy to chat further here or over slack if you want to continue this conversation :)

From my experiences, companies (at a high level) will ultimately focus more on the deadline versus the quality of code itself: deadlines can be treated as binary, while code/product quality can have a lot of nuances in the discussion (which a lot of upper management stakeholders aren't either equipped or don't want to handle). As the tech lead (not on the upper rungs of management), it is your job to own quality & velocity and abstract way any nuanced concerns away from upper management (and provide them simple, clear action items if there are).

For your scenario with the junior engineer, I have a few thoughts:

• If your peer/colleague is in a position to judge the code of the junior engineer, why not pair them up together? This way you can set up the junior engineer to better learn about writing quality code without having to oversee them yourself.

• What does the test plan of their code look like: is the junior engineer writing detailed test plans or writing exhaustive test suites (unit, integration, etc.) ? If the junior engineer is doing neither, I would block their PR until either condition has been filled.

• How big are the junior engineer's PRs? Code gets exponentially hard to read or judge with more lines of code, so breaking up code into smaller PRs makes it significantly easier to give nuanced feedback.

• Do you have regular 1:1s with the junior engineer? This would allow you to create the space to support them: either through actionable feedback or pair programming (like you called out).

In addition to the great advice provided by Jonathan, I would also recommend having team-level discussions and knowledge-sharing sessions about high quality PRs to establish best practices. This should reduce subjective disagreements about code quality and also help junior engineers in improving their PRs and commit less mistakes in future.