Gerry Butterwick
(email me at gbutterw@emich.edu)

Technical Writing: A Special Job For Special People

The inherent contradiction in the term "technical communication"
One of the ideas about Technical Communication that has stuck with me since I began taking classes in this program is something said by Professor Steve Benninghoff.  He told us that the term "technical communication" is basically an oxymoron, since the word "technical" has to do with specialization and the word "communication" has to do with establishing and defining relationships.  He read aloud the second definition of the word "technical" he found in the classroom copy of Webster’s Dictionary: "of, used or skilled in, or peculiar to a specific science, art, profession, craft, etc.; specialized [technical vocabulary]. " "When you have technical knowledge," he said, "you have specialized knowledge.  You are special." 

Now, when someone tells you you are "special," it can mean one of two things. It can mean you are precious and unique, or it could mean you are someone with "special" problems, with "special" needs. In my experience, I've found that many engineers, programmers and other Subject Matter Experts are often "special" in both ways. They can be brilliant problem solvers when it comes to approaching complex matters in their field of expertise, but their writing can be as cryptic as heiroglyphics. This is only a slight exaggeration. In my job as a database administrator for a Tier One automotive supplier, I had to literally keep a score card for some engineers' product programs because they couldn't reliably tell me what I needed to know to get them the information they needed, and the people in manufacturing were sometimes at a loss to understand what was expected of them. That was vital, because when the people in manufaturing don't know what to do, they can't build your product, and your company has no product to sell and therefore makes no money. It was often my job to translate the engineer's language into something the people in the plants could put to use. Without realizing it, I had already begun to work as a technical communicator. It was my job to provide the unique, precious engineers with the "special" communication assistance they sometimes badly needed.

The crux of the oxymoron, and the challenge to technical communicators
In discussing the inherent contradiction of the term "technical communication," Professor Benninghoff said that to have technical knowledge is to be part of an elite group of people who share a background no one else does, but to communicate is to breech the barriers that inhibit the sharing of knowledge.  "Technical" means we are defining one group against all others; that walls are being built. "Communication," means that we are building bridges between those who are "in the know" and those who need to know.  It can also be said that therein lies the challenge to the techincal communicator. It's your job to build a bridge through a wall, and it's about as easy as it sounds.

Easy reading is hard writing
At first galnce, the "communication" part of "technical communication," seems to be the "easier" part. We learn to communicate in one way or another as infants, and by the time we're in third grade, we're about as good at putting our ideas into words as we're ever going to be. Acquiring technical knowledge, however, means joining an elite, select group, requiring the schooling or training one can only usually only get as an adult. But learning the ins and outs of some specialized field of study is, in actuality, much easier than trying to put those activities into words for outsiders, or even deciding what aspects of the field are relevant to outsiders who need to know just enough for them to get their jobs done. I never learned enough about anti-lock brake units to actually take one apart and put it back together; it was never necessary for me to do so. But I did learn enough so I could tell people who weren't engineers what they needed to know, and I got to the point where I could hold my own in a conversation with an engineer so I could convince him that it was in his own best interests to answer my questions.

I don't fault any engineer for trying, and failing, to get his thoughts down on paper any more than I would think I could just walk in and do the job of an engineer. To make a product work well, yet so smoothly you don't notice it working was always the goal of the engineers I knew. Likewise, to write something so transparent the reader grasps the idea without noticing the prose itself has always been my goal as a writer, and is something my college training has helped me with immeasurably. Neither transparent product design nor transparent information design is easy. As Nathaniel Hawthorne famously said, "Easy reading is damn hard writing."

The Team Introduction Memo (TIM) and Process Documentation Memo (PDM): Who I am and what I'm doing here

Contextualizing the TIM & PDM

What I bring to the team: the writing itself must advocate for me
In this assignment, we were each asked to write a memo that would introduce us to the other members of the class. Part of the job of this particular piece of writing was to convince the other members of our class that we all would work well as potential partners in the class. Although there were no group projects, per se, assigned during the semester, we would all serve as each other's editors and allies, critics and supporters.

