Blog Archives

A new breed of technical communicator

If Part I of Rachel Spilka’s 2009 anthology Digital Literacy for Technical Communication was intended to frighten the reader of portents of being outsourced (and presumably destitute as a result), then Part II was meant to assuage some of those fears. In fact, my concerns about managers playing the “everyone can write” card was almost directly addressed by William Hart-Davidson in chapter 5, “Content Management”:

But managers do need to recognize the following: that writing needs to assume a high status in corporate work, and be viewed as a critical means to just about every organizational end. The lingering idea that writing is somehow a “basic skill” rather than an area of strategic activity for a whole enterprise sometimes causes managers to make poor choices…. Many see these as a chance to automate or, worse, eliminate the work that writing specialists do. I hope this chapter helps to dispel that myth and prevent such decisions. (pp. 141-2)

In other words the “writer” should be so much more than a writer. Hart-Davidson’s chapter describes how a technical communicator can pivot into any number of essential job roles related to the managing of content.

Similarly, in chapter 4, “Information Design,” Michael J. Salvo and Paula Rosinski argue that to be truly digitally literate, technical communicators must understand information design and information architecture and by doing so, remain relevant and vital to their organizations. In fact, they state that technical communicators have always had a greater task than writing alone: “Effective technical communication has never been simply about writing clearly, but rather, about effectively organizing written communication for future reference and application” (p. 123).

Both chapters agree that although writing is still essential, the structure, high-level design, usability, findability, and reusability are all vital parts of content generation. Technical communicators are uniquely suited and situation ensuring all of these needs are met while anticipating potential future needs.

Salvo and Rosinski provide several reasons why technical communicators are ready to evolve from content production to information architecture and design. First, technical communicators have historically applied effective design principles regardless of context (p. 106). Second, technical communicators understand historical principles of user-centered, which can be built upon to innovate, yet still advocate for the user (p. 106).

Finally, technical communicators have ensured that good design remained a focus, even as the scope of documentation evolved from simple content writing to building full Web sites. One part of this was making sure that design was driven by context; that is, the designs developed were appropriate for the context in which they would be viewed (p. 108).

Taken together, these three points argue that technical communicators can either call upon past experience, genres, and conventions and apply them to new contexts or develop new practices and styles for these contexts, all while anticipating and meet the user’s needs. They are able to effectively straddle the documentation of the past and the information design and architecture of the future. However, Salvo and Rosinsky point out, this requires that technical communicators maintain an ever-increasing knowledge of publication contexts—in other words, they must be digitally literate and remain so.

Returning to chapter 5, Hart-Davidson tells us, “Today’s technical writer… is typically expected to… perform a host of other tasks that relate directly to the management of content and not necessarily to its creation” (p. 128). In addition to content-creation tasks like writing or designing templates, the technical communicator must also manage the documentation, how individual pieces of documentation are related, and the workflows and production models used to produce and publish content.

When considered together, Hart-Davidson and Salvo and Rosinsky’s advice offers two ways technical communicators can remain relevant in a world that—regrettably—no longer values traditional writing or editing skills. The first is to shift from creating content to developing new, modern ways of presenting information in never-before-seen contexts—or adapting preexisting genres and conventions to these contexts. Second is to manage the content in addition to creating it—and also manage all aspects of content creation.

Combined, these new modes of technical communication should lead to a new breed of technical communicators that become future proof by continually adding new value to their organizations.

I do not always play well with others, but I will evolve.

While Spilka and her contributors for Digital Literary for Technical Communication drove me crazy by repetition large chucks of text ( see pages 11, 13, 16 regarding who the target audience for her book is) and having a chapter summarizing all the other chapters, there are a couple of things that I learned, besides understanding that if I have to read any more of this book, I will either need a couple of aspirins or a bottle of vodka. These two things that I found most important were evolving and that technical writers must play well with others.

 

            Evolve.

 

Yes, everyone should already know that technology is constantly evolving, and so its delivery methods and how technical communicators craft their messages need to evolve too. Without evolving, technical writers will fail to gain all the skills necessary for the latest publishing tools, such as FrameMaker and RoboHelp, to help their users and to continue building a positive reputation for whatever company is providing the products and resources. An example of this need for evolving ones skills is in the chapter titled, “The Effects of Digital Literacy on the Nature of Technical Communication Work,” Dicks writes,

 

                        The nature of work for many technical communicators is changing so

                        rapidly that many now perform an entire task set that they did not even

                        know about five years ago (p. 51).

 

But evolving to keep up with the changing technology should be common sense, and Saul Carliner provides a chapter on history (just to show how fast technology has changed when companies, seeking higher profits use user input to create the desires of the customer – custom corporate software, better online help, easier desktop publishing, etc. By evolving, companies and people have saved money and time, which is usually one of the main goals of nearly everyone. And as for me, my goals are to learn FrameMaker, RoboHelp, and Illustrator, because I missed out on getting my resume read by hiring managers in the technical communications field because I did not have experience in those tools. I, too, must evolve.

 

            Must play well with others.

 

Life would be great if everyone played nice and worked well together, and working well with others is an important soft skill that many people lack, especially for those technical communicators who have been working alone for so long. But in today’s technical communicators’ work places, it is necessary to work with others to gather information and for review. As Spilka states,

 

                        [W]hat seems most critical and meaningful is how we can contribute to

                        social, team, or collaborative efforts toward the greater good of large

                        scale projects…Our work is also more like than before to be

                        international scope (p. 5).

 

Thus, to be a desirable technical communicator, one of the main skills is knowing how to work in a team. By helping co-workers in a timely manner, work can be fun, enjoyable, and a success. As a valued part of the team, the technical writer may learn additional skills and be wanted for further projects, which new skills may be needed, so it would be a great opportunity to evolve again. That is why I would suggest to anyone in this field to always take a chance to learn something new. Take on a more challenging project to increase your knowledge and skills.

 

All in all, so far, I learned from this book that one must not be afraid of the latest technologies, and they should evolve by trying to learn how the latest technologies can benefit themselves and their work places. Besides learning the forever-changing technology tools, methods, theories, and etc., it is also important to know how to work with others, as most projects will involve many people who will be working on the same project, and the technical communicator will need to gather information, and give and receive feedback on the project, so that the project is a success. And if the project turns out not to be successful, have a drink, think about what could have been done to have made it successful, and then try it again next time. With that, you are evolving. Start your evolution now.

 

 

Resources:

Dicks, R. (2010). The Effects of Digital Literacy on the Nature of Technical Communication Work In R. Spilka (Ed.), Digital Literacy For Technical Communication (p. 51). New York, NY: Routledge.

Carliner, S. (2010). Computers and Technical Communication (Ed.), Digital Literacy For Technical Communication (p. 5). New York, NY: Routledge.

Spilka, R. (2010). Introduction In R. Spilka (Ed.), Digital Literacy For Technical Communication (p. 5). New York, NY: Routledge.