5 ways tech leads can become better mentors

Estimated reading time: 7 minutes

Mentoring junior engineers can be difficult when you aren’t someone’s line manager. Here are five principles that can help.  

Technical leads on engineering teams are regularly looked to for guidance, whether it be engineering managers, C-suit level individuals, or – more often than not – junior team members. Being able to foster an environment where people in the early stages of their careers can thrive is a rewarding but very challenging part of the tech lead role. To build this into your team, you must gently guide engineers using the following five guidelines. 

1. Work closely with their manager                

Depending on the way your organization is structured, you might not be the people manager for the less experienced engineers in your team. If you’re in this situation, it’s important that you sync regularly with their manager to ensure that you are in the know about your mentee. 

For the manager, this exercise will be useful as they’ll hear your feedback on the engineer’s progress. If you have any concerns or comments about your mentee’s progression, this would be the right forum to raise them in. It will be doubly helpful for both you and the manager to be able to align on their report’s focus areas. For instance, a manager might have identified that their report needs to work on their front-end skills. Armed with this information, you can then find the right project for them to exercise this skill set.  

1:1s with their manager can also open a channel for feedback from your mentee. If the junior engineer isn’t comfortable sharing constructive criticism directly with you, their manager may be able to speak on their behalf. This way of operating has opened doors to useful feedback in the past for me.

These syncs with their manager are also an ideal time to share what you are planning to assign your mentee. Use the meetings to consolidate and check if the tasks or projects you’ve planned to hand over to the engineer will fit into their wider progression plan. 

2. Be available

Engineers spend a lot of time focused on the task at hand and that often means headphones on, chat apps turned off, and trying to avoid distractions. If you’re in a technical lead position, you’ll need to accept that this might not be something you can do as often. 

Try to set a precedent of checking in with your team more regularly. As a technical lead of a team with less experienced engineers, a critical part of your role is to unblock others, and that means being present to do the unblocking.

This doesn’t mean that you have to answer every message immediately, as it’s important to carve out time for yourself. I have blocks of “focus time” scheduled in my calendar where I don’t take meetings or check my chats and email. Get to understand how you best operate; it could be talking in person to team members, syncing over video calls, or even taking things to an asynchronous level. The medium you use might change depending on the context and the task at hand.

To find a healthy middle ground between yourself and mentees, set expectations on how you like to work. Do so in a way that is harmonious with the team culture and way of working. 

3. Give them the space to debug

When you do get a message asking for help, it’s tempting to leap right in and solve it straight away. This will unblock the engineer, but if you’re providing the solution, then you’re not allowing them to go through the process of figuring it out themselves. 

One of the best ways to learn and improve familiarity with a codebase for an engineer is to work with it, get stuck, fix bugs, and debug errors. It may be frustrating for them, but it’s a very important part of the job and introduces a myriad of skills in patience, debugging, and navigating code. 

Here are some of the strategies I use when I assign a task to an engineer that might pose problems. 

• First, I debrief the engineer on the task and provide high-level guidance. I encourage them to spend about an hour (this can change depending on the task) debugging before asking me for help.
• When they do ask for help, ascertain what steps they’ve taken already to remedy the situation. They should learn to come to you with information on the problem and what they’ve done to improve their understanding or try to fix it.
• Set a check-in time. I like to do this when giving engineers larger pieces of work, or work where the deadline is slightly more pressing. “I’ll put a quick check-in call in the calendar for Thursday,” gives a nice point for both of you to sync and tells the engineer that you are giving them a bit of space to work on the problem.

4. Provide the next step, not the solution

Resist the urge when unblocking an engineer to do it all yourself. Instead, give them enough to move them onto the next part of the work. There are no shortcuts to becoming a great engineer, and the journey is what gives people the opportunity to learn and hone their craft. 

If they do get stuck, consider if you can help without providing code; can you point to an example pull request or some documentation that provides the answer? If you eventually do need to pair program and help them solve the problem, don’t provide them with all the answers – leave it slightly incomplete. For example, after working through a solution together, ask them to write the unit tests. By writing these tests themselves, they reinforce their understanding of the solution and learn to catch mistakes. 

Consider if there are particularly complex challenges looming with the piece of work they have, or if they are about to face a part of the codebase with more technical debt, and proactively share any documentation or resources that will be useful as they progress with the task at hand. This might enable them to progress without needing to talk with you again, which also gives your mentee a sense of empowerment and accomplishment if they can produce the final change without more hands-on help from you.

Accept slower short-term progress

Another reason you might be to work through a problem yourself is to speed up progress. I think every tech lead has had an “I could do this much quicker myself” thought process, but it’s vital that you don’t let this take over. Remember that you were in their position not that long ago and that it’s an integral learning curve. 

To make sure velocity changes don’t have a negative domino effect, think ahead when planning and assigning work. If a task or a project has an imminent and strict deadline, think carefully about which engineer should do that work. Environments with impending deadlines and external pressures aren’t conducive to healthy learning and growth, so this may just be an opportunity for a more experienced engineer to take the reigns.  

---

London • June 16 & 17, 2025

Speakers Gergely Orosz, Camille Fournier and Lara Hogan confirmed.

See who else is speaking

5. Identify gaps in your documentation

When a new engineer (of any experience level) joins the team, it’s a great opportunity to get some fresh eyes on your project and its documentation. When we’re familiar with something, we can have natural weak spots, and a new perspective will highlight any gaps.

Documentation is a very underrated skill for engineers to possess and one that I’m constantly encouraging people to work on. New engineers on your team should be able to get the codebase running on their machine by following the docs you provide, but they may ask questions you didn’t think about due to them not having familiarity with the project. 

To help fill any shortfalls in the documentation, encourage your engineers to add and proactively edit existing docs. Treat it as a live resource to be constantly updated by everyone. I recently helped an engineer solve a tricky problem that required a bunch of local knowledge of the codebase and the domain. I then asked them to spend some time writing all that knowledge and context down whilst it was fresh in their mind. Now the next engineer who works in that area will find it slightly easier.

A rewarding experience

Some of the highlights of my career have come from mentoring junior engineers in their first software roles and seeing them progress to more senior positions. It’s a challenging experience (for both the tech lead and new engineer), but the rewards go beyond writing code and building features.