What non-writing Skills are Technical Communicators using?

Posted: January 6, 2012 in School papers, Technical Writing
Tags:

This was an informal “short paper” I wrote for class. By the time I wrote the paper, I had 19 responses. I ended up getting 35 total. So if you responded after I finished writing, your data is not included. However, I carefully read and took to heart every single submission I received. Thank you so much, everyone who helped me out!

************************

What non-writing Skills are Technical Communicators using?

by Amanda M. White

As technology develops and more rapidly than ever, technical communicators can be left in the dust— not only in documenting evolving technologies, but in adopting the tools available, and increasingly necessary, to do our jobs. It is easy to feel overwhelmed by the rise and decline of competing software, alternate coding languages, and practices that the latest research suggests we master.

As a student currently working outside of the typical technical communication field, I was feeling confused about what would be expected of me as I vied to enter this profession. The list of proposed skills was long and diverse, and I didn’t know where to begin my extra-curricular training. So I decided to survey working technical communicators and find out what skills, techniques, and programs they were using, and how they learned them.

I began by selecting what I considered the thirteen most prominent tools proposed by the authors in Digital Literacy for Technical Communication: 21st Century Theory and Practice (ed. Spilka).

The thirteen skills I chose were as follows:

  1. Single sourcing/content management system
  2. Project management software
  3. Usability testing
  4. Graphics editing program
  5. Vector graphics editing program
  6. Adobe Framemaker
  7. FTP
  8. HTML
  9. XML
  10. DITA
  11. SGML
  12. PHP
  13. Flash authoring

Note the inclusion of specific software and mark-up languages, as well as general practices such as “usability testing” and “single sourcing.”

Using this list, I published an online survey, inquiring as to which skills each writer used or did not use in his current position. In addition, I polled subjects as to how they learned each skill: School, self-taught, trained by company, or other.

I received nineteen responses. Most respondents were found through either TechnicalWritingWorld.com or Twitter. Not every respondent answered every question, and each question allowed room for optional comments.

I ended the survey by asking writers their advice for aspiring technical communicators.

For the thirteen skills surveyed, I have simplified the responses into two graphs. Figure 1 lists how many subjects reported that they used each skill.

Tools and techniques used by Technical Communicators graph

                                                                      Figure 1

The near-unanimity of graphics editing programs (such as Adobe Photoshop) and HTML is remarkable. For skills so distant from writing to be so uniformly used by technical writers is important to note, as these are not subjects that would be intuitively covered in a writer’s training.

On the other hand, the obscurity of DITA is surprising after how firmly it has been touted as the future of our profession.

Figure 2 presents the results of the pedagogical aspect of the survey. Rather than present the results for each individual tool, I have simplified by adding the results for each answer. That is, if two people said they learned project management software in school, and 4 people said they learned usability testing in school, that would be six points for “Learned in school.”

                                                                    Figure 2

The obvious take-away here is there were over twice as many instances of self-instruction as formal training, in school or on the job combined. This has heavy implications for aspiring technical writers. Not only are we expected to learn highly diverse skills, such as HTML and Photoshop, but we must plan on learning them ourselves.

It is my hope that these results will help my colleagues choose which non-writing skills they need to focus on to help them begin or advance their careers. Along those lines, I’d like to share with them my favorite quotes from the generous advice given by the subjects of this survey.

“Let your love of writing show through. My employers have always liked how enthusiastic I am to do the ‘work’ they’ve given me.”

“The best thing an aspiring technical communicator can do for their career is learn and internalize the methods and ‘rules’ that govern good technical writing. Don’t be another journalism major, engineer, or programmer, who wanders into technical writing without learning the underlying orthodoxy.”

“Don’t plan on staying in one place— there is never as much work as they think there is.”

“I would emphasize the importance of fostering good relationships with subject matter experts. In many ways, they can determine the amount of success you have in creating a great product. Respect their time, be courteous, patient, express appreciation for their efforts and you will be someone they will want to work with.”

“Your strength as a technical communicator should come from your ability mine information from subject matter experts, your ability to identify your audience and their needs and your ability to write brief/concise information.”

“A good description of technical writers is ‘you are a professional student.’”

“Expect to reinvent your skill sets every five to eight years— and on your dime, because most companies will not pay for you to do it.”

“Consider yourself as an end user and work with the product.”

“Be open, fast, and agile.”

It is my hope that this research will help my colleagues feel better equipped to prepare themselves for the current and future states of the technical writing profession. “Be open, fast, and agile,” and ready for tomorrow.
Spilka, Rachel, ed. Digital Literacy for Technical Communication: 21st Century Theory and Practice. Routledge, 2009.

************************

I’m happy to report that I got a perfect score on the paper. Thanks again!

Advertisements
Comments
  1. Brian Winter says:

    Great work on the paper, Amanda, thanks for sharing!

    re: Fig 1, be cautious of relying on these numbers to draw a firm conculsion. A sample size of 19 can be informative, but is probably too small for your results to be statistically significant and produce confident conclusions.

    DITA/XML is expensive and time-intensive to implement and maintain. You’ll see it in large companies, where there’s a full staff of content producers and they can afford to support it. Solo writers and small businesses generally use cheaper, off-the-shelf single-sourcing solutions like Flare or Author-It.

    However, I’m not at all surprised that graphics is a top-needed skill. Most tech doc includes some sort of diagrams, flowcharts, or software screen shots. Relatively few companies have the luxury of dedicated graphics designers on staff, so most writers produce their own graphics.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s