Never a dull moment:
Technical Enablement and Course Development
offer challenges but provide rewards
by John Crawford
As a technical enablement specialist for IBM, my duties and those of my colleagues are many and varied. When I think about the things I do in a given week, thoughts quickly turn to a juggler or someone holding a rather tall stack of hats of various shapes and sizes.
That is one aspect of the job that makes it extremely enjoyable. Historically, in my life prior to working for IBM, somewhere between two and one half and three years, I was peering across the fence to see “what’s next” to borrow a phrase from the fictitious president Jeb Bartlett from the now-defunct West Wing television drama of a few years back.
As technical enablement specialists, my co-workers, some of whom you know from their blog posts here, and I, are charged with ensuring that IBM employees, as well as IBM customers who focus on Tivoli Cloud products and have a need to know technical details have the most up-to-date material at their disposal through white papers, instructor-led classes or self-paced virtual classes. This is a challenge for all of us who do what I do and again—one of the things that makes it a great job for someone like me.
The typical scenario for developing technical material as we do goes something like this:
Product management and development make us aware of new offerings or updated offerings. We are not only responsible for the new stuff, but we have to keep our materials related to the existing products current with the features and functions of new releases. So we may be working on TivSam and ISDM on one hand and SmartCloud Provisioning on the other hand.
Generally, one enablement specialist is named as a product “lead.” That person will have responsibility for managing the project and keeping everyone moving forward during the learning, writing, testing, re-writing, and re-testing, of the classroom slides and lab exercises. The lead is also generally responsible for one or more units of the final product and a whole bunch of behind-the-scenes procedural stuff that would bore you to tears.
We work with development and are given access to early releases of the code which change on a daily basis. In some cases, development teams are working on different aspects and when they integrate it all, new functionality may be there, but it may have disabled something else that used to work. So we write up what we can and wait. We poke at it, figure out what it is supposed to do and document how it does it—hoping there is little change when we receive beta, then the generally available (GA) code.
We also work closely with development and receive formal training on the products from the people who wrote the code. But if you think about it, they’re busy finishing the code. They have competing priorities just as we do. We have a deadline to produce our courseware. They don’t have time to stop and teach us any more than we have time to sit for 3 days while they teach us. But it’s something we both have to do. Getting everyone together to catch their breath and just talk to each other is a job in itself, but it happens.
So, let’s go back to the pile of hats or the imaginary spinning plates. The myriad skills we as educators or educational developers require include:
Above average writing skills
The ability (and desire) to poke at a piece of software to figure out how it works
Intermediate to deep troubleshooting skills
The ability to imagine courseware end-to-end
The ability to explain technical material in a way that it is easy to understand
Enough experience to create real-life scenarios for use in exercises.
Knowledge of PowerPoint to create slide decks for use in front of a class
Knowledge of Adobe FrameMaker to create training and exercise guides that includes doing things in Adobe Acrobat I didn’t even know were possible.
Knowledge of Camtasia to record the video and audio for class exercises
Self sufficiency to be able to ferret out information from a repository that contains a process for every detail of course development
You learn quickly that if you ask a question, the answer is going to be a link to a wiki page. And if it’s not already a wiki page, it probably will be next week, just because you asked and it wasn’t there.
We all work with amazing people. The knowledge in technical enablement constantly astounds me. Everybody is heads down, churning stuff out and following processes to ensure, in most cases, that we work smart and that we all do things the same way so our end product is consistent—and accurate. With five or six people all creating modules for the same end product, we all have to be on the same stylistic page.
It starts out kind of informally….notes on the back of a napkin. That turns into a deck of 50 slides with professionally produced graphics. Then the slides and the speaker notes from the slides become a FrameMaker Student Guide that goes to professional editors who read every word, check formatting, check spelling and make FrameMaker stand on its head and sing Yankee Doodle Dandy before they send it back to you. The editors are amazing and somehow always maintain a professional and good natured attitude.
We review the changes and accept or reject them (mostly accept, unless there is a technical miscommunication) Then we present our materials to the rest of the team. This is generally used as a train-the-trainer session but is also another editing round where we all make suggestions for changes to the materials that make them clearer. And we edit those changes in. Changing the slides, changing the speaker’s notes, and editing the FrameMaker documents getting things ready to go to the production team who use another set of tools to create the presentations and in some cases the professional recordings for the online classes.
As I have been doing some of the recording recently, in
almost every unit I thought I had perfect, when it came to the point of
following the instructions I had written and recording the actions on the
screen, I found things that needed to be changed once again in the FrameMaker
document. Some of it was edited for clarity but in some cases, things were just
flat wrong. Perhaps I left out the description of a screen that came up, so a
user would have no idea what to do next. Perhaps I made an invalid assumption.
Our train the trainer sessions is “take no prisoners” and I wouldn’t have it
any other way. The suggestions we receive are generally spot on from people who
have been doing this a long time.
Every phase of the process is an editing phase. If this stuff were on paper, it would be smudged and scratched through and tattered on the edges from the number of times it has been handled and changed. But through the magic of computers, when we Srint it, it looks as though it has always been correct. Wow, I love computers.
So, the next time you look at a technical class, maybe you’ll look at it differently. I know I do. The process takes months to complete. And before we ever get it out, there is talk of the next release, and fixes, and change in functionality or maybe a change in the way a screen is laid out. Never a dull moment. And it’s great!