Successfully On-boarding Software Engineers
This article was first published on Doximity's Engineering Blog on December 2015. Although it describes how we do things at Doximity, I believe it is relevant to the engineering community at large.
We’ve added about one engineer per month to our team in 2015, and hiring is likely to speed up a bit in 2016. Having a smooth on-boarding process has been, and will continue to be, key to our success.
We want to set people up for success. If you’re lost on day-one, confused by a convoluted setup, chances are you’ll struggle to keep up. Having been here for five years and having grown the engineering team to over 30 people, we’ve learned what’s worked and what hasn’t. Here are our best practices for setting up your engineers for success.
Once an engineer signs the offer letter, the on-boarding process kicks off. We generate a new company email account, and invite the new teammate to all the services they’ll need access to. Pivotal, Trello, Github, are a few. At this time we also add the email account to appropriate mailing lists. The employee doesn’t get access to this new account until 8 a.m. on their first day. [Boomerang](http://www.boomeranggmail.com/) (for GMail) is a useful tool capable of scheduling the delivery of the corporate email account’s credentials.
During this stage we assign an engineer on the team to help the new employee during the on-boarding process which leads me to…
This person is responsible for welcoming the new hire into the team on day-one. He hands over their laptop and shows them to their desk. We do hire quite a few remote engineers; I can’t emphasize how important it is fly them in during the first week. Another important task is to introduce the new team member to the rest of the crew. Once intros are done, the on-boarding documentation guides the rest of the day.
We keep a Google Docs master document that we duplicate and adjust for every hire. It outlines basic details and expectations for “Day One,” “Week 1,” “Week 2,” and so forth until “Week 6.” This document is no doubt the MVP of the on-boarding process. By giving ourselves simple items to follow, we greatly reduce stress while making sure things happen when we need them to. Here are some example tasks contained in the document:
* Ship code by EOD, add your photo to the team page
* Schedule discussion with the PM of the project you’ll be working on
* Spend two consecutive days working on your assigned stories, expect about 50% of the time pairing with your mentor
* Familiarize yourself with our wiki — particularly the “New Employee Guide”
We believe there’s lots to be gained from setting things up by hand rather than trying to automate and package our applications into an image. Having said that, we’ve automated and polished the README enough; getting it done is a fairly smooth deal. With the help from the “on-boarder”, a new engineer can get a couple of our main applications set up in their local machine in a few hours. The on-boarder gives guidance and context and answers any questions while things build. The remainder of our applications and services can be set up fairly easily later.
First Few Weeks
I touched briefly on our motto of setting people up for success. Doximity runs a goals driven environment (our engineering teams work towards quarterly goals). Throwing a brand new person onto a team mid-quarter would be risky and unfair, so new engineers don’t join a product team right away. Instead, they’re assigned more general stories. These stories will help them gain an understanding of various systems within our ecosystem without having the weight of the deadlines on their shoulders, which could force them to take shortcuts.
Oftentimes, the “on-boarder” will also be the mentor. The mentor’s role is to be the go-to person for any questions the newcomer may have. Having an assigned mentor relieves the possible stress or guilt of interrupting others while they work. The mentor also checks in a couple of times a week to answer any questions and remove blockers. Mentorship programs usually runs 1–3 months. They’re also great learning experiences for the mentors themselves.
Every pull-request intended to be merged into master requires at least one code-review and sign-off from a colleague. During the mentorship period, the pull-requests submitted by the new engineer will also be reviewed by a couple team leads. Not only do code reviews improve code quality, they also ensure work is going in the right direction.
Over the years we’ve created and maintained a large collection of articles broken up by sections and guides. The “New Employee Guide” answers a lot of the basic questions someone would have on their first week. At close to 200 pages and growing, it’s substantial, and we certainly don’t expect someone to be able read the whole thing. The “Guides” point out the most important pages. I’ll be writing more about our Wiki in the near future.
Another important aspect of this process is to collect feedback from new employees and use the feedback to fine-tune the process. There’s always room for improvement, but I can say the process has drastically improved from what it was five years ago.