How SHOULD Engineers Write? What Their Managers Say
Could the Challenger disaster have been averted with more persuasive writing on the part of Morton Thiokol engineers? The Rogers Commission report reveals there was test data showing the O-ring that failed in the launch was highly sensitive to cold. Engineers were unsuccessful in convincing the decision-makers of that crucial fact. How can engineers make sure their findings are understood?
A technical editor with RCA says that any message needs to answer three questions:
- What are the facts?
- What do they mean?
- What do we do now?
Managers assert that many engineers don’t clearly state what the facts mean.
This is only one of four writing problems that engineering managers consistently mention. The others are imprecise writing, technical jargon, and haphazard organization. Let’s start with the problem of failing to communicate clearly what the facts mean.
1. UNCONVINCING PRESENTATION OF DATA
Dorothy A.Winsor, in her book entitled Writing Like an Engineer, points out that engineers assume the data speaks for itself. Winsor suggests that “objects and data need a spokesperson who will stand between us and them to tell us what we see.”
Anca Voicu, Product Engineering Manager in the uPower SRAM Division of Cypress Semiconductor, says “One of the trends we see here in the engineering world is, when we run different device qualifications or a fabrication process, engineers present the data [in this way]: this is what we ran, and this is the data, followed by pages and pages of data (our VP calls it ‘data dump’), but [it’s] kind of meaningless. So we have been trained to follow the 3W rule:
- What do we know/what is the data – present history plus data
- What does it mean – we do have a problem, or marginality, or an issue
- What do we do about it – now that we know that we have this problem, what should we do about fixing it?
This last W should have a plan with the real schedule in work weeks, and owners with names assigned to it, so that we can track the progress, and get an update regularly, until the issues are fixed.”
These questions expand on those of the RCA technical editor.
2. LAZY, IMPRECISE WRITING
Even though on-the-job writing has become more conversational in the past few years, some writers carry it to the extreme. Using plain English is one thing, but using expressions that border on slang is another. Delete words or phrases that cross the line of professionalism and change the style and tone of a document.
University of Wisconsin professor and writing consultant Hank Sparapani says, “Participants in my writing workshops frequently intone the ‘write the way you speak’ idea. Consistently I have answered along these lines: If you speak ‘well,’ do so; if you speak ‘good,’ don’t!”
Lazy language irritates Manager Jan Reimer of Cirrus Logic, Inc.: “The biggest struggle I have seen is to avoid “Shop Talk” in technical writing, i.e., using casual conversational phrases, which are typically incorrect, technically and grammatically, in written reports. A response such as ‘but everybody knows what I mean’ is a poor excuse for not expressing oneself properly, especially when the authors sign documents with their names [attached].”
A conservative approach to keeping writing conversational without crossing the line of professionalism is to avoid writing anything you wouldn’t say. When writers avoid terms they would never use in speaking, writers connect better with their readers. Most of us don’t use “heretofore” in speaking. The use of such words in writing causes the reader to be distanced from the writing.
Reimer of Cirrus also bemoans incorrect word choices in lazy writing. He says, “An example in technical writing is the incorrect use of the words ‘precision’ or ‘precise’ for ‘accuracy’ or ‘accurate.’ ‘Accuracy’ refers to the true value of a measurement, and ‘precision’ refers to the repeatability of a measurement.”
In instances like this, use your dictionary. The American Heritage Dictionary is a good choice, and The Random House Webster’s Pocket Computer & Internet Dictionary makes a nice accompaniment. Dictionaries are not obsolete—even with technology at our fingertips.
3.TECHNICAL JARGON
Technical concepts are complicated enough without making them incomprehensible by using ambiguous language, acronyms, or tech-speak. Engineers would do well to consider the Malcolm Baldrige approach to using plain English. Baldrige was a plain talker from Wyoming who was appointed Reagan’s Secretary of Commerce. He had the computers programmed in the offices of Commerce to detect buzzwords and buzz phrases. Baldrige considered this language reflective of “a subconscious urge to cover oneself.” Every time employees used a buzzword on the Baldrige list, their computer screens would flash “Don’t use this word!” An extreme approach, but effective nonetheless.
Consider the technical reports that engineers write for top management. The executive summary, the part of the report that managers read nearly 100 percent of the time, needs to be written in the simplest English possible. Although it’s important to sound professional, it’s more important to be understood. In reality, you can do both. A writer can put together a proposal using plain English and still land the work. Why complicate the issue by using obscure or complex terminology?
A good rule of thumb is to use the longer word only if it adds color or clarity. So why “utilize” when you can simply “use”?
A participant in one of my workshops told me recently that her brother, a contract employee with a computer company, got the following answer about becoming a permanent employee: “We’re actualizing that action plan and it’s in the pipeline.” He’s still wondering if he’s going to get the job.
Engineers use too much jargon, forgetting that readers might not understand their word choices. Sometimes engineers invent terms using strings of nouns such as “three-dimensional rectilinear productivity habitat”—a “cubicle” in layman’s terms. (Perhaps the inventor of this noun string thought the manufacturer could charge by the word!)
The goal of one semiconductor company is “to target high-end niche markets with state-of-the-art high performance, complementary metal-oxide silicon (CMOS) circuit products.” A lofty goal in lofty terms. These terms can confuse the reader who isn’t clear about how the nouns relate to one another. Instead of saying “consolidated invoicing with individual departmental charge-back detail reports for each billing code,” say “compile a report that details the charge-back transactions for each billing code.”
Plain English can save an organization money. In 1984 a government agency in Great Britain rewrote the application forms for legal aid. The agency reported that, while the new forms cost $34,500 to write and test, the department saved $2,069,000 in the first year. No one had to interpret the writing!
4. HAPHAZARD ORGANIZATION
Not taking time to organize thoughts before sending an e-mail message is a consistent problem in engineers’ writing. A few minutes spent on organization can achieve productivity on both sides of the communication. The writer won’t have to clarify later because the reader will get the point in the writer’s initial e-mail.
Harvey MacKay stated in his newspaper column that an Office Team study showed that people waste 14 percent of every workweek due to unclear communication, both written and verbal. Fourteen percent equals seven weeks a year!
For e-mail messages, writers would be better off to have a format in mind for putting across the majority of their information. I advocate the PAPER format in most instances:
- Purpose for writing
- Action to be taken by either party
- Particulars or details associated with the situation
- Evidence – mention of any attachments
- Request for response – either by phone or email
Regarding organization of reports, Paul Wesling, Advisory Design Engineer at Compaq Computer Corp. in Cupertino, says, “Engineers tend to hide the important facts and conclusions under lots of discussion, making it hard to figure out what point is being made. One of the most important skills they can learn is to properly organize the key findings in a ‘summary’ section at the start of the report. The summary headings I like most: a brief Statement of the Problem or Opportunity; a Listing of Results or Findings; and explicit Conclusions and Recommendations that are supported by the details in the report. It helps the engineer get quick action, rather than yawns.”
________________________________________________
In sum, next time you write an e-mail or report, remember the four commonly missing elements in engineering writing: (1) persuasive presentation of data; (2) conversational yet professional writing; (3) plain English; and (4) crystal clear organization.
This is a re-posted article written in 2005 by Kathleen Kohnert of Speak and Write.