Teaching and Unteaching Engineers to Write in the Workplace: An Editor’s Perspective

By Bradford R. Connatser | Senior Member

I work with engineers, mostly electrical engineers, to ready their documents for publication. Many technical communicators work with engineers, translating their chewy prose into something more easily digestible. During his keynote address at Adobe Day during the STC Summit in Phoenix (18 May 2014), Senior Adobe Product Manager Kapil Verma revealed a sobering statistic: 76% of technical communicators report that they work with engineers. And those of us who work with engineers know that developing excellent communication skills takes a backseat to mastering engineering during their formative education.

Teaching engineers best practices in technical communication and unteaching their worst ones in the workplace can be a challenge for professional communicators. Reversing the entrenched, adverse writing habits of engineers may take more than marginal comments in a Word document. This article describes ways in which you can help to improve their documents through solid technical communication, from subtle suggestions to full-out group training.

Note that when I say, “Engineers do this” or “Engineers do that,” I mean engineers where I work and whom I have encountered, in general. You can substitute subject-matter expert for the term engineer, but there may be substantive differences between an engineer and, say, a chemist or a banker.

Leveraging a Philosophy of Technical Communication

As technical communicators, we try to understand the needs of the reader. We ask authors pointed questions, such as, “Who is your intended audience? Can you characterize your readers? What do you want them to get out of this? Do you want them ‘to learn,’ ‘to do,’ ‘to learn to do’?” But do we really understand the concept of the reader? Do we really know how documents communicate ideas from one brain to another?

Many of us simply do not have time to develop a robust philosophy of technical communication that includes all of the actors involved in the process. Over my 23 years as a professional editor, I have developed a philosophical bumper sticker that helps keep me grounded: Write for the reader. It reminds me that reading creates a dynamic relationship between the reader and a fictional version of the actual author, which Wayne Booth calls the implied author (consult Booth’s The Rhetoric of Fiction or Roland Barthes’ essay “The Death of the Author” for more details). The implied author talks to the reader, and the reader hears the content of the document through the voice of the implied author. Each reader, reading at a steady pace (not too slow, not too fast), synthesizes the voice of the implied author to create a unique meaning.

The talking that goes on during silent reading—sometimes called speech encoding—is essential to the process of fluid reading. This process happens “automagically,” without the intentions of the reader or the designs of the author. It just happens. Which means that conscientious, courteous writers have to account for what their readers hear, for what their readers say. Then, actual authors will likely create accessible, coherent implied authors and become reliable narrators of their stories.

If you make engineers sensitive to their audiences, then you give them impetus to accommodate entrenched behaviors of their readers, which is another way of saying that you give them a reason to improve their prose. Second, if you cause engineers to understand the reading process at least to some degree, then they can attach rationale to your recommendations to them—that constitutes teaching.

Opportunistic lessons may be very small, but they can also be very powerful. As you mete out micro-lessons over time, you inculcate a reader-centric philosophy into the brains of engineers. And because they are intelligent, this works.

Some of the lessons teach, but others unteach, such as teaching an engineer to not put two spaces between sentences. You can provide technical reasons for unteaching what engineers have been taught, but the greatest reason of all is the reader, who may know the correct rule and abruptly become the enforcer of it, clucking over the author’s prose. So, your marginal lesson might take the form of: “One space has become the law of the land for formal publications, and style manuals with enormous clout insist upon it. Your readers may know this rule and become distracted from what is otherwise an effective composition. Please don’t give your readers ammunition to shoot down your message.” Notice that in this fictional micro-lesson, I included the term your readers twice. It’s that important.

Now, here is a challenge. When you base a lesson on your personal philosophy of technical communication, and the conclusion of your lesson is in controversy, how do you convey your advice? Gently, I suggest. For example, in electrical engineering, whether or not to capitalize AC when abbreviating alternating current is an example of a style in controversy, and resolutely insisting on doing one or the other may place the engineer in a battle he would rather not fight. If the engineer expresses incredulity about your recommendation, encourage him to Google the controversy, enabling the engineer to perceive two things: first, that there is a constellation of people who care about such things, and second, that the engineer is in full sovereignty of his linguistic destiny on the matter.

