DEV Community


Posted on • Updated on

How to create an induction process from the ground up.

Helen posted an amazing discuss article on Friday about how you onboard staff.

It surfaced some really awesome comments and found there to be a lot of insight gained.

So as someone who is onboarding new staff this week, I was inspired to share my process on how to make an end-to-end induction plan.

I believe that onboarding is done very poorly in the majority of places.

Some of the common mistakes I see are:

  • An induction plan that they blast through 4 times as fast leaving you with nothing lined up for them to do.
  • A lack of current or accessible documentation leaving them without anything to refer to or reading a bunch of stuff that isn't applicable any more.
  • Forgetting what you used to struggle with when you started and making assumptions about what they know and how it easy it will be to learn stuff.
  • Teaching them the stuff in the wrong order, confusing them for longer
  • Assuming everyone learns the same way.
  • Holding them back from contributing the team for too long.

Time and time again I have seen the above, they are often indicative of a lack of information management , too many silos and no actual understanding of what goes into making a good staff member, let alone an understanding of what the role really is.

People tend to live in their jobs and are unable to step back and see the forest from the trees.

The job of actually figuring it all out is often to overwhelming so management lean on the biggest crutch available to them, time, and expect you to fail upwards until you eventually figure it out.

How often have you heard 'it'll take you 6-9 months until you'll get there.'?
It's bullshit. You're not stupid. How many classes did you juggle a trimester at university of different subject matters? "How many things have you self taught yourself?

It comes from them not knowing at all how long it should really take, and not investing the time to learn. So they leave your learning up to random chance, because for 99% of jobs 6-9 months of exposure to the job should teach anyone.

But what they don't see is what could be gained from doing it properly. If you knew for a fact that you could get someone up to speed in 6 weeks, then you wouldn't accept 9 months as an acceptable time-frame.
It's the equivalent of just leaving your savings to gather the lowest interest over 12 months because you can't be bothered to look into any of the other options.

And that's whats happening in most inductions around the world, they can't be bothered to make the time to figure it out.

I do understand that it's hard to make that time, especially if you are replacing someone who has left and are down in terms of resource, but wouldn't you rather your new employee be effective in six weeks as opposed to twenty four? Is that not the better use of your time?

Right time to explain some key points.

Figuring out what to teach
The fundamental aspect to knowing how to train someone is to break down what you want them to do into its smaller knowledge components.

A good simple example would be
Task: Send out the weekly report:
What do they need to know to do that?

  • Need to know who to send the report to
  • Need to know how to run the report
  • Need to know how to present the report.

Every single one of those points are actually what you need to teach in order for them to be able to do the job. Write a training plan for each point and then wrap it up into a bigger bit and voila you know what and how to teach them.

Not everything is that simple. Not every job is a series of tasks to be taught.

So let's apply this at the macro level. The team I run do not have a series of specific tasks I can teach them, they are analysts, so it's more about showing them where all the ingredients are in the kitchen and how to use them so that when the order comes in they can decide right there and then what to use and how.

So I did the above, just on a broader level. I wrote down every sort of thing they would need to know to be successful at the job and then worked out the smaller components that I would need to teach.

In some scenarios the same component came up time and time again. For example 'Need to know SQL', which then enabled me to break that down into the exact level of SQL needed to satisfy the the sort of things they would be doing in the role.

When you break things down like this, it helps you understand how you will teach someone, it also helps you identify the things you now take for granted that people often forget to teach.

It also provides structure and order so you can identify what to teach before other things, and over time this will enable you to understand their progress.

You'll be able to say with confidence that they are X% through the induction. And after a few runs of it you'll know for sure that it takes about X amount of weeks to get up to par.

Identify their ladder and count the steps.
Your induction will fail or operate at a lower efficiency if you don't know how they learn.
I call this the ladder. Everyone has their own kind of ladder.
Now the reason I use the ladder as a metaphor is because the key to explaining something to someone is to understand where they are now and figuring out how to get them to where you need them to be. It's all about steps. How many steps do they need to climb on the ladder.

For example, if you had to show someone how to use an app on an iPad, to someone who is familiar with what an iPad is and what it can do, you would probably not need to teach them much, they would only have to move one or two steps on their ladder.

However if you had to teach someone who had never used an iPad or smart phone / tablet ever then the amount of steps you would need to move them would be quite a lot as you would have to teach them some pretty fundamental stuff just to get them to the point where you could teach them how to use your app.

It's super important to be able to cater your induction to their learning style and to be able to quickly identify where they are on their ladder. If your induction starts several steps above where they are now, that's going to fail fast.

Don't trust, test.
This one may seem counter intuitive but I don't trust that they know something.

Even if it was very clear on their CV that they've been doing it for years it pays to make sure.

What you believe an ability encompasses and what they believe could be two different things.

For example 'I can build websites' could mean that they set up the whole shibang end to end with lean bootstrap and Javascript. Or it could mean I've set up wordpress sites and I know what HTML code to change that will customize it how you want. Now those are very polar opposite examples,but there are plenty of shades of grey in between. You may be great as JS, but your CSS might be rusty and you have no idea what a CNAME is.

Take the time to verify that what you think they already know is true, make sure your assumptions line up with there actual ability. The cost of assuming something can be quite damaging.

Teach them how to problem solve.
When so much of a job these days is problem solving, prescribing how they do something is only half of the experience. Show them how you solve problems and it will go a long way. Most people have about a handful of websites they have saved to their browser that they refer to when trying to figure stuff out, share your links and explain your thought processes.

I’ve made a “What to do when stuck” guide and its a detailed list of places to go to solve certain problems that are both inside and out of our network.

Set the scene, get in front of culture.
Being a new role comes with a lot of unknowns, primarily what is expected of you. Now you could leave your new employee in the dark letting them, through a process of trial and error, figure out where they stand in terms of working late, how quickly they work, working from home, etc. Or you could just tell them.

The first thing I do with new staff is take them out for coffee and discuss flexible working, the fact that they shouldn’t exceed their forty hours, what I expect from them culturally.

The bad things, like burnout, too often come from unrealistic expectations that employees set for themselves in lieu of concrete expectations from management. It is the absence of clear cultural and workplace guidelines that set people up to fail. Get in front of it, verbally set expectations and continue to throughout their employment.

Repeat what you teach
The last thing to cover is ‘teach everything thrice.’ No one gets anything first time and what often happens is they understand things in three stages.

  1. At first they understand the general context of what is being taught.
  2. The second stage comes from when they actually get some hands on or sees it in action.
  3. The third stage of understanding is when they see how it fits into the bigger picture as part of the wider system, which only starts to happen once they have got to the second stage on other items.

Either get fancy and build an induction plan that touches on every point three times or as the weeks go on make a note to re-touch on those points, one a day maybe. Some points, especially ones core to the job will naturally happen several times by themselves, so make sure its the stuff that isn’t happening naturally that you focus on.

Discussion (0)