Contents Despite tremendous advancement in the technology industries, one area still needs some improvement: communication between technical communicators and engineers or other subject matter experts. Although many such relationships succeed, negative stereotyping is still perpetuated by both sides. In “Working with engineers from a lone writer's perspective,” technical writer Rachel Houghton discusses the negative stereotype she had of engineers prior to becoming a technical writer:
Engineers. Before I became a technical writer, that used to be a swear word in my household. It meant logical, precise, controlling[,] and anal-retentive. [1]
In addition, some engineers still pigeonhole technical writers as wordsmiths who refuse to learn the technology. Technical writers actively define themselves against this stereotype. For example, in Noel Hartshorn's consultant profile on his computer programming company's (Jetbyte's) webpage, his ability to understand technological tools is emphasized:
Contrary to the technical writer stereotype, Noel is a very dynamic worker with the ability to understand the concepts and technologies relating to the projects in which he is involved. He is happy working alone or as part of a team, conforming to a client's in-house standards or in a more creative capacity. [2]
Although these stereotypes are less prevalent than they were ten years ago, they still exist and harm the profession. For instance, Janet K. Christian describes one engineer who thought technical writers were little more than “glorified clerk typist[s]” and a programmer who labeled technical writers as “those people who flowerize our [programmers'] writing” [3]. Also, Don Bush explains in “How to Get a Good Job” that engineers complain that technical writers are bureaucrats because we demand glossaries, overviews, forewords, abstracts, lists of figures, [and] ‘About This Chapter' sections. [4], p. 40
Both sides' negative stereotyping hinders successful communication between technical writers and engineers. Because an effective technical document, manual, or help menu is often the result of successful collaboration between the technical writer and the engineer or the technical writing group and the engineering team, it is important that these two groups (1) develop successful communication practices and (2) maintain an effective working relationship.
This article presents communication strategies for technical writers and engineers. These strategies are developed from applying Erving Goffman's social interaction theories to the technical writer/engineer relationship. These strategies should also help dispel some of the criticisms that engineers and technical writers have of each other.
Goffman's Overall Approach
Erving Goffman (1922–1982) was a sociologist who wrote nearly a dozen books on communication and behavior, but is best known for his work on social interaction [5]–[8]. He developed his theories from observing hundreds of people communicating. His analyses can be applied specifically to the communication of and relationship between technical writers and engineers using three of Goffman's concepts: roles/scripts, “stage” setting/rehearsal, and self-presentation/impression management.
A. Roles/Scripts
Goffman proposed that each individual takes on a particular role, and that communication occurs between an individual and “role others,” that is, people with whom we are communicating who also occupy their roles [7], p. 85. Almost all occurrences of communication between two individuals have role expectations; even an ordinary conversation between two friends who run into each other at the grocery store has a “script” from which the two friends play a role. In the grocery store, we expect the friend to greet us with a smile, ask us how we are doing, and then leave after a brief exchange of noncommittal communication about the weather, work, health, or family. The role we engage in as friend, of course, changes once we enter the check out line, where we take on the role of customer and perform our script with the cashier accordingly.
B. Stage Setting/Rehearsal
In much of the same way, Goffman envisioned communication as actors performing in roles. These “actors” follow a “script” to match a rhetorical setting. This setting is Goffman's “stage,” and, like a theatrical performance, has a theatrical “set” with other individuals cast in a “role set;” “the role-set for a doctor, for example, contains colleagues, nurses, patients, and hospital administrators” [7], p. 86. (The hospital or doctor's office, of course, would be the stage.)
Since communication is often anticipated, individuals are able to rehearse their roles in preparation. For example, a pediatrician who examined a male teenager with possible learning disabilities may prepare for the next visit by checking a medical database that catalogs studies about learning disorders. The pediatrician already may have ruled out Attention Deficit Disorder (ADD) and Attention Deficit and Hyperactivity Disorder (ADHD) because the teenager also exhibits slight physical abnormalities that are common symptoms of Klinefelter's Syndrome, a sex-chromosome disorder the pediatrician learned about in medical school. Further checking and reviewing by the pediatrician constitutes rehearsal, the very thing we expect from (the role of) a competent physician. Because Klinefelter's Syndrome is an embarrassing syndrome for some families, the pediatrician may further rehearse mentally what she might say to the family of the teenage boy should chromosome tests reveal an XXY chromosome.
C. Self-Presentation/Impression Management
Communication is a theatrical act in the sense that we must all prepare beforehand and perform a role that is part of a script that both parties accept. If one of the “actors” says something that is not part of the script, the other “actors” are thrown off, and the audience may perceive the actor as unprofessional or unprepared. For Goffman, presentation of self deals largely with the acting done during the first encounter or communication act. Impression management consists of evaluating one's behavior during the initial rhetorical situation, afterward, and during and after subsequent encounters.
Thus, the grocery store friend shows interest by asking what the other friend is doing but doesn't take up too much time talking or asking questions in case the friend is in a hurry or has ice cream melting in the grocery basket. Likewise, the pediatrician does not tell the teenager's mother to quit worrying about it.
If friends or doctors were to do such things, they would have added lines to a script that were unexpected, and they would not be fulfilling their role as a conscientious friend or caring physician. In sum, the individuals would be enacting an undesirable script due to misunderstanding the role expectations of a friend or doctor, or worse, apathy or disregard for the behavior and communication expectations of these two roles.
Practicing Good Communication
The goal, then, is to develop effective communication between engineers and technical writers by
enacting a good script, one that includes actors that perform their professional roles well
setting a professional stage via communication with individuals and preparing for phone calls or emails so that any face-to-face meetings may occur between the appropriate cast members
using knowledge about one's professional role and (good or bad) expectations about the other one's professional role to an advantage by making a positive initial impression, followed up with effective management of that professional self-presentation over time.
A. Roles/Scripts
The prevailing assumption about technical writers is that they emphasize their role as user advocates. Although this role concept has been helpful to the extent that technical writers feel they must champion the user by creating effective documentation, I suggest that this role might be harmful to the extent that advocating the user sometimes means that the technical writer does not listen to the engineer.
Fig. 1 shows the dynamic when the technical writer is focusing only on championing the needs of the user, with the result that she or he becomes bogged down in documentation and the product. Arrows in the figure indicate the main lines of discussion that influence document content. Note in the figure how interaction with the engineer or other subject matter expert suffers. When the technical writer and the engineer play consultant roles, however, the engineer and the technical writer are collaborating to help the user.
Notice how all role sectors are interacting in the consultant model (Fig. 2). Likewise, the customer/end user can contribute to the design process by communicating with the engineer via responses during usability testing or through communication early in the product development process [9]. Of course, the engineer (ideally with the technical writer) should be actively soliciting user feedback.
B. Stage Setting/Rehearsal
Good freelance technical writers research companies prior to the first meeting. Learning about the company and even the engineers themselves establishes the technical writer's integrity, which Goffman defines as the “propensity to remain loyal” to an individual or group of people [6], p. 97. By taking the time to get to know the company and the engineers before the initial encounter, the freelance technical writer conveys that she or he is interested in building a professional relationship, one that is based on collaboration. Investing time initially helps the engineers be more willing to give more of their time to explain the product, before one word of documentation is written.
Likewise, engineers should do their part in the technical communicator/engineer relationship. Engineers should be willing to address the technical writer's questions and suggestions. Engineers who are open to including the technical writer early in the development stages of the product may find themselves with happy end users and fewer headaches.
Not all rehearsal needs to be performed just prior to the first meeting, however. Not only is it the responsibility of the technical writer to examine the product before talking to the engineer, it is helpful and often necessary that the technical writer has some type of technical background. According to the Professional Communication Society's webpage, many technical editors and writers
first became engineers, software developers, and scientists before getting interested in technical communication. After achieving preeminence in technical fields, they saw the need to develop their communication skills to share information with their peers, clients, or students. [10]
Even technical writers from humanities backgrounds might reasonably be expected to also have training in technical areas. With the influx of programs in technical communication at universities, technical writers more than ever are expected to have majored in or have trained using the technical products for which they are writing documentation.
Similarly, the role of the engineer is more than that of technical guru. According to Vest et al.'s study based on a national survey of electrical engineers, effective and frequent communication was a must:
Overall, engineers say they spend a little over half of their day communicating (55%). The majority of this time involves communication with other employees working on the same project as the respondent (58%); the remaining time is divided approximately equally between other in-house employees (20%) and individuals outside of the organization (22%). [11], p. 39
Both the frequency and quality of communication between technical writers and engineers is crucial to effective document production and content end users.
C. Impression Management and Collaboration
How engineers perceive technical writers is often largely based on how technical writers view themselves and their role in producing an effective document. However, if technical writers are bogged down with the desire to champion the user over connecting with the engineering team, they may alienate themselves from engineers or other subject matter experts. The suggestions in this interface—presentation of self, rehearsal, impression management, and role concept—should always be employed in the spirit of collaboration (i.e., building relationships between technical writers and engineers that benefit not just the user and the company, but the engineers and the technical writers themselves).
In his discussion of individuals working on a team project, Goffman asserts that “each teammate is forced to rely on the good conduct and behavior of his fellows, and they, in turn, are forced to rely on him” [5], p. 82. Instead of the technical writer as user advocate and the engineer as techie, both serve as consultants on a team project where the end user is the audience. This way
a team may be defined as a set of individuals whose intimate cooperation is required if a given projected definition of the situation is to be maintained. [5], p. 104
Engineers and technical writers, therefore, must collaborate effectively and see themselves as part of the same team in order to produce user-friendly documentation.
When Bad Communication Happens
Suppose a team of software developers at a small but burgeoning company (a fictional place called Widgetech) creates software that needs documentation. Widgetech contacts a technical writer (Lovecraft) to create the help menu. Lovecraft has written product documentation but has not yet worked with this kind of software. Widgetech management hires Lovecraft; Lovecraft accepts, needing more software documentation experience to expand his résumé.
Management gives Lovecraft the software and says, “Contact the developers should questions arise.” At home, Lovecraft learns with some difficulty to work the software. He eventually drafts the help menu and arranges a meeting with one of the developers.
At the meeting, Lovecraft shows Miller, the developer, the draft. Miller says some of the descriptions are too long and that the draft has too many sentence and paragraph breaks. Lovecraft asserts authority and says, “Full sentences need end punctuation—surely we don't want our users to think your company doesn't know proper grammar?” Lovecraft asks some questions about how the software works, and Miller informs Lovecraft that this aspect of the software was worked on more by another developer in the team—perhaps Lovecraft should call her?
The meeting ends with Lovecraft thinking Miller is careless and unwilling to help make effective end-user documentation; Miller takes from the meeting that Lovecraft is inexperienced, yet arbitrarily bureaucratic about obscure grammar rules. Lovecraft submits the “finished” help menu to management, but an inexpensive usability test using only five people reveals that the help menu incorrectly defines terms and miscatalogs others; in addition, the software has a number of errors.
The above scenario can be better understood using Goffman's concepts of role/script, setting/rehearsal, and self-presentation/impression management.
A. Roles/Scripts
Lovecraft performed what Goffman calls “discrepant roles” or the “over-communication of some facts and the under-communication of others” [5], p. 141. He chose to “under-communicate” the limitations of his knowledge with this type of software, whereas he “over-communicated” grammar knowledge in an attempt to assert role authority over Miller in a play that is now a tragedy. Besides being an ethical breach, this miscommunication contributes to negative stereotyping and blocks effective collaboration and, consequently, good documentation and happy customers.
The above scenario had an adequate cast, or “role set” (development team, management, software, technical writer, users, etc.), but a successful software development script would have more interaction among cast members. For example, Miller stereotypes Lovecraft as a stiff grammarian, a label that limits communication and ultimately affects user satisfaction via poor documentation.
Notice in the above scenario how the technical writer meets with management and not with the engineer/software developer until much later. Lovecraft could have met with the entire development team sooner and more often. In addition, Miller could have been more forthcoming with information rather than referring Lovecraft to another software developer on the team.
The technical writer should meet with management, but it is more appropriate that the technical writer impress the developer; in other words, the majority of Lovecraft's effort needed to be spent enacting a good script (professional, helpful technical writer consults with knowledgeable, eager engineer to create an effective help menu). Miller should recognize that the technical writer's expertise in this scenario is to communicate technical information to a lay audience. Perhaps Miller should encourage Lovecraft to be involved in more of the process. Although Lovecraft was not hired until the software had already been developed, Miller could have consulted Lovecraft about the usability testing.
B. Stage Setting/Rehearsal
Lovecraft did very little to rehearse or prepare for the meetings. He accepted the contract without knowing all the facts: information about the company, knowledge of the software program, availability of the development team, etc. Miller also did not rehearse before meeting with Lovecraft; there was no email exchange regarding software points to help Lovecraft develop the help menu or questions to Lovecraft about other insider information he might need. Management also possibly contributed to setting an undesirable stage by hiring (“miscasting”) a technical writer who has documentation experience but not in this type of software.
C. Self-Presentation/Impression Management
Although Lovecraft may have made a positive first impression with management, he did not make a positive self-presentation during the meeting with Miller, and Miller certainly did not offer Lovecraft enough time and information. According to Goffman, the theatrical metaphor allows us to
consider the way in which the individual in ordinary work situations presents himself and his activity to others, the ways in which he guides and controls the impression they form of him, and the kinds of things he may and may not do while sustaining his performance before them. [5], p. xi
When applied to Widgetech, we immediately see the relevance. In this scenario, the engineer stereotypes the technical writer as a bureaucratic wordsmith—“Make this change because that's what regulations require”—or fussy grammarian—“Make this change because it's correct according to some rule of use.” We see that Lovecraft, by critiquing minor surface aspects of the developer's work so early in the meeting, has enacted an inappropriate script. A more suitable script would involve words and actions where one actor (the engineer) perceives the other (the technical writer) as competent, trustworthy, and optimistic [5], p. 1. Miller's apathetic attitude about the project did not help Lovecraft at all. Also, Miller's narrow-minded opinion about punctuation and paragraphing created a communication barrier that resulted in poor documentation.
The most important component of this scenario, of course, is the most neglected: the end user. Poor usability testing, mutual stereotyping, inappropriate scripts, lack of rehearsal, and weak impression management all contribute to communication misfires and impede good documentation development. Goffman's theories help us realize the importance of effective communication in the technical writer–engineer relationship.