Thursday, September 17, 2009

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.

1 comment:

  1. Pete, thank you for reminding me of that conversation. All I can say is yes, yes, and yes! I would like to add one more aspect that has concerned me for a long time (as long as I have been in the program.) When you say "...we're just teaching folks how to write memos," I see so much in there related to perceived subject matter expertise, or, as implied in your quote, the total perceived lack of it. I ask myself daily at work about what subject matter expertise I bring to the table as a technical communicator. It is way more than 'word smithing a memo,' in fact, I hate it when people use that metaphor because it implies that the content is just beautified and says nothing about the added value of invention, creation in that message. However, I have figured out that subject matter expertise is important for a number of reasons, among them, perceived respect by colleagues, engineers who see themselves as SMEs, respect for one's own work, and perceived organizational power. These aspects need to flow into the classroom to avoid exactly what you address. Okay, rather than go on a long rampage, I will link to the original post that you reference. Please find it at http://konjektures.com/2009/09/17/epistemological-considerations-in-technical-communication/

    Again, thank you for unearthing this, friend!

    ReplyDelete