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.
Software engineer onboarding
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:
- Quicker integration: We aim to have engineers ship production code in less than one week, and fully onboard them in less than three months.
- Reduce turnover: Engineers who have an awesome onboarding experience tend to stay with the same company longer.
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.
Software engineer onboarding process: An overview
- 💯 Before day one
- 💥 It's all about the onboarding issue
- 🥂 Pick the right onboarding buddy
- 👌 Pair, pair, and more pairing
- 🖐 All the coffee chats
- 🤘 Tailor the experience to the role
- 🚢 Ship some code in a week or less
- 💬 Let's get (and give) some feedback
💯 Before day one
The best processes for onboarding software engineers start as soon as the candidate has officially accepted the offer. This is done in a few ways:
- An onboarding issue is created with tasks for the hiring manager, their buddy, and People Experience (HR).
- The hiring manager selects the right onboarding buddy for the engineer and communicates expectations (more on this later).
- The engineer's accounts (Email, GitLab account, Okta, etc) are created and their hardware is shipped.
- GitLab reaches out via email to let the candidate know what the onboarding process looks like.
- The hiring manager reaches out to the engineer via email to set up a coffee chat on Day 1 as the initial process might seem overwhelming.
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:
- Domain expert: A onboarding buddy knows the domain the new engineer is going to be working in. They have already written, reviewed, and merged code into production in the same way we want the new engineer to. They know the process, pitfalls, and gotchas of the domain.
- Single context / Accountabilibuddy: A single onboarding buddy drastically reduces context switching and "paralysis by analysis." They know they always have someone to ask and this creates a psychologically safe space for them. GitLab can often be a scary environment to navigate when you are new due to impostor syndrome and we want to curb that.
- GitLabisms: At GitLab, we have code and then we have "GitLabisms." These are things that are specific to GitLab, be it workflows or custom tooling. These are often more complicated to become familiar with than the code itself. The onboarding buddy should have experience with these already and be able to point the engineer in the right direction when they are stuck.
- Mentor: Mentoring is one of the single best things an engineer can do to grow themselves and become more sure of their own skills. By being an onboarding buddy, they are given a growth opportunity to cover their own blindspots and upskill.
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:
- Create psychological safety: We all feel impostor syndrome. This is worse when you're new to a job and don't know the ecosystem yet. Regular pairing helps to undo that worry as you see people are just people and even staff/principal engineers forget the closing brace!
- Create relationships/network: In an all-remote company, it becomes important to know who to reach out to in moments of need. Regular pairing helps to foster these relationships and creates a safety net with your peers.
- Demonstrate our values: We believe in CREDIT at GitLab. Regular pairing supports all our core values and helps to encourage us to be mindful of them when working.
- Give and get real-time feedback: When pairing, we can get real-time feedback on our process and how we're approaching solutions. This is extremely important for new engineers who might not be familiar with core GitLab concepts such as iteration ("How can we break this down?").
🖐 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:
- Tooling: At GitLab we have a fantastic local development kit which sets up an engineer to begin delivering code. We support this kit heavily as a first-class citizen and are constantly refining the tooling and docs to ensure everyone can contribute. For a new hire, consider having their first pairing session to be setting up their GDK – this will get them one step closer to shipping quality code.
- Dev process: At GitLab, we always strike to break down work into its smallest deliverable that can be picked up by an engineer without deep contextual understanding. We do this to support the open source community as much as our own engineers.
💬 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:
- Appreciation (Collaboration / Results / Diversity / Iteration / Transparency): A moment of appreciation for something positive that is highlighted inline with our values.
- Coaching (Collaboration / Results / Diversity / Iteration / Transparency): A growth opportunity that is highlighted inline with our values.
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:
- What went well?
- What didn't go so well?
- What could be improved?
- Action items
💾 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.
