Some Advice On Technical Mentorship

15 Aug 2023

During my time as a director at New Relic, I founded the company’s internal mentorship program and ran it for about three years. Before that, I benefited from many mentorships, myself, on both sides of the relationship. Mentorship is one of the best ways you can improve your own skills - as the mentor or the mentee! - and also helps raise the skills of those around you. An effective mentorship program is an invaluable way for an engineering organization to improve its bench strength and build a sense of community.

Over the years, I’ve accumulated various pieces of mentorship advice, as well as developing my own ideas on the topic. I’m afraid I don’t have attribution for all the individual points mentioned below, but please consider this a curated collection of mentorship advice, rather than a fully independent invention.

Also, don’t feel bound by anything in this article. In my experience, every mentorship relationship is different, so you may choose to go a different way and that’s fine. Decide together with your mentor or mentee what will work best for the two of you.

What Is Mentorship?

There are many valid ways to look at mentorship, and many different things people might be looking to get out of it. When I think of mentorship, I usually think of somebody who has experience with a certain skillset, somebody else who has less experience with that skillset, and the two of them working together to develop their skills. I don’t see mentorship as having a “teacher” and a “student” - both people will probably learn a lot by working together. Also, job titles or overall seniority shouldn’t determine who is the “mentor” or the “mentee”, but rather their respective levels of experience in the specific skills being explored. A great mentorship is a collaboration between two people, and should involve mutual respect and a recognition that you’re both there to learn and improve your skills together.

Mentorship Tips

Agree on the basics before starting.

Before deciding to “officially” enter the mentorship, find a time to meet, discuss your backgrounds and interests, what you’re each hoping to get out of the mentorship relationship, and decide together whether you’d like to go forward with the mentorship. If it seems like a good fit, this is also the time to decide on the details of how you’ll be working together. Be very explicit about whether this is a mentorship - you don’t want a situation where one person says they are mentoring somebody, but the other person thought they were just collaborating on a project.

Decide up front on a meeting cadence that works for both of you.

Common choices include half an hour a week, or an hour every other week, but of course you can schedule more or less time if you like. Another option is to have more ad hoc scheduling, where the mentee schedules a session when something comes up that they’d like help with. Make some working agreements for the time between meetings, as well. Is it ok for the mentee to occasionally request some code review or ask questions on slack? Or would it be better to save those for the in-person meeting?

Let the mentee drive the scheduling and handle calendars.

This gives them some control over how things go, and can also be a valuable signal. If they slow down or stop scheduling meetings, that’s a good time for the mentor to check in and see if they’re getting everything they’re looking for out of the mentorship, or would like to make some changes.

Have a specific goal that you’re working toward.

This could be very broad, like “developing the mentee’s Elixir skills,” or more specific, like “understand how the company’s Java build and deploy pipelines work.” Having a goal will help to guide you toward a format for the mentorship, and what sort of processes might work best for you.

Agree on a time to stop and reevaluate the mentorship.

This might be when a particular condition is met (“once we finish this sample project”) or after a certain time (“three months”). It’s normal and natural for mentorships to come to an end after you’ve achieved the goal, and that’s ok. You may also decide to continue meeting and start on a new goal, and that’s great, too. Either way, it’s good to stop and reflect from time to time.

Pick a format for the mentorship sessions.

More on this below, but you should both have an idea of what a mentorship session will look like, and what each of you are expected to do between sessions.

Let the mentee make (at least) some of the decisions.

While a “lecture” based format is one way to learn, and works for some people, most folks learn better by actually practicing a new skill and then actively reviewing their work afterward. It’s important that the mentee is an active participant in whatever discussions or projects the two of you are doing together, rather than just a passive observer. At the same time, it’s also important that they feel they have the support and guidance they need to make progress. As is often the case, it’s good to check in regularly to see if the balance feels right and adjust as necessary. This is an area where it’s also important to be aware of any power dynamics at play. If one person is significantly more senior, or on the more powerful end of some other dynamic (gender, race, or others), it’s especially important that they make sure they are leaving space for the other person to speak up and contribute.

Working agreements aren’t written in stone.

As you go forward, it may become clear that your initial agreements aren’t working as well as you’d hoped, or you may just like to try something new. If you get to a point where you would like to change things, feel free to have a conversation and change them. Clear communication is the key here. It’s important that everybody understands what the agreements are, and if you want to make a change, it’s important to be very explicit about what is changing and what the new agreement is.

Often, the best mentors are just a bit further down the road.

