Three-Phase Approach to Onboarding Engineers in a Distributed Services Environment

Problem

At ThousandEyes (part of Cisco), we operate in a distributed services environment, which has a plethora of benefits when it comes to development velocity and operational efficiency. However, as a new engineer joining the organization, it could be a pretty overwhelming task to wrap your head around all the microservices, how they interact with each other, and understand the development, deployment, and observability practices for each microservice. Having to onboard remotely doesn’t make it any easier. Mandating a comprehensive suite of documentation is not good either, as they can easily get outdated in a dynamic environment unless the team is really particular about keeping them up to date.

Actions taken

To simplify the onboarding journey, I defined a three-phase onboarding process.

Phase 1: Product

This is the phase where we want the new hires to become familiar with our product at the level of a superuser. We believe that this will help our new hires make sense of any new service by connecting it to the big picture, and have the background context that will get them off to a good start.

We tend to keep the hires undistracted in this phase and help them develop a clear understanding of how the product is used by our end-users to achieve their end goal. To achieve this, we provide our new hires with a licensed version of the product and walk them through a series of functional demos where they get to learn the product through hands-on instructor-led training. At the end of the session, they are given the assignment to evaluate their understanding of the product. To wrap this phase, we have a session with the analytics team who walk our new hires through the product usage statistics, so they get a sense of all the usage patterns of the product.

Phase 2: Process

This is the phase where we expect new hires to become familiar with our GitOps practices, coding conventions, code review guidelines, observability practices, on-call procedures, release management and workflow management processes. To assist with this phase, each new hire is assigned an onboarding buddy who has time dedicated in the sprint to unblock new hires from any hurdles they come across.

The following are the success criteria of this phase:

• Set up a local development environment to be able to build all the required microservices, and execute the associated tests. We don’t ever expect (in fact prohibit) developers to set up the full platform on their local machines.
• Pick a simple one-liner ticket, and follow through with the team’s development and deployment process to see the ticket flow all the way through to production.
• Pro tip: We reserve a few one-line tickets in a special bucket just for the new hires.
  

By the end of this phase, the new hire is cleared of all the development processes and is ready to jump into the fire.

Phase 3: Priorities

This is the phase where new hires are introduced to the projects that their team has worked on in the most recent past, technical documentation, and the project retrospectives. Once they have an opportunity to digest that info, they are introduced to the ongoing projects through the respective project leads and given an overview of the progress made so far, and the road ahead. This is also an opportunity for the new hires to find a project that they would be associated with for their first assignment on the role. We encourage new hires to pick projects that have a good mix of skills they already know and the skills they are interested in developing. This will ensure that they are challenged, yet landing comfortable during their early tenure.

In addition to the primary project, the new hires are scheduled for a series of conversations with the technical lead on the team to get clarity on the scope of work we could be doing to achieve the next level of operational excellence. This would enable them to establish a second workstream that may not directly contribute to any specific project, but contribute towards the team’s operational health.

Summary

The goal of this phased approach is to treat new hire onboarding similar to a product launch, by having a well-defined scope and success criteria to exit each phase rather than shooting straight for the end goal. New hires typically deal with a ton of other nonproject related tasks that aren’t even mentioned in this doc (payroll, health insurance, benefits, etc.). A phased approach helps them stay focused on a particular theme of tasks at any given time, and lower the overhead of context switching. This approach also helps lower the burden on the team to support new hires from getting onboarded. In this journey, the product manager only gets involved in phase I, the onboarding buddy only gets involved in phase II, and the project leads only get involved in phase III. Lastly, it is important to set timeline expectations to exit each phase, and it is important to keep track of these timelines across your new hires. This informs you if there are any external factors or issues specific to the particular new hire that is causing a delay.

Lessons learned

• All of the phase I and a large part of phase II can be common across your department. It saves a lot of time and energy to team up a bunch of new hires to go through this common phase, and have them mutually resolve any concerns. It is also a great opportunity for new hires to meet other new hires and form early connections.
• It is best to let new hires figure out things they can (through a Google search or any other means), even if a seasoned team member can teach them about it in a few minutes. The exploration process would teach the new hire a bunch of things that wouldn’t be covered in a quick walk-through.
• On that note, onboarding buddies should time box the time they could potentially spend with the new hire, and factor that into the sprint planning. The time could vary a lot based on the new hire’s background. It is best to have a conversation with the new hire before coming up with this estimate. This relieves them from any pressure of delivering in the sprint and is able to provide a pleasant experience to the new hires.