I work in IT at a semi-lower level. Basically an IT Support Technician who dabbles in Jr. System Administrator level tasks and (like all small businesses) wear a lot of hats by doing things that go outside of the scope of IT, to bring value to the business. One of the best things someone like me can do with our spare time is reduce the amount of "tickets" we get through proactive continuous improvements. I think many people miss an important part of the 5th step in the CompTIA Six Step Troubleshooting Process:

  1. Identify the problem.
  2. Establish a theory of probable cause.
  3. Test the theory to determine cause.
  4. Establish a plan of action to resolve the problem and implement the solution.
  5. Verify full system functionality and if applicable implement preventative measures.
  6. Document findings, actions, and outcomes.

This is probably the most important portion since this will LEAN your IT Department over time. When I first signed on at this company there were many recurring issues that kept me busy right off the bat. But over time, not only have I found long-term solutions to those problems, but I have used my previous experience as a Restaurant Manager to train my coworkers in stronger basic computer skills and their own initial troubleshooting steps. This was so I could free up more time myself for long-term projects, research and learning, and this also gives me more time to analyze recurrent problems for a solution.

It's surprisingly simple to train people to do some minor troubleshooting on their part which often will resolve the issue they are having. It's also important to let them know that if they see a recurring problem to notify you, be a shoulder to rely on. Customer service skills are one of the most important parts of lower-level IT support, as you need to be trusted, confided in, and the kind of person that they don't feel judged by. Nobody likes this guy:

https://www.youtube.com/watch?v=dNB_RjpWnsI

So don't be THAT guy. :P

Well, looking at the title this might be a bit confusing. Why do I have to teach people how to learn? Shouldn't they already know how to do that?!

Yes, and they do. But they don't often have the confidence to learn about things that they are fearful of breaking. Even just rebooting a PC makes many users nervous, so much that they don't know what you mean by the term. Everyone exists in a sphere of their own contextual uses of language (thanks Wittgenstein) so you have to realize that what simply means "reboot" to you, may not mean the same thing to everyone else. I love philosophy on the side, and Wittgenstein's quote in his Tractatus Logico-Philosophicus is very important with regards to the fundamental absurdity of two people talking to each other who aren't using the same terms the same way:

Whereof one cannot speak, thereof one must be silent.

This is probably one of the more misunderstood and misused quotes, it's not about knowledge. It's about understanding of what the other person is saying, despite using the same words. I can't use your term "reboot" because I think "reboot" means something else, therefore I shouldn't arrogantly dictate to the other person anything hinging upon that term, and walk away thinking I was right all along.

Now that might have gone off the rails a bit, but the point is, start humble and stay humble. We in IT are pretty dang smart and "self-made" for the most part, so it's hard not to come out thinking your farts smell like daisies. But you have to make an active effort to try. Jane in Accounting may seem like someone incapable of doing the most simple computer-user tasks, but she also understands balancing the books, financial regulations, and is very good at being professional regarding confidentiality of our financial transactions. It's a trade-off, are you doing any of that? Nope. If you say something naive about accounting to her, does she scoff and laugh, guffaw, and make you feel stupid for saying something about something you don't know? Nope. So you shouldn't either.

Now with all that beat-down of humbling out of the way, onto the good stuff, me teaching you (or you learning) how to teach people to learn:

1. Don't show them, have them do.

Kind yoda-like, but who cares :P.

One of the most important things in training is to have the person who you are training DO something. So instead of me sitting down at the user's computer and clicking start, the power icon, and restart... I ask them to press the windows key on their keyboard. This often generates what I call a "training opportunity". They often do not know what the "windows key" is, and I get happy and excited to train someone about this little fact. I show it to them, show them how it has a windows icon, etc... I then have them press that key.

