The Reluctant Trainer

This is my last article on the topic of the reluctant trainer. I hadn't been doing much training recently and was feeling that my supply of ideas was getting a little stale. Then I was handed a part-time special project that turned into the reluctant training opportunity of a lifetime.

The Product Operations group in my company (which produces software products) had a number of new processes that they wanted to put into place, and they wanted to formalize that process by developing internal training, which would have the following goals:

• Instruct current employees in new procedures
• Repeat the courses periodically to orient new employees
• Integrate various department within Product Operations by sharing knowledge

My role was to work with individuals in Product Operations to help them design and develop courses that were planned for the curriculum. It was more of a facilitator/mentor role rather than either a manager or a course developer role. It was the opportunity of a lifetime.

The Up Side

This program had many of the factors that would predict a successful outcome. It had strong support from the head of Product Operations. There was a team to implement it that consisted of a training director, who shared my views of reluctant training, plus the person in charge of the process improvement effort, plus the head of program management. Developing the courses, or at least delivering proposals for how the process would be implemented, was part of the MBOs of the technical people who would be developing the courses.

The Down Side

What we did not have going for us was resources. In the current high-tech environment, software development schedules are so tight that adding an unplanned project that takes away resources can wreak havoc on production schedules. Nobody doubts that process improvement will pay off down the road, but we also realize that our first priority is to meet our deadlines. This situation is nowhere near unique to my company.

Nonetheless, it was a warning that training could have a doubly negative outcome: people didn't have time to spend sitting in the classroom, and they could not spend much time implementing what they had learned. Moreover, since the people teaching the course were technical people, they would be pulled away from their other job responsibilities to teach the courses whenever required.

All of these positive and negative factors had to go into the mix when deciding whether and how training should be done for each individual proposed course.

Train the Trainer

Since it was my job to help mentor the trainers, and since the trainers were really technical people without a training background, I wanted to lead them through a process in which we focused on how we could successfully implement the new procedures, then decide whether training was necessary at all, and only then decide on the best means of delivering the training. I developed a form that was stored at a web site that technical people who were were thinking of developing courses could fill in before our first meeting. The purpose of the form was to help them start thinking about why they wanted to develop training, what the alternatives might be, and, if they did train, how to design it most effectively. This form is accessible at http://home.earthlink.net/~nancyhild/data/DC_course_planning_form/course_planning_form.htm, and you are free to download and use it for your own purposes.

Successful Avoidance

This experiment is not over. We are only about three months into the effort. In one case, Engineering presented a plan for how they were going to implement a new process and argued that they preferred to incorporate it into their individual mentoring program and follow up with enforcement, rather than pull people into classes. In this case, not training was the best solution, since the goal of changing behavior was being met more effectively by other means. Once Engineering has implemented this plan, we can reconsider how other groups can be made aware of the new process in place.

Successful Training

The following case demonstrates how training can be really successful. Max, one of our architects, was to develop and deliver a course on software internationalization. He filled out the form mentioned above, and we discussed the issues involved based on his answers. It was decided that the training would be necessary, because the material taught was a combination of knowledge and skills, and labs held during the class would be valuable in integrating the two. Based on a number of factors, we decided on the following format:

• There would be a one-hour overview course, followed by two longer courses, each aimed at a different group.
  
  
• The overview course would be a basic PowerPoint presentation and would be considered a prerequisite for both of the other courses.
  
  
• After some piloting, the overview course would be audiotaped, and the audio plus the PowerPoint slides would be available as an internal Webinar, so this overview would be accessible to all new hires and would no longer take up the time of the architect to teach it.
  
  
• A quiz would be developed for the overview course to demonstrate mastery of the material before entry was allowed into the second and third courses. This quiz would be administered and scored using the online course tracking system that the company already uses.
  
  
• The second and third courses would be longer and would involve a combination of PowerPoint presentation and labs.

At the same time, other forces were put in motion to increase the chances of the success of these courses. Max created an easily accessible internationalization resource area on the Product Operations portal, so that participants could easily access information outside of the course. A position of Internationalization Architect was created for Max, helping to formalize the increasing emphasis on internationalization within the company. And Max himself was highly committed to the success of this project. Not only does he believe in the benefits of software internationalization, he could see the payoff that would result from passing on troubleshooting skills through his courses, because he would not be called upon so often to help with basic troubleshooting issues.

The result? So far, two of the three courses have been delivered. Both development and QA engineers have taken one or both of the courses. The second course achieved high ratings for quality and usefulness the very first time it was taught. Internationalization is already being implemented, so participants really saw the relevance of the course material to their daily jobs. Max will deliver the first course one more time to capture the audio portion of the presentation, and it will become a Webinar.

I believe that this is a case where training really has made a difference. The training was well planned based on how the knowledge and skills would be implemented and how it could be most effectively and efficiently delivered. However, it was not the training alone that had the beneficial effect. It was the combination of training, information resources made available on the Product Operations portal, and support from upper management in formalizing the implementation that provided the synergy that will make this effort succeed.

It Pays to Be a Reluctant Trainer