Reflecting on the TIM & PDM

Who I am and how I'll fit: it's about me, but it's not about me
I have to think about what it will take to balance my two primary objectives: to center my writing on the audience, and to provide relevant information about myself. On the one hand I have to think about the people who will be reading this memo, on the other, I have to think about what I want to say, the point I want to get across, and the most concise, unadorned and effective way to do so.

Tell a story: letting my fellow classmates in on my experience
After having decided that school and work experiences are the sorts of areas in which I could potentially find common ground with the other students in my class, I decided that some discussion about my writing experiences in those contexts would be appropriate.

The Creative Rhetoric Scenario: A Talk Over Lunch

Contextualizing the Creative Rhetoric Scenario

Finding fertile creative ground in two meanings of the word "rhetoric"
As one might assume from the project title "Creative Rhetoric Scenario," this assignment gave us a bit more of an opportunity to be creative than is ususal in a technical writing class. Yet while our scenario was to be the product of our imaginations, we were also expected to to keep our "eyes on the ball," so to speak, and not forget that the ultimate goal was for us to demonstrate some understanding of the word "rhetoric."

We were asked to come up with two or more characters and put them in a situation where they would discuss the meaning of the word "rhetoric." Or meanings, as the case may be. Since the term "rhetoric" is itself as multifaceted as the many fields that employ the methods and practices of rhetorical writing, it makes sense that there should inevitably be some confusion about what the true nature of "rhetoric" is. In this dialogue, my characters, two engineers named Mark and Tom, realize that they have very different ideas about what the word "rhetoric" means.

In the introductory section of this assignment, I talk briefly about how their confusion and disagreement is by no means unprecedented. From the time of the ancient Greeks to our present-day dictionary definitions, "rhetoric" is both the art and science of effective communication and the "artificial eloquence" of those who we might say are "full of hot air." When Tom holds up their esteemed manager, Gary, as an example of one who is skilled with rhetoric, Mark takes issue with that description. Based on his understanding of the term, Mark thinks that what Tom intends as a compliment sounds more like an insult. In the resulting conversation, they discuss the implications of these divergent notions as they relate to corporate managerial style and national politics.


Reflecting on the Creative Rhetoric Scenario

Mark's epiphany
In Mark's view, and in the view of many, it seems, to employ "rhetoric" is to "use some flowery language" in order to "pull the wool over somebody's eyes." Most often, when I hear the word "rhetoric" used, it carries its negative, "artificial eloquence" connotation, and Mark responds to Tom's use of the word with that connotation in mind. Tom, having been on the college debate team, has a much more nuanced understanding of the word. He is also more skilled in rhetorical practice. He shows that he can listen to the other person's point of view, recognize its logic and offer a thoughtful response. Tom's responses are of the gentle-but-firm type; he shows respect for Mark's opinion while clearly expressing the reasoning behind his own. Though Mark admits his reluctance to continue a couple times, Tom keeps him engaged, and Mark finally admits that Tom has helped him to gain a new perspective on the meaning of "rhetoric." That understanding would not have been possible without Tom's skillful use of rhetoric in the first place.

"A Talk Over Lunch" as a reflection of my own ideas about rhetoric
Both Mark and Tom express ideas I have about rhetoric, politics and corporate management. Mark represents my more fatalistic and cynical side, Tom represents the side of myself that's more considered and disciplined. In our Technical Communication classes, we are encouraged to be considered and disciplined, but we should be aware that the fatalistic and cynical are likely to be present in any audience.

The challenge the audience presents to the technical writer is the same challenge Mark presents to Tom. The technical communicator needs to answer the question, "Why should I care?" before anyone has the chance to ask. Like Tom, the technical writer does well to acknowledge his audience's reservations. The challenge is to do so without condescending, and at the same time without inadvertently making a case contrary to the writer's intention. An honest discussion of the limits of a product, procedure or policy can go a long way in fostering the trust and good will of an audience. When you're a technical writer, your job is not PR. Though your checks are signed by your employer, your primary obligation as a technical writer is to the audience, which any reasonable employer should understand and encourage.

