Menu

Technical Training Tips and Thoughts

Last week, we discussed what to do when you make a mistake. Today, I’d like to discuss what not to do when you make a mistake:

I took a calculus course in college with a very good professor. My roommate took the same course with another instructor, who apparently would never admit a mistake. My roomie was looking over his class notes of a long mathematical proof or derivation, uttering “what the @#$%! is this mess!” I couldn’t make heads or tails of it either, and we had already covered the topic my class. It took us a while to realize what was going on: the instructor performed a correct but irrelevant operation in the derivation partway through the process, which led to several other incorrect steps. Apparently the instructor realized (but would not admit) his mistake, so the next several steps simply undid the previous steps! My roommate and I realized that we could simply eliminate the middle third and have a good mathematical proof.

Don’t do that to students — rather, just admit your mistake, back up (and make sure your class know that’s what’s going on), and try again.

In our next blog post, I’ll tell you about one of the best examples I’ve seen of how you should act when you make a mistake.

Some time ago, I read an amusing article from a travel magazine on “What To Do When You Have a Car Accident in Italy.” Not if, but when — the author guaranteed it would happen.

I can similarly guarantee you will make a mistake when leading a training class. Believe me, I know this from bitter experience. I’ve misspoken, I’ve pulled down the wrong menu, I’ve used the wrong sample file, I’ve missed a key step in the exercise, and I’ve written some amazingly bad code in front of the class.

When these things happen, here’s what I recommend you do:

1. Stop. Take a moment to assess the situation. Training isn’t radio or television: a moment of “dead air” isn’t the end of the world. The silence may feel a little uncomfortable, but your class probably already knows something is wrong.

2. Apologize. In some ways, it’s not really necessary to apologize for being human, but we want the class to know that you know something is wrong. I usually say something like “Arggh! I’m sorry, I really made hash of this example. Let me try that again.”

3. Back up and start over. See what I did in the last paragraph? I essentially invited the class to unlearn my incorrect work, thereby letting them learn the correct procedure. “Pull down this menu, and use this command…”

4. Let it go and move on. That wasn’t your first mistake, it won’t be your last mistake, you’re a good instructor, your mother still loves you. Your students aren’t looking for perfection from you; they’re looking for solutions to business or technical problems. It may have taken two tries, but you gave them what they needed. You succeeded.

In future blog posts, I’ll give you examples of how to do it and how not to do it, both example from real life. Don’t worry, I won’t name names.

A good, quick rule of thumb in a technical training class is that your participants should be working on their first hand-on exercise within fifteen minutes of the start of the class. This will give them the “buy in” they need to feel like they are learning something.

That’s a tall order: you probably have to welcome the participants, describe the class, distribute the materials, tell them when lunch hour is, explain the location of coffeepot and restrooms, and have everyone introduce themselves, all in fifteen minutes. (At a chemical plant where I periodically teach, I am required to read aloud a lengthy list of safety instructions, too.) Try to get all of that out of the way quickly.

There’s an added bonus to quick introductions: you’re setting expectations for a rapid pace for the class, so you can cover material quickly if necessary, instead of cramming in the last two chapters at 4:45. (You can always slow a class down if needed; it’s difficult to speed one up.)

Some topics require some theory at the beginning, which can lead to a lengthy “chalk talk.” Try to find a way to do a hands-on exercise first, then cover the theory: “Here’s why we did what we did.” See if that improves class participation and satisfaction.

What is the ultimate goal of successful technical training? In a word, achievement. Everything else is secondary.

My first career was in academia, where book-learned knowledge was the key to success. When I moved on to industry, I quickly found out that the boss doesn’t care what you know, the boss cares what you get done. (Fortunately, they were looking for an ex-teacher for the job, so I was able to get quite a bit done.)

Success in technical training, therefore, means that learners must demonstrate achievement — that they can calibrate the device, that they can write the Excel formula, that they can use an array in programming. Then they can get done what the boss wants done.