Smooth Engineer Onboarding for All

Problem

Often times, without a smooth onboarding process, there can be confusion from day one by such a convoluted setup. New on-boards are more likely to struggle in keeping up with the rest of the team.

Actions Taken

With time, I have learned what works, and in return, what does not. The following subsections are some of our best practices for fostering success in our engineers at Doximity. Onboarding Kickoff Once an official offer letter is signed, the process of onboarding gets underway. A new company email account is generated and added to the appropriate mailing lists. The new employee doesn't gain access to this new account until 8 a.m. on their first day. The new teammate is also invited to the various services they will need to access such as Pivotal, Trello, and Github to name a few. The "On-boarder" It is important to have a person responsible for making the new hire feel welcomed into the team on their first day. They generally undertake such tasks as handing over the new hires laptop, showing them to their desk, and making team introductions. A caveat to remember with remote engineer hires is the importance of flying them in during the first week. After introductions and basic office familiarizations have been provided, our onboarding documentation guides the remainder of the day.
Onboarding Documentation We use a Google Docs master document that can be adjusted to fit every new hire. The basic outline includes details and expectations for "Day One," "Week 1", "Week 2", and so forth until "Week 6". Some example tasks identified in the document are:

• Ship code by EOD and 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 and expect about 50% of the time pairing with your partner.
• Familiarize yourself with our wiki -- particularly the "New Employee Guide". Application Setup With the continued help of the "on-boarder", a new engineer can get a couple of our main applications set up in their local machine in just a few hours. The "on-boarder" guides and offers context, while answering any questions as things build. The remainder of our applications and services can be set up with ease at a later time. First Few Weeks We run a goal driven environment, with the engineering team working specifically towards quarterly goals. Subjecting a new team member to a mid-quarter entry onto a product team would be both risky and unfair. Instead, they are assigned to more general stories from the beginning which allow them to gain an understanding of various systems within our ecosystem. This eliminates the weight of heavy deadlines on their shoulders, which could force them to take unnecessary shortcuts. The Mentorship More times than not, the "on-boarder" will also take the form of the mentor. Their role is to be the go-to person for any questions the newcomer may have. Mentorship programs usually run for one to three months. During this period, the pull-requests submitted by the new engineer will be reviewed by several teams leads before being merged into a master. The requirements for this include at least one code-review and sign-off from a colleague. Our Wiki Throughout the years we have masterfully created and maintained a large collection of articles divided into sections and guides for new on-boards. The "New Employee Guide" answers many of the basic questions someone would inquire about during their first week. At near 200 pages and climbing, it's quite substantial, and we certainly don't expect someone to read the whole thing. There are "Guides" however, that point out the most important pages for quick and easy navigation.

Lessons learned

• By giving ourselves simple items to follow in the onboarding documentation, we greatly reduce stress while making sure things happen when we need them to.
• Having new team members start with general stories rather than entering into product teams right away allows for a smoother and more educational transition.
• Assigning a mentor relieves the possible stress or guilt of interrupting others while they work.
• Mentors and mentees alike, gain a great deal from the mentorship experience.
• Not only do code reviews improve code quality, but they also ensure work is moving forward in the right direction.
• Collecting feedback from new employees is important because there is always room for improvement. We leverage the feedback to improve the process.