How We Onboard New Engineers at Zapier

It's your first day at a new company. You walk up to the doors of the office building, anxious about what today is going to be like. You’ve only been here once before, when you interviewed, and you’d rather forget the sweaty nervous mess of a person you were that time. Hopefully none of your now co-workers remember that day either. Entering the building, you find it mostly empty, probably because it’s 8:15 am. Nobody told you when the day really starts, though, so you played it safe. Now you get to twiddle your thumbs for awhile because you don’t know what you’re supposed to be doing.

Onboarding is a critical time for both new staff members and the company hiring them—an important process to get right. It’s an employee’s first impression of your company and it will dictate the mindset your new hire has about their job. You want to make sure a new employee feels welcome, valued, and starts learning the company culture and the expectations you have for them.

At Zapier, we’ve put in a lot of effort to make onboarding our teammates a smooth process. We want to share our process for the engineering department—what we’ve learned so far and the spots we are still working on. It may look a little different with our distributed team, but many of the principles should apply to a co-located office too.

Day 0

Onboarding starts before the new hire’s first day. By prepping ahead of time, you make the employee feel valued because you’ve already invested time in them before they officially started. You also avoid wasting people’s time by having a game plan for what the first few weeks look like.

At Zapier, we do a lot of the typical HR things upfront, like provision accounts to our tools, order gear so it arrives by the start date, and ask the new person to read our company playbook. A quick note on the playbook: your employee handbook doesn’t have to be a horrid looking PDF or printed binder that nobody wants to read. Make it useful and approachable.

Another thing we do ahead of time is write and share a personalized onboarding doc for the new hire. We follow a template that lays out in detail what the first week will be like—topics to cover and tasks to complete, and then a less detailed game plan for the following couple weeks. We also schedule calls with various team members that take place over the first couple weeks. Some of these calls are in-depth code dives with teammates. Others are quick 15-30 minute meetings with people from other departments so that the new person gets to hear a bit about what it’s like to work on non-engineering teams.

With all that prep in place, we are ready to welcome the new member to the team!

Day 1

The day has come! Your new teammate arrives and is ready to start working. So what do you do?

A typical first day at Zapier is centered on these goals:

• Make the new hire feel welcome
• Introduce them to Zapier, to the team, and to the role
• Set the precedent for how Zapier operates
• Give them time to read and handle their HR tasks

There is nothing revolutionary here in terms of what we cover. Where it gets interesting is how we tackle these as a distributed team. For one, meeting the team is not as simple as taking a tour of the office. We don’t do daily stand-ups. There is no group lunch to foster casual chats. Instead, an engineer’s first day is a lot of face-time with their manager, covering company basics and meeting the team on paper. Over the course of the week, those pre-arranged calls mentioned earlier, as well as regularly scheduled meetings, provide the opportunities for the new person to meet folks in real-time.

Communication is another part of Zapier culture we emphasize early on. It’s essential to ingrain how we collaborate, as many folks are new to working remotely. We make sure the new person understands which communication tools to use for which purpose. We explain our company value of defaulting to transparency, which feel unnatural and noisy at first. A new person needs confidence to ask a question in a 70-person Slack channel. They also need to know how to filter down all the available communication channels to the ones most relevant for their job.

In contrast with those challenges, the remote culture shines during onboarding when it comes to documentation. As part of our async work culture, we document everything! If a new hire wants to know how to spin up the dev environment, deploy to production, or perform a code review, we’ve got an internal knowledge base in Quip with articles on each topic. We record all lightning talks, so there are videos that give overviews of the architecture of the system. We are also very intentional about capturing conversations about code in GitHub commit messages and PRs, so a new person has a wealth of history to draw from as they learn our system.

All of the reading and chatting make for a bit of a mind-numbing first day. We don’t promise the information firehouse stops after the first day, but one thing engineers get to look forward to is that we shift gears for the rest of onboarding and get to hacking.

Days 2-5

After getting better acquainted with the company and the role on Day One, the rest of the week for a new engineer is focused on engineering-specific goals:

• Equip them with the knowledge and tools they need to do the job
• Teach them different areas of the system
• Give them success early
• Take them through the complete dev process
• Set expectations

