“What Do Technical Communicators Need to Know about Writing?” by Ann M. Blakeslee & Gerald J. Savage

Overview

The article “What do Technical Communicators Need to Know about Writing?” by Ann Blakeslee and Gerald Savage is not so much presented as a solution to a problem, as it is a “how-to” guide as well as a useful primer for what aspiring technical communication specialists should expect upon entering the field. Framed around the story of a plucky young technical communicator named Siena, Blakeslee and Savage build this guide around a series of questions based upon studies conducted about, and interviews with, different technical writers in different companies about the nature of their work. If there is a problem that technical communicators need to be aware of, it’s that, as Blakeslee and Savage report, “In many…studies, the power and complexity of writing as a literary practice sometimes seems to be in the background…Yet writing may be the one competency that really binds together the array of practices we call technical communication” (Location 7208). Or, in other words, the one thing that makes a technical communicator a technical communicator is an ability to write, despite the fact that this may not be the most highlighted (or appreciated) aspect of his or her work.

In order to prepare technical communicators like Siena, the article builds a heuristic around six categories of questions that should be considered when acclimating oneself to a new workplace. These are:

1.       The amount and quality of writing entailed and expected

2.       The nature of writing

3.       Genres and rhetorical strategies

4.       Approaches and processes for writing

5.       Knowledge and skills

6.       Personal traits and qualities.

Ultimately, each of these categories relate to HOW the technical writer spends his or her time on various writing projects, rather than merely laying out a monolithic set of best practices. They write that “Knowing how much you will write…is important for several reasons, not the least of which is determining how best to manage your workload, time, and resources” (7261). Questions a writer must consider include the quality of the work, deadlines, what is at stake for the audience, and how does the organization in which one is working value a given document.

These concerns branch out beyond merely the act of putting text to the page. Under the second category, a writer must consider both what kind (and how much) research they are expected to do for different types (or genres) of documents, and what conventions are expected of them in their field (7294). This also ties to approach and process (category four) and knowledge and skills (five), since if a writer IS expected to conduct research or work with different modalities like visual programs or web design software. They write that “technical communicators also need to possess technical skills and knowledge. What this encompasses is, again, highly variable” (7343) and that, while specific technical skills are important, the true work of a technical communicator is to put a generalized set of skills into “a larger context of other knowledge” (7356). Or, put simply, a technical communicator needs to know how to figure out technologies on demand, and then frame and use them within the rhetorical and generic constraints of their field. They must be jacks-of-all-trades in much the same way that rhetoricians must be: the kairos of the situation determines their tasks.

The final category of questions is, to me, the most interesting, and potentially problematic as well. A technical communicator, in addition to navigating the mercurial demands of writing, genre, research, and multimodality expected of them by different employers, must also be “people persons” (a quality that I got into writing to avoid…). This could involve collaboration with other technical writers, or the use of social media to promote one’s work (or the work of a company).

Connections

Ultimately, this article serves as a bridge between the general concept of genres in technical communication and the specific concerns about multimodality, visual design, collaboration, and international concerns posed by the following articles. Siena’s journey through the labyrinth of her office, guided by the Virgil-esque mentor Allison, brings her to confront each of the questions raised in prior and subsequent articles. She learns about design when determining whether she must create documents from scratch, since, “Twenty of our respondents…said they spend at least part of their time creating documents from scratch…[many also] said that they spend at least part of their time rewriting or repurposing existing documents” (7439). She learns about concerns relating to audiences in her journey, local and international, since, “for most technical communicators…everything is driven by the needs of the audiences…technical writers need to be diligent in seeking and obtaining sufficient knowledge of their audiences, and of the rhetorical contexts of their work” (7490). Ultimately, after asking about collaboration and editing, Siena learns the ultimate lesson of technical communication: time management. Since technical writers must learn their technologies and audiences anew with each project, they will be expected to produce high quality work, but ultimately, “projects occasionally have different levels of importance, depending on factors such as audience, purpose, and different stakeholders” suggesting “the importance of understanding just ‘how good’ one’s writing needs to be in any situation” (7409). This also, potentially, ties into issues of user-centered design. Or does it?

Questions

I wondered, overall, if these practices, and the considerations of audiences mentioned throughout the article, constitute an emphasis on user-centered design, or the extreme-usability Johnson-Eilola earlier warned against. Though there are frequent reminders that the audience’s needs must be at the forefront of the technical communicator’s mind, the myriad demands of modality, genre, design, and technical literacy suggest that a successful communicator will always be in a hurry; a mode of operating which lends itself much more readily to extreme usability than the slower, more careful design encouraged by previous theories.

Similarly worrying to me was the question of where in the corporate hierarchy a writer is placed. While this article focuses primarily on the technical communicator as a member of a single company or field, many technical writers are freelancers. What concerns must an untethered technical writer navigate? Is it possible to learn the generic and rhetorical and technical literacies when you may be employed by a new company (or several new companies) each week? I, for example, worked as a freelancer for several years in an international company where my supervisor would regularly be rotated. What began as a simple translation-editing job quickly expanded to involve research, original writing, and even some creative work. There were also several complications with expectations, given the international and multicultural nature of the company, and the audience to whom I was writing.

Tying this to the sixth point about collaboration and social media further complicates this. As Anne Wysocki writes, “technical communicators need to know the social-networking software their audiences are likely to use, and, importantly, they need to know how to use the software rhetorically” (8577). While, true, this has some interesting, if troubling, implications for what constitutes writing or rhetoric in the social media age. After all everybody needs to be a social media expert these days, and, further, many already-established companies or celebrities employ technical writers to “ghost tweet” on their behalf. As we move into Web  2.0, how do we use these heuristics to help technical communicators (especially freelancers) retain agency?