Creating an effective remote onboarding process is essential for tech companies working with a distributed model.
Yet very few companies get it right.
You can’t build your remote onboarding process the same way you build an in-person onboarding process. Sitting at home and being on a video call is very different from getting together and meeting face to face.
Shopify has taken a proactive approach to maximizing the effectiveness of their remote onboarding program for software engineers. Jerie Shaw, as senior technical program manager at Shopify, led the shift to remote onboarding, and she shared everything she’s learned so far. Interview by Karolina Toth on episode 36 of the Level-up Engineering podcast.
Jerie Shaw has been working at Shopify for five years, and she’s currently the senior technical program manager leading the technical onboarding process. She has always been fascinated by education, and she fell in love with the challenge presented by building a remote onboarding process for software engineers.
Technical onboarding at Shopify is the collective onboarding program for everybody in a technical role. Beyond software engineers, it includes employees in product, data, and UX. We have a holistic onboarding program that starts with getting your laptop set up on day one, which also includes in-depth technical bootcamps and workshops, for example, React Native.
As we keep using and refining our remote onboarding process, I’m starting to think we’ve built a superior method to onboard employees.
Shopify has become a remote company, and we plan to stay that way.
Some employees will still work from offices, but the majority will continue to work from home after the pandemic ends. We plan to keep hub offices to use for occasions like celebrations at the end of onboarding cycles, but not as primary workspaces. This allows us to leverage the benefits of remote education, while also using office spaces for meeting in-person.
When the global pandemic broke out and companies switched to remote work, everyone expected to be able to use the same methods on Zoom that they had used in person. It didn’t work well for anyone.
The remote environment forces educators to be deliberate and intentional about every detail. You can't rely on people being excited to be in a room together away from their desks, which was a key element for people participating in training.
We started from scratch, and asked managers what it looks like in everyday work for software engineers to have a significant impact. That’s a clear sign of being successfully onboarded. Our goal was to figure out the actions they needed to get comfortable with.
For software engineers, this meant shipping pull requests, doing code reviews, pair programming regularly, and taking on-call shifts.
We started with this, and built activities, workshops, and bootcamps around these specifically. This allowed us to build an action-oriented remote onboarding program with clear goals. The engineering managers know what the most important challenges are for their specific team, and they select the related activities for their new hire.
This guided us while building an active remote onboarding program for developers.
We’ve built remote onboarding activities around keeping engagement and energy high.
In-person onboarding was smoother, because our team members became good at managing the energy in the room, as people fed off each other and get engaged. When it comes to onboarding remotely, you can’t simply read the room. You have to be intentional about structuring activities to make sure you keep up energy and engagement.
Solving problems together energizes people. On the other hand, spending an entire day on a video call drains their energy. Knowing this, we redesigned the onboarding experience to be active, synchronous, and hybrid.
We give a group of new employees a real challenge, like ship a dashboard or build a data pipeline. They work on it together at the same time. We provide them with support structures like a virtual pod for better collaboration, and experts on the topic to answer their questions via Slack.
This gives them a sense of being with a group and working on an interesting problem without being trapped in a video call for eight hours straight.
The biggest challenge when onboarding software engineers remotely is isolation and loneliness. We're trying to make the social aspect work remotely. Finding ways to have people together but not exhaust them is an interesting challenge.
We're still grappling with this challenge.
We’re doubling down on synchronous learning experiences, so we onboard newly hired software engineers in groups. This encourages collaborating with a wider group or pairing up to solve problems. We offer drop-in social opportunities, like playing Drawful together online a couple of times a week.
We're involving the managers and onboarding buddies in the process. We used to do the onboarding separately and then hand over the new hires to their respective managers. Now we aim to turn this into a partnership.
We give new joiners something to build in the first week; they love that. While working on this, they will deliver something to their lead or their onboarding buddy, which they're going to review and celebrate with the new hire. This is another opportunity for new hires to connect with their manager in a meaningful way. This helps to alleviate the isolation.
I’ll give you an example from data onboarding. In week three, new hires spend the entire week shipping a data pipeline. They design a data model, implement a pipeline, and build a dashboard based on it.
At the beginning of the day, we have a 30-minute call with a group of new hires to explain the challenge for the day, for example, design a data model. They get their structured activity that leads them to their goal, and we let them go and work on it.
After that, they all stay online in a Slack channel and in a virtual pod. A virtual pod is a Google Hangouts meeting that stays open on the second monitor. Turning off the microphone or the video is okay, but they have the option to unmute as if they’d turn to a neighbor at the office, and ask for help, “Hey, I'm stuck on step five. How do we create this aspect of the data model?”
They provide support for each other, and it’s a great opportunity for them to connect. More experienced employees drop in at certain points during the day, when the new hires are working on things we expect to be challenging and they may have questions.
At the end of the day, we make a group call to debrief and discuss what has happened. We also send their deliverables to their managers for feedback.
This is what a typical day looks like. This approach only requires new joiners to be in a video call for about one hour each day, but they get the experience of working with a group. This design had a big impact, and we’re excited to watch the results.
The hiring manager is the most crucial person in the process. They develop part of the onboarding plan, give feedback on deliverables, and select the onboarding buddy.
The onboarding buddy role is more informal but just as important. They’re usually part of the team the new hire will join, and they help a lot in the social aspect. They help them find fun Slack channels to hang out in, or show them how to access the support they need.
The whole technical training team takes part in onboarding new software engineers. My team manages the technical onboarding processes for people; we work directly with every single new hire.
We’ve built a modular, customizable onboarding program for all new hires.
The first week is mostly spent learning about the history and company culture of Shopify and setting up your laptop. Near the end of the first week, new hires get to ship code for the first time. We’re very proud of this.
In week two, new hires embed on the support team for a week. This helps them to build an in-depth understanding of the product. They build their own test store, configure shipping settings, and dig into the code.
Beyond this, they answer some of the questions of real customers dealing with challenges in their online store.
In week three and four, new hires transition into work through a custom onboarding plan that their manager and the onboarding team have built for them. The manager selects from a list of optional learning experiences offered by my team, including bootcamps, workshops, and self-directed activities. We’re continuously working to add more modules to the list.
The first two weeks are similar for every new hire, but weeks three and four are different based on the team they’re going to join.
Onboarding processes tend to differ significantly from being on the job. Our goal was to make the transition seamless by building a holistic program.
The first three days of introduction are run by our team called Startup; the next step is the technical onboarding with my team, and then new hires start to build the context. At this stage, they have one-on-one meetings to get to know their colleagues; they’re introduced to the project they’ll be working on and to the team's processes.
The first part is highly structured. After that, it moves towards problem-based, team-based and project-based learning. We don't consider employees to be fully onboarded after one month, but this is the period where we provide extra support.
We’ve also built in a transition period, while we're actively supporting a sense of community among new hires as they transition to their teams. It’s important because remote work can get lonely, and by then, they’ve built connections they should cultivate.
These steps help them get comfortable in the company.
We meet incredible people, and we often invite them back to our social company events. We have a great, vibrant community.
We also follow their progress to evaluate the success of our program. We haven’t found the perfect formula for measuring the success of onboarding, so we’re always exploring new ways.
We’re examining many short-term metrics as guidance.
A useful metric to evaluate our program is how much time it takes for newly hired software engineers to get to their 10th pull request. The most important feedback for us is how long it takes for newly hired software engineers to get comfortable with shipping code. It’s great for Shopify, but it’s also the reason developers join. Our mission is to provide the knowledge and the confidence to contribute, so contribution is our key metric.
Another method is asking people after every learning module if it offered good value for their time. This provides us with some feedback.
It’s essential for us to make sure that developers joining Shopify have the opportunity to fully understand what we offer. We’ve explored different options for doing this. We realized that we have a group of people at customer support who are experts concerning our product and our customers.
We worked with the support team to design this program. A small group of new employees pair up with a couple of support advisors familiar in education, and take new hires through a guided program.
New joiners first learn about a specific part of our product, like shipping, then use it on a test store, and finally support customers struggling with that specific part of their store. All the while, they’re supported by facilitators who are experts in the platform and in customer support. We often draft and review emails multiple times before they’re approved to be sent to a customer.
It’s a rewarding aspect of the onboarding process. It feels great to get a message back from a customer saying thanks and explaining how much you helped. The reactions of the engineers are amazing, and they get to experience this in week two.
We heavily underestimated the impact of social isolation on new hires working remotely. We used to work in an office, but we’ve turned into a distributed company, and most people will work from home from now on. As people who are used to being in an office, it’s hard to put yourself in the shoes of remote hires.
We’ve been experimenting with different ways to get people to start forming social relationships. It’s not only important in remote onboarding, but also for people already working at the company.
It’s part of the engineering culture at Shopify to turn the video and audio on at virtual meetings. Seeing people smile, nod or simply sit and pay attention is important to human connections.
We don't require people to turn their camera on. There may be reasons for not using it at any particular time. Most people show up to online meetings with the camera on anyway, and it improves the experience.
The focus on what daily work looks like for software engineers when they have a big impact gave us the right direction. It helped us build an active learning process focused on problem solving. This is a great first step.
We launched the new remote onboarding program on May 11th only for developers. We built a modular program, and this design gave us the option to launch with 15 optional activities, and add more as we go. The managers choose the useful activities for new hires, and if none of them is useful, they can simply jump into their role.
We’ve launched new activities with each group of new hires ever since. For example, we have a three-day Rails bootcamp.
Breaking up the remote onboarding process into modules frees you up to work iteratively, start small and experiment. You can build one module at a time, and replicate what works in other modules. Keep this up, and before long, you’ll have a great remote onboarding experience.
This approach also helps because you get to learn a lot as you go and to apply it when designing the next module. Most of the onboarding methods we used to use in-person won’t work remotely.
People didn’t care if a workshop wasn’t highly relevant or the lectures were boring, because they got to be together away from their desks. You lose this in a remote environment. It’s not a good experience to sit at home alone and to listen to a boring lecture.
Flexibility is essential when onboarding remotely.
We have a global team, so we work with multiple time zones. Almost every part of our program has a fully self-directed option and a facilitated option as well, which helps manage the multiple time zones. Facilitated activities are tied to time, which can get uncomfortable for people living in different parts of the world, but the self-directed option is always available.
This also supports different types of learners. There are people out there who prefer the self-directed options to working directly with an educator and a group.
🚀 Need developers for your team or project? Hire our experienced Angular or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.