By Rachel Amity, NCSU Student

Technical writer, information developer, knowledge manager, information architect, documentation specialist, technical editor… With so many different titles, it’s no wonder so few people know what technical communicators actually do. In my second year of the Master’s of Science in Technical Communication program at North Carolina State University, I’ll admit that I still struggle to define our work, and find that I’m not alone.

A favorite pastime of my classmates and mine is to swap stories about trying to explain our work to family and friends, who most often look at us quizzically and say something akin to, “So, you write instructions?” This description isn’t exactly wrong, but it isn’t exactly right, either. So how can we more accurately define our work? As my classmates and I try to craft definitions that account for all the hats that technical communicators might wear, we’ve often found ourselves defining the field in terms of what it isn’t, a kind of technical communication mythbusting, if you will.

Perhaps one of the greatest myths — Myth #1 — is that technical communicators spend most, if not all, of their time writing. When I started an information development co-op earlier this year, I anticipated spending hours at a time in front of my laptop screen, fingers dancing prolifically across the keyboard, but in reality, it seems that most technical communicators are lucky if they can spend even half of their time writing.

That’s because – Myth #2 — technical communicators are actually quite autonomous. We might receive fully developed and meticulous input from developers and Subject Matter Experts (SMEs), but more often than not, we’re responsible for working through the problems we’re asked to document, getting our hands dirty in workflows and graphical user interfaces (GUIs) to see the product as the customer does. Every day, we analyze problems and rhetorical situations, confer with developers and SMEs, consider how to present needed information and where to include it. When all that’s done, if we’re lucky, we might have time left to write.

At my co-op, when I stumbled upon problems I couldn’t solve on my own, I busted another myth — Myth #3: that developers and SMEs are reluctant to help technical communicators. In my program at NC State, we often discuss tactics for communicating with developers and SMEs, as if they’re temperamental birds who must be coaxed out of their shells. Yet my classmates and I have found that developers and SMEs are mostly happy to share what they know with us. It seems that the old days of viewing technical communication as peripheral are gone: today, developers and SMEs recognize that technical communication is an integral part of the customer experience.

A misconception — Myth #4 — is that technical communication is straightforward. To an outsider or newcomer, our work might seem simple: we explain how to use products. But, like any other kind of writing, ours is filled with nuances that take time and effort to refine. We tarry over global issues, like usability, and local issues, like word choice. We consider how broad or specific to be given our intended audience. We ponder over paradoxically vague feedback telling us our writing is too vague. Given all these tasks, it’s clear that technical communication is anything but straightforward. Instead, it is dynamic and robust, often undefined and almost always iterative.

So, now that we’ve busted some of the myths that might lead perceptions of our work astray, what is technical communication? Like technical communication itself, our definition will never be straightforward, but one thing’s for sure: it’s a lot more than just writing instructions.

Rachel Amity can be reached at reamity at ncsu dot edu . Read more articles by Rachel Amity.