A Case Study: Four Ways to Teach and Unteach

The many ways to teach and unteach engineers to write better prose range from the conspicuous—such as conducting formal courses endorsed by your employer—to what I call stealth education, which is an attempt to impart knowledge to engineers without being conspicuous. What follows are four ways to educate engineers, and they cover the complete spectrum of intervention, from the full-on single- or multi-day courses to subliminal suggestions. Each may not fully apply to your situation, but perhaps you can glean some pointers and modify them to work for you.

1. Compose a Formal Course or Presentation on Effective Technical Writing

Here are the steps I took to develop and implement a course on technical writing for engineers after getting buy-in from management. The ideal situation in which to teach engineers best practices in technical communication (and unteach their worst ones) is to have a captive but engaged audience, where you control the discourse but enable the students to express confusion or frustration with a principle and perhaps participate in exercises.

Prepare Your Materials

• As you edit content you receive from engineers, raise your antennas to detect common impediments to fluid reading and potential causes of misreading. For example, identify the damaging inertia of tradition and “superstitions” (such as double-spacing between sentences). What constitutes a superstition in writing? According to dictionary.com, a superstition is “a belief or notion, not based on reason or knowledge, in or of the ominous significance of a particular thing, circumstance, occurrence, proceeding, or the like.” As Stevie Wonder says, superstition is “when you believe in things that you don’t understand.” When engineers adhere to rules that modern editors dismiss as invalid, those superstitions should be recorded and addressed during training.
• Acquire meaningful real-world examples. Use the good stuff that engineers write as well as the not-so-good. Harvesting their good writing practices and disseminating them to others are beneficial to education.
• Research, explore, and experiment (surreptitiously if necessary) to test your observations. For example, in 2003, I conducted an experiment using engineers as my subjects. My hypothesis was that the putative rule for harmonizing a parameter value and its unit of measurement was faulty: that is, “Use the singular unit of measurement for values between 1 and -1, inclusive.” Based on the experiment, I discovered that the intuitive rule is different (namely, “Use the singular only for the number 1—not zero, not negative 1, not 0.1, or any other number”). This result was published in Technical Communication, which added clout to my encouraging engineers to use this “new” rule (see “Reconsidering Some Prescriptive Rules of Grammar and Composition” in Technical Communication, May 2004).
• Outline, annotate, prioritize, and pace your lessons. Don’t try to fill their brains in a single course. Marathon sessions are not productive, and a two- or three-day courses may require more time than engineers have to devote to post-grad education. Allowing time for them to reflect and apply what they have learned incrementally is essential to the desired outcome of education in the workplace.

Teach and Unteach in a Formal Setting

• Introduce engineers to their readers. I do this with a top 10 list, such as “Top 10 Things You Didn’t Know That Your Readers Do.” Once you demonstrate how complex the reading process is, engineers are more likely to make adjustments to their writing to accommodate readers.
• Hit the biggest offences early and provide many real examples harvested from their own writing. You may be tempted to create examples, but fabrications are not as powerful and relevant as real-world ones.
• Integrate live exercises into your course. For example, noun strings are indigenous to the writing of engineers. During formal training, I present engineers with many examples of noun strings and ask them to repair them by using a three-step process: Identify it, determine the meaning and relationships between the words in the string, and re-compose the words using connective tissue (mostly prepositions), which typically results in re-arranging the words.
• Integrate enabling technology into your course. During exercises, I project the monitors of the students onto the screen to show the class how effective revision can be accomplished in several ways. I also use explanatory animations to visualize reading processes.
• Handle resistance to change sensitively and with compassion. Asking engineers to consider old rules in new ways can engender confusion and incredulity. Concrete examples help engineers reconsider errant writing practices that persist due to assumed efficacy (“superstition”). There are many ways to introduce engineers to new ways of doing things, but I’ll limit the list to three.

1. Trace Changes in Usage

