What a good onboarding process looks like

I’ve recently started a new position at Kroo which I’m excited about! It’s given me a bunch of time to think about onboarding and joining a team.

If you’ve worked in software development before then I’m sure you’re aware of how the first weeks can go as a new member of a development team. There are a million new things to learn, people to meet, forms to fill in and processes to learn. It can be an intense period of time.

My latest onboarding has been one of the best examples I’ve been through. I spent many years as a consultant so joining new teams and organisations was a fairly frequent activity. A good onboarding can make a world of difference in those important early days and help get a team member productive quickly. A good start can really motivate a new joiner. On the other hand…

A bad onboarding can crush any motivation when joining a new project / team. My worst onboarding experience involved me showing up on day 1 and then needing to wait three weeks for a laptop to be assigned to me. It was extremely demotivating. Why am I here? I can’t even get a laptop they clearly don’t value me etc.

So here are some tips that have made my various onboarding experiences good ones.

Getting a workstation setup

I solve problems with software for a living! I’m going to start with an issue close to home! Going form a new factory default laptop to a working development machine with all the tools needed to contribute to a team.

In my experience the best approach here is to invest in automation. A lot of organisations have a common tech stack for their projects / products so it makes sense to have an automated script that installs the tools required for working with those technologies.

Install, nmv, gradle, docker and brew for example. I’ve worked in a few places where each team has a script which runes git clone for all of their repositories.

Automaton also has the advantage of being reproducible. If everyone in the team has downloaded and installed the same tools from the same place and in the same order they should have near identical dev boxes. You might even be able to reuse some of the automation in your application builds if you deploy machine images or Docker containers as your deploy-able artefacts.

It also saves your new team member hours of tediously and manually working through a list of what needs to be installed and checking them off.

Onboarding starts Before day zero

A lot of tasks for getting a new teammate going quickly can actually start BEFORE they show up. For example it’s possible to get accounts provisioned before they arrive so that they can login to email, Jira or Notion on the first day.

Things like GitHub accounts can require a bit more involvement, generating ssh keys etc, but actually getting added to the organisation and appropriate team’s should be a days long process. Make the people who have access aware that they’ll need to add a new team member on the first day.

Having an onboarding plan in place before your new team mate arrives will also help manage their expectations when they arrive. ‘Ah okay I’ve got these 5 sessions to go to this week.’ is better than ‘OMG what are they going to throw at me next no-one seems to know whats going on!’.

Genuinely, spend some time creating a repeatable onboarding experience. Take feedback from people who go through it and make alterations accordingly.

Buddy up

I really like this practice. Get one of the team to be responsible for helping getting the new joiner through their first few days. Having a dedicated person act as an onboarding buddy can really make you feel welcome to a new team. This person would be the first port of call for questions and clarifications.

Now I’ve said in before and I’ll say it again, Pair Programming is by far the most effective tool to share context within teams. Both technical context, ‘we need to use tool X because tool Y doesn’t work on this version of Z, and product / business rule context, ‘our sales team can’t have more than 5 open opportunities at once’.

Pair with your new joiners! Help them debug any rough edges from installing / getting the development build running locally. Share knowledge you think might be pertinent to know and make yourself open for them to ask a lot of questions about how things work in your team.

Have the onboarding buddy pair with the new joiner! It really rounds off having a person dedicated to getting the new joiner going as quickly as possible.

Fix a Bug Together

The final tip I have is to try and be deliberate in the first task your new team member picks up with their pair. I’ve found small bugs are good candidates for a few reasons:

• Bugs involve explaining whats is happening vs what should be happening in the system. Exposing the new joiner to domain context and opening the door to them asking more questions
• Making a small change to what is already in place is genially easier than writing new code in an existing code base
• It exposes them to the ways of working in the team, ‘how do we get changes into the staging environment’, ‘what does the QA process look like in the team’, ‘what does our build and deploy process look like’.
• Small bugs tend to have a fairly limited scope so they can be fixed quickly and in a single service. A quick piece of work can let the new team member take a task from all the way to production in their fist few days.
• Small bugs are also fairly low stakes as a first piece of work while still having meaningful value when delivered.

TL;DR Something small but real which will introduce the new team member to how the team and organisation works.

Conclusion

A good onboarding process makes a great first impression for people joining your organisation / team and it is well worth your while to build a reproducible one which sets up new joiners for success in their role. You can start the process before their first day and should use automation to manage the more tedious tasks such as installing development tools. Assign your new joiner a dedicated buddy to answer questions and show them the ropes and get them to pair program on a small task to get their feet wet.

Thanks for reading. :-)