Sometimes, the best mentors will be folks with just a little more experience than their mentees. People in that position often remember what it was like to learn those skills for the first time, what aspects were confusing or difficult, and where some extra support might be helpful. There are also advantages to having a mentor with deep expertise in a given subject, of course, but it can be more difficult to bridge that gap and adds some additional challenges. If there’s a large skill gap, pay extra attention to clear communication and check in frequently to see how things are going.

Be explicit about which areas the mentee is already familiar with.

It can be difficult for a mentor to judge what material a mentee might already understand, or when more explanation might be helpful (especially when there’s a large skill gap). This can lead to situations where the mentee feels patronized or talked down to if things are over explained, or alternately, they may end up feeling lost if there’s not enough explanation. One approach is to just explicitly ask when bringing up a new topic for the first time. For example, “how familiar are you with Kafka?” or “if I say GraphQL, do you know what that means?” Make sure it’s clear that this is not a test, it’s fine if they’re familiar with those topics or not, and you’re just checking in to see how much explanation would be helpful.

Frame things in terms of the listener’s background.

When an explanation is warranted, it can be helpful to put it in terms of systems the listener is already familiar with. For example, if they’re moving from one language to another, it can help to explain structures in the new language in terms of how they’re similar (and different!) from structures in the language the listener already knows.

Go beyond just the final product.

While it’s certainly valuable to see specific techniques and patterns implemented in code, it can be even more valuable to discuss the broader context. What other approaches might have worked here? What are the considerations that lead to choosing this one? How did you find that information, and what other people were involved in that discussion? “How did you know what to write” is often just as important as “how did you write it?”

Let your managers know about the mentorship.

Part of your manager’s responsibility is to support your career development, and participating in mentorship is an explicit part of many career ladders, so this is relevant information for them. They can also help support you by offering advice, working around scheduling constraints, etc.

Some Mentoring Formats I’ve Seen Work

Ongoing Mentee Project

In this format, the mentee has a project they’re working on specifically for the mentorship. This might be a personal project, an “innovation time” project, or potentially just a toy project to learn a new technology. “Real” projects are usually better if you’ve got one handy, but make sure it’s nothing with an urgent deadline. Both of you should do the initial planning and project setup together and discuss next steps, and then the mentee works on the project between sessions. At each session, review the progress that’s been made together, and the mentor offers feedback. This will often involve the mentee making adjustments, or backtracking and going in a different direction, and that’s totally ok. This style is all about exploring the options available and discussing trade-offs, and is a great approach when the mentee has the basics of a language or framework down, but wants to progress to an intermediate or advanced level.

Regular Pairing

In this style, the mentorship takes the form of pairing sessions. This could be on an ongoing project, as described above, or you could pair on whatever the mentee or mentor is working on with their team. This is a good approach if the mentee is still looking to pick up the basics, or would like a little more guidance as they actually work on the code.

Code Review and Deep Dives

Another possibility is to find some interesting code to review together at each session. Review the design decisions made in the code, consider other ways it might have been done, and discuss the inherent trade-offs to different approaches. This could be work from either person’s team that seems relevant or interesting, or it could be a deep dive into internal systems the mentee is interested in, or open source projects, or anything else. This can be a good approach if the mentee has very specific goals in learning about a particular project or codebase, or if you know of some specifically great (or not great) code to learn from. This could also end up leading to some pairing work or a mentee project, if you decide to actually implement some of the alternate approaches discussed.

Q&A Sessions

This is often the default that new mentors and mentees fall back on. It’s important to know that other options exist, but this can be an effective approach for very new mentees who are still figuring out their goals and what they’re interested in learning more about. This can also work well for a more on-demand schedule, where the mentee schedules sessions when they have a situation they’d like some help working through. It may not be a great long-term approach for regularly scheduled sessions, though, as it can be hard to predict when questions may come up.

So Many Other Possibilities

Don’t feel limited to just the things on this list! These are some ideas and possibilities to use as a starting point, but you should work together to decide what approach is best for the two of you. You can always modify things as you go, or switch to a completely different approach down the road.

The Only Actual Rules

There aren’t many things I would say are hard rules in a mentoring relationship. However, there are two elements that are absolutely crucial: mutual respect, and clear communication. It’s important that everybody understands what the expectations are, has a high degree of psychological safety, and feels comfortable asking questions or suggesting changes. If you have those things, you have the basis for a rewarding mentorship that will be a valuable experience for everyone involved.