Networking

How to "fix" bad training

Sometimes trainers inherit the legacy of a bad predecessor: poorly trained or ill-informed students. Brush up your diplomacy skills and learn when to pull rank in this article about damage control.


It’s always a bonus when a student starts a class with some experience, but as the saying goes, “A little knowledge can be a dangerous thing.” This can be even more accurate when the knowledge concerns computers.

It is a trainer’s job to make sure that a student knows how to use software and hardware correctly—and this involves reeducation from time to time. A student often will get bad information from a coworker or self-proclaimed “expert.” These ideas are sometimes the hardest to banish from a student’s mind.

“Well, my neighbor Betty has been working on computers since they first came out, and she says the only way the bold font sticks is if you make the type bold, and then turn the computer off, and unplug it, and turn it back on.”

Sometimes the worst situation is when another trainer has given a student bad information for whatever reason. You don’t want to make a colleague look bad, but you have to get the student straightened out. Here are a few suggestions about how to go about cleaning up someone else’s mess.

Six steps for repairing the damage
First, try diplomacy. Practice saying, “Well, in my experience . . . “ or “Well, I’ve never had any success with that method,” or “Well, maybe that was the best way to do it several versions ago, but with this version . . . “

Second, try both methods with the student. Sit down with the student and have her perform the task your way and her way. Maybe you’ve seen this particular shortcut or function crash a computer every time you try it, but that doesn’t change the fact that the user has had only good luck with it. If you’re extremely lucky, the student’s computer will crash and burn when she tries it during a training class, but you’re not always that lucky.

Third, go into more detail. Explain the advantages and disadvantages of each one, and push the student in the direction of your method. Sometimes one method saves time, is more efficient, or better suits your particular situation, whether it’s your network, your protocols, or the skill level of your users. If you share this information with the student, this can help to persuade him or her to use your method. In general, most users are not interested in this much background, but having the information ready to distribute can come in handy from time to time.

Fourth, know your history. It helps if you have previous experience on your side for back up. Once I was in a meeting where we were discussing domains for a fairly large company. The firm had seven main departments, three of which were already on one domain. One department was still using work groups and contained one member who wanted to keep it that way. He wanted his own separate domain that he could control. The remaining departments didn’t care one way or the other.

Corporate’s recommendation was one domain, and seven other subsidiaries had tried multiple domains, only to abandon that setup for one domain. Seven attempts and seven failures were enough for me (and almost everyone else) to sign on to the one domain idea. But not the work group guy. His own ideas had to win out, reality be damned. This is the user who says, “It’s always worked for me.”

There are always special cases that you will never be able to convince, but 99 percent of the people will at least grudgingly agree with the “it’s worked this way for everyone else” argument.

Fifth, be firm. “I’ve worked with this software for years, and this is the best way. I appreciate your input, but this is the method I want you to use.” If this isn’t enough to win the debate, you may have to move on to the next tactic.

Sixth, pull rank. “We decided that this is the standard method, and that’s what everyone is to do. If we find you have changed the setup or deviated from this standard, your supervisor will be notified, and this problem will be noted in your personnel file.”

Obviously, this last method won’t earn you any bonus points with the individual in question, so this should be used as a last resort. You shouldn’t hesitate to do this, however, if the security or integrity of your network is threatened by an individual’s actions.

An ongoing process
Of course, this entire discussion is based on a trainer staying current and knowing what he or she is doing. You have to be fairly certain that you are, in fact, right before trying to persuade a student to agree with you. Learning is an ongoing process, and trainers more than most other IT people have to participate in this process on a regular basis.

Because, as Thomas Henry Huxley said,

“If a little knowledge is dangerous, where is the man who has so much as to be out of danger?”
What happens when you meet up with a student who is using inefficient or outdated methods? What do you do when a colleague has misinformed a student? Send us an e-mail with your suggestions about fixing bad training.

Editor's Picks

Free Newsletters, In your Inbox