Writing about TC is often not TC

I’ve been thinking about this oddity this week while creating help materials for engineering students. I realized that my “instructions” about writing a memo weren’t technical communication, or were at least different enough to not appear to be TC. My instructions took on the form of an essay, though I did use headings, sub-headings, a bulleted list or two, and zero references to William F. Buckley. In fact, I noticed when I read through Tom Johson’s recent post “How to Get a Job in Technical Writing — A 7-Step Guide for Students.” His post wasn’t really TC, either; again, more like an essay.


Why is that? Why should a communication-based field use a non-native genre when describing itself? Is TC naturally descriptive while the essay’s explicative style lends itself to explanations? I don’t think so. Good TC documents, like a spec sheet, can contain quite a bit of explicative material such as reasons why a particular product must be used rather than another, similar product.

Or am I wrong? Is it that TCers simply use a style similar to essays when explaining what TC is, but that that similarity is only passing? I bring up these questions because essays are, in a way, antithetical to the kinds of writing TC professionals are routinely hired to write. While an essay may be used to persuade, inform, or entertain, a TC document always needs to do something, and if the writing is also pretty then that’s fine, too. It’s purpose, too: TC documents are usually not intended to do anything but help someone with a problem (or prevent a problem from occurring), whereas an essay isn’t a necessary thing; rather, essays are often artistic and pleasurable. Like the difference between a statue and a column: they may both be made of marble, but one’s needed for support and the other is just. . .well, pretty. But describe the use and purpose behind columns in structural engineering and you may wind up writing an essay. Odd.

TC and Epistemology

A friend of mine posted the following to an email list about a year ago. What follows it is a revised version of my original response.

“I believe that by attempting to clarify or define our epistemology we could make strides towards a more satisfactory and possibly more universally acceptable definition of our field. For that to happen, all students and teachers of TC need to concern themselves deeply with how knowledge in our field is created and also with the ever evolving/changing epistemic processes that underlie knowledge accumulation/gathering/owning.”

Agreed. As a tangential commentary to your statement, I might point out that most of the intro-level tech writing books I’ve seen define TC (often calling it tech writing, as I’ve done here) as getting usable information from one source to another such that the audience can make a decision or perform an action. This definition limits us to the communication of information rather than combining it with “the processes we use to gather/create/own knowledge,” as you’ve so aptly pointed out.

Furthermore, those same texts never take the time to define the word “technical,” which is certainly fraught with difficulty (particularly for an intro text). But the attempt is necessary. As another friend of mine might point out, oversimplifying our field for intro service courses has the indirect result that professionals entering the market retain the illusion that technical writing is a largely pedestrian skill rather than a broad, rich field; thus, our service courses continue to undermine our own efforts at establishing recognized value for TC. In simple terms, we’re teaching our students that TC is memos, reports, and email. End of story.

I’m differentiating between data transmission and data collection because one has to do with serving other professionals and the other as to do with knowledge creation, ideally for the benefit of anyone and everyone. The transmission aspect is something we’ve been doing for quite some time. We analyze genres, rhetorics, and really dig into usability testing in order to get those ideas to users. What we haven’t, perhaps, focused on so much is that we’re collecting and validating that data in the first place, and part of our epistemology (unlike other fields) is that while we do engage in creating knowledge (again, like other fields) we also (and this is critical) keep a lookout for how the audience receives and validates the data we’re going to communicate. That community aspect, what Robert Johnson might lump into his “user-centered design” paradigm, and what I’ve called the “non-system system,” differs significantly from fields similar to ours, such as sociology and psychology: we gather/create data, we find ways to assemble it, AND we work in conjunction with our audiences in making that data work while also teaching them about the structures (and yes, epistemology) underlying that collection and transmission. And maybe that’s our “hook,” so to speak. If more traditional social scientists can help explain how individuals and groups behave, then maybe we’re the ones who explain how received knowledge is communicated and validated from one group to another. That seems like a powerful incentive to encourage a serious revision of how TC is approached in both academics and business. Otherwise, we’re just teaching folks how to write memos.