Uber-inspired practices for developer mentoring

This post lists the key insights from this article, by Gergely Orosz, engineering manager at Uber.

Mentorship has been the best things that’s sped up the author’s growth and others engineers around him. Indeed, Uber has an official mentoring program. This post discusses mentorship practices that work well engineer-to-engineer.

What is mentoring?

Mentorship is a learning relationship between an experienced person and someone who wants to grow.

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.

Onboarding is 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.

Informal mentorship: it’s happening everywhere

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.

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. 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. What the author 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. You can 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.

When you are 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.

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.

You could keep a running doc, shared with your mentor, where you drop notes between our catch-ups and prepare a list of topics:

Key things that happened since last time.

Reflecting on action items / guidance / discussions from last time.

A challenge I’m having.

A recent success you’ve had. Nine out of ten times, you will 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

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 problemsand 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. Sharing similar situations and

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. 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. The author is 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

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 the author 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 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.