Training that survives Monday morning
The team spent a week in a classroom learning the new platform. The slides were thorough and the instructor knew the product. The following Monday a routing change was needed, and the engineer assigned to it opened a ticket with the vendor.
Nothing was wrong with the course as a description of the product. It was the wrong kind of course for people who had to operate it. Knowing what a feature does and being able to change it safely at two in the afternoon are different skills, and only one of them is learned by listening.
Teach tasks, not features
A feature-based outline follows the product's menus: system settings, devices, routing, reporting. A task-based outline follows the job: bring a new site online, find out why a call failed, change what happens on a holiday, recover when a server is lost. The same material is covered. The difference is that every topic ends with something the engineer can now do.
Make them type
An engineer who watches a demonstration remembers that it looked easy. An engineer who performs the task in a lab remembers the three places it went wrong. Every topic should have a lab, each attendee should complete it personally, and the lab should include a fault to find, because faults are what the job consists of.
Use their network
Generic examples make people translate: the course says "Site A" and the engineer has to work out what that means at home. A course built on the organization's own design, with its site names, its numbering and its carrier, removes that step. It also surfaces questions about the real design while there is still time to change it.
Leave something behind
Slides are a record of what was said. A runbook is a record of how to do the work. The most useful thing a course produces is a set of short procedures the engineers wrote themselves during the labs, in their own words, for their own environment.
Time it to the project
Training delivered three months before a system goes live is forgotten by go-live. Training delivered the week after is too late. The most effective pattern is short sessions spread across the project: fundamentals early, operations just before go-live, troubleshooting just after, when the team has real questions.
Questions to ask of any course
- What will each attendee be able to do afterward that they cannot do now?
- How much of the time is spent in labs?
- Is the lab environment like ours?
- What do we keep when the course ends?
Judge a course by what the team does the following Monday.