Leaders: How to Coach Engineers to be Great Mentors
5 things to watch out for to turn engineers into great mentors
When you advance beyond the senior level, you become accustomed to mentoring engineers. However, as you assume leadership roles, you also begin coaching other engineers to be effective mentors. This is a crucial skill for building your team and delegating responsibilities. What makes this difficult is that you see the mentee through the lens of the mentor, so you need to assess the situation and help both the mentor and the mentee accordingly.
I have coached 10s of engineers (including other Staff Engineers) to mentor senior+ engineers. So, today, I'm sharing tips that I have used to help engineers become great mentors.
Last week, my newsletter crossed 10K subscribers. This is a huge milestone! Thank you.
If you are new here, I write about growing people skills for engineers & leaders. You can find more articles in my newsletter.
The Setup
Mentor = The engineer you are helping to become a great mentor. Technically your mentee, but will be referred to as the mentor.
Mentee = The engineer receiving any help (not just onboarding help).
Ideally, you should have a good working relationship with the mentor and be aware of the mentor's strengths and weaknesses. That way, you know what they can handle well and what they need help with.
The Mentor’s role
Their job is to help the mentee succeed. The mentee may be new to the company/team or a teammate that needs help with something. So, the support needs to be customized.
Key areas that the mentor should support the mentee on are - Showing care, finding projects, brainstorming solutions with them, helping build cross-team relationships and giving honest feedback to grow.
Your role
Contrary to what you may think, your role is to help the mentor, not so much the mentee.
As a mentor of mentors, I set very clear expectations for the mentors. While I let them find a pattern that works for them, I share examples of how I mentored them for reference.
The hardest part is doing this without being directly involved. To do this, you have to watch out for things going sideways. You may need to have some infrequent 1:1s or casual hallway conversations with the mentee.
5 Things to Watch Out For
My approach varies depending on the mentor's experience and who they are mentoring. However, here are the top 5 things I watch out for:
1. No Care
Some mentors treat mentoring as a chore. They take a very passive approach and let the mentee reach out. This doesn't build a bond between them.
I ask the mentors the following in my 1:1s
“What did the mentee do in the previous job and what did they like?”
“Does the mentee want to play ping pong or some other team activity?”
“How often do you meet your mentee? How long do the discussions last? What do they talk about?”
Answers to these questions help me understand what may really be going on. If they have not asked questions along these lines, then I remind them to care more.
2. Mentee feeling lost
I expect mentors to assist mentees when they feel stuck on their projects. While it's good practice to encourage mentees' independence, some mentors may adopt a very hands-off approach. That can make the mentee feel stuck with no hope.
I ask:
“What do you think they should do next? Does the problem actually have a solution or is it too ambiguous?“
“Did they write down a plan and did you review it?”
“Do you need a brainstorming session?”
I might even have a direct discussion with the mentee to understand more. If I learn that the mentor needs to be more engaged, then I will give them that feedback.
3. Not giving direct feedback
This has been the most common thing I have helped mentors with.
I had a few cases where the mentors were frustrated because the mentees were not churning code and not asking for help.
I asked “What did they say when you told them they were not meeting deadlines?”.
If the answers were not satisfactory, I would dig into how they phrased the feedback. If they ended up sugarcoating feedback then I would help them ask pointed probing questions.
I would even share the exact phrase they could use but I would have them deliver it directly.
4. Giving wrong suggestions
Mentors are not perfect and that is ok. So, you should be watching out for the major recommendations they give.
To catch them early: I use my 1:1s with the mentors to discuss projects and vet ideas. I am also available for ad-hoc discussions when they need my help.
If I notice that the mentor has already made a poor suggestion, I will contact them directly to help fix it.
5. Solving the problem for them
Some mentors are overly friendly and eager to help! They end up giving out solutions. It is difficult for many mentors to "teach" tricky things. For example, if the (senior) mentee is struggling to build consensus, the mentor may step in and resolve it for them. They fail to understand that their job is to teach the mentee how to do the same.
In such cases, I try to understand how much the mentee struggled before the mentor stepped in. I will help identify where the mentor should have been hands-off vs hands-on. To be fair, this one is hard for me too when the situation is critical. I may tend to take charge and fix the issue vs letting my mentees do it.
Parting Note
Growing mentors is one of the favorite parts of my job. I care deeply about the type of onboarding and growth support that mentees get. This skill played a critical role in my promotion to the Staff level 4 years ago. So, if you want to build up your tech lead skills, invest in coaching mentors now.
If you enjoyed this article then hit the ❤️ button. It really helps!
If you think someone else will benefit from this, then make sure to 🔁 share this post.
All excellent tips, Raviraj. I'm a self-taught mentor, and I wish someone told me these sooner. I'm guilty of making the 2) mistake early in my mentoring.
I figured the cause for that, so I would add a 6) Not building confidence.
I have to work on this because I felt that sometimes people were afraid of communicating if they were stuck because they had ideas about where they should be and things like that.
Very insightful article indeed. I wanted to share in case there is a better approach out there. I had struggle with a developer who doesn’t test their work, late on delivery, bugs from past work interrupted current work and so on. At first I helped her navigate requirements, put guard rails to test the work but nothing worked.
I did this next thing and it is on going and give it some time. Since I noticed the QA person had a better hold on the requirements so now I paired her with that QA person. I am thinking that blurry requirements (in developer head) are the root cause of the developer behavior.