Many people training users will "show" or ask them to "click the windows icon on the desktop". This is all wrong from the start. You should make people confident in using hotkeys, shortcuts, and all that as a default. Then I tell them to click the button on the screen that looks like a power symbol. This has them scratching their heads, but that is a GOOD thing. You want people to be actively engaged in learning, not just instantly find the solution to the problem being led by their nose! You want someone to feel CONFIDENT using a computer, remember? That will free up some of your own time, which is the goal.

Then I ask them to restart, as a little drop down opens up that ask them what they want to do. I will sometimes say "restarting/rebooting is like starting over fresh. When you came in today, you started the computer, but sometimes you have to restart because things get messed up over the course of a computer being turned on. It's not a big deal, all computers need a restart/reboot once in a while." I will, if they joke about IT guys asking people to restart, laugh with them and go "yeah, it's a stereotype that makes us look lazy, but what's funny is it actually works and has good reasons behind it" in a friendly way, not in a correcting way.

If it reboots and the problem is gone, I often thank the person for letting me know there is an issue. This is key. When people thank you, you should thank them too for the opportunity to do your job, and for reporting an issue to you. If you have everyone comfortable with letting you know there is a problem, you are collecting better data for your larger understanding. This is one of the many reasons why customer service skills are essential.

2. Follow-up

