Stuff – Not Fluff
In conducting my needs assessment for Networks University, one theme I heard again and again from the people who would attend is that they needed “stuff, not fluff.” For the most part, the attendees were technical people and they wanted to talk with technical people – they were wary that the program was being sponsored by the marketing group and, repeatedly, they said they didn’t want to “waste their time listening to marketing fluff.” In fact, the phrase “Stuff, not fluff” became a mantra for Networks U.
As the technologies for local area networks rapidly evolved, we were challenged in how to get the best and latest technical information put together for the program. We were talking about new technologies, a whole new set of products, new services unlike anything the company had provided in its history. When I had tried to impress these points on the company’s educational services organization, the response I got was “That’s not how we do things.”
Educational Services had built its own model for how to train employees. For each new computer model (which took 3 to 5 years to develop), it created a one-week comprehensive program that covered everything from pre-sales to installation to trouble-shooting. That program took 12 to 18 months to develop and had development costs of $100,000 to $150,000. The new reality for the Networks and Communications (NaC) group was that the development cycle for new products would be well under a year and sometimes as short as a few months. The Educational Services model was clearly not going to work for this business unit.
So, if Educational Services couldn’t help us develop and deliver the content for Networks University, who could? The solution was to get the subject-matter experts to develop and deliver the training. With the support of the entire NaC business unit, we got whoever we needed – product managers, marketing managers, engineers, back-up support groups, college professors, consultant – whoever we needed, we got.
This was not a slam-dunk strategy from the beginning. When I approached several engineers as we were planning the first session, I got remarks like, “You want us to talk with sales people (said with a sneer). What possible value is there for us to talk with sales people?” I called in some favors that were owed me and got a few engineers to participate in the first Networks University session. At the end of the session, I met with the engineers. “It was amazing,” they told me. “Did you know that these sales people actually talk with customers and know what customers like and don’t like about our products? That they talk with customers about what they would like to see us develop in the future? We never thought we could learn anything from sales people, but we were wrong.” From that point on, we never had problems in getting engineers and other technical people to participate in Networks U. (It also didn’t hurt that we fed them well.)
Now, you have to realize that engineers, product managers, and other technical personnel do not always make the best trainers. First, they haven’t been trained to develop or deliver training. Second, egos sometimes get in the way (“People will see how brilliant I am and once they see that I can answer all of their technical questions, they won’t care if I’m a great speaker or not”). How to overcome these and other obstacles? Here are a few ideas (Note: a more comprehensive approach can be found in my article on using subject matter experts that you can find on my Articles page (www.tobincls.com/articles).
- Provide training on how to put together a presentation
- Encourage them to take a presentation skills course
- Assign an instructional designer to work with them to help organize their presentation and develop some good visual and job aids
We also emphasized to these technical speakers that they needed to focus on “stuff, not fluff” and that they needed to prepare for their sessions, rather than walking in cold. The most effective strategy we developed was to require presenters to review their content and approach with two volunteers from the target audience. In this way, we ensured that what the audience needed was what was delivered.
Despite all of these warnings and preparations, we were not always successful. Because we were running multiple concurrent sessions throughout the week-long program, the participants quickly learned to “vote with their feet,” i.e., we had a few disastrous sessions which might have started with 100 or more participants, but ended with only a handful of people in the room – the rest had quickly lost interest and moved to other sessions. It didn’t take many of these occurrences to get the message across.
These many sessions within a single Network University program were the core of the program. But there was much more to Networks U that these formal sessions, and I’ll cover some of those aspects of the program in subsequent blog entries.