Developers mentoring other developers: practices I've seen work well

How does mentoring work? I asked this question ten years into my software engineering career when I joined Uber. Until then, I've never received or done mentoring, or at least never put this label on any activity I've done before.

Uber, however, had an official mentoring program. Almost every engineer I met had a mentor. Mentorship is an expectation for senior and above engineers, it being listed in our engineering competencies. Since working here, I've been mentored, been a mentor, and have observed engineers around me grow via mentorship.

Mentorship has been the best things that's sped up my growth and others engineers around me. This post discusses mentorship practices that work well engineer-to-engineer. The practices come from my own experience, observations I've made people mentoring each other and from conversations I've had with half a dozen mentors in my network and on Coding Coach. I'm hoping this post will be a good starting point if you're either an engineer wanting to mentor, or a developer looking for mentorship. Let's dive into the topics:

What is mentoring?

I've heard the term mentoring used with various meanings, often as a substitute for onboarding, coaching or helping. I like to narrow this down. In my take, mentorship is a learning relationship between an experienced person and someone who wants to grow. The Wikipedia definition of mentorship is not far off. The person receiving mentorship is referred to as the mentee, while the person sharing their expertise is the mentor. With software engineering, the setup is pretty typical: a more senior engineer mentors a more junior person.

Reflecting on my previous experience, before joining Uber, I do recall many situations where I was mentored or was a mentor. When I was a junior developer, I paired with a senior engineer for a few months, learning lots from him. When a new person joined our team, I sat with them for a few weeks, helping them understand the codebase. These were all mentoring situations, though I never put the mentorship label on them.

Onboarding: a specific type of mentoring

A common type of mentoring is having an onboarding buddy when joining a new company. This person helps understand the new environment, and often pairs to write code that ships to production for the first time. They explain how systems, processes, and unwritten rules work. Some teams refer to this role as a mentor as well.

I find onboarding being a nice example of mentoring. It's well-defined in scope: the mentor shares their expertise on how the team and company work. The duration is not too long and not too short: it lasts from the first day to when the new start is onboarded, typically in one or two months. Also, the responsibilities are clear: the mentor needs to do a lot of the preparation and drive this relationship, given the mentee is new. It's also something that happens pretty frequently. Most engineers are receivers of this mentorship every time they switch companies - even if it's not formalized.

Informal mentorship: it's happening everywhere

Mentorship doesn't need to be formal for a less experienced person to learn from a more experienced one. And for the most part, it isn't. It happens naturally when developers work together and collaborate.

Code reviews are frequent examples of informal mentorship. There's no need for formalities for a less experienced person to learn from a more experienced one. And for the most part, there are no formalities. At teams and companies, where code reviews are everyday practice, this learning happens with every review. It happens with good code reviews and even more with better code reviews. Code reviews and the discussions during and after helped me significantly level up as a developer. I had many mentors, learning a little from each of them.

Working on a project, as part of a team is another situation where mentorship is given and received. It might be during planning meetings, architecture discussions, whiteboarding, retrospectives, or something else. When working closely with other developers, feedback and learning naturally happen.

Formal mentorship: more effort, more focus, more growth

The mentoring I've observed to be rare for developers is a more "formal" type of mentorship. A setup where a more experienced mentor agrees to mentor a more junior engineer, they kick things off and have a regular cadence of meeting and the mentor helping the mentee grow.

Why bother with the effort of more formal mentorship? After all, informal mentoring happens all the time. Well, first, you might not be working with enough experienced people and would want to find someone targeted to learn more from. Second, more importantly, having a more "formal" mentoring relationship can help you grow faster and in a more focused way.

There are two places where it's easy to get started with more formal, more focused mentorship: at more structured tech companies and within online communities. More and more tech companies have internal mentorship programs. Unfortunately, though, they advertise very little of these to the outside world. Uber, PayPal, and Amazon all places I know have various internal programs that make it easy to get more focused mentorship. Online communities of mentors are also a welcoming place with an easy way to start. Coding Coach is a new and thriving online community, which is a great place to join as someone looking for mentorship or as a mentor.

Having formal mentors throughout my developer years would have helped me grow faster. So when I transitioned into engineering management, my first point of action was finding a mentor. This decision was the thing that helped me grow the most. I've seen similar success stories with developers on my team after they kicked off focused mentoring with another engineer. For junior engineers, it was no surprise that they ended up growing faster. What I did not expect is how much senior engineers gained from setting up formal mentorships with more experienced - staff or principal - engineers.

