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?