Frustrated with your “incompetent” mentee?
Framework to debug and fix your mentees’ problems.
As a mentor, have you ever felt:
Why can’t my mentee do this right?
They are not serious about their work and deliver poor-quality results
They are not motivated to work fast.
I had felt the same and also seen other mentors get frustrated. However, if you are one of those mentors who also thinks, “Is there something I could do more?” then this article is for you!
Good mentors can change the growth trajectory of their mentees. But how can you be that good mentor? If you can get an engineer unstuck and help them succeed then you are a good mentor. If you can do this with multiple engineers then you are a great mentor!
After helping many engineers get unstuck from various situations, I learned the key ingredient to helping is having an open mind. When I reflected on all the major issues that I helped my mentees with, I realized the three pillars of being an effective mentor are:
Thorough situation assessment
Give actionable suggestions
Tracking progress and helping them pivot
🕵️♂️ 1. Thorough Assessment
A thorough assessment is foundational to providing the “right” help. If you don’t understand the problem, you can’t help. Worse yet, you will provide the wrong help and get frustrated when you see no improvements.
Symptoms vs Root Cause
A common mistake is to assume symptoms to be the root cause. Asking questions is a great way to learn more about the situation. Before you ask questions to your mentee, you need to ask yourself a whole bunch of questions to ensure you are not biased.
Let’s look at a few example situations and what you can ask yourself. Your mentee exhibits:
Slower execution
Do you know if they were actually slow? If yes, by how much?
Do you understand how long it should have taken them?
What were the reasons you think it was slow? Did you ask where they were stuck?
Do you think they don’t communicate how difficult the problem is?
Do you think they discover harder problems too late?
No grasp of their project
What does firm grasp mean? Are they not making decisions soon or making the wrong ones?
Do they not understand the details of the project? Are they not asking for help?
Is the project level appropriate?
Deliver poor-quality work
Are there too many bugs in what they ship?
Was the code they were touching always unstable?
Are they missing trivial issues or complex ones?
Are they cutting corners because they are unable to say NO to more work?
Clear Feedback
To build clarity, discuss the problem and listen to their perspective. That way, you will learn about their struggles and why it is hard for them to fix it.
Keep the following points in mind.
Do they already know they exhibit these concerns? Did you tell them that in a simple language?
Did you share what the desired outcome is?
Have you discussed, what they think about the concern?
Do they understand the severity of the concern?
What is their justification?
💡 2. Actionable Suggestions
Once I have some understanding of the root cause, I will make suggestions that they can implement immediately. A hack that always works for me is, thinking about what I would do next in their situation. That forces me to come up with concrete suggestions. Later, I can transform those suggestions so that it applies to them.
Let’s look at the same examples as before:
Faster execution
Suggest topics they should invest in learning
If it is a perception problem then give them tips to improve their communication. Help them highlight project complexities.
If they discover hidden issues too late then guide them to prototype the difficult things soon.
If they are not parallelizing their work and wasting time waiting for stuff then share what works for you.
Building a product mindset
Reverse engineer their wrong decisions and highlight what they missed. Maybe they haven’t internalized what matters to the customers. Maybe they don’t understand how to quantify impact. Show them what they are missing.
If they haven’t asked enough questions then tell them the kind of questions they should ask you and other stakeholders to build clarity.
If they don’t understand the vision and product timeline, explain the depth they are lacking.
Deliver with quality
If the codebase is already unstable, suggest that they should consider a refactor first
If they are missing trivial issues then tell them how it affects their reputation and help them build a checklist.
If they are missing complex issues then show them how you tackled it in the past
If they are not saying NO to new requests then share phrases they can use or help delegate.
I believe the key is to make them feel empowered to act on your suggestions. If the suggestions are vague or too ambitious then they will never be able to overcome the problem. That makes them feel dejected and makes you frustrated.
📈 3. Tracking Progress
Now that you have done the harder part, don’t miss this important last step. Complex issues take time to fix and some even need follow-up suggestions.
Let’s look at the same examples to understand the follow-ups you need to handle:
Execution speed
Finding hidden issues can be harder when they lack experience. When you find out they keep missing certain kinds of harder issues, help them bridge the gap in their knowledge. Explicitly discussing that will help them in future iterations.
Product mindset
Multi-year projects have a lot of historical context that can trip someone new. Watch out for such misses and help them avoid it.
Chasing quality
There are various facets to quality and can depend on the team. One team wants absolutely zero bugs while the other errs on the side of fewer bugs but faster iterations. Help your mentee internalize such unspoken rules and assist them in making the right trade-offs.
Track their progress and follow through. Giving up on your mentees when they start making progress is terrible.
It is extremely rewarding to me when my mentees come out of their struggles.
Beyond your control
Understand that you may not be able to assist in every situation. If there's someone better suited, don't hesitate to redirect your mentee towards that person.
If your mentee proves to be un-coachable, it is necessary to consider cutting losses. However, I believe in making an honest attempt to help before resorting to this measure.
Parting note
We, as software engineers, are great at debugging software problems. However, not all of us invest in learning to debug our mentees' problems. This is an important leadership skill that you should invest in today. It will help you not only in helping your mentees but also in building an awesome team!
🎤 Shoutout
The Ultimate Guide to Writing an Engineering Newsletter by
My Strategies for Work Life Balance by
3 Ways Software Engineers Can Prioritize Deep Work by
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.
Great read! What I noticed happens more often was a lack of focus and understanding for the bigger picture. They sometimes lack the clarity, they don’t see the forest from the trees.
Great suggestions to understand a mentee’s problem and navigate them in a successful path