A few years ago, I noticed that one of the engineers on the team had very quickly gotten up to speed. A few months in, she was dealing with external stakeholders and owning large projects independently. It seemed like she had been on the team for years. When I asked the engineer who had onboarded her about his strategy, he said he used an intentional technique he had picked up in the Marines. Each week, they roughly doubled the amount of work she took on — until finally they discovered the limits of her capacity and then dialed it back.

What was fascinating about this onboarding strategy was that because they were working on a somewhat isolated area of the codebase, it was so different from what was happening elsewhere in the company, but it was extremely effective at getting her up to speed and autonomously working on major projects. And it got me thinking about the different ways we onboard engineers.

When we think about onboarding process, we often think about codelabs, classes, and tutorials. And let's face it — at most high-growth startups, it can never seem like the right time to spin up a project for some engineers to build out more onboarding resources. When hiring is slow, it's important but not urgent, taking a backseat to more pressing engineering work. And when new hires are streaming in, it's easy to say “oh we really should have set up some codelabs...let's do that for next time.”

Many years ago, I spent a bit of time thinking about the highest impact changes I could make to Medium's onboarding process. What I saw was that yes, codelabs and tutorials would of course be great. But there were more foundational inconsistencies that would be higher leverage. One new hire might be lucky to get seated next to an especially helpful and not-too-busy-seeming engineer who was roughly in the same area of the codebase. They might get to chatting, and the new hire might feel comfortable directing all questions to that engineer. Another new hire might be seated near people with headphones or feel a little less comfortable asking questions because everyone seems so busy. And the compounding impacts of these very subtle differences build up. One engineer might have their first bug fix or feature work open for review in just a day or two, and another engineer may be off in the woods with no supervision or help for weeks.

I implemented two subtle but powerful changes to the onboarding process. Surprisingly, neither of them are engineering-specific or have to do with code walkthroughs or tutorials at all. I'll share them with you now, as well as a third bonus tip for building alignment quickly with a new member of your team.

Onboarding tip #1: First Impression

The first day of a new job can be daunting, overwhelming, and looking anxiety-inducing — so no matter how much other onboarding classes or codelabs or dev environment setup documents you have in place, one of the highest impact ways you can put someone at ease is the first impression they have when they show up for work. I decided that a crisp, beautifully printed welcome letter on their desk with all the information they would need to get started would set the tone. I went out and bought a pack of nice, thick, creamy cardstock, and then I created a template I used for every engineering new hire.

An initial paragraph expressed the team's enthusiasm at their joining, followed by a beautifully formatted schedule of their first day. I included the name of their onboarding buddy (see next tip), as well as a pointer to the Medium Eng Getting Started Guide to work through in between meetings.

Every time a new engineer joined, I loaded their first day into that template, made sure the entire letter looked beautiful (no typos, weird indentations), printed it out, and signed it with a pen, “Welcome! ~Medium Engineering.”

When everything is digital, receiving something personalized on creamy cardstock is a delight. “Wow this paper is so nice!” Seeing the look of delight on each new hire's face as they appreciated the thought and effort that went into this personal welcome was well worth the extra 20 minutes or so it took me to put it together.

This practice was soon adopted for the rest of the company, and I passed along the same tips I'll share with you here: make sure the paper is really nice (please no standard printer paper), and make sure the formatting is beautiful. In a day of overwhelming new accounts, new people, laptop setup, and calendar invites for onboarding events for the next week or so, a simple and personal reference to what they need to feel welcome and get through that first day is key.

Onboarding tip #2: Onboarding Buddy

The biggest inconsistency I found across different engineers' onboarding experiences was whether or not they had adequate access to someone they could ask any question to. It's hard to know who to ask what question to. In an open office, everyone always looks busy at their desks, so if you're not assigned someone specific, it's easy to not want to bother people if you get stuck setting up your dev environment, or any of the many other things to set up the first few days and weeks at a new job.

The most impactful change I made to the onboarding process was to assign every new hire an onboarding buddy. I'd make sure the buddy had bandwidth to be available to answer questions. Once they agreed to be a buddy, I'd send them an email detailing the responsibilities of an onboarding buddy. Their highest priority for the first 2-3 weeks was to be available to the new hire to answer questions, pair-program, direct them to the right people, etc. Not only that, I also required that on the new hire's first day, that the buddy have a conversation with the new engineer, making that explicit. “My highest priority is getting you up to speed, so even if I look busy, feel free to ask me questions any time. Even if I don't know the answer, I can point you to the right person.”

Every new hire who was not working remotely sat next to their onboarding buddy, even if that meant shuffling a few people on the team around. What was important about the assigning of a buddy, the explicit conversation about priorities, as well as seating them together, was reducing the barrier to asking for help. Getting someone set up and up to speed in days instead of weeks helps put them on a trajectory to be successful for their time at the company.

Onboarding tip #3: Powerful Questions to Build Alignment

This tip comes from my own observations of how different people learn, as well as through coaching conversations with engineering leaders thinking through how to best set new grad hires or senior engineering hires up for success in their organizations.

What I saw was that as companies grow, they start to codify their onboarding processes to scale with the scaling engineering team. But people would come to me in coaching sessions with the problem that what worked for one engineer didn't seem to be working for other engineers. One engineer thrived until light supervision, while another needed more guidance and guardrails. One engineer would ask for help from whoever was around when they got stuck, while another engineer would go for days or weeks without much update.

And perhaps the pattern that I saw most clearly was that a lot of longer-tenured engineers had themselves been “onboarded” or grown their careers in chaotic, little-to-no structure environments where they were forced to be resourceful. And now that they were leading engineering teams, they were setting up onboarding systems that were the complete opposite — start off with code walkthroughs, then fix a non-critical bug, then pair with your buddy for a week, then contribute to a pull request.

What became clear to me is that in all the conversations about building onboarding processes, there was very little about how differently individuals learn — how some like to be thrown in the deep end with a meaty project, and some like to have their hands held for a few days before leaving the nest. And in putting in onboarding process, we often assume there's one best way to onboard people. That's not to say that you need to create a bespoke onboarding process per new engineer, but some upfront and ongoing conversations to discover how someone likes to be onboarded, and how they've been successfully onboarded in the past can go a long way.

Ask a few of these powerful questions early on, and the answers may surprise you:

• What would be your ideal onboarding experience?
• What's a time when you felt really excited and motivated on a new project and team? What about it was most motivating?
• What does being supported at work look like for you?

Of course, as your team scales, you'll also add more standard onboarding resources like documentation, walkthroughs, maybe even a regular cadence of domain-specific classes. Those things are all important, but they also take a lot more time. These three tips I shared here — creating an inviting first impression, setting up an onboarding buddy system, and having an upfront conversation to discover what successful onboarding looks like for each new hire — don't require much time to implement, are extremely high leverage, and can really effectively smooth out some of the bumps as your team grows.

If you enjoyed this piece, you may also enjoy Engineering Leadership and Minecraft: Surviving Your First Night, which ties in onboarding with surviving your first night in Minecraft!