Catalyst 1: Audiovisual Role (Overlooked)
With the instability of contract renewal pending and the lack of housing in the desert, I switched jobs to a non-profit organization, the LDS Church, which had an agile environment and about 600 IT employees and was growing rapidly. They had already been coding an application for about six months and realized that they would need a professional technical writer to explain it to the audience.
It was my first experience in an agile environment. And although there was one other technical writer and a manager at the organization, I was the go-to technical writer in my assigned department.
Not many people had worked with technical writers before in the department, surprisingly. Although the IT organization had been in existence for years, it had only gotten serious about IT for the past two years, and all this time the technical writers were scarce and never centralized. Here I would begin to see my role change from just a writer to something more.
All people expected of me was to create a manual for their product. I was brought into the portfolio manager's office, and he explained the projects I would be working on for the next couple of years. I could very well have continued on in the same role I had previously played -- quietly documenting what I had been asked to document. Creating little reference manuals and online help. Doing no more than fulfill the wishes of the portfolio manager.
Initially I assumed the environment would be the same as before -- with a specific list of the applications I could install, a defined list of help formats I had to produce, a style guide I had to carefully conform to. But I soon realized that none of these restrictions were in place. I could install anything, deliver anything, and do it all according to the styles I wanted.
I remember sitting one day in the portfolio manager's office explaining that I wanted to use a different help authoring tool. He kind of shrugged and said, Why don't you?
I already had the software, I said.
Then why don't you use it? he asked. I kind of paused, like a prisoner just unchained might do with his first step of freedom. I felt liberation inside.
I always felt video was a neglected component in the help authoring deliverables. Very few technical writers actually deliver video with their documentation. Managers don't ask it of them, and if you think about translation, it's easy to dismiss video out of cost alone.
And yet, when I needed to learn a new software tool, I seemed to always turn to video. In our organization, videos were often produced by other the audiovisual department. In fact, the audiovisual department had more than a fifty year legacy in creating multimedia. They had more voiceover experts alone than we had technical writers.
Additionally, I had no e-learning background, no studio or fancy microphone, and no real knowledge of how it was to be done. Still, videos were always something I had wanted to produce at my former company, so I set about making them.
With the first software release, I produced an online help and a printable PDF, as well as several quick reference guides (which actually made the manager so happy he started to cry), but I also produced videos. I made about twenty of them. I hardly knew what I was doing, so they were all caption based rather than voice based. I had to stay up all night to finish them before the deadline to include them in the application release, but I did it.
About a month after the release, the department manager asked if I could actually create some videos. Huh, I thought? Wasn't that what I had already done? What they had in mind, it turns out, was something with voice. I had been doing podcasting, but I never felt I had the voice talent to be the narrator for professional work videos. My voice was too wavy, too amateur.
With the next release, I started to drop the inhibitions about my own voice and recorded a new round of video tutorials with voice. My voice. Not relying on a voiceover talent to create the voice component. It was exhilarating, using my own voice. I suddenly had full control over the entire process. I showed a voice-based video to a colleague and a caption-based video asked him to compare. He said he preferred the voice-based video about 10 times more than the silent video with captions.
Creating and narrating videos added a new dimension to my work. Rather than having another department or e-learning specialist create the videos, I was creating these videos myself. By this time I knew the application so well, I could easily write the video scripts without any review. I created the scripts, I recorded the scripts, I produced the videos, I published the videos. I was running the whole show. I didn't have to hand it off to anyone else. And I realized how much more efficient it was to combine all of these other roles into one.
Feedback from the voice-based videos was as I expected: users liked them. In fact, videos were about the only thing I received feedback on. It was what users said they found helpful. The manuals, the online help -- almost no one gave me feedback about those materials. It was always the videos.
Creating videos was my first step in breaking out of my prescribed role into a new sense of freedom. Other writers have similar stories about their first steps in a new role and the exhilaration that follows. Several years ago Larry Kunz collected some stories of writers who also stepped into non-traditional roles. I want to share a few of their stories here.
Diane Feldman (North Carolina) explains how she stepped into a design role:
As you know, tech writers often complain that their jobs are made difficult by software interfaces that are poorly designed and that they wish they could have more input into the design process. One year I attended a session at the annual conference that focused on ways for tech writers to get involved in design. I included a description of this session in the trip report that I wrote up when I came back to the office. Trip reports were posted to the company intranet, where the Engineering Manager for a new product line happened to read it. The short version of the story is that this trip report led to the Pubs team being entirely responsible for organizing the interdisciplinary teams that would design the interfaces for the new product line.
In this example, Feimin Lorente (Ontario) explains how he stepped into a programming role:
I like programming as a hobby (but I'm definitely not a professional; my degree is in English), so I tend to apply it to documentation development whenever I can automate something. About 15 years ago, I wrote a program to pull the error messages out of the programming code, present an interface to the programmers so they could document the message, stored all the information in a database, then spit out a manual in FrameMaker by tagging the fields with MIF. About 3 years ago, I wrote a program in VBA to find the abbreviations in a Word document, linked them to a database so the user could choose the right expansion (or enter a new one), then generated the list in another Word document.
In another example, Wendy Cunningham (Pennysylvania) explains how she stepped into a marketing role:
I was hired as a technical writer for a small software development group. They had a team of programmers and technical support staff, but no marketing department. They hired a consultant for any marketing materials they couldn't handle on their own…Being someone who quickly gets bored with the "same old" routine, I kept my eyes open for an opportunity to spread my wings. My chance came prior to an annual software industry conference. ... I designed an auto-running PowerPoint presentation. ... The presentation was a hit. After that time, I became their primary source for marketing copy and was included in marketing strategy meetings. ... They found that my in-depth understanding of the software helped me write more convincingly than the consultant."
About Tom Johnson
I'm a technical writer based in the San Francisco Bay area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.