Brew the perfect onboarding storm
Your handbook and your developer documentation lay the foundation for streamlining your onboarding process. The speed of your onboarding journey is a function of technical, managerial and cultural efficiency. Here are some ways to optimise this experience for your new hires.
- Adopt a write once, run many times approach to creating onboarding assets. You can avoid redundant, ephemeral conversations this way.
- Enrich your FAQs to preserve new hires' "dumb questions budget.
- Use checklists to take away the guesswork from onboarding.
- Assign a buddy for every new hire, so they have a friend to guide them in their initial days.
- Use synchronous interactions to build connectedness and camaraderie with new hires.
Writing things up coherently takes effort. In fact, this makes asynchronous work feel daunting to beginners. If we look back at the principle of balance, you’ll notice that asynchronous communication optimises for the future, even if it’s tougher in the moment. In the long run, you’re also optimising for productivity and efficiency.
Onboarding is one of the first areas where you’ll see payoff for the effort you spend in writing things up. James Stanier says that “onboarding speed is a function of your technical, managerial and cultural efficiency”. I agree.
So in today’s post, let’s explore a few mindset shifts and a few tips and tricks you can use to bring people aboard your team. As you read on, you’ll notice how your handbook and your developer documentation are among the key ingredients to brew the perfect onboarding storm.
Write once, run many times
Conversational onboarding, to documented onboarding
In the absence of a written medium, onboarding can be a cumbersome process. You need to share all information in conversations and meetings. Not only is this redundant, it’s hard to keep these conversations consistent. You could keep the information somewhat consistent by having just one person do all onboarding, but that makes the entire process very fragile. Do you stop onboarding people onto the team if that person falls sick, goes on a vacation, or worse, leaves the company?
And even if you have one person do all the onboarding, they’ll eventually get bored. You’ll then have to make your process inconsistent by bringing in more people to do this. The alternative is to let the same person have the conversation a little differently each time, just to keep themselves interested. None of these situations are ideal.
Well written onboarding documentation is an upgrade to these fragile, redundant and ephemeral conversations. Here are some advantages.
When you share these assets so they’re visible to everyone, the entire team can co-create and improve these assets.
People can join your team any time - you don’t have to batch and queue people for onboarding sessions.
When people have questions, they can drop them in line with the materials. Anyone on the team can respond to these questions and either improve the materials or enhance the FAQ.
Each time you onboard someone they see the latest version of these materials. They’re persistent and they keep getting better.
And guess what! You’ve already created all of this content as part of your handbook and your developer documentation. You just need to curate it so you don’t overwhelm your new colleagues. More on that in a bit.
Preserve the dumb questions budget
Joining a team in flight is hard. Even if everyone’s friendly, new hires have many fears and trepidations running through their mind. In geeky organisational cultures, many new hires doubt their skills and experience and they feel the fear of “being exposed”. We know this as the impostor syndrome. There’s also an implicit “dumb questions budget” in everyone’s head. New hires want to seem competent. Given a chance, they’d like to ask only the questions that are necessary.
“Anything, any new hire on my team wants to know, is written down somewhere. They can find it out, they don't have to use their dumb questions budget. People don't often don't want to ask too many stupid questions that limit themselves. They can go and read whatever they want to read. And then they can come with better questions and have an interesting conversation.”
No question is truly “dumb”. It may be from your perspective, but not so much for someone new to your team. When structuring your handbook and your onboarding materials, be sure to expect these questions and answer them in an FAQ. Enrich the FAQ as you encounter more questions. This is how your materials stay fresh and relevant. You also show empathy for your new teammates this way.
Leverage checklists
When you think about onboarding at its most basic level, it’s a series of steps that allow a new hire to contribute to a team. A precise checklist takes away the guesswork from this process. Document what the new hire needs to do, by when they need to do it, and how. Here are a few tips to design the checklist.
Focus on the essentials. It can be tempting to throw the kitchen sink at your new hires. Instead, think of the shortest path to productivity. What’s the least they should do before they make their first contribution to the project?
Start with verbs. The checklist should have a list of actions for the new hire to perform. This could include reading some documentation, completing some paperwork, getting access, or completing a course. Phrase these checklist items such that they start with a verb. That way the new hire knows exactly what they need to do.
Make it the onboarding hub. Link the checklist items to their associated resources. For example, if the new hire needs to fill out a form, link the corresponding checklist item to the form. If they need to learn something new, link to the course they need to complete. Be sure to provide a point of contact if you expect they may get blocked. These points of contact can be on a per-item basis or for the entire onboarding journey.
Provide due-by dates. Just so the onboarding process doesn’t drag on, provide a due-by date for each checklist item. That way the new hires can keep themselves accountable. To make the checklist generic, you can keep the date ranges broad - e.g. what to do in the first week versus what to finish in the first 30 days.
The key here is to think like a designer. The design of your onboarding journey should be subtractive, not additive. That mindset will help you keep things lightweight, so you don’t overwhelm your new teammates.
Antoine de Saint-Exupery
“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”
Find the new hire a buddy
A good way for everyone in the team to take part in the onboarding process, is to institute a buddy system. Each time someone joins the team, pair them up with someone else in a similar role. The buddy becomes the new hire’s tour guide in the team. They can be a sounding board for questions, the person who makes introductions to others and also the first port of call for help.
Checklists are a good way to set expectations for the buddy as well. Align the new-hire’s checklist to the buddy’s checklist to facilitate shared accountability. For example, if you expect the new hire to attend a team happy hours call, then expect the buddy to introduce the new hire to everyone else on that same call.
As more people become new-hire buddies, they’ll learn about the onboarding experience. This’ll create a feedback loop so the onboarding materials and the process stays fresh. Expect buddies to add ideas to improve the onboarding process in a shared space. This could be a separate backlog that the team reviews every few weeks.
Build relationships
What’s a team without relationships? The sooner your new teammates experience the sense of togetherness and camaraderie, the easier they’ll settle into your ways of working. An async-first culture needs trust. You trust people who you have great relationships with. So don’t underestimate this part of onboarding. This is where meaningful synchronous interactions come into play. Real time communication is great for building connectedness, so use them to integrate people into your team.
First, establish the reporting relationship for the new hire. Reporting managers should set up regular check-ins with their new hires. Use the first few meetings to set expectations with the new hire. These meetings should address not just their role and performance outcomes but also how the manager and direct report will work together. I’ve described how to build managerial relationships, in a previous post.
Second, include the new hire in team activities. Earlier, I explained why meeting in person is valuable and why you need shared team experiences. At the very least, organise a periodic team “happy hours” meeting when you can catch up to just chat without an agenda. This takes nothing to organise, except an hour off everyone’s calendar, every few days.
Last but not least, encourage the new hire to meet people 1:1. Some people may find it daunting to set up these conversations by themselves. Foster a welcoming atmosphere in the team where experienced teammates voluntarily set up 1:1 meetings to introduce themselves and to get to know their new colleagues. I’ve found that 1:1 meetings are amongst the quickest ways to get to know people deeply and to break the ice. All you need to do is make it easy for newcomers, so that regardless of their personality they experience a sense of warmth from their teammates.
James Stanier adds that the onboarding equation isn’t just about onboarding. Your whole department is a function of your technical, managerial and cultural efficiency. When your new team mates report a high level of satisfaction and a low level of frustration with your onboarding process, you have a proxy for how efficient your team or your department is. When you extend this same efficiency to the entire organisation, you’ll notice that people can move across teams and departments seamlessly.
Depending on your position in your company you can improve things at a team, departmental or organisational level. It’s ok if you’re not senior enough to change things for the entire company. Remember that you’re part advocate, part guerilla. Be a guerilla to influence things within your control. Be an advocate to share your blueprint with others in the organisation so they can learn from your experiences.