In the past four months I've hired about five software engineers (including interns). So I've been thinking about how we onboard new engineers to the team. This has been especially important because over half the engineers have never had an engineering job before, or even a job as a university graduate.
This means that onboarding isn't just about introducing someone to the company or the engineering team, it's about bringing people into both their first "proper" job.
It feels awesome that I can make someone's first experience as a software engineer so good. Or at least have the potential to do so.
Tell you what doesn't feel super: the onboarding process. It takes a lot to introduce anyone to the way that professional software engineers plan, do, and think about work. It means that my time is spent teaching, not doing. And while teaching is doing, I definitely notice a loss of momentum and bandwidth in the (already quite small) team.
A new engineer will land in your team anywhere between 0-90% ready to start contributing code to production. The goal of an onboarding process is to get that slider to 100%.
I argue that slider is tending towards 0% unless you're effectively onboarding them. That is, if you bring someone onboard and then make cursory efforts to keep them get them up to speed, they'll slowly grind down to 25-50%.
I also suspect it gets harder to move this slides close to 100% over time. Onboarding is like a high interest debt: if you're going to pay it, you'll pay less if you pay it quicker.
In thinking about onboarding in our team, and in our company, there are a handful of insights that I think are worth sharing explicitly.
Cook from chilled not frozen: If someone comes into a new job knowing the bare bones of the job (anything that's in their contract, who their manager is, and where they'll be working) ten they're coming in frozen. There's been no progression between the end of the interview process, and the start of the working process. I (very purposefully) run a pretty high-touch interview process, and by the time a candidate receives an offer, there's been some good rapport built between us and them. Making sure that the candidate knows exactly when and where they're expected in on their first day is table-stakes. Defrost it even further by setting clearer expectations and timeframes. Bonus points if you can CC their colleagues into these emails.
Do it in person: we're a remote-by-default hybrid engineering team. Honestly I think that works great for us[^That's not to say it's easy. Remove work comes with its own challenges which are real and can slowly strangle a company or team] but onboarding should be done in-person, or as close to synchronously as possible. There are just so many little things, like using new Browser, using Slack not Teams, MacOS not Windows, that can make "simple" things deceptively hard. If you're doing something in person, or synchronously, you can put a real early stop to some rabbit-hole chasing. You also get the best feedback possible for improving your onboarding process.
Read from a script: Despite doing it in person, have a really clear (ideally ordered) checklist of things that need to be done on the very first day of onboarding (accounts to create, software to download). New starters should have access to the checklist, but the checklist is not the interface. You, a human being, are the interface. Allow someone to synchronously ask questions, send emails and messages on the new starter's behalf.
Have many checklists: I've written three lists for onboarding new engineers: accounts and software, a list of people they need to arrange meetings with, and the code deployment pipeline. Each of these have different time frames and purposes. Break things up, instead of having one big old long list.
Complete the checklist ASAP: Focus should be on getting a new starter to the end of all the lists ASAP. Accounts and software should be as as close to complete by the end of the first day. We aim to have an engineer go through the deployment of a bugfix/quickfix ticket in the first two days (sometimes three days), and by the end of their first week I want them to have events in their calendar to meet everyone they need to.
Force one-ones with the entire business: We're an engineering team in a highly ops-focused startup, and we're hybrid remote as a team, but distributed across three cities as a company. This means that the chance of water cooler chat is pretty low. I think there's incredible value in having engineers meet as many members of the team as possible, across as many functions as possible. This is especially important where internal staff are also users of the software you're building.
See other articles