Remote Onboarding: Setting New Hires Up for Success

Problem

In December 2019, my company started to consider remote work for the first time. However, as often is the case, we did nothing until we had to. When the pandemic hit a few months later, we quickly transitioned to remote, which was easy to do because the decision was already made. A few months into the pandemic, I started to hire again into my team. While many things worked exceptionally well in a remote environment, I was a bit concerned about onboarding.

Actions taken

For starters, we created the welcoming package that detailed all upcoming steps and would be sent out to personal emails of new hires. A few days before the starting day, our virtual office manager and IT department would deliver all the necessary equipment, whether a computer or mobile device. We kept our pre-pandemic practice that every new hire would start their onboarding on Tuesday. So, their first onboarding session would be held on the same day, and the office manager would introduce them to the main tools used across the company. After completing the first part, they will be ready for team onboarding, which was too a standard pre-pandemic procedure.

We would always try to hire in bulk as much as possible. I would make sure to be informed of the other engineering team’s hiring cadence so that we can group together all new hires and have them start their onboarding on the same day. All new hires would undergo a two weeks-long training program that would include 10 to 15 hours of targeted training. Managers and senior engineers across the company would be invited to deliver training presentations on various topics. The training itself is custom per person -- mobile and back-end engineers have obviously different needs in terms of topics and tools, but nevertheless, the structure would remain the same. I would open the training with a brief welcoming speech and introduce new hires to mentors assigned to them.

My key welcoming message is: start building your environment. That, of course, can mean different things depending on the type of development, but that is a point: everyone should build their own environment. The ‘real’ training would start the next day when the new hires would be tasked to fix some bugs and become more familiar with the codebase as well as our development processes. A week later -- depending on seniority and prior experience -- they would start working on tech debt. The great thing about tech debt is that it is engineering-driven and without pressing deadlines and urgency around it. Tech debt is also often isolated from other parts of the code and requires minimal understanding of context. By completing their work on tech debt, they would complete their two weeks long training, which would qualify them to start working on regular features.

Every new hire would be assigned a mentor. While interns would have mentors throughout their internship, full-time engineers would go with a month or two of mentoring support. The mentoring would include daily check-in meetings; initially, they would last half an hour but would be gradually reduced to 15 and then 10 minutes. Regardless of their length, those meetings would serve as an opportunity for people to get support and get answers to all of their questions.

Lessons learned

• Transition to a remote environment was supported by a number of communication tools that, in some respects, made communication between people more seamless. However, when people were in the office, the sheer physical proximity made the whole process more natural and spontaneous. But when people communicate through a screen, there is a barrier that needs extra effort to overcome. So, we had to come up with a structure that would compensate for that lack of spontaneity in communication. Whether those are weekly Zoom calls or daily check-ins, you need to create a structure that will enforce communication. Once people get together on their in-advance booked Zoom calls, they will find something to talk about.
• Before we started to onboard new hires remotely, I felt there were too many unknowns. But once we started doing it, we realized that the difference was not as significant as we had imagined it. When we broke the process down into smaller parts, the same way we do in engineering, adjusting the existing processes to a remote environment was quite easy.