So how do you go about setting up formal mentorship? Like with any long-running project, a good kickoff helps to get all participants - in this case, the mentor and mentee - get on the same page.

Kicking off mentoring: the introductory meeting

The best way to start formal mentorship is with a kickoff. I often suggest people to approach potential mentors and open along the lines of "You're someone I look up to. Can I setup time to talk about areas I'd like to grow in and how you could potentially help, as a mentor?"  It's good to get some dedicated time for this, to share some background and see if both people can and do want to commit time for mentoring.

Come prepared for the intro, making a list of the topics to discuss. Topics that are worth discussing in this kickoff are:

• Background. It's nice to share backgrounds to break the ice and get to know the other person a bit better.
• What's in it for me? What are you hoping to gain from this relationship? Where would you like to grow? Ask the other person the same thing. The best mentorships are two-way streets, where both people get something out of it.
• Roles. What would you hope to get from the mentor? What would the mentor expect from the mentee?
• Topics to cover. What areas are you interested in? Where would you like to grow? Is there something more pressing to discuss?
• Cadence. How often should we follow up and when? I've seen most developers catch up once every two weeks for half an hour or and hour, at a time that works for both of them, e.g., sometimes over lunch.
• Communication between catch-ups. Would the mentor be open to random pings? What is their schedule like?
• Short-term wins. What is an area you'd like to grow in the next month? Let's start with focusing on that.
• Evaluating progress. What criteria would help to assess how efficient this mentorship is?
• Challenges. It's nice to lay out things that might make this relationship hard. For example, it's okay to share with your to-be-mentor that you have no clue how mentorship works. Or your mentor might share how they have a crazy next month, and they will be swamped.

Don't forget; it's always okay to say no to mentoring. As a mentee looking for a mentor, I've had potential mentors politely decline several times. Sometimes it was lack of time; other times, they felt they did not have the expertise I was looking for. Don't let this derail you: ask for any other recommendations this person might have and try meeting another potential mentor. Sooner, rather than later, you'll have your first match.

When you are a mentee

With a running cadence and regular catch-ups in place, how do you keep getting value out of the mentorship? I'm a firm believer that as a mentee, you need to invest time and effort in mentorship, to get value out of it. Set expectations clear from the start. Come prepared to the catch-ups with your mentor, making good use of their time. Bring challenges, wins, and areas you'd like to get their input on. Have a list of top things you'd like to talk through with them. During the discussion, as you get advice and ideas, commit to actions, follow through with these, and let your mentor know how it went. In the Manager's Path, Camille Fournier advises following a similar approach:

You owe it to this person not to waste her time. If you don't have the time to prepare or don't feel that preparation is necessary, ask yourself whether the mentoring relationship is really something you need at all.

I like to keep a running doc, shared with my mentor, where I drop notes between our catch-ups and prepare a list of topics. The structure I use is this:

1. Key things that happened since last time. I like to fill in mentor briefly on key things that happened since last time. I keep this short.
2. Reflecting on action items / guidance / discussions from last time. If I did something we talked about last time like tried out an approach, read a book, I share the results. This is useful for both of us, and my mentor gets to learn something interesting.
3. A challenge I'm having, talking through it and brainstorming on an approach to solve it.
4. A recent success I've had. I describe a situation I thought I handled well and why I thought it went well, asking my mentor to share what she thought of it. Nine out of ten times, I get feedback from a different angle, that make me re-evaluate how I'll handle the situation the next time.

When you are a mentor

Being clear with expectations both ways is the foundation for a good relationship. Clarify how much time you can commit to, and also tell your mentee what you're expecting from them. If you'd like them to come with a list of things to talk through, say so. If that's not your style and keep it casual, tackling things as they come, discuss this upfront as well.

Being a supportive and efficient mentor

Being an efficient mentor is not about solving other people's problems. It's about helping them grow so they can solve their problems themselves. When mentoring, you want to delay sharing solutions as long as possible.

Listen to what your mentee has to say. This is the most important role a mentor can play. The mentee is coming for advice, but talking about what's going on and how they are feeling is just as important. Try starting the conversation with questions that help you listen, like "What's on your mind?", "What are you struggling with?", "What are you working on?" "What are your goals for the week?". Sit back, listen and think about areas you might be able to help with.

