How Onboarding Should Look Like

Onboarding, the process of bringing on someone new into an organization can go wrong in many ways, but can also be an investment with noticeable rewards.

What most people miss about onboarding, is what it’s really supposed to do. Onboarding is not to hand-spoon new joiners the codebase, it’s teaching enough so that they can be fully autonomous and “get” how things are done in an organization.

So how can you do that with minimum effort and time?

I’ll share what I’ve learned so far from my experience¹ working at different orgs in this essay.

Commit from Day One

The best way to get an engineer comfortable with the code is to let them change it and merge something new, it helps break the ice and gets them to feel that they’re actually starting to do work.

To get something done on the first day, it probably won’t be a new feature or a major bug fix, rather it can be something simple that they can grasp quickly and get them to go over the full life cycle of creating new software at the org.

Going over this, by the end first week they’ll probably have gone through everything from unit tests to regression tests, code review, CI/CD, etc.

There is an argument to be made that maybe a new joiner should be introduced to the whole codebase piece by piece, which on paper makes sense but mostly fails in pratice which leads me to my second point.

Train to Become Fully Autonomous

Probably all employers want people who get things done autonomously, why wouldn’t they? The trick here is that you need to invest time and effort to enable newcomers to become autonomous contributors. Assuming you hired the right people that are hands-on and get things done, instead of training for exact details, teach for abstractions and concepts of how the product works.

With advanced dev tools nowadays, anyone can research on their own to understand how a certain block of code works. Also, when your codebase has more than 20+ million lines of code with lines written 25 years ago, it’s impossible to teach details and expect them to stick with them.

I’ve learned this firsthand working at IBS, there are almost too many things to learn, even after a year of working there. Instead, you just have to trust the growth curve and that this person can figure their way out of the black hole.

Build Trust

This is often lacking in remote work environments, especially when they start off without any personal connections or real-world meetings. It’s nice to have company events to gather all employees in person so that they can get to know each other better and build stronger personal relationships. This helps a lot in communication for work and teamwork.

Ideally, employees should enjoy working with each other, and the best way to get to that state is for them to actually know each other.

The First Week is for Fundamentals

Something I love at IBS, the company I work for is that in the first week, because I lived in Ottawa and am working remotely, I spent it sleeping on the couch of one of my friends in Montreal to have a great onboarding experience.

The architect of our whole codebase for 20 years spent the whole week every day giving me lectures on the fundamentals of Linux, Operational Research, Bash, Git, etc. He’s introduced to me concepts like abstract machines and proof of code correctness.

He’s changed the way I write software forever.

Set Baseline for Culture

The final note I have for onboarding is that it can be very effective for setting the ground of culture with new joiners. People adapt to whatever the culture of an org is, and this can help to set the mood for work expectations and values.

Notes