A Few Reasons Why Your Software Buddy System isn't Working

Mentorship requires at least 2 people. However, anyone who has ever queried information about software developer onboarding, could notice right away a strong focus on the onboardee. Most onboarding approaches are centered on guiding new hires through their first days, tasks or overcoming the hurdles of getting started. But this approach rarely highlights the troubles and challenges of the mentors*. We frequently hear about the “Sink or Swim” approach by which new engineers are “thrown into the deep end” with hands-on tasks on their first day in. The truth is, mentors are also treated this way, although unintentionally and with no buoy waiting for them.

Mentors are, by definition, some of the more experienced and confident engineers on the team, so it’s almost counter-intuitive to highlight their insecurities. Yet, my experience is that this is in-fact the core problem of engineer onboarding.** 

In this post, I'll try to shed light on the role of the mentor in the onboarding process:

1. The Good Mentor Checklist
2. How Poor Mentorship Reflects in Business
3. Mentoring the Mentor 101

* By ‘mentors’ I mean experienced engineers tasked with onboarding a new hire, sometimes also called “buddies” among engineering teams.

** There are some awesome onboarding experiences out there. I am not claiming they don’t exist. But my experience is that they are not the norm.

1. The Good Mentor Checklist

The journey to good mentorship starts with reflecting on your own experiences (as a mentor or mentee). What were some of the tools and traits of a super successful mentor, and what were the hurdles? Why do some mentors fail to thrive? Here are some key reasons:

• Time. Or lack of it. It’s no coincidence that most mentors are extremely busy. Knowing their way around means they get picked for harder tasks. Good mentorship requires ample time and patience, and many mentors lack those.
  
• Good Documentation. So much has been written and said about how challenging it is to create and maintain good documentation. Suffice to say that a mentor’s life would be much easier with it, and it rarely exists.
  
• Mentorship Skills. If you have been picked to be a mentor (congrats), you are likely very experienced and know your way around the company or code. But being a really good mentor means you also need a separate skill-set: leadership skills, best practices, training techniques, and more. Many mentors get picked with no regard to that skill-set.
  
• A Realistic Plan. While most organizations create a basic onboarding plan for the first few days on the job, this plan consists mostly of HR issues and basic orientation. My experience shows that most teams don’t have a plan for onboarding the new hires onto the codebase, explaining common issues, legacy code, best practice or edge cases. If they do, it’s usually a basic checklist.
  
• Passion for mentorship. It goes without saying that a little passion for paying it forward and teaching others, goes a long way and makes all the difference between a mentor and a really good mentor. A major hurdle is identifying such spirit in mentors and leveraging it, but also making sure they don’t burn out.

2. How Poor Mentorship Reflects in Business

So we covered some key elements needed for the job. We also established that many times, mentors, experienced and competent as they may be, are not properly prepared for the task.

How does this affect our job and business?

• The "Swiveling Chair Syndrome". Getting a task you feel unqualified for, might lead many mentors - even potentially great ones to procrastinate. Preparations for the new hire are pushed to the day before their arrival and sometimes happen on-the-go. The result of which - talented new engineers swiveling in their chairs for quite some time, waiting for something to happen…(or in other words, stretched out time-to-value).
  
• Blaming the company. Another unfortunate product could be finger-pointing and blaming “the system”. Feeling embarrassed with their inadequacy, mentors might vent hints of frustration with the new hire: “Yeah, there’s some documentation, but I wouldn’t bother with it… Just try to figure it out…” or “They told me you were coming last week, but we have a version coming out, so I guess you’ll have to manage…”. Of course, these are the last things you want new hires to hear in their first few weeks.
  
• Sinking, not swimming. We mentioned the “sink or swim” approach earlier. Sure, letting new hires struggle with no help is a way to weed out weaker hires, and it may shorten the time it takes to spot a poor fit. But this also means you are giving the good hires a hard time, sending them to fend for themselves. This method is often used to mask insecurity. Rather than admitting you don’t know how to deal with onboarding someone, it is much easier to explain a lack of a plan with ideology. So, even if this method is not beneficial in the long run, unprepared mentors might adopt it anyway.

3. Mentoring the Mentor 101

So, what can you do about this?

Like with other issues, acknowledging there is a problem (i.e. that mentors are being overlooked) is a good starting point. Ask senior developers how prepared they were or currently feel to mentor. Ask them how their own onboarding was like, and whether they would have wanted it to be different. Recall your own onboarding experiences, both as a mentor and a new hire. But mainly, focus on knowledge sharing and how to do it right for your team, creating a tier of mentors equipped with the best tools to handle their next assignment.

Hey, I’m Tom, Co-Founder of Swimm, a DevTool we launched after witnessing how engineer onboarding practices could massively affect R&D effectiveness. My background is in Tech, Training and Policy. I hold a Masters in Public Policy from Princeton, an MBA and a B.Sc. in Physics and Math.

Also published at https://swimm.io/blog/2020-07-14-who%E2%80%99s-mentoring-the-mentor/