Onboarding new starters is one of those things that when it is running smoothly is barely even noticed, but if it starts to fall apart begins to cause a hell of a lot of pain. It’s also not really clear from the outset where it may be going wrong, but as you are thrown into a “welcome to the company” meeting with a new starter whom you’ve never heard of before and whose role you don’t know for the second time in as many weeks, you are pretty certain that something isn’t right. This is then compounded by the number of complaints from multiple sources about “performance and processes” of recent hires.

Onboarding, like most complex processes (and it is definitely complex), is something that needs to be reviewed and considered on a somewhat regular basis. This is especially true during periods of change or rapid growth. For the most recent, large failures in onboarding I have had to dig into this was a dual strike of the company moving to permanent remote working followed by doubling the size of the company over a year. It failed slowly and has not been an easy, quick fix as we continue to grow at the same explosive pace.

Debugging onboarding is a tricky process where stepping through each section of the existing process and touching it up seems to be the most effective approach. Adding alarm measures in so that you can catch failures early and target fixes is an excellent idea here too.

It begins with working out what people need to know.

Work out the details

What is it that people need to know to function in your workplace? This can be split somewhat cleanly into software, process, HR and people, and an amount of the answers will already exist although probably out of date or incomplete.

Software

What are they going to use day to day? Depending on your organisation and department this can be an abstracted list, e.g. ide, git client. Or something more specific e.g. Photoshop, XD. This will help with a list of accounts to be created and invites sent but won’t be the total of them. You’ll need to remember everything like HR systems, things like jira etc. Check with your IT support, what are they always getting asked to provide accounts or access to? Should that be being thought of as standard?

Process

From way on high with how the company functions down through how the department functions and how their team functions, all the way to what is expected from the new starter as an individual on a day to day. For example: the company is an agency, what does that mean? how does that change how we think about projects? How do we get projects?
The department has meetings every 2 weeks to discuss things we’ve learnt and the way we work.
This is the general flow from you doing a piece of work to it being in production.
This is the way the team functions, we work in sprints, these are the regular meetings, this is how you will be assigned tasks.

HR

Who do you go to with a problem? What to do if you’re sick? How to book holiday? Employee handbook, security policy etc Also company structure, helping someone understand where they fit in the company will help them, well, fit in.

People

Who does the new starter need to know? Who needs to know them?Who will they meet? Who are the big names they’ll see jumping in on Slack? Who is their line manager? Answering these while meeting people in the office is overwhelming but fairly organic. Remote is both easier and harder, easier in that you can give a straight forward list of people that immediately maps to the main method of communication (Slack, Teams, etc), but harder in that the new starter is basically just another name in that registry to the majority of the company. Working out natural or unnatural ways a new starter meets people is part of onboarding

Get Organised

Now you have an idea of what a new starter needs to know it’s time to get organised.
Start with working out which of the details are an internal task, which are documentation, and which are a meeting. Some may be more than one.
Developing this as a check list is a useful tool for tracking the tasks and meetings. Things that are documentation should be compiled as part of a welcome pack email. Your checklist and documentation may already exist in some form or as several, but if onboarding is failing it is likely to be out of date or incomplete.
That welcome pack email should be waiting for your new starter when they start, but should not be the first communication with them. Check up on your existing process, you should be letting new starters know what’s happening a few days before they start, what will their first day look like etc (this communication is handy to be sent to both their personal and new work email so they can find it easily in a few weeks)

The other half of this is working out your people and letting them know what they need to be doing and when. The standard onboarding meetings should be booked as early as possible and those who are taking them should know what they are talking about.
IT/Sys admins should be informed as soon as a start date is agreed.

We’re all humans

With everything above its easy to slip into a ticking boxes attitude and forget there is a human being on the other side of the check list.
Starting a new job can be exciting and scary, give that human plenty of chances to meet and speak to other humans. This is especially important to manage when working remote, the natural interactions simply don’t exist in the same way. It’s a great opportunity for some good old organised fun, coffee meets, Friday beers and the like.
There is also going to be a huge list of things to talk to them about or point them to, make sure you are building opportunities to digest the mountain of info and/or take a break into your onboarding plans.
Something that has been working really well for me is a Red Amber Green sheet of everything new starter should know to be considered onboarded and getting the new starter to update it on a weekly or fortnightly basis. This allows them to decide when they’re comfortable with things, when they’ve understood and when they’ve been on boarded. It treats them as a unique human who will learn and remember differently to others, and avoids the annoying situations where a lead is frustrated with the new starter because they haven’t remembered that one thing they mentioned on day one. The sheet and the meetings around it also will act as part of your alarm system, if something is being missed or not thoroughly explained it will come out here.

It is worth adding a review process to onboarding. Early on this is simple and aimed at tailoring things to the individual, a senior for example could be ready to just get on with things far earlier than the process is expecting. But towards the end or at the end of a probation period it is extremely valuable to find out what they thought of it, what was missed, what they think could be improved. Actually doing something with that feedback and adjusting your processes at regular intervals (don’t just react to anything and everything suggested, one person may hate something that the majority found extremely useful) is worth carving out the time for.

Time

The final thing to consider (that to be honest should have already come up as you’ve been creating your onboarding) is time. You should have an idea of how long it takes to be able to build support systems and to start to produce useful work in a way that doesn’t hugely impact others. That is usually not just a few days as seems to be a common belief. You should be working on a scale of weeks. It will take months or even a year to be getting the full potential from any new starter but that is a different discussion, this is about feeding someone all the information they need to function in their new workplace, and for them to take it on board.

So with that in mind spread those meetings out. Does the new starter need to know how to log time on day one or can that wait until sometime in week two? Do they need to be introduced to the project immediately or is it better to spend a few days on processes and getting set up? Work out when someone needs to know each of those details you’ve listed (and be prepared to shift things for those that move faster or slower than expected)

Final thoughts

So I mentioned at the start that onboarding is most definitely complex, just from reading the above, the sheer amount of small things a new starter needs to know combined with how many people need to be involved with the process at various stages is daunting. It is very understandable that it can also break quite easily, perhaps someone key leaves the company, perhaps software is changed but onboarding not updated. Whenever that eventually happens, having included some sort of alarm system for when things fail is invaluable, whether the form that takes is probation questionnaires, RAG sheets, regular reviews or something more fancy, knowledge of failure should come from the data not from passive aggressive comments at the Christmas party…