A friend and fellow staff+ engineer posted a question to a peer group Slack:
Anyone have suggestions on how best to mentor software engineers?
At the time, I said a few things about radical candor and actionable feedback, but the question stuck with me. I mentor people, but I’ve never thought formally about what it is or how I do it. Like a lot of soft skills, we’re rarely taught how to mentor – most of us are left to figure it out on our own.
Mentoring, coaching, or sponsoring?
Mentoring and coaching activities look similar, but the impetus is different. In mentoring relationships, usually the mentee sets the agenda. In a coaching relationship, usually the coach sets the agenda. Coaching also tends to be more formal and more transactional. (People hire coaches, not mentors.)
Sponsorship is very different. A sponsor uses their authority and influence to create opportunities and recognition to advance someone’s career.
Depending on the context, a mentor might also act as a coach or sponsor.
One way to think about the distinction is whether there are direct consequences to following or ignoring advice. Mentors advise; coaches assess. This is one reason why people often seek mentors outside the management chain. It’s hard to trust a manager to separate these two roles. Senior individual contributors – while they may also coach – are often better positioned to provide consequence-free advice.
When I thought about ways I’ve mentored people, the first things that sprung to mind were actually coaching roles – situations where it was my responsibility to help someone improve.
Code review is a pervasive example of coaching being confused with mentoring. Code review is part of the job. Every time I review someone’s code, I might find opportunities for teachable moments. Yes, I’m helping someone improve their skills to advance their career, but that’s not the same as mentoring.
Mentors should operate at three levels. 🔗︎
When people have come to me for advice, whether formally or informally, and whether once or twice or regularly over a period of time, the kind of conversations we’ve had are quite different from my coaching conversations. When someone comes to me, they’re usually asking bigger questions not tied to our day-to-day work.
I’ve found that these conversations fall into three broad categories, ranging from the strategic to the tactical:
- Goals - figuring out what they really want
- Situations - handling the unfamiliar or difficult
- Skills - getting promoted
In all three areas, I think that radical candor – caring personally while challenging directly – is essential to effective mentoring. You have to have someone’s best interest in mind and you have to be willing to help them see uncomfortable truths. If that’s not in your personality or you don’t feel that way towards a prospective mentee, the best thing you can do for them is to send them elsewhere.
To mentor goals, ask questions. 🔗︎
Mentoring about goals is tricky because the best goals come from within. Telling someone what they should want isn’t as powerful as helping them discover it for themself. Goals are most meaningful when they are deeply understood.
To help someone understand their goals, ask questions that help them reflect on their current situation, consider potential futures, and chart a course from one to another.
In the simplest form, it’s the “where do you see yourself in five years?" question, but that’s a big leap for most people to take in a way that’s authentic and not what they think they ought to say or what the mentor wants to hear. Instead, probe for how well they understand their current situation. What’s going well? What’s not going well? What about your role do you enjoy the most? What’s most frustrating? If you could change one thing, what would it be and why?
Only then is a mentee ready to think with specificity about a future in contrast to the present. Maybe that’s “do more of what I like and less of what I hate”. Or maybe that’s “overcome the things that are hard”. Everyone is different. A mentor can help ground aspirations with current reality so that the mentee can find the path that they can believe in and realistically follow.
To mentor situations, tell stories. 🔗︎
It’s hard to benefit from experience if you don’t have it yet. Some people read histories, stories, case studies, and so on to learn from the experiences of others. Others don’t. Mentors are a great source of lessons from the past because what they have to say is personalized to the challenges facing a mentee. And, unlike a book, the mentor can answer questions and provide more context if needed.
Faced with the question “what should I do?", a mentor should resist the urge to recommend and should look for an opportunity to tell a personal story instead. Why answer indirectly with a story?
First, sharing a related experience reassures a mentee that they’re not alone – that someone else has faced a similar challenge. Second, stories engage the listener’s brain, helping them focus more completely on what they’re being told rather than their own problems. Third, stories let a mentee consider a situation through an abstraction – when they aren’t the protagonist of their own, immediate problem, they have a chance to see a situation more objectively and consider different perspectives. Finally, it preserves their agency and sense of control. A story is a teaching tool – “this worked for me” – but you leave the decisions up to them.
Be honest if you haven’t experienced a situation personally. In that case, let them take the lead without being prescriptive. You can still be sounding board for their ideas and help them wargame an approach to what they’re dealing with. Even without a story to guide them, having someone in their corner is valuable support.
Similarly, be careful if you’re speaking from a position of privilege that your mentee doesn’t share. What worked for you might not work for someone else. You should still share your experiences, but share with awareness and candor about the difference.
To mentor skills, observe them in action. 🔗︎
Mentoring skills has the most overlap with coaching. In a mentoring context, you’re doing it because they’ve asked you and not because it’s your job, but what you do is fundamentally the same.
First, you have to observe the mentee’s activities or output. For coding skills, code review or pair programming would work. For communication skills, sit it on a meeting they expect to actively participate in or watch them practice a presentation. For technical writing, read what they’ve written.
The most important thing you can do is provide actionable feedback. This means being specific about your observations of their work. It also means providing direction about what they could have done differently or what they need to learn or practice in order to improve. If your mentee doesn’t know what to do next, your feedback wasn’t actionable.
Sometimes a mentee has a specific skill they want to level up. Other times, they’re looking for more general guidance, usually with an eye towards promotion. I wrote about using career ladders for growth conversations in the context of managers, but as a mentor you can offer it to a mentee as a tool for self assessment to guide where they think you can help them the most.
What if you want to mentor, but people don’t ask? 🔗︎
Sometimes, you see someone that you think has potential, but they’re not where they ought to be and they aren’t seeking advice. You could approach them – tell them you think they have potential and offer to mentor them.
If your company has a formal mentoring program, you could sign up. If they don’t, you could invite people to come to you. That doesn’t have to be a formal declaration “hey, if anyone wants to work with me as a mentor, let me know”. It could be as simple as announcing office hours for anyone who wants to talk and seeing what happens.
Start with listening. 🔗︎
There’s one take away I’d like you to have: mentoring is about listening. Resist the temptation to offer unsolicited advice. Listen to what they’re asking about. Goals? Situations? Or skills? Then listen (or observe) before sharing your questions, stories, or feedback.
If you’ve read this far, you may realize that nothing I’ve said is specific to software engineering. Mentoring is a general skill; your experience makes it industry-specific.
More on mentoring:
- Developers mentoring developers by Gergely Orosz
- Mentoring from privilege by Will Larson
- You’re not wasting your mentor’s time (Voltron mentors) by Lara Hogan
Special thanks to Matias Lespiau for feedback on a draft of this article.