Scaling Onboarding Iteratively

Problem

We were onboarding many engineers onto a small engineering team. Onboarding was time-consuming for some of our most experienced engineers since they were best able to answer questions and could lead the most training sessions. Additionally, sometimes one or two engineers would join off-cycle from others, and they might prefer to get to learn the content at their own pace and ask questions when convenient. There was also a lot of knowledge being shared one-on-one with buddies that could be scaled more effectively.

Actions taken

We leveraged the existing buddy system to assign buddies to new engineers. We made sure someone was available to help them one-on-one, and they could set up 15-minute check-ins almost every day for the first month. By selecting different buddies for all engineers and then have them work on the same projects, we distributed the work and helped the buddies learn to delegate.

We recorded all onboarding sessions and made the slides and resources available in a common place, linked to each engineer’s onboarding plan. We kept some live sessions while asking for others to be recorded.

We also experimented with sharing new content, introducing topics like automated testing, observability, or infrastructure steadily. We booked Q&A sessions with the experts for them to ask follow-up questions to any of the videos. One developer had the idea to host sessions to practice solving a problem using our open-source framework as a group, and the feedback was very positive.

We made a calendar with sessions public, so anyone in Engineering could opt into new sessions or rejoin a session they might benefit from watching again. That became increasingly popular after we introduced infrastructure and testing overviews, and we ended up helping more of our teams adopting similar practices.

We updated the templates we use to communicate expectations to new hires. When someone would start their job, we would create a unique copy for them with a unique setup they needed to be successful, including their first bugs and project. We updated these to add additional resources and links to the knowledge they should be familiar with: how we test, what tools we use, what are the code review expectations, etc.

We used a survey to collect onboarding feedback. We just used Google Forms, but at my current company, we now do this using CultureAmp.

Lessons learned

• Most people didn’t miss the live sessions, especially given the booked Q&A sessions that followed them. In fact, some people preferred them in order to be able to watch them at their own pace.
• What isn’t replaceable is mentorship and some kind of pair or group programming. Once we started hosting sessions where many people are in a room working on a similar or identical problem, people asked for more. They didn’t miss or need more learning sessions; they wanted more opportunities to practice and learn our systems with guidance.
• To iterate again, I think we’d consider trying to capture some of these as tutorials so that a mix of them could be done independently and with support.
• Onboarding can benefit existing engineers. When adding new types of content, consider inviting current engineers optionally if it's something they could benefit from revisiting.
• Doing things iteratively -- recording sessions, updating templates, and sending surveys -- was easy to do and led to people trying their own improvements.