Losing Your Marbles on Onboarding

Does high-speed software engineer onboarding mean a sooner real contribution?

just like any cool medium article, here’s some Dilbert comic

If somebody opens a story with a question like this, the answer is usually no. To avoid being pointed out some facts or statistics that contradict this writing, let me begin with: this is based on my experience, from my point of view, with some effort to look at it from my employer point of view. Obviously, if you’re responsible for the onboarding process for a company, you should look at real research on this topic. The result of the same onboarding process also differs among employees, we all can agree it depends on the employee’s skills and experience, but one particular skill stands out, the ability to take what is really important and move along. We might be exploring that in another article.

I’ve gone through four different onboarding processes for the last few years. Each is different from the other. But we can categorize them into:

Welcome, please work right away

This model usually used in a very small startup. Like the title suggests, here a person from the company will welcome you and you’re given a task right away. The company priority is that the new employee should be producing features (or putting fires out) as soon as possible. In this case, how hard a new engineer onboards depends directly on how complex the company technology is, including the codebase, the infrastructure, the product, and the team workflow.

For a junior-level position, this method is acceptable when the technology is still relatively simple. Without proper documentation, reading a small amount of code is manageable. But, if there are, let’s say 8+ big repositories to learn, this method will be excruciating and unproductive. New onboards will repetitively do what their predecessors do, conducting trial and error just for running an app. Every task will be paired with a buffer for learning. Ultimately, I believe if a company is about to use this method, the expectation should not be a fast real contribution, but the opposite.

Reading Documentation and Codebase for a Week

Getting up a new employee to speed with documentation is a good minimum choice. It will at least gives you how the product works. The documentation quality relies on how up-to-date and accurate it is, which affects the overall onboarding experience. The best way to maintain the quality is for your team to have a collective discipline towards documenting changes. The second best thing is to ask the onboard to fill in the gaps. Each onboards will go through the process then contribute to completing the document, if applied correctly, onboarding should be more delightful over time.

Mini-Tasks

My personal favorite is to have mini-tasks for each repository or workflow for onboarding. In this model, for the first one to two weeks, you’ll be given small tasks that will actually prepare you for writing codes. For example, if you have an app repository, the mini-task would be:

1. clone repo
2. run the app
3. finish scenario A
4. finish scenario B
5. change component X
6. and so on…

You should ask new employees to capture each step as proof of success. The scenarios you write should cover the minimum knowledge you need to have about the repository. With mini-tasks, you make sure they can actually run the repo (it seems trivial, but a lot of time is actually spent here). Another important thing is to include a “making a change” step as it will give the employee confidence to tinker around the codebase. Ideally, there should be an onboarding buddy that supports and reviews the new employee's works.

At the end of the day, revamping the onboarding process is usually at the bottom of priority. The impact is definitely less direct than new features and fixing bugs, but putting it to the backlog for the next sprint will be worth it. If it’s too much, start slipping one repo per week and you’ll have excellent onboarding in no time.