The word putative is used to describe a consensus of usage, such as the putative spelling of a word. However, when spellings are in controversy, how can we prove that our recommended spelling is the right one? Ngram has come to my rescue on several occasions. Engineers love charts and graphs, and ngrams serve as clarifying narratives about the competition between two or more words or phrases. At books.google.com/ngrams, you can visualize how word usage changes over a vast time (decades or even centuries) and fortify your position on prevailing usage. Encourage engineers to conform to the latest forms or trends. For example, consider how some phrases evolve from open forms, to hyphenated forms, to closed forms. The ngram in Figure 1 illustrates how health and care have been represented as a unified concept: open, hyphenated, and closed, and while the open form still prevails, its usage is in decline, while the trend for the closed form continues to rise.

The slow but certain evolution of some irregular verbs to regular (inflected) verb forms is another trend supported by ngrams. For example, consider the past tense of burn in the ngram in Figure 2. Some people hang on to the obsolete form (burnt), and showing them the ngram below clearly demonstrates prevailing usage.

The haphazard Anglicizing of some irregular Latin and Greek plural forms also causes confusion and inconsistency among engineers. Antennas is supplanting antennae, but indices, spectra, and appendices endure, as shown in Figure 3, remaining the putative plural spelling. Sometimes, the old way gets its way.

2. Introduce the Concept of “Two Grammars”

“That’s not what I was taught.” I’ve heard this sentence several times. It reveals the tensions between synthetic grammar (also called normative or prescriptive grammar) and organic grammar (also called intuitive grammar). On occasion, these two grammars fight one another. I introduce the concept of notional accord to engineers to clarify these tensions. For example, many grammar mavens would agree that when you use none as a subject, the verb should be singular, as in, “None of the steel was compromised.” However, the prepositional phrase that always follows none bears upon the subject/verb agreement in notional accord. “None of the people was injured” may conform to the prescriptive rule “none takes a singular verb,” but it violates notional accord (intuitive grammar). What is the notion of none in its context? Is it singular, as in steel, or plural, as in people? Explaining to engineers that rules come from two distinct sources—one from DNA and one from the classroom—and encouraging them to weigh their rhetorical and grammatical choices in favor of the reader will help them craft better, more reader-centric prose.

3. Recognize That Engineers Are Expert Communicators

Engineers are not professional communicators by education and practice. They must write as part of their profession, and this part of their duties is often an afterthought. However, engineers are experts in communicating their ideas. They do it successfully day-in, day-out—on the phone, in an email or text message, through social media, or face to face. But formal expository writing raises the bar immensely. In a technical report or an instruction manual, formality and correctness prevail, based on the reader’s expectations of correct, clear, thoughtful prose. Editors should make a sincere effort to avoid condescending to engineers because they are successful in their conveyance of ideas to their peers and clients. We are here to “simply” help them when it comes time to declare and publish those ideas in formal communication genre.

• Establish an open-door policy by inviting engineers to come to you for questions. Act on any interest in technical communication that an engineer expresses by immediately engaging him and, if appropriate, suspending the conversation until you are prepared to inform the inquisitor with research that you have conducted during the interim. When engineers are reluctant to do things differently, the why becomes an essential component of successful education.

2. Provide On-Grid Sporadic Education

My favorite way to provide sporadic education is to send an email to engineers asking them for their opinion on a linguistic question, which sometimes spawns an enlightening discussion. I refer to this as “in-reach”—reaching in to the engineers within my organization and initiating dialogues about writing. Using your internal email, you can send observations and tips to people whom you know to be interested in improving their writing skills—as you encounter problems that become opportunities for teachable moments.

Sometimes an engineer drops by my office or invites me into his office to ask a simple question. I use these opportunities to broaden the question and transform it into a lesson. For engineers at the beginnings of their careers, this type of sporadic education can take the form of mentoring. Mentoring young engineers to improve their writing is to go out of your way to speak to them without pressure. I recently conducted a one-hour course on technical writing for the Early Career Network at my employer. This was an introduction to the concept of considering the audience and preventing/repairing noun strings. But it was also an introduction to me as a resource for them.

3. Provide Off-Grid Education

I implement off-grid education by composing and sending tips to an email distribution list of engineers (and other staff) who have expressed an interest in receiving them. Here’s how I made it work:

