Back to resources

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

Onboarding
Hiring

6 October, 2021

Sai Dhalli
Sai Dhalli

Sr Software Engineering Manager at ThousandEyes

Sai Dhalli, Sr. Software Engineering Manager at ThousandEyes, shares how he followed a three-phase approach to make the onboarding of new hires flawless while working in a distributed services environment from a remote work 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

The Importance of Culture and Values When Building Teams

26 May

Elwin Lau, Director of Software at Jana, advocates the importance of maintaining culture within a company when scaling teams.

Mission / Vision / Charter
Scaling Team
Building A Team
Company Culture
Collaboration
Onboarding
Sharing The Vision
Elwin Lau

Elwin Lau

Director of Software at JANA Corporation

10x engineer or 10x impact?

26 May

Hiring 10x engineers is hard for most companies. It’s a tough battle out there for talent. So how should most companies approach building their team?

Building A Team
Leadership
Hiring
Coaching / Training / Mentorship
Vaidik Kapoor

Vaidik Kapoor

VP Engineering - DevOps & Security at Grofers

How to Streamline Your Recruitment Process for Quick and Effective Hiring

26 May

Philip Gollucci, Director of Cloud Engineering at CareRev, describes a new method for hiring in a market climate that favors candidates instead of recruiters.

Scaling Team
Building A Team
Hiring
Philip Gollucci

Philip Gollucci

CEO/Founder at P6M7G8 Inc.

How to Maximize Employee Retention in Engineering Teams

25 May

Vimal Patel, Founder and CTO at iMORPHr, shares how he retained all of his employees since beginning his software development company in 2019.

Building A Team
Company Culture
Hiring
Retention
Psychological Safety
Vimal Patel

Vimal Patel

Director of Engineering at iMORPHr

Hiring a Data Team With a Stubborn Manager

24 May

Liz Henderson, an Executive consultant at Capgemini, shares her experience hiring a data team with a manager who was difficult to work with.

Managing Up
Building A Team
Conflict Solving
Hiring
Data Team
Liz Henderson

Liz Henderson

Executive consultant at Capgemini

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.