Have you ever helped a teenager learn how to drive a car? If you have, say no more. I feel your pain.

It takes a lot more than just explaining to them how the car works. You would never just give them instructions and then hand over the keys. That’s true for several reasons: Driving a car is complicated, the stakes are high, and they are certain that they know everything.

In some ways, the same can be said for implementing new technology across an entire company of employees who aren’t familiar with it. I started my career in human resources. I had little interest in the innerworkings of technology. As a result, I distinctly remember what it’s like to have folks use a plethora of technical jargon to teach me something they claim will make my life easier, only to find the opposite to be true.

At times, technical teams roll out software from a new project and say, “Go and make great use of the new system – and by the way, be a champion for this new initiative and run with it,” often without enough training. If that champion can’t, in turn, train a colleague, then they were not set up for success.

Designing, creating and configuring a new system or software is only going to be useful if the people it’s meant for are positioned to use it where value realization is almost instantaneous. Here are four steps I like to think about when training users on a new system or software.

  1. Demonstrating

The first step is demonstrating what this software can do. It doesn’t require much from the trainee, just listening and following along.

In this step, they are not expected to have a strong knowledge of the how or the why. It’s me demonstrating to them what the best version of navigating and running through the business processes should look like. That’s the easy part.

  1. Coaching

This is when we get a little more hands-on. I like to say this is when we go over the why of it all. I’m not just showing them what it can do, I’m also going over the details on how it all happens. While this coaching step is a little daunting, it’s extremely important in the learning process.

So often, the technology team will provide the trainee with a user guide. It’s typically a glorified list, like “Six Steps To Perform This Function Within The System,” but they won’t provide the why behind any given step or process.

The why is the thing that enables them to troubleshoot in the future. The why is significant because if they run into an issue or one of the steps just doesn’t go exactly how it was talked about during training, understanding the why will provide clarity in what could have been a paralyzing situation.

There’s logic behind it all. Don’t be afraid to share it with them.

  1. Facilitating

At this point, I allow the trainee to be my co-pilot. They come alongside me without fully taking the reins. Based on everything they just saw and heard, can they help me go step by step?

Maybe they’re explaining the why back to me, or clicking through all the steps with me keeping them on the right track, or simply answering questions. The key point in this step is that we’re working together, and I’m encouraging them along the way.

  1. Handing Over The Wheel

Handing over the wheel doesn’t mean making a clean break. You must remain available, and if possible, be right there alongside the trainee.

Most importantly, this is where I allow them to make adjustments. Let them discover and embrace the fact that there isn’t only one way to do things. There will be variations of what I show them during the demonstrating stage.

Encourage them to explore. If what they try works, they can make that adjustment. If the trainee does something in a way that takes a little longer but it’s easier for them to remember it, then allow them to learn in their own way. Just continue to encourage and motivate.

In this way, it becomes a learning opportunity for us both. In my day-to-day, doing the back-end work where functions can be repetitive, it’s not uncommon to fall into tunnel vision, so having others step through the same processes from a different approach is enlightening.

Dunbarger is PPAI’s business systems analyst.