How We Onboard New Engineers

Article Header

Over the past few years, we’ve written about how we hire a distributed team and how important it is to us that everyone feels happy within their team and can do their best work while working independently as part of a remote team. But there is one small step missing between joining us and being a fully productive member of our team, and we know it can’t be taken within the first day.

Our onboarding process is something we’ve been continually improving upon. For us, it’s important that expectations are clear to our new colleagues and that we do whatever we can to help because we want them to be successful. So when they join, they receive a list of expectations for the first six months. During the initial few weeks, the tasks are more straightforward, and they become more high level toward the end. Finally, at the end of the six months, they should be prepared to take over all the necessary responsibilities.

The First Week

Every new hire gets assigned someone as their go-to person for the onboarding process, but it’s usually the team lead who takes this over, although everyone else is happy to jump in and help as well.

Day 1

The first day is all about getting everything set up and explaining how we work. We begin by detailing how we plan our product roadmap, e.g. what the place of a product is within our ecosystem and what we have planned for the future. We also schedule regular one-on-ones with the new hire and the team lead throughout the week, along with weekly talks with the manager of the team. We explain that no one should be afraid of the one-on-ones, because they exist for the purpose of having face-to-face time, and they allow the new hire to get to know who they’ll be working with better.

The new hire also takes part in our Monday Hangout, where they can introduce themselves to the whole team and talk about what they will be working on and what they enjoy doing outside of work. They also spend time reading through our Playbook, which not only covers most of the company information, but also details our workflows and our support guidelines.

Day 2

The second day is actually incredibly valuable, not only to the new employee, but also to us. Since PSPDFKit is an SDK other developers are using, we have the chance to get feedback on our API documentation, guides, and the product itself from someone with fresh eyes who is also willing to share all the findings. Additionally, this is an opportunity to improve our internal documentation, because if something is not self-explanatory, it needs to be improved. Beyond this, the second day is all about setting up the work environment, getting to know the product, and submitting the first PRs to improve documentation.

Days 3 – 5

From now until the end of the week, the new employee’s goal is to fix one or two bugs. During this process, we sometimes pair and explain our architecture and how we’d tackle the bug. Fixing bugs is one of the best ways to be introduced to and become familiar with a codebase. This is because, when searching for the cause of a bug, we will likely stumble upon a few components and need to understand how they interact together. Also, it feels nice to accomplish something that will be part of our next release!

The Next Weeks: Building a Feature

For the next step, the new employee is supposed to build a significant feature of our upcoming release! The timeframe for this is about six to eight weeks. We’ll sit together and let them decide what feature of the roadmap suits them best. Then we’ll write a list of expectations for the feature together, and they can start doing research, writing a proposal, implementing, testing, and writing the documentation on their own. But of course, there is always someone they can reach out to for help, and we check in with them regularly.

What we expect here is for the person to think through the feature and write a reasonable proposal. We know that writing something detailed takes time, but we’d rather rewrite the proposal a few times and discuss it in detail than throw away code. We also want to see them thinking through the user interaction with our designer, or if it’s not a user-facing feature, showing a preview of how the public API will look. In the end, they can proudly demo the new feature at our weekly company hangout.

After Three Months

By the time the first three months are over, it’s likely the employee has already fixed some bugs, built some features, written a blog post, taken over support tickets, and become familiar with our tech stack. If they accomplished all of this earlier, that’s fine as well, but three months is the timeline we have in mind. However, we now assume they will be more independent, which falls in line with our outlined expectations.

After Six Months

After the six months of onboarding are complete, we want the employee to write issues for features or improvements, present them to the team, and take over their responsibility. We trust them to care about the product and everything they build to be tested and written in the interest of being maintainable. They should also take care of things like support tickets or bugs and take ownership without being asked, all while keeping everyone in the loop. It’s also important to be proactively looking for ways to improve the product, fix bugs, build features, and better the codebase. Speaking up when things are unclear and communicating early and often is also desirable (and this is especially important with a remote team).

Final Thoughts

I joined PSPDFKit before we introduced this clear onboarding process. When we came up with it, I initially thought it involved a bit too much planning (or even micromanaging), but the feedback we have received from everyone onboarded in this way has proved me wrong. They were all happy to not get lost and grateful that someone was always there to help and explain everything. They also appreciated that all expectations were clear so that they weren’t faced with a scenario where they were held to a standard they didn’t know about.

I know all this could be a bit frightening for someone because we seem to expect a lot, but we’re doing everything to prepare new hires for their roles and really want them to be successful. We believe in having coworkers you can trust who take over ownership.

As a final note, I should clarify that this process applies to most of our teams at PSPDFKit. However, since I am part of the Web team, I realize some parts of onboarding might be handled differently on other teams.