The best way we’ve found to accomplish all of these goals is to get the person up and running. We prioritize setting up the dev environment on Days Two and Three. Once that is ready to go, we assign a small task for the new person to tackle. This could be a well-scoped GitHub issue or a tiny feature—anything that a fresh set of eyes can pick up without needing tons of Zapier-specific context. For example, a new member on the Platform team updated our Google Sheets integration with an “Add Column” action. It was a great first project because there was existing code to borrow from and the feature was an independent addition that didn’t spider out into the rest of the system.

In shipping something small, a new engineer experiences our typical git workflow, the code review process, and a production deploy. That early win builds confidence and momentum. It also sets the precedent for the expectation we have of shipping things. We don’t go at break-neck pace, but we do emphasize driving a PR to completion. There is no better way to get that mentality than by doing it from the start.

Along with solo dives into the code, a new hire learns through the pre-arranged calls with teammates. We have team members teach something in their area of expertise. Paired with more time to read and watch videos, a new person absorbs a lot of context in these few days. One teammate, for example, shared how our core task runner works with a new engineer onboarding. Or we have an hour long video that covers the structure of our Django app and gives an overview of our infrastructure setup in AWS.

Week 2

At this point, a new engineer is ready to go. They have a dev environment. They’ve been through the process. It’s time to learn by doing. We don’t expect them to know everything. In fact, we encourage lots questions early on as opportunities to show them how to answer their own questions. The goal now is to increase the complexity of the tasks they are working on. To that end, we queue up more interesting GitHub issues or a small project. Often these tasks focus on something the engineering team wants to knock out, such as prep work to support GraphQL server-side or upgrading a minor version of Django, but it can be a product-related change too, like improving the Partner API that can be used to list Zap Templates. Either way, the new engineer gets space to dedicate the majority of their time to the task.

Week 3

After two weeks, a new engineer settles into a routine. Once they complete that first project, they may get another small project. If a cross-functional team is ready to bring them on to work on product features, they’ll join forces with a Product Manager and get cranking on bigger initiatives. This might also be when they get into their workflow groove, too. They find their best hours to work (especially as a remote worker), set up their automation systems and workflows, and learn how the company and their immediate team communicate best.

Something else that kicks off during Week 3 (if not sooner) is “Support School.” Everyone at Zapier does support. For engineers, this entails a week-long rotation where an engineer either answers technical questions for customers or squashes issues in Github. To do either of those rotations, an engineer has to know how to use all the debugging tools available. For example, we use Graylog extensively, piping in http requests as well as events and debug messages from the system as Zaps run. To sift through the millions of messages, an engineer has to know the Graylog query syntax, the structure we provide messages (i.e. facility:httplog for all inbound http requests), and what messages to expect when a Zap runs. To learn that, and the other tools we have, we setup a new hire with a Trello board that walks them through docs, videos, and pairing sessions with a support teammate.

Week 4 and Beyond

The capstone of onboarding is a trip to meet some of the team in person. Within two months of joining, Zapier flies new employees from all departments to California for a week (or, in some cases, depending on the individuals' situations, we might continue virtual onboarding or do in-person onboarding at a different location).

New folks join their managers and the founders to work side-by-side for a week. We book some Airbnbs and spend the week hacking on projects during the day, then eating yummy food and hanging out in the evenings. It’s a great way to show new people the Zapier culture in action. It strengthens the relationship between the manager and the new teammate. It also let’s new folks meet our CEO, CTO, and CPO, re-enforcing the open and inviting atmosphere we pride ourselves on.

Once folks are back home, the onboarding process is officially complete!

Next Level Improvements

While our current onboarding works well, there are always things to improve in the process. One is the personalized doc. At the moment, each engineering team has its own template. Where we would like to get to is a tiered template, where everybody in the company can re-use the section on culture and communication, an engineering-wide section for all engineers, and then sections for the specific teams and roles. To make this work, we need people to own each template and keep it up-to-date. To that end, our people ops team hired someone to be dedicated to onboarding and training.

Another thing we are working on is our dev environment setup. Docker has gotten us far by providing consistent container setup. However, there is still setting up vpn access, nvm with brew, downloading fixture data, and a few other steps. Our ideal is a single script that you run and it does all the work.

Lastly is automating more of the training. For example, our support team is doing something really cool with the support school. The current system with the Trello board works, but it’s static. Our support team is building a Slackbot that you can interact with, telling it you are ready for the next lesson, then working through the lesson with the bot instead of just reading and checking off lists.

---

Those are just a few examples of how we’re always trying to improve an onboarding process that has worked well so far. If you’d like to experience the onboarding process yourself, the first step is to see our open positions.