In 2015 we've added about one engineer per month to our team, 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.
On-boarding Kickoff
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 (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…
The "On-boarder"
This person is responsible for welcoming the new hire into the team on day one. They hand 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 to 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.
On-boarding Documentation
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"
Application Setup
We believe there are 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.
We have fun and introduce people to our culture right away.
The Mentorship
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 run 1-3 months. They're also great learning experiences for the mentors themselves.
Code Reviews
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 of team leads. Not only do code reviews improve code quality, but they also ensure work is going in the right direction.
Our Wiki
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 to 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.
Hope you've enjoyed a peek into how we onboard. I expect to write a few more articles about our engineering culture and processes in the near future. Follow us @dox_engineering if you'd like to be notified about updates to this blog.
Thanks to Jason Seifer, Jey Balachandran, and Natasha Singh for reading drafts of this.