• I purchased a Web domain for a website (thedocwriter.com). The domain costs $15 a year, and I host it using a Web-hosting service that I’m already paying for.
• I created a website to present the tips. I decided to store my tips in a Microsoft Access database, with each record being tagged with things like key terms and categories. Also, I wrote some code to enable visitors to search the database, as well as code to link key terms to a dictionary.
• I send out periodic invitations. Each invitation contains an abbreviated form of the tip itself, and my tips are always progressive, from a title, to the abbreviated tip, to the tip in full, and then finally to an essay on the subject (in some cases). Invitees can bail on the tip at any stage, preventing them from wasting time on subjects with which they are already comfortable or items in which they have little interest.

Of course, your implementation of off-grid education does not have to be so time-consuming. You can simply build a distribution list and pitch out tips ad hoc.

4. Provide “Stealth” Education During Review and Editing Cycles

Through stealth education, I find opportunities to slip in pithy, relevant lessons about technical writing, usually in the margins of a Microsoft Word document that I’m editing. Sure, you can change since to because, but will the engineer learn from that edit without your guiding comments? Why not embed a micro-lesson in subordinating conjunctions? Perhaps point the author to your tip site.

Sometimes, the engineer will get the lesson from repeated corrections. For example, one engineer had a habit of placing his transitional conjunctive adverbs (such as however and therefore) in the middle or at the end of his sentences instead of at the beginning where they belong, often interceding between the subject and its verb or the verb and its object. I made several dozen changes to these intercessory conjunctions, without comment, and his next report was resplendent, with his conjunctive adverbs taking their proper positions within his sentences.

The little lessons in the margins build momentum for the big lessons in more robust channels, such as training courses and communication tips. But editors and engineers alike are in a hustle to get documents delivered on time. The danger in crafting terse lessons in haste is accidental condescension or hurtful “discoveries” of an engineer’s linguistic inadequacies. In other words, when implementing stealth education, be aware of the author’s ego.

Negotiating Difficulties

The proper metaphor for continuing education is not a superhighway to knowledge but a winding road that requires vigilance and caution. There are several difficulties related to teaching and unteaching engineers to write, but here I’ll limit the discussion to three: dealing with a “big pencil,” establishing authority, and managing plagiarism.

Dealing with a “Big Pencil”

Sometimes I deal with engineers who are proud of their writing skills but have not been formally trained in technical communication and therefore do not understand the nuances of best writing practices. I call these engineers “big pencils” because they have and sometimes exercise veto power over my edits. They generally are superior writers and make an editor’s first pass easy. However, they tend to reject edits as superfluous or inconsequential. Relentless iterations to reach a compromise are sometimes futile, and an editor may lose a big pencil as a client if he or she is not treated with respect.

Editors must be sensitive to the psychologies of big pencils. When commenting, try to be modest and gentle. Remember that the stigma of red editorial marks haunt many engineers, so consider changing the color of your changes and comments to blue or another hue.

Establishing Authority, Dealing with Resistance, and Taking It Easy

Your credentials—no matter how impressive—do not automatically confer authority to you in the discipline of technical communication. Earning a reputation for good work over time will, in theory, establish your authority on the subject. Still, some engineers will resist your recommendations to improve their documents, and some will strive to compete with you, and in the aftermath of any competition, there are winners and there are losers.

For me, “competition” or “subordination” is an unacceptable way to frame a relationship between a subject-matter expert and editor. To achieve parity in an engineer/editor relationship, you have to continually find new ways to improve the writing of engineers as painlessly as possible and delicately explain the reasons for following effective rules. But when you meet with stark resistance, turn the other cheek. When an engineer indignantly revolted against my relentless hyphenation of unit modifiers, I dutifully repeated the renowned quote in the Oxford University Press style manual attributed to its editor, John Benbow: “If you take hyphens seriously, you will surely go mad.” So giving in is not necessarily giving up. Conceding the imperfections in our rules of grammar and mechanics may open the door for respect.

