Anyone who has ever queried information about developer onboarding, could notice right away, what we at Swimm call ‘The Onboardee Bias’. 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*. While 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 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, our experience is that this is in-fact the core problem of engineer onboarding.** In this post we try to shed light on the role of the mentor in the onboarding process:
- ‘The Good Mentor Checklist’
- How Poor Mentorship Reflects in Business
- Mentoring the Mentor 101
* By ‘mentors’ we mean experienced engineers tasked with onboarding a new hire, sometimes also called “buddies” among engineering teams.
** There are some awesome onboarding experiences out there. We are not saying they don’t exist. But our 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). Form a list with some of the tools and traits of a super successful mentor, and then try to map out 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 an entire skill-set associated with mentorship such as leadership skills, best practices, up to date training techniques, and more.
- A Realistic Plan. While most organisations create a basic onboarding plan for the first few days on the job, this plan consists mostly of HR issues and basic orientation. Our 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 a basic checklist.
- Passion for apprenticeship. 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 have established 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).
- System malfunctions. 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 naturally occurring bias?
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 cultivating a culture of knowledge sharing, and creating a tier of mentors equipped with the best tools to handle their next mentoring assignment.
To learn more about Swimm, sign up for a 1:1 Swimm demo.
