Effectively Onboarding New Engineers
Every software team has lots of ideas for what it could accomplish if only it had an extra headcount. However, teams don’t merely want just a new headcount; they want a full-fledged engineer who has necessary background knowledge and is able to work independently.
Much of the work of turning a new hire into a full team member falls to the new hire’s more senior peers. In many organizations, including my current team, we designate one person to be the new hire’s “mentor” or “onboarding buddy”. The role of the onboarding buddy is to get a new hire up to speed on the team’s technical and organizational knowledge, turning the new hire from a fresh face to a full contributor. I have had the chance to serve as a manager-designated “onboarding buddy” three times in my career so far. I’m with my sixth employer now, which means that I have myself been onboarded six times. Having experienced both sides of the relationship, here’s what I’ve learned about how to do it well.
Aim to project warmness, not just competence. When you first meet with your new hire, the first question on your new hire’s mind is whether you are a nice and trustworthy person. The new hire is not concerned about your level of technical knowledge, your job title, or the length of your tenure at the company. For the new hire, you are a lifeline and you are one of the primary representatives of the company. The new hire is starting out in a vulnerable and uncertain position; real or imagined emotional coldness from the onboarding buddy makes the experience much worse. As the onboarding buddy, you need to not only be a reliable source of answers, but also be warm enough that the new hire is comfortable asking dumb-sounding questions to you.
When in doubt, just talk. Are you the type of person who carefully watches your words to make sure you don’t accidentally blurt out something stupid? Are you the type of person who delays responding to inquiries until you have a complete and well-thought-out response? When onboarding a new hire, precautions like these are not necessary. For someone who is starting from scratch, virtually all information is helpful. Err on the side of response speed and information quantity rather than communication quality.
Start with a product focus, not a code focus. New hires are often eager to start coding, but reading code without context is overwhelming and likely fruitless. It’s better to start by teaching the product, first from the customer experience side and then from the architectural side. Teaching the product establishes important concepts and domain-specific vocabulary. Coding is a bottom-up activity by nature, but top-down knowledge of the wider system helps it make more sense.
Answer questions before they are asked. If the new hire sets out to do something that is confusing or contains a hard blocker, it is inevitable that they will get stuck and reach out for help. If you know you’re going to get interrupted with a given question or help request later, it’s worth preemptively answering it in your current conversation. The less often the new hire is blocked, the less often you will be interrupted at inconvenient times. Especially in domain-specific technical matters, expecting that new hires will somehow unblock themselves on their own is usually wishful thinking.
Be candid rather than defensive. Your new hire is likely to ask some sharp-sounding questions about pain points like technical debt, bad internal tools, spotty documentation, and bad user experience. Some questions will carry undertones of criticism or complaint, which can sting you a bit. If you respond defensively or dismissively to things that sound like complaints, you may unwittingly deter the new hire from asking sensible critical questions in the future. Giving misleading information doesn’t help anybody. Your new hire is your teammate and you don’t need to put up appearances the way you would when talking to outsiders.
Keep the first coding tasks very small. The goal of the very first code checkin is to have the new hire learn how to navigate source control, pre-checkin checks, and the code review process. For the first checkin, the goal should be to learn the process, not learn the codebase. The first coding task should be something really simple that can be done in only a couple of lines of code. From there, you can start assigning progressively larger and more complicated coding tasks. Getting code changes quickly checked in is also very good for the new hire’s morale, or at least much better than being stuck for weeks on a big project with nothing tangible to show for it.
Keep task instructions in writing when possible. People put lots of misplaced faith in their ability to remember things that were mentioned in long-ago conversations. Taking lots of notes is an acquired habit and you shouldn’t assume that a new hire, especially one fresh out of college, will have mastered it yet. Writing down tasks and spelling them out in detail is costly up front, but it will reduce how often the new hire gets stuck and reduce how often you will get interrupted. The new hire will eventually need to learn to deal with ambiguity, but doing so is much easier once the new hire has a solid foundation of background knowledge.
Prepare your backlogs in advance. You’re going to get randomly-timed moments when your new hire will interrupt you and ask, “I have nothing to do. Do you have any more tasks for me?” To protect yourself from too many interruptions and to keep the new hire from becoming idle, it’s worthwhile to be prepared in advance for these questions. The ideal coding tasks for new hires are low-difficulty, low-urgency, and low-priority. If your team hasn’t been maintaining a good written backlog of improvement coding workitems, you will need to either rely on your own codebase knowledge to create new tasks, or do some on-the-spot dives into the codebase to find something that needs improvement. Finding and documenting a worthy coding workitem can often take more time than actually coding it. It’s helpful to maintain a reserve of coding items for the new hire so that you’re not repeatedly put on the spot needing to find something new to assign.
Don’t settle for half-measures. The goal of onboarding is to create a full team member, not to create an almost-full team member. Technical problems with things like email lists, corporate permissions, or workstation dev environment setup deserve full attention and complete resolution. If the issue isn’t resolved early during onboarding, it will eventually show up again at an inopportune time. If something was supposed to have been resolved during onboarding but wasn’t, the new hire may feel embarrassed bringing it up again a few months later.
Ask for feedback and track it. A new hire offers a chance for someone to look at your system and your documentation with a fresh set of eyes. The new hire and you should both keep track of all the technical stumbling blocks and documentation holes that you encountered. Once onboarding is mostly done, it’s important to quickly address the gaps, especially the low-hanging fruit like documentation holes; these tasks have a tendency to end up in a low-priority backlog and never get done. There will likely be more new hires in the future, so it’s worth the effort to pay it forward and make sure future new hires have an easier onboarding experience.