Discuss specific situations to dive deeper. These situations can be ones brought up by the mentee or ones noticed by the mentor. Topics can be from communication, cultural issues, deep technical questions, code reviews, and many more.

Provide context and perspective for the specific situation. You probably have been in the industry for longer and had similar situations that your mentee is struggling with. If you work at the same company, you probably know how things work a lot better. Reflecting on how you experienced a similarly challenging situation back in the day, and how you also struggled with it can help the mentee feel less anxious.

Leverage your network to help your mentee. This is especially powerful when you work at the same company, as you can put them in touch with other people who can help. Mentors are usually a lot better connected than mentees. Making introductions and asking others to spend some time with the mentee goes a long way. When you don't work at the same company, you might still see opportunities to connect them with others, helping with a warm introduction.

Be supportive and let them know that you are on their side. People who approach you for mentorship are not only looking for advice but also support. The less experience they have in the field, the more likely they feel like an impostor and the more your support will help them. Encouraging words go a lot further than you would think:

Any mentor I've worked with here so far has always ended our conversations with -- "You got this" or "You can do this" or something of that nature. They may just be words, but damn if they don't mean the world to me. (quote from a mentee sharing their experience)

Avoid giving answers on a silver plate. You want the person you're mentoring to get to solve their problems themselves, with as little direct guidance from you, as possible. Ask questions, offer alternatives, and hold back telling people what to do. Taking a patient, coaching-first approach empowers more junior developers and accelerates their learning.

A few more tips on how to be a great mentor:

• Aim to learn something new from your mentee. Be curious about the problem they want to solve and understand their viewpoint. Even if you know a good answer, if you coach them down the line, you might learn something new, looking at the problem through a different lens.
• Help mentees come up with multiple solutions to their problems and help them articulate the tradeoffs themselves. Explain concepts over solutions and help mentees understand that there are rarely black or white answers. This is especially true for technical topics and mostly holds for non-technical problems.
• Tailor your approach for technical vs non-technical topics. Technical questions are usually easier to deal with: you can coach by asking what avenues they've tried and guide them with questions towards something that works. For non-technical topics like communication, conflict and others, listening is key.
• Mentoring brings benefits on the long-term as well. Beyond the short-term benefits of becoming a better communicator and teacher, don't forget about the long game. The software industry is small, and the person you are mentoring as a junior soon grow more senior. In a few years, they might be a director or CTO even. Be a supportive mentor, and they'll think fondly of you. You might reconnect later, in a different setting.
• There is no one pattern for mentorship. For most people, mentoring is a mix of informal mentorship and regular catch-ups. People often reach out to mentors with one-off questions. Some prefer in-person mentoring, and some mentorships don't go beyond reviewing code. All the mentors I've talked shared one thing about what their approach is: "It depends."

Mentorship across the organization

Mentorship is time- and emotionally consuming. It's often invisible to managers of the mentors. At the same time, it's one of the best ways to grow seniority on the team. It's one of the best tools to retain people at the company. When developers get mentoring, they learn. When they learn, they are engaged. When developers are engaged, they are a lot more likely to stay. Thus, recognizing and encouraging mentorship within teams and companies is one of the most important things managers can do and advocate for.

So how can you support more mentoring within your team and organization?

• Facilitate setting up mentoring relationships between people. As a manager, you have a good understanding of the strengths and weaknesses of people. It also carries more weight, when you are reaching out to a potential mentor, asking them to have an intro meeting with a mentee on your team.
• Recognize that mentoring takes time, especially from the mentor, who is not getting an immediate return. As a manager of a mentor, create time where you can and don't assume they'll get to mentoring in their free time.
• Lead by example. Volunteer to be a mentor to others and seek out mentorships. Be open about this, sharing your progress with your team members.
• Mentorship being part of promotions, performance reviews, and competencies. Make mentorship part of performance evaluations and promotions. I am not saying that someone mentoring should get paid more. However, to make mentoring something that spreads across the organization, make sure mentoring is called out as an expectation from senior engineers. This does three things.
  
  First, it makes it a requirement to mentor others to get promoted to the senior level. High performers, who are on the path to promotion, now have another incentive to help others. Second, for non-senior engineers who already mentor others, it explicitly recognizes them going above and beyond. Finally, it creates an incentive for existing senior engineers to mentor and share their knowledge more.

