Starting a job is a lot like moving to a new city.
When I first started at Stack Exchange as a developer, I’d already been living in New York for six years. I knew my way around: what train to take to get to which stop in Manhattan, why you don’t actually eat hot dogs from a cart, when the best time to take a cab is, and so on. These are bits of knowledge locals learn through experience, and if you don’t learn them as a newcomer, the city can quickly become the mean, hard-knock concrete jungle you should have known better about. The best way to navigate your new territory is having the guidance of a local friend: The city doesn’t seem like a labyrinth you want to escape from and instead turns into the energetic place that you’ll grow to love.
The experience of starting at a new company can similarly elicit anxiety along with excitement. There’s just as much local knowledge in a company’s ecosystem as in a big city, so having an onboarding process can make a world of difference. As a developer, I’ve found that effective onboarding is particularly useful for us for two main reasons:
I’ve found that developers are the kind of people who will wander around instead of asking for directions. We like to think that when we run into a problem, we can fix it on our own. If we’re in a bind, we only turn to others as a last resort. This is something many of us have been conditioned to do. When joining a company, we’re willing to tackle problems without getting to know anyone else on our team. And if we ever did want a little assistance, we won’t know who to turn to for help.
Developers come from a diverse range of backgrounds.
Some developers are completely self-taught (like myself), others might have formal training, and all of them have been involved in the industry for a different amount of time. Just as someone from the rural Midwest might discover different areas of New York City than someone from Los Angeles, you can’t expect all new developers to seamlessly pick up your current team’s practices. Since developers come from different backgrounds, your onboarding strategy needs to include more than just throwing them into the fray.
If you’re bringing in technical hires, think of yourself as that local friend. You already know the ropes, which means that you and your peers should be the ones to show them around town. So, what’s the best way to onboard developers? Treat it as you would introduce a friend new to your city: Introduce them to locals, give them some resources so they can navigate on their own, and help them form a plan their first few weeks. Here’s a few things that we do at Stack Exchange that have worked well for us:
Pick someone who knows their way around the codebase, the team, and the overall development goals who can guide the new developer for their first few weeks. At Stack Exchange, we try to choose a more senior developer who has a good perspective on the history of the projects and general practices of the team. Think of this mentor as the go-to person for any new hire. They should answer technical questions, introduce the team, and even walk them through some code or pair programming.
Though having in-person resources is critical, it’s inefficient to always need to go to other people for help. At Stack Exchange, we use Google Drive for most of our internal documentation. Having a chance to not only read through onboarding docs built over the years, but to also contribute to them can be extremely helpful. We include items like workplace setup, fixing common bugs, benefits, perks, and other elements that just need step-by-step instructions. Developers are generally used to going through in-depth documentation, given the sheer number of technologies used, so developers will typically be comfortable reading through documentation about your technical workflow as well.
At Stack Exchange, we’ve started building a clear plan that each new developer goes through in their first several weeks. Everything from getting equipment, meeting the team, working on bugs, and even doing a sample project is included in the curriculum. This is to ensure that everyone is on the same page and gets the critical information they need without exception. It also saves a lot of time and anxiety just knowing that a schedule exists--both for the new hire and for the existing team who assists with the onboarding process.
These are just some of the things that we do at Stack Exchange when bringing on new developers, but depending on your team’s needs, you may use a very different process. Whatever you decide to implement, a strong onboarding experience should let developers forge a connection with the other team members, offer them critical knowledge about developing at your company and using your products, and most importantly, let them feel welcome in a new environment instead of regretting the decision to join. When done correctly, it can mean the difference between being lost in an unfriendly environment and loving their new home.