Onboarding: what should be in there?
Onboarding a new hire into an engineering team might seem trivial at first, but there can be a lot to do.
So, what's the point of an onboarding process? What should be taken care of in it?
Note: the following is focused on onboarding people in the engineering team who will write code and make software in general.
The point
An onboarding process should get your new engineer all ready to work. That should encompass technical topics and non-technical ones.
While automation can help prepare things, don't underestimate the need for a human element. Automation should take care of what's repetitive in the process (from one hire to the next) but shouldn't make things cold and impersonal.
You want your new team member to feel welcomed and cared for, not passed through a series of automatons to get into a boring cubicle, ready to rubberstamp paper.
Overview
The whole thing generally starts even before the new hire is at the office or pinging you online on their starting day.
Fire up your best note-taking app and make a list or map of the following steps.
It usually starts with the first talk by one of the company's leaders. This talk can cover the company and team's mission, introducing the company and team's values to the new hire. This can also extend into giving an overview of the company and teams but tends to stay reasonably high level. This is mostly a welcoming talk to get the new hire into their new world.
0: get the new hire in the company by sharing the basis of the company's culture and the company's overview.
It then goes on with getting all accounts set up for the new hire: email, code hosting, ticket and board service, monitoring, instant group chat, etc ... This can sometimes be done with a script but can also be done manually. Check with the different websites and applications to see how they can help you onboard an individual or a group.
1: create accounts for all the tools.
Then we will need to make sure the new hire has a computer to use for the work (well, if we are a tech company, that is). Your company might have chosen to provide such a computer to the new hire. If you are in a small company, you might be buying computers directly online and getting them delivered to the new hire. Remember that this can also be handled through different services online and might not involve an actual purchase (leasing is also something you can do for computers).
You can also request the new hire to use their own devices. That's up to you. Be careful that there might be some issues regarding Intellectual Property and the like. Check with your favorite lawyer or HR person.
Once the above question is solved, you want to get that computer ready for work. Don't rely on a vague list somewhere. Use, at the minimum, a script maintained by the team to get everything set up in as little time as possible. This should only take a couple of hours.
2: get the new hire a computer and get it setup automatically for their needs in your team in less than half a day.
While the computer uses plenty of CPU cycles, you want to use that time to break the ice between the new hire and the team. Of course, that should involve the team they will be involved with most of the time but also the teams often involved with them and beyond. The new hire should have met their team and have a good idea of the teams around them and their leaders.
3. get the new hire aware of their team, the ones orbiting them and the ones they orbit.
Once the computer is ready to use, even partially, you should get the new hire situated with the tools their team uses. While this can be done by having them follow a page on a wiki, I'd encourage one particular "mentor" to be attached to the new hire and go through the different tools.
4: get the new hire aware of the tools their team uses and how they use it, with a mentor if possible.
Now, either in the second half day or the next day, the new hire should be able to start working for real. Don't just leave that person on their own. Ensure that they are able to start working by having their mentor pair with them to get through the usual hoops of getting the code base or code bases cloned to their computer. That should also include making sure they can build and run any piece of code they have to work with.
5: get the new hire able to work for real with the code bases they will work on.
Self-review
Going through or preparing this process should already tell you a lot about where you are and how you are doing. If you can, grab one of the new, shiny laptops and follow through the process yourself.
If there is much fiddling to do and custom files to share between people to get the new hire to work, then it clearly shows you need to make adjustments. Except for encryption keys and other delicate data, you should have all environment variables needed for a development environment set by the software by default. They should be safe to use locally without risking or compromising the integrity of remote environments.
Support
All that process should be supported by a written, easily accessible wiki or something similar covering the different steps, what is usually explained to new hires, etc ...
This wiki should not replace the onboarding done with the mentor but complement it. It can be used as support after the onboarding. That way, if questions arise about a detail that slipped through, the new hire can find some support online before reaching out to their mentor.
Conclude
Onboarding should not take long to get the new hire situated and started. The process will likely take a couple of weeks for the new hire to be fully able to work and deliver value. Yet, if the initial onboarding is fast and smooth, it will already make a good impression on the new hire and simplify the next steps.
To get started
We have prepared a little checklist reusing the skeleton of the article as a basis. It's also reusing some of Google Docs' onboarding notes templates. It's free, but you only need to sign up to access it.
You can export it as PDF, other formats or make a copy in your account.