First impressions matter, especially when someone joins your team. Your onboarding process will define their first impression, not just of you, but of how your team functions.
For better or for worse, new joiners will be the first people to notice all your dysfunctions. They come in with fresh eyes, and they are not calibrated to your normal. They evaluate the team as a whole at that point in time. Far too many times I have seen teams struggling, but being satisfied that “at least it’s not as bad as it used to be”. That doesn't mean things are actually working. They won't know why your team does things a certain way, and that may be a good time to re-evaluate that yourselves, instead of going "well, we've always done it this way".
Onboarding is there for when teams grow to make sure the new joiner is as effective as possible. However, team growth means additional people added to the team, which has the potential to destabilise a team. Research run by Google found that the biggest determinant of a team's success is the level of psychological safety there is in the team. And as much money as companies put into finding a different answer to what creates psychological safety, it still seems to be how long the team has been together (in the same formula)0.
So if hiring people disrupts the most important factor to team efficiency, why do it? Well, regardless of how effective your team is, there are still only so many hours in a day, and as companies grow they need more people to handle the workload. Onboarding becomes essential to making sure the gains outweigh the cost to the team. And we do that by making sure we provide the new joiner with everything they need to thrive. Even experts who have all the ideal skills, have honed their skills outside of your team and company. Therefore, chances are they will be doing things differently. Take your time to onboard people.
One of the first things I ask in an interview with a future manager is: "What is your onboarding plan?". Now just because they have a plan, that doesn't mean they will follow it, but in general this is what I consider most important. To have tasks. Sure, documentation is important, and so are runbooks. But the only documentation that is updated frequently enough is documentation that is used, and documentation that is used, is used because oldies and newbies alike use it. Therefore, that you need to teach people is how to search1 for it, not expect them to read multiple tomes the size of the Necronomicon and memorise them. Get people to do things, people learn by doing, with help. This is why I believe onboarding tasks are the holy grail of successful onboardings.
Onboarding tasks need to be clear. No ambiguity allowed, they are so precisely defined, that the new joiner will not have to wonder what one thing means or another, they won't deal with politics or with ever-changing PM requirements. It needs to be clear. And whomever is the point-of-contact for the task needs to know exactly how it should be done. Even better, they have already done it, just never published it.
I think they make excellent onboarding tasks as they expose the new joiner to the structure and overall capabilities of the codebase. The migrations or restructurings should already be fairly well-defined, so they are not running in the dark.
Why it’s good: While they don’t need to think about functionality, as they are not (supposed to) be changing it, this means they mostly learn where things are. When you need to find something in the future, this is invaluable. Basically they teach people where to search.
If you ever get some tasks that are kind of repetitive in what needs to be done, but the differences are subtle enough that they can’t be automated... Jackpot! You have just hit a mine of onboarding tasks. Every repetition can be another task.
Why it’s good: you can give them a template. You’ve done it before, so you know how it can fail and how to guide them if things go wrong. They get to play with the technologies. And the best part, you already have a test plan that they can follow themselves.
For lack of a better name, there's occasionally some tasks that are incredibly simple, but they become a nightmare just because they touch so many systems. One such example is adding a field to a CRM form (or if you really want a challenge, deleting one). Simple, right? But you've got to update the database, ensure push safety, update the backend, update the front end... did I mention push safety?
Why it's good: Something like this is basically the task equivalent of an end-to-end test. It touches everything, and it does it functionally. While the migration task touches everything in breadth, this touches everything in depth. And in the process you are teaching the new joiner how everything is plugged together.
You ever have something you think could have a potentially great impact, if only you had the time to do it? Something that's so dear to you, you go to work hoping the day will come when you will have a day with no workload, so you can finally do that project? Do you see it clearly in your mind? It's so clear, if only you had a few extra hours in a day... Yeah, that's the one. I'm sorry to tell you but... chances are it's an onboarding task/project. I know it's hard to part with it, it's your brain child... but give the new joiner a chance.
Why it's good: if you believe in it so hard, it means it will likely fill the new joiner with a great deal of satisfaction when they're done. The reason however you haven't done your project yet was because you couldn't justify doing it. Either because the chance of success were unknown, or it was hard to justify to the business. The new joiner has the advantage that noone expects them to be productive in the first few months, so give them a shot at your moonshots, they may surprise you.
I have been repeatedly told I had the best onboarding tasks back when I was at Facebook. And I still wear that as a badge of honour. I think I am prouder of that than I am of my proudest project.
My onboarding at Reddit has probably hit every single what not to do in the list of what not to do when onboarding someone. I would say it was arguably worse than not having any onboarding at all. It was one helluva rocky start, that impacted the rest of my time at the company. Because while it was a bad first impression, I cannot say it wasn't an accurate one.
My first task was a migration. All, good, right? I have done plenty of migrations in my past, some pretty big ones at that, and having worked in the release engineering team I knew a thing or two about push safety. Safe to say I already knew all the best practices to make sure things are safe. So I went on cracking. It was a new programming language, so I was still learning new things. Overall a great task to ease myself in.
Of course, there's a but coming... But... After publishing my changes for review, things got fun. There was a massive message from the most senior person on the team saying how we don't want to do this unsafely, and talking about all the dangers of doing this wrong way and that he didn't think we should do it at all. It was harsh... but I soon realised it wasn't referring to any of my code. The second most senior engineer on the team2, tried to defend me, which lead to a couple of days of back and forth between the two of them, on my pull request3. Eventually the decision was to abandon the changes. After a great deal of frustration, I decided to be an adult about it and message the most senior engineer with something along the lines of: "I know we have decided not to go forward with the changes, however as this is my first task, I would appreciate it if you could give me some feedback on my code. You have expressed concerns about the safety of the migration, I worry that I have done something wrong. The purpose of this is for me to learn anyway, so I would appreciate it if you could point out what I did wrong, so I can learn from this exercise.". Result: Radio silence.
On the surface this looked like a fantastic task. It was a migration, it was well-defined, or so I thought, and it was repetitive in that I could do it once to get approval on the method, and then repeat it multiple times getting exposure to even more of our systems.
Ok, here's a list of my most hated onboarding tasks/projects.
There is considerable conflict about whether the task should be done.
There is considerable conflict about how the task should be done.
There's this bug you couldn't figure out how to fix, let the newbie figure it out.
There's this task you really really really don't want to do, a newbie will do it.
I have no idea what this task is, but I know it's important, but not urgent. We'll figure it out when the newbie comes.
There's this project that would require a lot of research, new grads still know how to do that, right?
Some great advice I got from a very senior engineer was: regardless how senior you are, when you first join a new company just do what you are told for a couple of months. If you jump to try and help too early, you risk losing credibility. Basically what he was saying was -- take your time to learn the ways of the company, and their values. There will always be things that are a little different, and if you act as if they are not, it just breeds misunderstanding and conflict. Think of a doctor. If you walk in, and he prescribes you antidepressants before you get a chance to even describes any or all of your symptoms, how likely are you to trust their prescription? How likely is it to actually be correct?
Yeah sure, you're an awesome engineer, but that’s not the point. In fact, I firmly believe you should not make an onboarding task that would take you, a seasoned person on a team, more than 2 hours to do in a first place. And you should expect them to take much longer than you would.
If that's your approach, I would hate to see your documentation. Onboarding someone new, when done well saves you hours of mistakes in the future, and gives you many hours of extra capable hands on deck for your future problems. I think losing a couple of hours is not exactly losing anything here…
Well, talk with your manager about hiring expectations in the next year, assume someone may leave and there may be one headcount for them, and after that keep around enough tasks for that many people. Your team should have a bank of onboarding tasks ready most of the time.
Then do it and replace it with another one.
You could, but speaking from experience those are rarely any good. In that situation, you tend to make do with what you have on your plate, picking the best option. The best option is often not a good option.
You can, I ain’t stopping you… I am sure it will feel great when you complete it. You, amazing engineer, you! Good job!
There is a cost to hiring, and there is a cost to onboarding people. But it is arguably the most important step in growing a company. You can hire good people, but if you never properly onboard them you will have a collection of independent contributors, not a team. You might as well hire freelancers. If they don't need the money, chances are they will be just as temporary.
Onboarding sets the tone to how the team operates and shares knowledge. There are advantages to having fresh eyes on a team's workings, if we are willing to listen. And putting the right things in place for them to understand why things work, will enable them to continue to make things work.
Have you ever had an onboarding experience, good or bad, that shaped your view of a company? Would you add anything to my lists?
0 There are a few studies here is one of them.
1 Coincidentally, I think Facebook/Meta is the company that did internal search the best from all the ones I have worked for. I think that's hilarious because Facebook's external search has always been atrocious. Funnily enough, Google's search is still the most respected out there, yet I found their internal search to be more than lacking.
2 Really liked this guy from interviews, he was actually the person that informed my decision to accept the offer. Based on my impression of him, as well as how a friend talked about him. Unfortunately he "left" soon after I joined.
3 While today I would like to imagine me watching munching on popcorn, it was more like a ping pong game that went "Oh, so I am doing this", and "Oh, I'm not doing this"... back and forth.