My worst onboarding experience was my first day at an upscale dog walking service in Boston. And yes, there is such a thing as an upscale dog walking service - imagine normal dog walkers but we had fancy shirts. I got to the boutique where the business was based, someone handed me a list of clients, and I was told to “get to it”. No instructions on which dogs required special handling, no introduction to other team members, not even a map or directions to the locations of the pooches. Needless to say, I didn’t last very long at that job and the business itself is no longer around.

I’ve been thinking about that experience because the onboarding process has been on my mind for the last few months as an engineering manager. We’ve onboarded five people onto our team in the last six months, which has doubled the size of our team. And starting tomorrow, we’ll be onboarding two more engineers onto the team - one who has many years of experience, and one who is fresh out of undergrad.

Onboarding is exhausting to me. I love doing it, I get an immense amount of satisfaction and pride at seeing new engineers succeed and grow and find contentment on the team, but it’s *exhausting. As an introverted and somewhat shy person, this is especially true. I find that engineering management as a discipline requires expending effort and energy into various external sources. Consensus building around a new initiative, mediating disputes between direct reports, organizing professional development opportunities: these tasks require sociability and assertiveness. To put it simply, as an introvert, these things spend energy rather than provide energy. When you factor in an onboarding period, which can require a great deal of regularly scheduled interpersonal interaction and activities, it can be daunting to remain present and energized for your new team members.

Given this, how do we avoid the situation I was in as a dog walker, where new engineers are left to sink or swim because no one has the bandwidth to properly set them up for success? Obviously, there’s a spectrum between “No help given” and “Let me sit on your shoulder and spend every waking moment prepping you for success like a mommy bird.” Finding that balance is especially important now, where myself and many of my colleagues are doing the entirety of our onboarding process in a remote setting.

The first thing that’s helped over the last few months of onboarding is proper planning and expectations. I started off with a weekly set of goals for new engineers, but quickly realized it was too restrictive. Instead, I started to think of them as chapters in a book, with new hires needing to progress through a chapter in order to proceed to the next. If that took a week, great! If it took a few extra weeks, then that would be okay too. The important part was being deliberate in establishing a cadence and sequence, so that we could build context and skill sets over time in a gradually unfolding fashion.

Another important learning point was to find the balance between too many touch points with new engineers, and too few. When I say “touch points”, I mean any setting where the onboarding engineer has a meeting with other members of the team (including myself). It can be very tempting to schedule ALL OF THE THINGS, and overload a new hires schedule with a tide of seminars and workshops and pair programming exercises and… you get the point. We got great feedback from our first cohort of onboarders this year that they just had too many context building meetings and too little time to sit with new information. So we pivoted, cancelled a bunch of stuff, and deliberately made space for a chance to integrate new learning. I found the sweet spot for recurring checkins with new engineers to be one morning (say, 10:15 - 10:45am) and one afternoon (say, 4:30 - 5:00 pm) session per day. The morning touch point would be a chance to set expectations for the day, and the afternoon would be a chance to answer any pressing questions, review core concepts, and just chat. And the “just chatting” portion was especially important. Remotely onboarded engineers don’t have the benefit of all the interstitial social time that comes with being in an office. Our onboarders craved opportunities to get to know their fellow engineers, and so my big takeaway was: “However many social events you have planned, do at least two more than that.”

Finally, I found it incredibly important to invest our new engineers with the ability to take ownership of the onboarding process. Even though we had a solid plan for each onboarding period, I wanted to make it clear that the process itself was a dialogue with our new team members. If certain aspects didn’t work, we’d take them out. If new engineers needed more hands-on exercises, we’d make them up, often together – and then add them to our onboarding documentation. I feel that this process of negotiation empowers engineers to be responsible for their own progress, and also holds me accountable to their individuality as team members.

As a manager, the vital task of onboarding your new teammates can be big and daunting and rewarding and affirming, all rolled into one. Hopefully, for our two new team members starting tomorrow, it will be a chance to feel welcomed and empowered, and set them up for many years of success. And hey, at the very least, it can’t be worse than fancy dog walking.