New-hire Onboarding is an Investment

Written by Scott Stebleton, Senior Engineering Manager

Photo by David Marcu on Unsplash

You never get a second chance to make a first impression. First impressions last in just about every human interaction, from friendships to dating to schools and politics. It’s equally true when bringing a newly-hired employee onto a team: a department’s onboarding process shapes a person’s trajectory in the organization, from how quickly they ramp up to how engaged they feel, and everything in between.

At Omada Health, one of our company’s guiding values is Grow Together. For a new hire, that growth requires initiative and guidance from their leadership team. For a manager, onboarding is the best opportunity to set expectations about a new hire’s level, their role, and the rules that apply to everyone in the department.

More broadly, hiring someone is an investment. Obviously, there’s the financial investment, expressed through salary and benefits. Then there’s the time and effort (and possibly money) spent in the hiring process. But it’s important to consider what comes after: it’s essential that every new employee learns our norms and practices, and gains knowledge of our systems and the tools we use — all in service of being a productive, and integrated, member of our team. Doing this requires the investment of building an effective onboarding process.

At Omada, new-hire onboarding includes steps that everyone goes through, regardless of their department, as well as department-specific steps. Our People & Culture team has gotten company-wide onboarding down to an art, including thorough introductions to the company, HR and benefits, and IT and Security procedures.

In this post, I describe the steps we took in developing a new onboarding process for the Engineering department, why we had to do so, what the new system looks like, and how it’s worked out for us so far, including with employees who joined us under shelter-in-place restrictions.

How Engineering onboarding was falling short

Prior to our most recent adjustments, Engineering onboarding consisted of a couple presentations and a patchwork of trainings and resources specific to each team. This led to inconsistent expectations of new hires across teams: standards were often confined to the team scope, with department-wide expectations left to osmosis and exposure over time.

One consequence of this variability was a lack of standards for performing 90-day new-hire evaluations. Among other problems, inconsistencies like this can open the door to bias in those evaluations, and they can make it difficult to know if an engineer was hired at the correct level.

We found inconsistent awareness of our ecosystem among our engineers. There was a lack of knowledge about the systems we have and what they do, including how those systems support the business and the broader company strategy. People reported not knowing much about other teams in the department and what they do, nor about who to ask when domains or projects overlapped.

A survey of both team members and existing documentation found our reference materials to be lacking. We have a wiki, but a common problem with wikis is entropy; they atrophy without investment. Ultimately, we found ourselves relying on organic, person-to-person teaching in order to socialize knowledge. Legacy teams can get away with this kind of thing, but what happens when a team is composed largely of recent hires? Where does institutional knowledge come from then?

Finally, it bears mentioning that the shortcomings of our old system would have been even more stark once we went fully distributed in response to Covid-19. Relying on person-to-person teaching cannot work when person-to-person contact is impossible.

Coming up with a new system

As with any systemic issue, the first step of fixing it is acknowledging the problem. Our leadership team recognized the issue, and in response formed a working group of interested engineering leaders to tackle it. This group would wind up meeting once every two weeks for five months, brainstorming problem areas and possible solutions.

During our meetings, this working group probed a number of topics, most notably including:

  • Expectations by level: what do we expect from junior engineers vs. senior engineers?
  • Department-wide expectations: what do we want people to know when they hit the 90-day mark, regardless of their level and team?
  • What are we doing now that’s not working well?
  • What actions are we already taking to improve the onboarding process?

Through these discussions, we developed a tiered, clear set of expectations, which of course went through several iterations. We ultimately concluded that a successful onboarding meant that expectations needed to be paired with documentation, resources, and formal training. This meant eliminating the reliance on osmosis and informal learning, and spurred the creation of a lot of documentation, as well as identifying areas that require formal training sessions, and recruiting team and technical leaders from our ranks to produce and lead those sessions.

What the new system looks like

From a high level, our new onboarding plan is a somewhat long list of topics, ranked by priority. These topics can be lumped into broad categories:

  • Elements of how we work: security and compliance; our systems, environments, and data models; our departmental values; and operating standards like pair programming and test-driven development (TDD).
  • Logistics: how our continuous integration and continuous delivery (CI/CD) system works, our software development lifecycle (ticket systems, the Agile methodologies we use, feature leading), and incident management.
  • Technologies we use: containerization (Docker, Nomad), metrics gathering and monitoring, and various tools (New Relic, SumoLogic, Bugsnag)

Within each topic, we have identified a concrete set of expectations for new hires to meet at the 90-day mark. Each topic has links to documentation and resources, most of which are internal, but some of which are external, such as guides to using tools like Pivotal Tracker.

For some of the more involved topics, such as Docker, we’ve created trainings and hands-on guided learning sessions, and the onboarding plan includes checkboxes indicating whether a new hire has completed them.

The plan also includes prompts for the new hire and their manager to check in at the 30-day and 60-day points, during which they’ll look for areas where knowledge is deficient and identify areas to focus on.

Our experience using the new system

Since completing the new onboarding plan, we have hired several people into the Engineering department across multiple teams. The new hires have been encouraged to work through the plan frequently, in small bites. (The list of topics is quite long, and can be intimidating to open up.)

The plan has received universally positive feedback for its organization and availability. Its presentation as a checklist makes it easy to navigate, plan tasks, and track progress. Expectations are clearly laid out, along with how to get the knowledge to meet them. It provides a broad understanding of our various applications and how to use them. One new hire had this to say: “It’s a great feeling to see Omada Engineering invest in a variety of trainings as part of the onboarding process.”

The plan helped each new hire and their team plan their immersion and ramp-up. This meant that the new hires were ready to join their teams’ firefighter rotations after about a month — way faster than our experience with previous onboardings. Plus, each of our teams saw a nice downstream effect: they were motivated to level-up their wiki pages and other documentation.

Perhaps most importantly, the new process made it relatively easy to onboard new hires while everyone was sheltering in place. (As of this writing, we still are, with no end in sight.) With everyone working from home, the old habits of osmosis and organic knowledge transfer would not have worked. The plan makes each expectation and its supporting resources and documentation easily discoverable, so the timing of its completion worked out very nicely for us.

What’s next

For the engineers we’ve hired since putting this process together, the next step is using the new 90-day plans in their new-hire evaluations. Beyond that, we plan to make the new resources and training sessions available to all engineers, so they can refresh their knowledge or close any gaps they may have.

Moving forward, we have distributed the responsibility for periodically refreshing all the documentation and resources, so that they are always current. We will also periodically revise the expectations laid out in the 90-day plan, so that they are also always current.

And now that we have leveled up our onboarding process, the next big thing to do is hire more people, of course. That will help us continue to see returns on this investment!