What’s the best way to handle a situation as a tech lead when you are under pressure to deliver your tasks and ensure that the other team members are also on track? If one developer slacks and doesn’t meet the deadline, is it automatically the lead's fault, especially if the situation was raised well in advance. If the person continues to under deliver with poorly written code, is it okay to spend time and pair program and get work done just to meet deadlines? Keep in mind that the developer is a junior engineer and requires fair bit of hand holding.
I had to approve a PR, although I was not 100% confident, it wasn’t a breaking code and it wouldn’t have caused any backward compatible issues. I received extremely harsh feedback for approving a sub standard from a peer/colleague. Had I not completed the PR, my manager would have provided feedback on the delayed project, what’s the best way to navigate between two leads or managers who are not aligned and expect different outcomes from the same situation?
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.
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:
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 :)