Onboarding is the official process of integrating new team members into an organization. It's a good spot to start everything on the right foot. Over the years, I've been lucky enough to introduce great engineers to my teams. In some cases I onboarded solely on our codebase, sometimes it was a tool we used frequently or it was just about the product and responsibilities. Regardless of focus area, our goal stays the same:
Enabling newly joined team members to contribute.
At the end of the process, onboardee (Yeap! There is such a word) should have clear answers to their questions, should feel confident and comfortable enough to kickstart their journey.
Remote working is becoming a strong norm, it's escalated with Corona and hopefully it will be permanent for many companies. It will be more and more common to onboard new members remotely in the future. I wanted to share my experience on welcoming new engineers during fully remote setup and to highlight what worked well within in the long run.
Before we begin it's safe to raise my assumption: My experience is based on cross-functional teams who work on dedicated parts of products with a huge active user base.
I assume you already have a detailed documentation for your platform or domain in general, where you explain the tools, frameworks, patterns you make use of. If you don't, it will be wiser to start with that. I think onboarding through documentation is more efficient because it's scalable, quotable and iterable. I usually create sections with the topics I wanted to talk about, create special diagrams to help me explain concepts or architectures better. Stating the purpose of each layer, giving links to other detailed documentation areas are good practice. Something I noticed is that adding screen shots of the product helps a lot to associate code with product and features. Even recording some features to show user flow brings many advantages.
Having a short to-do list for the new team member gives a lead to start and creates sense of accomplishment. This list is just consist of small tasks that everybody needs to do when they join the team, such as; joining the common slack channels, requesting needed permissions for tools, joining certain trainings, finding a pairing buddy, joining to office tour etc. They can do them theirselves and cross them out the list.
Pairing is such a secret weapon which should be used so often that it stops being secret anymore. You can also take advantage of pairing during onboarding process. Whenever possible, you can invite the new team member pair on tasks where you'll be the main driver and navigator, while onboardee is mostly observing. This might give more clarity on topics and ease the overall onboarding journey.
One of the things I really like to do is spreading onboarding meetings over a wider period of time. Keep in mind that this is not the only onboarding they are attending, in first weeks they probably have organizational and cultural ones too. Instead of discussing the codebase for 4 hours in one day, I setup multiple slots spread over the days where I get together with the onboardee and have a talk for about an hour. As this gives them space and time to think about the topics we discussed, it also allows me to direct onboarding process better. I usually setup the last meeting as AMA (ask-me-anything) style, where onboardee can address any kind of questions, technical, organizational or even personal.
Once I joined a team where many concepts were new to me, I had to learn a new language and how to use bunch of tools. This situation quickly becomes overwhelming; good way to solve it is having enough time to digest new chunks of information and to experiment enough with new tools. Luckily at the time, my team gave me enough time and space, this allowed me start contributing when I felt comfortable, removed the pushy feeling, resulted with the best possible outcomes for the team and product. I believe that's a good practice instead of expecting onboardee to start with a small bug ticket in few days.
Feedback is a gem, having a habit of asking feedback often brings tremendous benefits. So it's important we don't miss this step and ask for feedback about the onboarding and overall process when it's completed. Additionally, usually after 3 months, I ask for an extra feedback. At that point, they have worked together with the team for a while, completed certain tasks, understood how team and product works, thus they can look back in retrospective and bring ideas about what could be improved. This will help to iterate all the practices above and most importantly it will benefit the next onboardee (yes I like this word) a lot.
Onboarding is a continuous process during a team member's first year. Remote or not, having an efficient onboarding process have long-term benefits: increased productivity, robust product, better team member retention, reduced anxiety, accurate expectations.
I hope practices above helps you as well. Do you have any other ideas how to make onboarding more efficient? Let me know in the comments below!
This article is originally posted on my blog.
Say hi to me on Twitter!