Remote mentorship

Mentoring is powerful when done in-person, but sometimes mentors are not based in the same place or location. Mentorship is a powerful tool with this setup, as well.

One of my mentors lives in San Francisco, so we do video calls all the time. I've also talked with several experienced mentors who do remote mentoring on Coding Coach and have all had great experiences using this format.

Exercises work exceptionally well for remote technical mentorship in this kind of relationship. Both mentors and mentees have mentioned that this is a tool that they've seen work better than others. A mentee I talked with, summarized it like this:

I personally enjoy getting my hands dirty, so when my mentors have offered up exercises, or specific challenging questions that require me to figure it out, I loved it. The information seems to stick more. (quote from Ryan)

The same rings true from the side of the mentors. As an experienced mentor says:

When mentoring remotely, I try to help by giving some exercises regarding the level of the developer. I do the exercise as well and I give several steps to build, but I give no indications/hints at the beginning. There is just a problem that needs to be solved. I'm doing this, since a big part of the developer's job is to know what and how to search. So the mentee is usually spending a lot of time looking for online examples or pieces of algorithms they have to understand eventually. When they are ready, we talk about our mutual solutions, and I ask to explain the choices they've made. We discuss the algorithm, the methods they chose, and the code quality. (quote from Loïck)

The best engineers are great mentors

The most sought-after software engineers I know, are all generous mentors. People not only look up to them for their coding, architecture, and execution skills. They also do so because they are approachable and continuously help others grow around them. This is because they are generous mentors, may this be informal or formal mentorship. And mentorship is how they keep growing their skills in areas like teaching, listening, and leadership, and growing a strong and supportive network around them.

If you are not being mentored or mentoring, reach out and find a mentor, or volunteer to be one in your company or online. Doing so will help yourself and other people grow further.

Finally, if you'd like to read more about mentorship for software developers, the Mentoring chapter in The Manager's Path is another good read on this topic.

Closing quotes from mentors who are engineers

In writing this article, I've reached out to several mentors and mentees in my network and via the Coding Coach Slack group, asking about their experience and tips to share. Below are some of my favorite comments, which all highlight how different, yet how valuable mentoring is, for both people involved:

Mentoring is a bit more intimate in a way as it's a 1 to 1 interaction. But you get to make a difference in someone's life. As cheesy as it might sound, I think it's quite special. It's a win-win situation where I get to meet and help other developers, wherever they are in their career path. I also get to deepen my knowledge and improve my communication skills. Teaching is the best way to learn - this is quite true. - Aurore

I use multiple approaches when mentoring. I have a small number of people with whom I have a cadence, and a slightly larger number of people that shoot me occasional, targeted questions. Both styles are great! Also, in my style, I lean heavily toward coaching. I feel strongly that people learn best when they help themselves. - Brent

A mentor is someone who has skills that a mentee desires to have and the time and willingness to help the mentee attain them. It's not really more complicated that. I find that if you try and make it more complex than that formality and process tends to get in the way of what should be a fairly natural thing. All the mentors that I've had throughout my career weren't formally my mentors. They were just people with skills that I admired, so I spent time with them and they were kind enough to share with me how they did things. I listened, and I practiced, and now I'm in a position where I can pay that favor forward on behalf of my previous mentors, and so I do it. - Zac

In some situations, we discuss what it takes to get to the next level in the person's career. Throughout the mentoring sessions, I try to spot opportunities to help them grow faster in their career, based on what worked for me. So I might suggest "I think you could lead this project end-to-end" or "what would it take for this tool to be adopted by multiple teams?" or other things" - Willem

I don't expect the mentee to come to me with questions all the time; it's a two-way relationship. It's easy to get trapped in the mindset of "Oh I'm the mentor. Why should I do all the work?". I did this for a bit, but ultimately, the mentee is working hard learning, and I volunteered my time so I can and should help. - Zac

This community in general is amazing and incredibly supportive. No one will straight up give you the answer (usually) because you learn nothing that way, but they will point you in the right direction, give you hints, show you reading material, and always boost your self-esteem when diving into the unknown - Ryan

Special thanks for the discussions on mentorship from Aurore, Brent, Le Digabel, Ryan, Zac and Willem in the making of this article.

from Hacker News https://ift.tt/2Kyxl3w