This post is one of a collaborative pair of posts produced by my good friend and Ruby afficionado Rachael Goodenough and myself.

Please make sure to read Rachael’s Post before mine to get the full story 😀

Introduction

I’ve been leading teams for a while now - helping small groups of very smart people achieve great things. A lot of my job involves understanding everyone’s best thinking on a topic, then contributing my own if I think it is valuable, and then moving forward to test that thinking as the rubber hits the road.

This might sound like mentoring to some. I provide my opinions and experience to my teams, and they provide theirs back to me, and we all leave with a bit more than we started with.

It isn’t though.

Back in 2017 I was working as a Principal Consultant at Readify. One of the best things about Readify was that everyone believed in what we did, and was really into technology. Even outside of consulting - sales people, people people, administrative people - lots of people either used tech day to day outside of consulting (shout out to Lucy and her data-driven office administration), or had an aspiration to grow in their understanding and capability to wield technology.

One of the people with aspirations of being able to bend computers to her will was Rachael Goodenough - better known as Goodo.

In classic Goodo fashion, without any semblance fear and with great enthusiasm, Rache had booked herself in to go and attend Rails Camp. Before really knowing much about Rails. Or Ruby.

Goodo relayed this fact to me, and her growing trepidation about the upcoming experience. She felt she needed to at least begin understanding the basics of how to code to legitimise her attendance - not that this would be a problem, Rails Camp is an amazingly welcoming place!

Emboldened by my equal lack of knowledge of Rails or Ruby, I offered to mentor her in the fine art of developing software with them.

Where To Begin When You Are Beginning

Many of us probably have not had to ponder where we would begin learning if we erased all of our knowledge of software development and had to start again. It is actually a fairly terrifying thought, especially with the complexity of even the most modest modern software stacks.

I was worried I would not be able to give the best advice in this area. I had some ideas and opinions, but they were not concrete, and I also couldn’t back them up with appropriate subject matter.

To begin to learn something new, you need subject matter - books, videos, courseware, projects - whatever can be used as a vehicle for your learning.

My biggest misconception about mentoring was that I would need to be some sort of provider of all of these things - direction, material, insight, answers.

You don’t.

In fact, if you did find yourself having to provide all of these things, it would probably be a bit of a red-flag signalling that perhaps your mentee was not invested in their own success.

Rache demonstrated this to me from the get-go. She came in with a pile of learning resources and questions. Where should she start? HTML? Javascript? Ruby? What types of resources were the best? What did I think of these particular resources? She liked the idea of learning topics that would help her eventually develop software for the web.

I provided a sounding board for her to affirm her own decisions - she ended up chosing to begin with HTML which I agreed sounded like a great first step, and she found an online course that broke down learning HTML into bite-sized pieces which I had a quick squiz at to make sure it seemed legitimate.

Be Concrete

Once Rache had gotten started with the online course, we settled into a regular cadence of catchups. This provided me my second Aha! moment when mentoring.

Rache would progress through the online course to the best of her ability - and when she came across things she didn’t understand, or couldn’t solve herself, she would note them down. These notes became the backbone of our catchups.

It is really hard to give advice about oblique things - without concrete topics or examples to discuss, it is almost impossible to provide valuable input as a mentor.

I’ve participated in ‘mentoring’ relationships previously that exibited this trait - where each catchup was a slightly vague discussion about what the mentee had accomplished in their given area of growth over the past couple of weeks, and what could possibly have improved or be done differently.

My experience this time was a real eye-opener - each time we would go into a mentoring catchup, we had a handful of concrete problems to solve, and I left each meeting feeling I had really contributed to my mentee’s growth, allowing them to understand what they previously had not.

Metaphorically Speaking

It is easy to forget the depths knowledge we have accumulated over tertiary education and years upon years of professional experience. Many thousands of small pieces accumulate, and we no longer think about them directly - we use this knowledge as a basis to reason about higher-level, more complex problems.

Communication is most effective when we tailor our approach and content to our audience. If your audience happens to be a beginner or junior developer that you are mentoring, you need to work pretty hard on not assuming anything about their prior knowledge.

This became very clear to me when explaining concepts like variables, functions, objects, and methods.

Work hard to break your knowledge down in a way that your audience can consume and digest it. For Rache, we found metaphors worked best.

One metaphor we used very early on was variables being like boxes on a shelf. You could pull one down, give it a name, put something in it, then put it back on the shelf. Next time you wanted the contents, go and find the box with the name you wanted!

Follow The Pace, Don’t Set It

A cornerstone of personal motivation is that people invest in things they personally contribute or commit to - if you want someone to win the game, you need to let them dictate how they play it.

There were times that Rache was flying through course content, and we would struggle each week to answer all of her questions in the time we had available! There were also other times when work and life would take the focus off of learning new things, and we had to postpone catchups.

In either of these situations it is important as a mentor to do your best to support wherever your mentee is at. This may mean you need to race along with them, and invest time in making sure you can contribute to their accelerated learning and don’t leave them blocked on important problems (I certainly had to learn some Ruby between our catch-ups!). It may also mean you need to assure them that not focussing on the goal for a week or so wasn’t going undo progress to date - it is a marathon, not a sprint.

By allowing your mentee to dictate how they work towards their goals, you are doing the best possible thing for their intrinsic motivation. Side note: if you have not read Drive by Dan Pink, I highly recommend it!

Think Win/Win

One thing that I didn’t anticipate was just how much of a kick I’d get out of working hard to break down concepts to a point where I’d see they had landed, and then see Rache apply those learnings in future developments.

This enjoyment isn’t just accidental though - you need to get something out of the relationship too. If you don’t, it is likely you’ll burn out as a mentor, and it won’t be a sustainable endeavour, which isn’t good for either party.

I found that I really enjoyed breaking down fundamentals for Rachael, so I now know mentoring junior developers is something I get a lot of personal satisfaction from. If you want to be a mentor, you’ll need to think about where you would get the most benefit - do you want to help people set a solid foundation, or do you want to work with seniors on more complex problem sets? Is your love in a particular knowledge domain, like cloud?

Wherever your passion lies, ensuring you look for opportunities to mentor in that area will benefit both your future mentees and yourself, as you will be setting up for sustainable, durable mentoring relationships.

Postface

Firstly I’d like to thank Rachael for inviting me to co-create a pair of posts on our mentor/mentee experience - it was a great experience to reflect on 🙌.

I thought a summary might be in order to distill the above, so without further ado:

• Mentoring is one on one - being a leader isn’t being a mentor
• You don’t have to supply all the things required for your mentee’s learning - they bring the options and problems, you provide your best thinking to help evaluate and solve them
• Make sure you always have concrete problems to discuss at regular intervals
• Discover how your mentee learns best, and work hard to break your knowledge down and package it in that format
• Let them dictate how they play the game
• Be honest about what you get out of it and only commit if it is win/win

If you are looking for a mentor and want some advice from the other side of the equation, make sure to read Rachael’s Companion Post to this one.