What makes good teachers (as well as good people) applies here: compassion, kindness, empathy, even tenderness, if you can conjure these under the pressure of your deadlines and the day’s frustrations. Egos are often the sacrificial parts of the review and editing cycles. Like brake pads on your car, they wear down with normal operation. Wearing down egos to bare metal simply turns the engineer away from you. To get respect, you have to give it.

Of course, you can always shrug and say, “I didn’t make the rules,” which works as a kind of salve for the chafing sores that sometimes erupt between author and editor, but that does not instill confidence in your authority. If you believe in a rule, own it, defend it. Otherwise, confess your uncertainty in terms that at least reveal thoughtfulness. But if you wallow in ignorance, you may become a victim of low expectations.

Managing Plagiarism

Plagiarism, especially self-plagiarism (also called reuse or repurposing), can be a difficult concept to grasp. When John, an engineer at Acme Engineering Services, is hired to write a document for Sigma Electrical Research Corporation, the resulting document belongs to Sigma. Yet the words are his, and he feels a sense of ownership, an innate entitlement to reuse them at will. This is called self-plagiarism, and it is not an exception to the common prohibition against ordinary plagiarism. In fact, this form of plagiarism is more insidious than ordinary plagiarism because it is so misunderstood, but it is just as likely to result in copyright infringement as the ordinary kind.

Not all “borrowed” words in a document constitute plagiarism. Properly cited sources of material are in fact necessary for advancing scholarship in a given field. But when an author lifts material from another document and presents it as his original thoughts, then not only does he engender scandal, but he also risks censure from his employer and the scientific community to which he belongs.

What is a company to do about this? Third-party software can help by objectifying plagiarism for engineers, definitively showing them sources of unoriginal content that appears in their documents (which may or may not be properly cited). One such program, iThenticate, enables anyone with an account to upload a document and receive a “similarity index,” which is the percentage of content that can be found in other sources of materials that have been collected in a database (called CrossCheck) or that exist on the Internet. Once engineers have experienced a high similarity index, the specter of future high similarity indices from third-party software should motivate them to curb the outsourcing in their prose.

Because plagiarism can be accidental, its discovery is not necessarily an indictment of the engineer but an indictment of the document, which can be exonerated or repaired with discretion. False positives can be swiftly dismissed, but when you discover true plagiarism, clearly explain the offence and offer ways to correct it, such as using proper citation and introduction of “borrowed” content.

Conclusion

When engineers graduate from the academy, their once-elastic notions of expository writing get locked in amber, and it’s up to technical communicators to drill in, like the pseudo-science in Jurassic Park, and re-animate that organic matter, preparing it for new ideas about what constitutes a good sentence. As university engineering programs graduate bright-eyed students into the real world, I keep seeing the same mistakes in linguistic craftsmanship, despite their high intelligence. If academia will not remedy this problem, then who will?

All of the efforts described in this article to teach and unteach engineers may seem like a lot of bother. And they are. So why do it? Why teach in the workplace when the tangible professional rewards (such as awards, promotions, and raises) are elusive? First, because you can provide insight into the writing process, the resulting improvements in communication make the author look good, make your employer look good, and ease your job. Another benefit of teaching is growing your own skills. Putting yourself on the line as an authority encourages you to learn and master your trade at a high level. Finally, it’s simply satisfying to help engineers succeed by expanding their linguistic knowledge beyond mundane rules of English composition, enabling them to take a more thoughtful approach to their writing chores.

By teaching and unteaching engineers, my purpose is to improve the quality of the documents that engineers abundantly produce. This relentless stream of documents, in fact, is the linchpin of ongoing research at the core of my employer’s mission. To help keep the flow of high-quality information going, teaching and unteaching engineers to write is a warranted (if not lauded) endeavor that we technical communicators should proudly own.

Acknowledgment

The author thanks ace editor John Webb for his indispensible and transformative review of this article.

BRAD CONNATSER (bconnatser@comcast.net) has been writing and editing technical documents for over two decades. He has authored dozens of articles in trade magazines and peer-review journals. Brad taught technical communication and English composition at Temple University, Maryville College, and Pellissippi State. He has served in various capacities in the STC East Tennessee Chapter.