Onboarding Remote New Hires
As hiring managers, we put a lot of effort into recruiting new people and encouraging quality work. One of the less enjoyable parts of the job is helping correct somebody struggling with performance. Unfortunately, this often happens after the cement starts to dry. This happens because we bring people on and, too often, leave them to their own devices without giving them the specific tools they need to succeed on our teams. You’ve hired them because they’re smart, have the experience, are capable and you need them.
But every team and organization is different and you have to help set up your new hire with tools they need to succeed. It’s like drafting a quarterback and throwing them out onto the field without spending the time going over the playbook. Yes, they did well on their college team, but how do they know how work with your current team’s system? When they face a defensive formation they don’t like, how do they know which audibles to call? Failure to prepare them is a failure to do the basic job of a coach. And that’s what we, as hiring managers need to avoid. Here are a few things I’ve found help the most in onboarding new hires.
Keep Them Warm
Getting a new offer is always exciting. Starting a new job is almost always exciting. And scary. The negotiation and interview process can even be stressful on them. So now that they’ve accepted an offer, let the fun begin. Show them you’re excited (you shouldn’t be hiring somebody unless you’re actually excited about them). Give them a call in the time between their negotiation and start date to see if there’s anything on their mind. Send a welcome box and invite them to lunch or a happy hour with the team while they’re waiting for their start date. The specific methods will differ based on your team culture and whether you’re all even working in the same city, but the spirit is the same.
We’re excited to have you and we want you to know we’re thinking about you while we wait for you. And by the way, we’re pretty fun to work with.
Give Them the Onboarding Schedule
We have a 90-day introductory period at ASH and new engineers on my team receive a 90-day schedule. It is broken up into two 4-week intervals that outlines what they’re expected to learn and work on in each interval. The schedule doesn’t have specific projects, but general guidance, such as “at this point you should be fully participating in scrum meetings and owning PBIs.” Or “at this point, you should have contributed to content or small property changes and understand the workflow and project structure.”
The goal of this is so that each new engineer knows exactly what’s expected of them on day 1. And they can spend their time focusing only on what is expected of them during week 1 only. The schedule is progressive and builds on itself. I meet with them at least weekly at the beginning and pair them with a mentor so they’re not left to learn completely on their own. Side note: they are expected to read documentation on their own and come to meetings prepared to discuss topics, which is where we can go over specifics at ASH and clear up any questions and confusion together. Many of the items that aren’t specific to ASH should already be familiar to them (e.g., JavaScript Promises). But listing those topics makes sure that every person on the team has the same foundation of knowledge when they start, regardless of their experience before ASH. This helps ensure that nobody is left feeling like they don’t know those basics during team discussions.
Channel Their Barbara Walters
During the first couple weeks, I want our new teammates to get to know the rest of the team. I’ll give them a list of questions to ask each member of our team that have nothing to do with work, such as “ask [name] which sport they used to play,” “what is [name]’s favorite place they’ve traveled to?” Every question is specific to each person, depending on their interests. Also, every team meeting starts with a warmup and, in each person’s first and last meetings, they get to go around and ask each person a question of their choosing, and each person asks them a question of their choosing as well.
The goal of these questions isn’t to fill them with random facts about where one of the best burgers are in town. It’s to allow the team to get to know each other as more than the person that comments on their pull requests and, more importantly, give a potentially shy new team member a reason to open the door of communication with somebody they just met. This is especially important now that the team is distributed throughout the country. So while they’re asking somebody what their favorite football team is, they can also ask them a question about a project they’re working at the time. Or they can just build those muscles to see how open and inviting the team is to answering questions and helping others.
Meetings…Lots of Meetings
No, not boring, mundane status meetings for projects your new hire might not be familiar with yet. Or training meetings (actually, we also have those for the first few days). I’m talking about meetings to get to know the rest of the team. Every new hire on my team has the following meetings:
- Meet with each member of the team to get to know them and what they work on. We have a team of distributed engineers who work in a microservice architecture on various scrum teams, so this helps them learn about all our products and how they come together.
- Meet with leaders from across our organization, all the way up to the CTO. These meetings usually brush over what their teams do, but are often general get-to-know-you meetings where the new hire gets to meet leaders outside of their scrum team. These meetings also reduce nervosity and the feeling of isolation; especially in a remote environment, they won’t have a chance to get to know a vice president by bumping into them on the office floor or in the kitchen.
- Meet with the PO and Scrum Master of their team. This happens in week 1 and sets expectations about the scrum process. It also gives them a chance to learn about all the services and products their scrum team owns.
Welcome Kit
Every new hire gets a custom-designed welcome kit from the team. The kit includes a card, shirt, water bottle, and other gifts to welcome them to the team before their first day. It’s a small gesture that creates a touchpoint between the team and new employee, and gets them even more excited to join a team that’s thinking about them.
Team FAQ
Each engineer is a part of their discipline (front end, UX, QA, DevOps etc.), but does most of their day-to-day work on different scrum teams. So, while we work in the same stack and components, a lot of our communication is with scrum teams or, due to the nature of Slack, in private channels. It’s also easy to take for granted knowledge that is in our heads, or not documented. Because of this, we spend a lot of time making sure we keep documentation in Wikis and keep it up-to-date. But, as a new hire, it can be daunting to know which article to go to when you run into something . Or in some cases, they might not even know to look at an article about team principles or communication expectations, because they might not know it exists.
We have an FAQ that’s contained on one page. It’s broken up into sections, such as “Getting Started,” “Communication,” “Gotchas and Common Errors,” etc. As a new hire, you can navigate to the page, do a “find in page” for your issue, and read a succinct answer there. A lot of answers have a link to the main documentation for that issue or tool so they can continue reading there. Having a central place to start was a major improvement to help new hires navigate their day without feeling like they need to Slack somebody for every small issue.
Technical Mentor
All new hires receive a technical mentor. It’s usually a senior, or at least somebody above their level in title to help guide them more closely than the rest of the team or their manager. This is usually most new hires’ favorite part of their onboarding. And it often carries over into a less time-consuming mentorship after their introduction period.
Technical mentors will check in every couple days and have an open door for the new hire to ask them questions at any time. Their job is not to simply provide answers, but show the new hire how to find solutions and answers. They should explain the why and not just the what in solutions, ask about their projects and see where they can offer guidance. They should also take part in design sessions, and pair with the new hire on a semi-regular basis.
Document It
As a manager, it’s not always easy to remember all the little steps it takes to onboard somebody. So, document the process so managers can refer to it throughout their onboarding process. You can even go further and make it interactive. Or share the process with new hires.
What About You?
There’s more to onboarding new members of our team than what is on this list. At ASH they range from very common to very specific. What about your teams? Is there anything you’ve found particularly helpful? Or as a new hire, is there anything you’re grateful for or wish you would have had? I’d love to hear; just drop a comment here.