Following up is absolutely essential to training, as my intensive 6 month (should have been 4 month, I'm a slow learner) manager training program at the restaurant showed me. Following up is not just to make sure they know what they are doing. It's to show you care (or "give a shit" as we put it in the restaurant). That will allow people to know you are a shoulder to rely on, and will give you better data in turn. This is a very grand systemic view that all IT pros should be taking in their approach to any problem. It's a long-term strategy.

A follow-up in IT is a little different than when you manage employees. Typically as a manager you pop-quiz people or ask them to show you how they do something, a couple hours after you had them learn the task they are supposed to do. See if they retained it. In IT, using the reboot situation above, I want to see if someone has rebooted their PC when they saw a similar problem. This not only gives me data as to the frequency of the problem (which can generate an instance in which preventative measures would be valuable), it checks to see if they retained the knowledge. Next time you have to help them, you can have them do the same task, if they have not retained the knowledge. 99% of the time, my users in this instance have been able to retain the simple tasks I have had them do.

In this example of the reboot, I will ask them as a follow-up maybe a week later, "Hey x, have you had any of the same problems you had before with your PC? Just checking to see if everything is working well." and often they will say "I had another day where things were feeling slow, and I did what you had me do last time and it worked! Thanks for showing me that!". The feeling of gratitude from the user for having them fix it themselves is because they don't have to unreliably wait for you to answer their question, they also feel good learning a new thing about the tools they are working with.

How could you work in a pizza restaurant if you don't know what a "peel" is? A peel is what we called the tool to remove the pizza from an oven, a huge spatula. How confident would you be if you defaulted to "pizza-remover-thingy" as the term? That wouldn't feel great to work at a place like that. That would be an example of a lack of training. Likewise, a user who uses a PC will feel better if they can say, "I'll first reboot to fix most problems, and then call IT" instead of, "things are messed up and I don't know what's happening, gotta call IT and wait for them to get here". Empowering a user with confidence in understanding and using the tool that they use to do 99% of their job has to be intuitive to us in IT to do our job.

3. Gradually give more complexity

When you realize that the user reliably understands reboot, next time they have an issue, you should show them another trick or two. I often use WIN+D as an example. If I have to check out their PC again and see what is going wrong, I will use WIN+D to default to the desktop, and they will either exclaim, "Woah! How did you do that?!" or it gives me the opportunity to really quickly show them that windows has hotkeys. Just the realization that they can use hotkeys to do things more quickly, gets the cogs moving from that previous confidence building.

Now if the user feels more confident in using hotkeys, sweet. This will generate value for the business. This is less about time-saving as it is in using your role as an IT Support-type person in generating dramatically more value for the business. This creates value in reductions of wasted time. If a user knows how to minimize everything with one hotkey, they can probably do things a little bit more quickly each day, which can result in a years worth of a few hours in savings. If you teach this to one user and they get paid 20 dollars an hour, it could be worth a few hundred to the business for time you were using anyways to work on their computer with them watching, and talking while you work (it's obvious I do very little remote work, I prefer in-person IT in my career, as I'm a people-person). If you teach this to every user that can save thousands upon thousands of dollars. Continuous improvement is vital to a businesses long-term success. Why should IT not participate like other employees do in improving the business in every area that is relevant to your department?

After showing them hotkeys, I give them some breathing room for a few weeks. They got a job to do, and I'm not their manager, and I'm not really their teacher. Stay out of the way for the most part and let them do their job. However, next time they call me up about something, I may ask them to use the hotkey to show their desktop (follow-up) so I can start working on it without seeing all the stuff they have open, and if they forget, I say "windows plus D". Usually "OH YEAH" comes up, and they do it. This solidifies the technique in their brain, because now they have DONE it and been followed-up on.

Another thing I try to ask my users is to save their work and close down everything (I need to be more diligent in consistently doing this come to think of it, everyone has something to improve). I ask them to do it, I don't like doing it for them and asking them what I should and shouldn't do as I work on their PC. This can lead to them doing it proactively later on, which will save me time. It will also make a connection in their brain between the vital nature of saving mission critical work before making any change to a computer, or even walking away from their desk. This is another entry into the next piece of teaching people how to learn:

4. Helping them internalize reasons for best practices

Often, when I'm working on people's PC's while they are there, I use analogies in my speech to explain basic concepts, so they don't feel like what I'm doing to their PC is mysterious, so they feel less like it was their fault, and so they feel comfortable with me fixing their problem. This builds up "necessary reasons" for why things ought to be thought of a certain way. Let me do another pizza analogy, which I love doing... Which would help you learn and understand your job better:

  1. "You spread the sauce evenly on the dough because that's correct."
  2. "You spread the sauce evenly because each time a customer takes a bite, they get a consistent amount of sauce, and they enjoy the pizza more overall."

The second one, obviously. And if you know the second one's reasoning inherent to it, you will internalize the correct focus for your approach to spreading pizza sauce, you will internalize an empathy to the customer.

To go back to rebooting a PC, helping a user understand that the longer a Windows PC (and yes I'm singling out Windows for the most part, since it's the worst offender of this) is on, it kind of gets "tired". More issues can pop up. So if they want their PC on it's best performance when they come into work, give it a reboot, OR reboot the PC when they leave everyday. That way it's ready to go. This is the time saving component of the reboot example AGAIN! If a user reboots when they leave every day, guess what happens? You will almost never get a call that the user has a problem that a reboot will solve! Additionally, if they experience a problem that will be solved by a reboot, they will reboot first before calling you, and probably spend less time themselves waiting on you, and spend less of your time as well. Win-Win-Win!!!

This is important. The reason they would think of rebooting in the first place, is because they internalized the "my PC is getting tired and has to take a quick break every now and then, just like I do, or else it doesn't work as good" explanation. If they internalize this, they will "spread the sauce evenly to keep the customer happy". This is CRUCIAL because you are establishing a salient link between the observation and the reaction, you are shifting their reaction to an observation from "call IT, I dunno what's wrong" to "maybe I'll try this first since it will be better for me and I won't have to bug IT". If they tell you they rebooted their PC in an excited way because they solved their own problem, do a sincere "that's awesome!" and ask them about the issue they were experiencing as well to see if it is the kind of thing you can be proactive about and improve their situation. Again, this is a potential continuous improvement opportunity.

And so on...

In Conclusion

Basically, these are the essential steps and the general philosophy for all training I did at the pizza place where I as an Assistant Manager of 50+ employees (we were a little more than a shift leader, we took on some store manager responsibilities in that role for sure), and I have translated those skills into the workplace in my current non-managerial role. I hope this article is beneficial to you, even if you aren't in IT. Everyone at a workplace is somewhat responsible for the performance of their coworkers. We can all bring each other up.