Onboarding Can Be Sane
Or, how to not cause your engineers to develop an ocular spasm on day 1
Every company has a completely different approach to onboarding engineers, and most of them suck. I’ve onboarded to no less than a dozen companies, ranging from 5 to 50k employees. The larger companies tend to onboard all the same: stick you in a few days of HR meetings, corporate trainings, piles of paperwork, and enough ice breakers to make you literally hate your own name.
On the other end of the spectrum is the early-stage startup that thinks they’ve found the secret to productivity, and you’ll never guess what it is:
Shipping code on day 1. I know, groundbreaking.
I’ll never forget the company that put me in a room with ten other new hires and didn’t let anyone leave until we all had pushed something meaningful to production.
On our first day.
Nothing says “Welcome to a job you definitely do not regret taking” than a 12-hour first day led by a frenzied Staff Engineer with an ocular spasm. Here’s why this doesn’t work, and something that is a much better use of time.
Art Not Science
First, why I hate rushing devs to their first deployment.
The job of a Software Engineer is more art than science. This is not controversial: we’ve done everything possible to ensure engineers spend their time in high-level languages that are closer to prose than machine code. First, it was languages like Python that mimicked human speech patterns, and now it’s literally just writing prompts to generate code.
Artists do not begin their practice by producing a painting as fast as possible, rather, they start by learning how to properly stretch and gesso their canvas. When a chef onboards to a restaurant, they aren’t expected to cook a full menu on their first night, lest they risk a terrible morning of reviewing Yelp feedback.
Nobody learns a process by speed running it. I’ve never subscribed to this “push something useful by end of first day” ideology. I’m a big fan of teaching the process over the course of the first week:
Start by making sure your dev machine is set up and you know how to use it
Push a no-op change to a development environment
Learn how to access this environment to verify changes
Learn how to promote to production
Learn how to verify changes in production
Finish this stage of learning by going through each of these steps once more, solidifying the process
The idea is that engineers can only really learn so much at once, and work better when they have confidence in their actions. When you’re learning to lift weights, you want to get your form solid before adding plates to the bar. I could keep going with metaphors here but I think you get the point: start with a solid foundation and build from there.
Simple Tasks Are Never That
One of the non-unique experiences every engineer has encountered is the “easy new hire task that isn’t actually easy.” These all start the same way: A more senior engineer assigns you a task from the backlog, one that is pretty straightforward. And then the first speedbump hits. Sometimes it’s a dependency that’s harder to work with than previously expected, other times it’s side effects that need to be mitigated, other times it’s a complex automated test that needs to be edited. Regardless of what it is, the “simple” first task is usually anything but.
This usually ends up with a frustrated senior dev who is struggling with why you can’t just go figure it out on your own.
You, the person who doesn’t know which of the two observability surfaces you should be looking at (when it’s the third one, that you don’t have access to yet.)
You, who don’t have any experience in half of the technologies you’re working with, let alone how they’re configured at this org.
You, who don’t even know where the restroom is yet (but somebody better tell me fast, I’ve been hitting the bevi way too liberally.)
And then you’re sitting there, feeling like you have no idea what you’ve gotten yourself into. Your confidence is gone, your energy is drained, and your ability to absorb information is at an all-time low. An anxious brain is in self-preservation mode, not learning mode. Worst of all, you’re left with no time at all to focus on the actual most important onboarding task.
Bottom line, I want my engineers to be ready to push code sustainably. If I bark at them to just get code out as fast as possible it will put them in a situation where they don’t know something, and they’re too afraid to ask, because they’re 4 weeks in and should already know it. Everyone is going to learn codebases and processes at different paces and while as managers we should drive our engineers to put in that extra 10%, we don’t want to force them into a completely uncomfortable place too early.
The Most Important Onboarding Task
On day 1, when I meet with my new team member, there’s one specific task I assign them. The goal is not to fast-track their ability to push code, as they’re already focusing on that naturally. I know they are, because my team doesn’t hire people who aren’t eager to jump in and start learning the ropes. What’s important to me is that when my hiree needs something, they know who to get it from. And more importantly, that when they need something from this person, it’s not the first time they’re talking.
Relationship building.
By the end of day one, I ask my new employee to have set up 30 minute 1:1s with everyone who is going to be immediately important to their role. That includes the other engineers on their team, stakeholders such as PMs and designers, representatives from other teams that they will likely interact with, and other company leaders. I ask that they prioritize meeting with people close to their role in the first week, and then work outwards. These 1:1s are typically to be scheduled over the course of their first month, depending on how many people are on the list we work on.
The assignment is that, coming out of each 1:1, they know the following about this person:
Who they are
What they are responsible for
What they care about
This relationship building can only happen in the first weeks of the role, because they only get one opportunity at first impressions. Before they need something from someone, before they are in a meeting where they are interacting with someone, they should know who those people are and where they are coming from. After all, when they get their first big task to accomplish, it’s likely that they’ll need to rely on others. Whether it’s for access from the IT team, implementation details from a stakeholder, or even just a code review from another dev, having a good rapport with that person will make sure they get what they need. If you know what someone cares about, when you’re sitting across from them in a meeting and they ask you a question, you’ll know exactly which angle to reply from.
One other thing I tell the new hire is that they shouldn’t ask for permission to set up a 1:1- just put it on their calendar. The person you’re meeting with should know that you’re here to get shit done, not waste time.
How To Survive The “Deploy Fast” Onboarding
Okay, cool, but you it’s day 1 and your manager clearly doesn’t subscribe to my substack.
When we’re interviewing, managers want to hire self-actualized individuals (and this starts during the interview process!) People who know what they need to succeed, and aren’t afraid to tell you. So step one, if you’ve been hit with unrealistic and unhelpful expectations about how you organize your time while onboarding, is to tell your manager.
Pull them aside and explain why this isn’t helpful, what would be more beneficial to you individually, and ask if there is any way to bridge the gap. Hopefully they will see what you need and reprioritize your tasks. Whether that’s a slower time to deploy valuable code (maybe start with a whitespace change to learn the deployment process first) or just allowing for more time for relationship building, you might be able to find a happy medium.
But I know for a fact that if I had brought this up at the startup I mentioned previously, my onboarding lead would have had a melt down. They had the way they did things, and that was the right way, and that’s that. Nothing is more annoying to naturally inquisitive people than being forced to learn at a speed that only allows for rote memorization of processes, which is demotivating and anxiety inducing. If you’re in one of these situations, all isn’t necessarily lost.
What you need to do is figure out what is important to learn, and what you can stick in the bucket I call “The Zen Of Not Knowing.” Basically, when you come across something that is new to you that you want to understand, ask yourself if you really need to understand it at all. Do you need to know what happens in the deploy shell script that you’re told to use? Do you need to understand how the test harness works? Or can you just use it the same way everyone else does, and figure out the details later? If you need to beeline to getting something into production, you’re being told not to worry about the finer points.
If you want to excel, however, you’re going to have to put in a few extra hours. Know your limits, of course, but during your first few weeks I would argue that this is the time to grind. Extra work you put in during this onboarding period is an investment in future sustainability: the sooner you have a solid grasp on how to ship code in these fast-paced environments, the sooner you will know when you can take your foot off the gas.
So that’s it. That’s my big secret to getting engineers onboarded: help them build relationships. And it works. I’ve built and led top-performing teams at a wide range of companies across various team sizes and industries, and it’s always been by following this onboarding ideal. And when I get clients to my Elevate Onboarding Program, this is the task I give them in our first meeting. Because the only thing the Staff Engineer that forced me to stay past 8pm on my first day accomplished was to give me my own ocular spasm, and encourage me to start looking for a new role within 90 days.
