How to Onboard Your Own Engineering Teammates
Hurray! That engineer that you interviewed a few weeks ago just signed and your manager asked you to help onboard them. You’re not the new hire’s manager, but you do know what it’s like to be an IC (individual contributor) on the team, and your day-to-day work will be greatly impacted by how quickly your new teammate gets up-to-speed. Let’s make it happen!
What is an onboarding buddy?
At Gusto, we choose a peer to help the new engineer learn more about the team, codebase, and culture. It’s beneficial to have an onboarding buddy who isn’t their manager because as a peer you can feel more accessible. You’ll also be able to keep the manager accountable by knowing what your new buddy needs day-to-day and prompting their manager to do anything they may have forgotten.. Most importantly, you’ll help make the implicit explicit by answering questions and sharing information about how things work that isn’t currently documented. Bonus points if the onboarding process helps produce more documentation!
Before they join
Onboarding Document
Work with the manager to make an onboarding document specific to them. Company-wide templates can be a great starting point, but they may present a lot of high-level information that can be overwhelming initially. Consider starting the document with the most critical day-to-day information that’s specific to the team or product area, then include some of the company-wide information.
For example, at Gusto some team-specific documents that we include are:
- An org chart that shows all the teammates and the structure of the team
- Team project planning documents
- Quarterly OKRs
- The product roadmap
- A working agreement that defines norms for how the team works together
Starter Tasks
Identify small tasks to help the new engineer dip their toes in the code. Even if the task itself is fairly simple, the entire process of making a code change, going through code review, merging it, and deploying the change differs between companies and it’s valuable for the new engineer to learn the overall process around shipping code. Over time, these starter tasks should begin to become larger in scope.
When looking for starter tasks, great candidates are tasks that aren’t critically urgent to the product but important enough to provide real value. For example, you might ask them to make a UI change that’s bothered you but you’ve never gotten around to doing, or add a new column to a table with additional information that users have been asking for but that never quite got prioritized.
Once they’ve handled a few starter tasks, it’s time to ramp them up into a starter project. This project should probably take around one to two months, to ensure that it’s significant enough for the new hire to feel like they really have ownership and expertise around at least a part of the codebase. They shouldn’t work on it alone! Ideally, another experienced engineer will be pairing with them on the project and is equally responsible for getting the work done well. This ensures that the new hire always has a knowledgeable resource for their project, and they never feel like they need to “bother” someone because their teammate is working on the same thing they are.
The starter project might be something that their manager might choose for them, but bringing suggestions and considerations to the table will help make sure that the right project gets chosen.
Training
Depending on the new engineer’s experience level and background, it can be beneficial to provide additional resources to help them learn the stack and set them up for success. For example, at Gusto we have a bootcamp that university hires (interns and new grads) attend together when they first join where we teach them the basics of React and Ruby on Rails. We also have occasional sessions open to all new hires about security, infrastructure, and the architecture of some of our most critical codebases.
First week
Intros
They’re finally here! Learn what the company’s general onboarding schedule is like and set aside time to find them afterward to show them to their desk and introduce them to other folks on the team. Consider doing something more fun like a welcome lunch or a team event. Set up a one-on-one schedule so there’s a plan to check in on a regular basis. If they’re interested, also set up a regular pair programming session to help immerse them into the codebase. Depending on the new hire’s personality, it can also be helpful to facilitate intros, lunches, or coffee with other teammates, including cross-functional partners.
Set Clear Expectations
What is expected of them in the first week, month, year? How long does it typically take for engineers to be ramped up? What does it even mean to be “ramped up”? Their manager is in charge of most of this expectation setting. However, you can assist in helping reassure them that onboarding is indeed difficult but the fun learning opportunities lie more in the journey than the destination.
Expectations can also depend on their background and experience level. For example, new grads might be nervous about meeting expectations in their first full-time job, so communicate that they're expected to spend a sizable portion of their first few months ramping up and learning industry practices. Remote folks might be wary of over-communicating or bothering with Slack, so make sure they feel empowered to stay in communication with the team. Engineers with substantial industry experience may not be familiar with the business domain, so help them calibrate their expectations for their own ramp time. Other folks might have responsibilities outside of engineering, so work with their manager to identify those responsibilities and figure out what their modified engineering capacity might look like.
Dev environment
Work together to set up their development environment if one is not already provided. Companies typically have a setup document or script with steps to follow. It’s typically a living artifact, so encourage them to document anything that’s different or new to make it easier for the next new engineer.
First month
Starter Tasks
Continue helping them work on starter tasks or projects and answer any questions. If they are interested, pair regularly and encourage them to start driving the pairing sessions. Watching them try to navigate the product or codebase and seeing where they stumble is a great opportunity for you to learn the fuzzy areas that you’ve become accustomed to and figure out if there are ways to simplify.
Set up shadowing sessions
Depending on the company size, engineers can be a bit removed from the business or customer experience side. If possible, set up shadowing sessions with cross-functional partners to build empathy and learn more about the business.
Whiteboarding
As they become more immersed in the code, consider having them lead a whiteboarding session where they map out their understanding of a part of the domain and more tenured engineers can help fill in the gaps. This process can help them reflect and realize how much they’ve picked up in a few weeks! Another benefit is that it’ll produce documentation for others.
On-Call
If applicable, share more information about on-call processes and rotations, and pair together on solving issues. This is a great way to gain breadth and depth quickly because the issues are likely in a different product area than their main work. Additionally, this is a great way to build empathy for the users as well as the operations folks that are working with the users.
Always
Encourage questions
Every question is a learning opportunity. Remind them that there are no dumb questions and that asking a question will then in turn enable them to answer that question for someone else down the line. Questions can also help identify confusing parts of the code or gaps in processes and lead to efforts to tidy up or improve the processes.
Be Inclusive
Consider asking the new hire what name and pronouns they use, or suggest that they include that information in their Slack profile. If they are remote or come from an underrepresented group, be mindful of making them comfortable and heard in meetings, especially in larger meetings where there are unfamiliar folks. Share information about existing affinity or interest groups to encourage them to find a community!
Seek out feedback
New folks have a superpower. They can more easily spot broken things that more tenured folks have become used to. Maybe it’s an overly complex process, an oddly-behaving feature, or a confusing part of the codebase. Check in regularly and encourage them to share ideas for how to improve.
Celebrate their work!
Onboarding is difficult — there’s a lot of new processes, concepts, and faces to learn. Celebrate their accomplishments, no matter how big or small. For example, share when they’ve landed their first PR with the rest of your team! Keep notes on technical things they’ve done as well as non-technical impacts they’ve made, and share those regularly. New engineers can bring insight to a team that didn’t have it before, and it’s nice to be appreciated for this that come naturally while you’re still in the process of ramping up on the specific technical work.
That’s all!
Just kidding. A lot more goes into fully integrating a new person into a team! There’s tons to learn and, if things go well, the new person will also end up teaching you as much as you teach them. These are suggestions based on personal experience from helping to onboard many of our own teammates, but ultimately you are the buddy. Your job is to support the new hire and their manager in making sure that the new hire can contribute to your team in ways great and small as soon as possible, and that they feel empowered enough to keep doing that for years to come. Do that in whatever way feels most authentic to you.
Go forth and onboard #withGusto!
