How to quickly (and successfully) onboard engineers

Jul 21, 2022 ยท 12 min read ยท Leave a comment
David O'Regan GitLab profile

No one ever said hiring was easy. As a matter of fact, talent hiring and retention are some of the hardest aspects to get right for any software company.

According to a recent article at Developer Pitstop the average engineer will only stay at a job for an average of two years before moving on, and this tenure is shrinking as time goes on.

When we look at the average timeline for engineers in a new role we usually see something like:

  • Learning and adaptation (3 / 6 months): Coming to grips with the new company, team, and their processes.

  • Creating value for the organization (6 / 12 months): Adding value to the business by becoming a functioning member of the team.

  • Becoming a role expert (6 / 18 months): Owning the role completely and helping to shape the direction of the team.

At GitLab we pride ourselves on an outstanding onboarding process to reduce the amount of time an engineer will spend in the learning and adaptation bracket and accelerate their evolution into the creating value for the organization bracket. We do this for two main reasons:

The bottom line is that with these benefits, investing in an amazing onboarding process gives you the highest ROI on your hiring initiatives.

So, now that we know why we need to ensure we onboard quickly and correctly, let's talk about how we do it at GitLab.

Overview

onboarding

๐Ÿ’ฏ Before day one

The best onboarding processes start as soon as the candidate has officially accepted the offer. This is done in a few ways:

For us, the most important aspect is communication with the engineer to ensure they are set up for success. We provide them with access to their onboarding issue, helpful video guides for getting started, and a primer on how to navigate our handbook like a pro. The reason this is so important is that we know if we stop communicating with the engineer after signing, we are at risk of creating uncertainty, introducing inefficiency, or even losing them to another offer during that time.

๐Ÿ’ฅ It's all about the onboarding issue

At GitLab, our onboarding issue is the most effective tool we have for successfully onboarding a new engineer quickly. Hiring managers use this issue almost exclusively, both for building momentum and for following our value of transparency. We use this issue, instead of Slack or email, to create a single source of truth for everyone during the process and to prevent fragmented communication. For anyone new at GitLab, the first few weeks can seem like a lot to get on top of, so the hiring manger wants to be mindful of opportunities to consolidate communication and reduce context switching.

Our onboarding issues are confidential because they contain sensitive account information, but the templates of the issue are public and they look something like this:

- Accounts and access
- Day 1: Getting started: Accounts and paperwork
- Day 2: Remote working and our values
- Day 3: Security & compliance
- Day 4: Social & benefits
- Day 5: Git & push some code
- Weeks 2 - 4: Explore
- Job-specific tasks

As a hiring manager, you want to ensure that you have fleshed out the job specific tasks ahead of time with things that are important for the specific role the engineer will be working in. This will generally include things like ensuring they have database access, pointing them to the working groups that will support their work, and letting them know the right Slack channels to support their development.

๐Ÿฅ‚ Pick the right onboarding buddy

The advantages of the buddy system have been well documented for years. At GitLab we lean heavily on the onboarding buddy model and rather than having multiple people support the new engineer, it will generally be the hiring manager and a single buddy.

The advantages of an onboarding buddy at GitLab are several:

As a rule of thumb, the onboarding buddy should ideally be someone from the engineer's new team who is working in the same domain, i.e. a senior frontend engineer mentors a new intermediate frontend engineer, both of which are from the same team. While this rule is not set in stone, it is often less effective to have an onboarding buddy be cross-team due to a lack of domain expertise.

๐Ÿ‘Œ Pair, pair, and more pairing

Pairing when programming and when working on tasks is a very effective way to help new engineers build up their knowledge without needing to pour through documentation.

In general, we would recommend that the engineer pair with their onboarding buddy on their first few merge requests to get used to the workflow and pitfalls of working with the GitLab Development Kit. But this is not where it should stop. We encourage pairing across the board at GitLab either via open pairing sessions such as our Frontend Pairing office hours, having a manager pair with an engineer, or pairing with a stable counterpart such as your team's UX designer.

When it comes to onboarding, pairing is helpful. We do this because we want to:

๐Ÿ– All the coffee chats

Being distributed means we do communication differently at GitLab. One key to successfully onboarding a new engineer is to get them comfortable with our communication style.

To do this, we encourage regular coffee chats and a culture of zero shame about it.

Encourage your new hire to set up regular coffee chats with people across the company to help build rapport and become comfortable with GitLab as a whole.

To help empower new hires, have them ask the following question in their initial 10 - 15 chats:

What is the one thing I can do to be successful at GitLab?

๐Ÿค˜ Tailor the experience to the role

As a hiring manger, you need to understand that people learn and grow in different ways. No single method will work for everyone and it is your job to ensure your new hire feels supported in how they want to learn.

During the onboarding, observe your new hire and touch base with them in your weekly 1:1 for what they are and are not enjoying about the experience so far. Once you have this information, iterate on it and tailor their onboarding to include more of what they prefer.

Ask constructive questions that can have actionable tasks each week to ensure a better process for them:

Do you want to pair more? Do you want more alone time? Are there particular areas you need more guidance in? Are there things I can do to better support you?

You should aim to strike a balance during their onboarding for a mixture of practical work and time dedicated to studying. Work with the direct report to establish the best balance for them as an individual.

๐Ÿšข Ship some code in a week or less

This is arguably the most important aspect of successfully onboarding an engineer and setting them up for success. The sooner they can push code to production, the sooner they can begin to refine their skills and work effectively with the team.

The best software companies in the world set a timeline of shipping code in a week. At GitLab, this is not a hard-and-fast rule, but in the Create stage is what we strive for.

To ensure an engineer can ship code within a week, we need to ensure they are supported in a few ways:

๐Ÿ’ฌ Let's get some feedback

As a hiring manager, you want to ensure you build a stable feedback loop into your processes and this includes onboarding. During your 1:1s you should include a weekly feedback cycle for both you and your direct report.

These feedback cycles should take the form of:

These weekly feedback loops allow the engineer to highlight things that could be done better in both the context of the onboarding and their day-to-day experience.

Lastly, it is optional but encouraged to hold an onboarding retrospective when the initial onboarding issue is closed with the following points to talk through:

๐Ÿ’พ TL;DR

The most successful software companies have a solidified onboarding process and continue to expand on it, setting up both the company and engineers for long-term success. The above methods are how we do it at GitLab.

๐Ÿ’ป Remote development and the developer experience

At GitLab we have recently been hiring for our Remote Development effort and many of these items are in play with the engineers we are bringing into the company. We want to improve these processes to make onboarding even easier, mitigating the need for even setting up a specific local development toolchain to be able to ship production code.

If you think you might be interested in a role at GitLab working on Remote Development, check out our open listings here.

Read more about leading endingeering teams.

โ€œHere's how @gitlab quickly onboards engineers successfullyโ€ โ€“ David O'Regan

Click to tweet

Open in Web IDE View source