Being a Mentor and Giving a Shit

Don't make this The Bad Place for someone trying to learn

Becoming a mentor is its own skill set, much like programming, leading, managing people, and others. It is also, in my experience, one of the most fulfilling because it is about helping people to grow and improve themselves. Learning to be better and supporting others so they can become a better version of themselves is a central theme of one of my favorite shows, The Good Place.

As Michael (Ted Danson) says in one of the final episodes:

Look, the point is that people improve when they get external love and support.

One way of providing that external support is mentoring. One thing that can stop someone from improving though is a shitty experience while being mentored. I've had several mentors in and out of the software industry who were just kind of garbage at it for different reasons. Each time it happened it evoked the same feeling as reading a new technical book and finding the writing confusing or misleading or lacking the context needed to learn it. I don't begrudge them for it because most of the time it was simply due to their own inexperience or inability to help me in a way that worked for me.

Most mentors are not trained on how to be good mentors in advance because it's common to conflate the ability to understand a concept and the ability to teach that concept to someone else. It's also uncommon to train people on how and why they should care about someone else's experience. Tack on the fact that organized mentoring in the software industry (besides paid programs) is rare and you can imagine how variable your experience might be in the case you do get access to a mentor. The result is you can not predict whether a mentorship will be useful or fulfilling until you go through it and try it out.

Inexperienced or under equipped mentors being so common reinforces the unchecked idea mentoring is some dark art, taught only to those who go beyond the veil. There are ways to learn how to be a good and better mentor, but they're not exclusive or hidden arts. Mentoring is about being a solid teacher and a supportive fellow human. In order to accomplish either, as a mentor, you need to start by meeting the other person where they are.

In other words, it is the mentor's responsibility to bridge the gap between themselves and the person they're mentoring. It also means giving a little bit of a shit about that person even if you don't know them well and it means helping them be accountable to themselves and their own goals. Keeping this in mind, there are three tactics we can apply to better focus on our mentee and help them grow.

Break down goals into practical tasks

Ok, but what do you really mean?

Building a plan to help someone grow is much like building a technical design for a product. Imagine the mentee as a Product Manager, bringing you a high level design, a set of perceptions they hope to evoke, and even some preliminary features. Any Software Dev experienced in technical design will ask questions to better understand, from a development perspective, how those goals could be achieved practically and then create tasks from that understanding so they can measure progress towards the design.

When you begin working with a mentee it's normal to start with their goals for the mentorship. They may bring goals like, “be better at public speaking,” or, “learn more about Docker,” or, “become a <insert next job level>.” These are all good places to start, but they're much like a high level product design: too broad to be useful to someone trying to make progress every day. Treat these as an endpoint and begin to walk backwards to find tangible steps that can be taken towards them. Try to understand their perception of these goals to see if they can be better defined as individual problems to solve.

Ask about their motivation or how they perceive the final result. Learn about what they feel they know or what they can do now in comparison. Identify opportunities for them to practice those skills - these may be readily available, or you can find some, or you can find a way to create them. All of this will lead to creating tasks where they practice their skills and produce some type of tangible result you can review together. These tasks will then also become markers of progress, check in points for feedback, and clear examples of your mentee's ability at each step in their journey.

The extra nice thing about practical tasks is they can act as proof of accomplishments to those outside of your mentorship. Your mentee can prove, afterwards, they have a skill in public speaking because they provided an organization wide presentation on a topic. Other folks can see their skill in documentation because the new section of your development handbook is authored by them. At the least, these accomplishments will be something you can both look back at to remind yourselves of what progress you made together.

Figure out how your mentee learns

A sack with a book someone doesn't want to read is worth the sack

As developers we are often required to meet schemas. Database schemas, method parameters, API requirements, and others. To put it simply, we're regularly asked to align our request or demand by working within the requirements of something with which we're engaging. You can't call a method with any old parameters and you can't authenticate against an API in whatever way you prefer.

So think about your mentee as an API. Even if they don't know it yet, they have a particular schema to the way they can effectively learn.

Ask them about it!

  • What's your preferred way of learning?
  • How do you learn best?
  • Do you like to read books?
  • Watch video tutorials?
  • Would a hands-on project be better?

Asking and learning about your mentee is part of building a relationship with them and these questions will expand your understanding about them quite a bit. It helps inform how you can talk to and teach them as well. Do they prefer drawing or writing things out? Then conduct meetings with a whiteboard (digital or real). Do they prefer reading content? Then send them some relevant articles to read before your next meeting.

The amazing thing about asking questions like this is that if your mentee doesn't already know the answer then they'll have to figure it out and you will have helped them learn something about themselves. That's pretty fucking mindblowing, if you ask me.

Mentoring, for us, and learning, for our mentees, is a hell of a lot of work. It'd be a real shame if we forgot all that we did together after we close out a mentorship or move on to a new goal. The completion of a goal or the closing of a mentorship are great opportunities to look back and summarize the most important learnings and achievements. This post has used a few references to practices in software development and this step could easily invoke rituals like post-mortems and retrospectives.

Those rituals, however, have a lot of variation to them and the goal here is rather specific: help your mentee distill what they have learned into something they can easily remember, repeat, or reference.

We want them to remember their accomplishments to bolster their self confidence.

We want them to repeat, or practice, their skills so the knowledge is engraved into them.

And we want them to reference what they've done because learnings should be tools they can rely upon in the future.

You can ask questions like the following:

  • What are the most interesting or fulfilling things you've done or learned here?
  • What is something you've been thinking about during this process that you don't want to forget?
  • What is something you can say to yourself or write down to summarize the most important things you've learned?

Answering some or all of the above will lead to some very interesting answers. In some cases, your mentee will want to remind themselves of their value and resilience when facing challenges. In others, they'll want to remind themselves of that one annoying thing in Docker they keep forgetting because it's so stupid and they always forget it. In some cases, your mentee will come up with a repeatable phrase they can say which will put them in the right mindset at the right time.

Not everyone needs to walk away with a pithy phrase, but hopefully you will work with them to come up with some clear lessons learned, goals met, or general concepts that remind them they worked hard and became a better version of themselves.

Remember to do the same for yourself. Mentoring is not completely altruistic and we can only become better mentors by getting feedback and having someone else give a bit of a shit about us. Ask for feedback from your mentee on what went well, how they felt supported or how they could have been better supported. This can happen through a feedback form, but hopefully you've built enough of a relationship with your mentee by the end of a mentorship or a goal cycle that they feel comfortable enough providing you with feedback.

And if they don't, well, that's important feedback on its own.

About Joe Greathead

I've been a Staff Developer at Shopify, I created the Tabletop Library app used at PAX and the Verge Taglines app for the Tidbyt. This is my blog on Software and other stuff.