Imperfect #6: On the unreasonable effectiveness of onboarding buddies
Imperfect #6: On the unreasonable effectiveness of onboarding buddies
And the many pitfalls to avoid
Joining a tech company sometimes feels like getting a new phone plan. You’re pitched very hard and hand-held through the recruiting process. Once you’re in, you’re left to your own devices.
As a manager, I’ve overseen onboarding systems that failed to get people up to speed. So I’ve some thoughts on what fails. Luckily, I’ve also designed systems that have new joiners actively contributing to code and design within weeks if not days. So, some thoughts on what works too.
Onboarding goals
After we work hard to find an engineer that seems like a good fit (and vice-versa), we typically have a few months to determine whether or not it was the right fit. Signals start coming in on the first day, and by a couple of weeks we usually have a pretty reliable gut feeling.
These are a few of the main things that indicate the new hire is being successful:
Their code is making it to production and meeting role-appropriate quality standards
They’re showing elementary understanding of the business domain
They show signs of job satisfaction
They actively participate in design discussions
Stuff that they do or say is mentioned by others in a non-negative light
They seem to have budding connections to coworkers
In short, I want to see them happy, productive, and engaged.
As managers, we must understand that we can’t make anyone _be_ anything. Our job is to create the conditions, make goals clear, and point in the right direction.
Let’s assume that new joiners have a few basic motivations. If those don’t seem to be present, it might be necessary to part ways early. But that’s a matter for another day. The motivations I’m considering here include:
Contributing to the codebase
Learning
Developing their careers
There are many more, but I find that these are the main ones initially. Every professional developer I ever came across wants to code, learn, and either develop their careers or find a happy place.
I could write a lot about proper onboarding programs with presentations, workshops, reading materials, documentation, quickstart guides, etc. But most startups have nowhere near the time and resources. So most let their new hires sink or swim.
Onboarding Buddy to the rescue
There’s a very simple tactic that can help new hires swim, and it’s so effective that I recommend it to teams at all levels of maturity: the onboarding buddy.
Can’t get simpler than this. Nominate someone from the new joiner’s team as their onboarding buddy (OB). This person will be their go-to resource for _everything_, from questions about the codebase to where the bathroom is. It goes without saying that it should be someone who’s already gone through their own onboarding.
The new joiner will mainly pair with the OB in their work, to get a grasp of the codebase and any tricks might be needed to work with it. The OB must guide the new joiner through setting up their team-specific development environment, checking out the code and getting it running locally. Then they need to guide the new joiner through any issues they’re working on, explaining why they exist, which goals they have, the design and tech choices that have been made. The new joiner should be encouraged to ask questions and allowed to challenge all these.
On a non-technical front, the OB should introduce the new joiner to regular team rituals (standups, planning sessions, etc) and guide them through their first participations. They should also make introductions to people that’s good to know, such as systems engineers that work with that team more often, designers, PMs, anyone who’s part of the unofficial chain of communication and helps things get done.
The OB should be relieved of some work to account for all this, of course.
The way I like to run this is to do a meet & greet with the team first thing in the morning (remotely these days), make sure the new joiner has all the hardware available to them, then leave them alone for most of the morning to get their laptop set up. The OB won’t be hovering around them, but will be easily available if needed. In the afternoon, the OB comes, they can spend some time getting to know each other, and then get to work pairing on something the OB has on their plate, taking care to get the new joiner’s environment completely ready to run the codebase.
After that, the new joiner should be allowed time for independent exploration (they have a working environment now), as well as other onboarding duties. Each day should be a mix of those, plus some quality time pairing with their OB, dropping in and out of their work. The OB needs to be able to explain the decisions that happened between pairing sessions, and be willing to accept questions and challenges.
From my experience, there’s no universal duration for these onboarding periods. Aim for one to two weeks minimum, then judge as you go.
With a good onboarding buddy, a competent new joiner can be expected to get to the end of their first day with a few accomplishments under their belt:
A working development environment
The ability to explore a working codebase locally
Knowledge of the issue tracking system
Some notions of why things are the way they are
Maybe even some code in production, depending on how the first pairing went
Knowledge of who to reach out to
That’s a lot of accomplishments in not a lot of time.
Pitfalls
There are surprisingly many obstacles to this simple idea, and some complications. So let’s go through a few things that can go wrong or distract the new joiner.
Too much waiting
New joiners need to get their hands on their laptops as soon as possible. Ideally, before the first day. There should be nothing standing in the way of getting their laptop set up and accessing the bare minimum to start kicking the tires.
Suggestion: As soon as they’re legally allowed to access company information (probably midnight first day), email access should be granted. When they log in, they should find essential accounts already created for them (issue tracker, slack, company wiki, etc), and access to essential services granted at team level (namely the code repository).
Non-team onboarding buddies
Some HR departments love nominating OBs, from different teams or even departments. The idea is to prevent the new joiner from becoming isolated in their own department, and fostering cross-pollination of relationships and ideas across the company. Worthy goals for sure, but it muddles the waters a bit. The new joiner might be confused about who’s their _main_ main point of contact, and that OB won’t be able to help them actually getting up to speed.
Suggestion: Don’t get into fights with HR. Allow this, but treat is as an add-on. Make it very clear to the new joiner that their team OB is the main one, and that they are expected to work closely together through their onboarding period. But welcome the cross-departmental OB, as it is useful to have connections outside of one’s own team.
Fragmented calendar
Going deep into anything takes time. It’s tempting to fill a new joiner’s calendar of introductions and onboarding sessions, as it’s important to give them access to information and the right people. But we must remember that they’re developers. Creatives. They need long blocks of uninterrupted time to go deep into things. It’s going to be hard to understand any of the codebase in 1-hour fragments of time around meetings.
Suggestion: Go easy on the onboarding sessions and introductions. This person will be here for one or two years, there’s time to get to know Dave from Marketing. Protect their time as you would any other developer, and make sure they have ample time to dig into the code and the systems (3h+ blocks).
Too busy to spare a buddy
Teams that are too busy to onboard new hires shouldn’t be hiring.
It needs to be understood by all parties involved that any new joiner brings an immediate negative impact to productivity. Time must be invested in onboarding activities. That investment can be proactive, following a deliberate plan, or reactive, dealing with issues at code review time, in production, and if everything goes wrong, having to replace the person.
Suggestion: As managers, we must make sure that everyone understands how onboarding works. No one from Product must expect extra capacity from day one, and everyone must be prepared to deal with delays from the initially slightly decreased capacity. Onboarding buddies must be allowed time off their planning, and team mates must be reassured that taking time to help the new joiner is encouraged. When we invest the time early, we help the person get up to speed sooner and they’re delivering value before we know it.
Being the Onboarding Buddy ourselves
I’ve seen places where the expectation from above is that managers personally hold new joiners’ hands through onboarding, the idea being that it helps foster a good relationship and also that the manager is ideally suited to teach about the work and culture of the company.
I agree with some of that, but there are a few hidden pitfalls there:
What if we onboard multiple people simultaneously? Can we spare the time? If so, why do we have so much free time? If not, why are we trying to?
If we’re so comfortable with the codebase and systems that we can onboard others, why is that? Maybe we’re coding too much and managing too little.
We’re preventing others from developing themselves. Being an OB is in itself a learning opportunity. An OB gets to have a fresh perspective on things they took for granted, see faults they’d become blind to, and ends up understanding their own work much better through the act of teaching it to others.
As managers, there’s nothing wrong with taking an OB role here and there, but it shouldn’t be the norm.
Not checking in enough
The opposite pitfall to taking on the role of OB all the time is not checking in regularly enough. If someone else is doing a great job of onboarding the new joiner, it can be tempting to mark them as “handled” in our mind and keep to the regular schedule of 1 on 1s. That way, we can miss out on a crucial chance to build rapport with our new team member at best, and completely miss cues that something is wrong at worst.
Suggestion: Check-in at double the usual frequency during the first month. Conversations don’t have to be all work. In fact they might be better if they’re not. This is a time to get to know each other as people first, coworkers second. That rapport will pay dividends for both parties going forward. But make sure to ask about what’s going well and what’s more challenging.
Also, check-in with the OB specifically about the new joiner. Get some early feedback and use it to understand them better, so that you may support them to succeed.
Pairing isn’t a practice that we follow
This is very common. Unfortunately, the myth of the lone developer is alive and well. We might be dealing with an organization that is very resistant to the notion of “wasting” developer time by pairing. Transforming an organization to value active collaboration is beyond the scope of this article, unfortunately. But this is one of the biggest obstacles I’ve seen to effective onboarding, as it prevents buddies from working at their full potential.
Suggestion: Changing an entire organization takes time. I suggest sneaking pairing in by dressing it up as an activity that’s specifically for onboarding. That might be the pilot project you need to convince others that it’s worth doing regularly.
Regardless of how mature a company is, there’s no better way to learn than from someone else. On the other hand, teaching is one of the best ways to learn. Pairing new joiners with members of their team gives them the go-to person they need in the beginning, someone who can answer their questions and share that undocumented tribal knowledge from the very first days.
Onboarding is fraught with challenges and pitfalls, but if we keep our eyes open and are prepared to address systemic as well as individual issues as they arise, we should be able to turn an expensive new hire into a valuable and productive team member in no time.
Paying attention early on and giving people the support they need also does wonders for their experience working with us. A relationship that starts well often goes on to be satisfying and productive for both parties.