Designing Engineer Onboarding at Affinity
This summer, our team added four new engineers, growing our existing engineering team by 33% to a total of 16! As their start dates approached this summer, we knew we needed to clarify our onboarding process to ensure each engineer had an effective start to their career at Affinity.
There are a million blog posts on the internet describing how to onboard engineers effectively (and now with this blog post, a million and one). After reading through a few, we realized that different companies took quite different approaches to onboarding (some companies had a 6-week bootcamp, some had very little onboarding structure), especially startups at different stages of growth. We needed to clarify our own priorities and approach, especially given our size and stage. We started out by defining our goals: to ensure (1) that new hires immediately feel like members of our team and (2) that they learn our codebase and become effective engineers at Affinity as quickly as possible.
Our revamped onboarding process consists of three key components: a venue for any and all questions, a welcoming existing team, and a quick productivity ramp as soon as new engineers join — below, I’ll expand on each of these components. If you’re looking to design a similar onboarding program at your startup, we hope this is helpful in conceptualizing and operationalizing the first weeks of a new engineer’s experience.
The Buddy System
Two years ago, Affinity’s onboarding had only one formal component: upon joining, another engineer would be assigned as the official “buddy”. It was the buddy’s job to onboard the new engineer, help set up their dev environment, and answer questions as they came up. With fewer than ten engineers at the time, we couldn’t devote too many resources towards standardizing the buddy’s responsibilities. This iteration was fairly unstructured as a result: each buddy developed their own approach towards how to onboard someone effectively. However, we still enforced one key condition: each buddy had the responsibility of being available to answer questions.
Since then, feedback from new engineers consistently emphasized that the most valuable part of this informal onboarding process was the freedom to ask questions to an experienced engineer. As a result, our formalized buddy system now requires being available to answer questions — no matter how busy you are, how frequent the asks, or how simple the question — as an explicit core responsibility.
New hires should expect that any time they have a question, there will be someone available to answer them (if the buddy is OOO, it’s their job to find a substitute). Even though the buddy now has a checklist of additional buddy responsibilities (choosing onboarding tasks, conducting initial 1:1s, help set up dev environment, etc), being available for questions still remains their top priority. This demonstrates that we’re invested in the new hire’s success, minimizes time wasted on understanding complex abstractions, and accelerates the onboarding process.
A Welcoming Team
We believe that the most effective engineering teams work as a cohesive unit, not as individuals. As such, we continually aim to reinforce collaboration and communication across our team. Just as important as having a buddy who will guide them through onboarding is having a welcoming integration with the rest of the team.
The buddy is responsible for scheduling lunches throughout the first few weeks between the new hire and other engineers, designers, product managers, etc: not only to get to know their domains of expertise, but also to get to know them as people. Different engineers have different areas of responsibility, and onboarding tasks are chosen by the buddy to expose the new hire to as many parts of the codebase as possible. This implicitly encourages collaboration across the team and promotes interactions with as many engineers as possible.
Even though a buddy is officially assigned as the main go-to for questions, all other engineers are expected to play a similar role! Unblocking others, being helpful, and explaining concepts are core expectations of an Affinity engineer — even when doing so might interrupt their own work. There should be no need to feel bad asking any other engineer a question, as we’re all invested in the new hire’s success, regardless of who the official buddy is.
Effective on Day One
Many other onboarding frameworks (for example, Facebook’s Bootcamp) spend the first few days or weeks introducing the new hire to the codebase, describing core abstractions, and teaching classes on engineering concepts to help the new hire get up to speed. Feedback from engineers who’ve joined in recent months, however, taught us that having a fixed onboarding was actually unhelpful, as introducing concepts without product-facing tasks to reinforce them didn’t lead to much retention of new concepts.
As a result, our onboarding is designed to introduce the new hire to our codebase as fast as possible. On day one, they’re assigned a set of tasks with immediate product impact, with the goal of completing a few of them within the first week. They’ll learn how to write Ruby and TypeScript, modify API endpoints, and update React components by completing actual tasks, rather than sitting through a tutorial. Onboarding meetings are evenly spread out over the first few weeks instead of the first few days, giving new engineers more time to absorb our culture and spend more of their first week jumping into real code. Of course, the buddy will also be available to pair program, help explore the codebase, and give tips if they get stuck.
That doesn’t mean that all of our technical onboarding is dependent on jumping into code and asking questions. For certain more complex abstractions, having documentation to follow is of course helpful. We took inspiration from Quora, and wrote our own set of Codelabs (for example, on git)! The goal, as always, is to help new hires become effective engineers at Affinity as quickly as possible, and all of our onboarding strategies and tools are in service of that goal.
To operationalize and formalize these three key components of our onboarding program, we’ve created two Asana templates: one for the new hire and one for the buddy (screenshotted above). We’ve noticed that new hires tend to speed through checklists to complete every single task as soon as they can, so we’ve also sectioned the checklists into explicit “Day One”, “Week One”, and “Week Two and Beyond” sections. These two templates help us ensure that all onboarding steps are addressed and given proper consideration.
Since joining, all four of our new hires from this summer have since graduated from our onboarding program and are now full members of our engineering team! One of them even mentioned that Affinity had “the best engineering onboarding experience I’ve ever been through.” That’s great to hear, but we know that our onboarding, like anything else, will require continual improvement to become even better and and keep pace with our team’s growth. We’ve already taken our new summer hires’ feedback and re-incorporated it into our onboarding process for the next new hire.
Whether you’re an engineering candidate interviewing with us, someone designing the onboarding process at your own startup, or just a curious reader, we hope this post has been useful!
Hit us up at eng@affinity.co with any questions, comments, or suggestions on how to improve the onboarding process. And if you’re looking for new opportunities, we’re hiring!
