How to become a better mentor

It’s important that this mentor is not the boss, or someone they report to, because that will be a “conflict of interest” if the person you ask honest, sometimes embarrassing, questions to is the same person who hired you and who's also setting your salary. Preferably a mentor is a senior developer in your team with a genuine interest in helping junior developers early in their new career.

During the last decade I’ve been mentoring a lot of developers and also lead several development teams. I’ve been part of mentoring programs working on how to improve the onboarding experience for new developers as well as lecturing on Universities for aspiring developers and during these years I’ve come across a few lessons on how to be a better mentor.

Now I’m not saying that I have perfected the art of mentoring, which is why this article is called ‘How to become a better mentor’, not “the best”. I believe mentoring is one of those skills you never fully master and god knows I’ve made mistakes along the way (some of which I’ll share with you in this article). These are just some of the things I’ve picked up and thought I would share with you today. Enough chit chat, let’s get started!

Reserve time for mentoring in your calendar 📅

It’s not uncommon for an employer to ask you to mentor a new developer on top of your regular work commitments. This is great business for your employer, having a new developer introduced and mentored in their new position with no loss in production since you’re still expected to deliver as you did before. Unfortunately, unless you’ve perfected the art of cloning yourself, my experience is that this never works and it will only result in two possible outcome:

1. You will become stressed out trying to balance your ordinary workload while trying to be a devoted mentor. This will result in poor mentoring, stress and you’ll probably decline any future mentoring assignments.
2. Or more likely, you won't feel that you have time for mentoring because you need to focus on your ordinary assignments and the new developer ends up getting little or no attention from you which will result in a poor onboarding experience (and again, you probably won't sign up for more mentoring assignments any time soon).

This is why I now, based on past experience, always make sure to put all cards on the table as soon as I’m asked to mentor a new developer. I’ll say that I’d be more than happy to do so as long as I get planned (reserverd) time in my work calendar and that I can’t be expected to deliver the same amount of workload as I did before. This is more fair to everyone involved and if that can't be promised due to the high workload at the moment, I’ll kindly say no to mentoring this time.

But how much time should I plan?

So how much time should be planned every week for mentoring you might ask? Well this is a tricky question since it varies a lot on the level of experience from the new developer and the complexity of your project, but I usually ask for 4 hours per week to start with and adjust that time up or down after a few weeks when you and the new developer got to know each other. This way I make sure I have time devoted to mentoring tailored based on the new developers' needs. 

Don’t assume everything’s fine (even if they say so)

This lesson I had to learn the hard way many years ago when I was asked to help out a new developer in our team. Everything started out fine and after a while I stopped hearing anything from him and the few times I did he said everything was fine and he didn’t need any help at the moment. And since I had a high workload at that time (again, back to my first lesson) I thought that everything was going fine since he said so. 

It turned out that this developer was not good at reaching out and asking for help because, like most developers, he didn't want to come off as “inexperienced” and instead spent days trying to figure things out that I could have helped him with in minutes (based solely on background knowledge). Eventually this developer quit his position and joined another company and to this day I can’t help but blame myself for this loss.

Check in regularly

That's a mistake I’ll never make again and this is why I now always check in regularly, even if they don’t ask for it, to see how things are going. Pro tip: Set a calendar reminder to check in at least twice a week. 

I also make sure to not just ask if everything is fine but make them elaborate on what they are working on at the moment and how they've planned on doing it. While doing so it becomes a lot more natural to ask related questions and share tips along the way as they pop up. 

They code, you guide 👩‍💻

When the person you are mentoring actually does reach out and wants your help with something, do not make the mistake of just sharing your screen and quickly jump between projects, tabs, classes, commands etc. because you want to be as efficient as possible when delivering the answer. 

There's nothing more stressful for a developer to watch someone else’s screen and try to follow along and at the same time listen and take notes on what is happening on the screen with no option of pausing or rewind. It doesn’t matter if you stop and check in regularly with -”You follow?” because they will just say yes regardless if it’s true, since they don't want you to feel that you have to start all over again and that they are taking up too much of your valuable time.

Don’t steal the screen!

Instead I’ve found that it’s best to let them share their screen while I guide them through the possible solution (most video conference tools today have the option of showing both mouses so you can point them in the right direction without actually doing it for them). 

So sit back, take your time (again, back to my first lesson), grab a cup of coffee ☕ and walk them through the whole process and make sure they fully grasp what's happening and why, and I promise you’ll never have to repeat this information again. Which leads me to my next lesson...

Don’t just give them the answer

Often when you’re stressed and someone reaches out to you with a specific code related problem that you know the answer for based on past experience, it’s easy to just quickly throw out the answer like: -”Oh well that is because you need to add this line here or run this command here. You’re welcome, bye!”. 

While it’s nice of you to share the answer, this is not really a good long-term solution unless you want to be the person at your company that everyone comes to for answers for all eternity. This might sound like a good thing for you but trust me, it's not! In other words: Don’t be Brent! (Read “The Phoenix Project” or this summary of "The Brent Effect".)

Give them the tools to find the answer themselves 🎣

Instead, if you have the time (again, back to my first lesson), share the background and how you found the answer back when you first encountered this issue. Where you looked, things you tried and what you searched for in order to finally arrive at the solution. This is far more educational because then the next time that developer has the same or a somewhat similar issue they now have the tools to go and find the answer themselves before they reach out to you.

Raise them up!

This is one of my favorite lessons and if you only take one thing with you from this article I hope it’s this one. When the person you’re mentoring accomplish their first achievement, preferably at the end of their first week, make a habit of raising this achievement in one of the companies communication channels (for instance in some general channel on Slack). 

An achievement can be big or small, anything from merging their first PR to the core, moving their first ticket to Done, performing their first production deployment etc.

This could look something like this:

#H5YR 🖐

Posting this literally costs me nothing, takes only a minute of my time but it could mean the world for the nervous new hire just about to close in on their first week at their new job. If you have a great workplace (which I hope you have) this person will be greeted with countless high fives throughout the day and encouraging conversations by the coffee machine.

And I guarantee you, at the end of the day when this developer comes home to his or her family, hopefully with a bottle of nice “celebration wine” 🍷, the dinner conversation will most likely start with something in the line of: -“Oh, I had the most amazing day at work today…”. 

Wouldn’t you want to be the source of that?

And repeat.. 🔄

I hope you found these lessons helpful and besides everything mentioned I just have one more thing to end with: If you’re serious about becoming a better mentor, then you need to continue practicing it, over and over. And don’t forget to ask for feedback along the way and book a review meeting at the end of your mentoring period so you can find out what you did well and where you can improve as a mentor. 

Like I said in the introduction I believe that mentoring is one of those skills you never fully master but that gets a little bit better every time you do it, hopefully now with the help of some of the lessons in this article.

Take care of each other and happy holidays.

Cheers friends! 🧡