The Context/Genre Analysis Project: The Life and Times of an Engineering Document

Contextualizing the Context/Genre Analysis Project

The Goal and Structure of the Assignment
The goal of the Context/Genre Analysis assignment was for each of the students in ENGL424 to take a look at some type of context in which documents are used, be it a workplace or a classroom, and give the reader an idea of what it's like to work or learn in that context. Having provided the reader with some understanding of the context, we were then to discuss how a certain genre of document was supposed to function in that context, and how, in actuality, it did function.

Prior to working on our projects, we were given copies of the article "Writing Technologies at White Sands," written by Powell G. Henderson, a civilian employee at the U.S. Army's White Sands Missle Range in New Mexico. Henderson, as a greaduate student, had studied the writing habits of his fellow White Sands employees. Henderson describes his experience of looking at a variety of documents in his workplace in an effort to understand how technology impacts the writing that gets done in a nonacademic setting. While the scope of our projects were to be much more narrow than Henderson's, we were to take a similar critical look at contexts we had been in. By thinking back on these contexts, and by looking closely at a certain genre of document and asking questions about that genre's successes, failures and unintended consequences, we were to be able to draw certain conclusions about the context and the relationships that created and sustained it.

Since I worked for seven years in an enginering design group in the automotive industry, it was logical for me to choose the Engineering Change Request (ECR) for my genre. I have seen literally hundreds of these in my life, and I feel confident about my ability to discuss them.

The Context: Narrowing the Scope of the Report to the Design Group's Role
The ECR is among the most important documents used in the automotive industry. Every phase in the development of an assembly and its respective components is documented in ECRs. Since ECRs are so important, they must invariably pass through many hands. There are far too many people involved in the engineering change process for me to provide a complete overview of the ECR's business context, so I instead have chosen to focus on the part I know best: the role of the design group.

The Genre: Narrowing the Scope of the Report to the ECR Proper
Part of what makes it challenging to write about ECRs is the fact that they are such versatile documents. The ECR package itself is made up of the Engineering Change Request proper, and potentially dozens of other documents, including marked-up engineering drawings, faxed estimates from suppliers, memos between engineers and customer representatives, bills of material and specifications. Here again, in writing about how ECRs function in the workplace, it helps to focus on the ECR proper and only bring in references to the document's many appendices as is appropriate.


Reflecting on the Context/Genre Analysis Project

Realizing Now What it was I Learned at TRW
One of the things that I found to be somewhat tricky with the Context/Genre assignment was in clearly delineating between the context and the genre. To say this may, at first, seem ridiculous, since "context" is supposed to refer to people and their work environment, and "genre" is supposed to refer to the types of documents they use. But in exploring the relationships among co-workers at TRW, and in considering the way the work environment and ECRs mutually impacted each other, I've come to realize that determining where the "genre" leaves off and the "context" picks up is terribly difficult to extricate. In terms of what actually gets done, it's hard to know if the documentaion is "pushing" the work along, or "pulling" against it. It's probably safe to say that, depending on who in the company you might ask, the same document can seem to be helping and hindering.

As in any large office in any multinational corporation, there is a complex network of wants and needs; there is the influence of power and money; there is the ideal of shared purpose and the reality of political maneuvering; and finally, there is the documentation that records, and indeed inspires, all of those things. A page of an ECR, full of numbers and engineering terms, can seem painfully dry to someone who can only appreciate what is there at face value, but for someone "in the know," it can tell a story of ego clashes and political expediency, of professional satisfaction and corporate policy failures, of lessons learned and lessons that should have been learned, but weren't. The more years I spent at my desk, the more I not only learned to read between the lines of an ECR, but the more I came to understand what was between the lines better than I understood the literal meaning of the text. It took me two years away from the company, and my work on this assignment, for me to realize that.