Teaching an Engineer how to Write

 

Home            

Resume         

White Papers

Presentations

 

Teaching an Engineer how to Write

Every manager can help technical types translate their knowledge into actionable business communication.

An ENGINEER, The old joke goes, is the type of person who would rather take a telephone apart than use it to call his mother. This bit of humor actually reveals a truism of the engineering world: sometimes, engineers’ close attention to how an object works causes them to overlook the object’s larger relevancy.

This focus on analysis and understanding helps the engineer in his job, but it can stymie you in yours as his manager. Say you want to make a compelling case for a bigger chunk of company resources. If the technical members of your staff can’t persuasively articulate how their proposed projects will translate into bottom-line business payoffs, your bid is going to be dead in the water. 

Fortunately, there are strategies you can employ to help engineers and other technically inclined types on your staff create clear, cogent prose.  

Why they write that way

Engineers’ personalities and education deserve credit for work that has greatly improved our lives. Their accomplishments have come largely from manipulating things. Thus, to them, the object is paramount. It’s what they work with, design, and control. Engineers’ language naturally reflects such concerns, which can lead them to construct wordy, noun-filled, passive-voice sentences such as:

 “The 10-32 1-3/4 inch wood screw was driven into the hickory with a Phillips head screwdriver 5-3/4 revolutions.” 

Moreover, engineers tend to organize their thoughts around their understanding of a system. But their non-engineer peers and managers care less about the objects that make up a system and how the system works than they do about what that system as a whole can help them accomplish.  

Engineers also are often reluctant to try to convey ideas to those outside their field because they are unsure how to communicate with those who lack specialized knowledge. As we all like to stay within our comfort zone, with engineers, that means they may have little experience talking plain English to everyday people.

Thus engineers have a difficult time understanding how to write for other audiences. There’s a vast difference in expertise between engineers and any other audience. And they have a big fear of ‘dumbing down.’ – i.e., to speak in a plain simple language 

Some engineers and other technical specialists are uncomfortable working in what they perceive as the subjective field of writing. Technical work is a complex, highly rules-based enterprise. Writing well is also a complicated endeavor but one whose rules are decidedly less absolute. Thus engineers, accustomed to their cut-and dried world, hesitate to labor in a less objective discipline.

Improving engineers’ communication


To advance their business unit and further their careers, technical types sometimes have to communicate their specialized knowledge to a non-technical audience. Here are four ways that a manager can help them do this:

1. Define the audience’s needs for them.

Engineers face the same problem as all of us: - “How do we talk about what we do in ways that are useful to others?” 

Engineers are used to answering questions from other engineers, but managers typically ask questions that serve different needs. So you must articulate those different needs. Once engineers understand what a reader wants they find constructing individual sentences easier. 

For example, say a metallurgist at an auto company has been researching why a prototype’s piston rod continues to break. She may be tempted to present her results as if she were addressing an audience of other metallurgists, using specific terminology and framing her results to satisfy the questions other specialists in her field might have. But discussing the piston rod’s metallurgic properties won’t help design engineers, who seek information about redesigning the system, nor would doing so aid managers, who want to know how long the problem will take to fix and which processes will be affected. The more managers can identify which questions need to be answered the more successfully engineers can rise to the challenge on their own terms. “Focus on usability, not readability”. Engineers are more familiar with the concept of how readers can use documents than they are with what seems to them the vague concept of readability. 

How do you make readers’ needs more concrete? You might try creating a representative reader, one you describe in detail. Alan Cooper, author of The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity (SAMS, 1999), suggests introducing  engineers to a persona—a hypothetical but specific audience member. Since engineers love the tangible, he advises using specifics, including a name and a face, to make that pretend individual distinct. “For example, we don’t just say that Emilee uses business software. We say that Emilee uses WordPerfect Version 5.1 to write letters to Gramma… [and drives] a dark-blue 1991 Toyota Camry with a gray plastic kid’s seat strapped into the back and an ugly scrape on the rear bumper.” 

2. Probe.

When technical specialists are uncomfortable addressing non-technical audiences, sit down with them and ask the types of questions that will elicit the responses you’re looking for. Keep asking questions to get them down to the appropriate level:

“What’s the assumption under that? 

“How did you get from point A to point B?” 

“Will your audience understand that word?”

Interaction with others is the only way to help engineers reach beyond their disciplines. “It’s just practice, practice, practice.”  

3. Help them structure the document.

When business manager edits engineers’ reports, they usually have to reorganize. A need to restructure often results because the writer did not use any sort of an outline. (Or he wrote the outline as a last step.) For instance, factual information may appear in the “Recommendations” section, or vice versa. This problem is ironic because the same engineer who mixes up parts of a report on a ground water study wouldn’t dream of completing the steps of the study haphazardly. 

A manager can help a technical specialist structure his writing by providing an outline or a sample document that serves as a template. The writer can use such a concrete, tangible model in much the same way as he uses a set of formulas or follows certain rules, knowing that they work because they’re proven. 

Managers also can increase their effectiveness in communicating with engineers by adopting some of their language. What if, when handing over that outline, you called it a flow chart? Most engineers are familiar with flow charts, which detail the steps they need to take to move from an initial state to a desired outcome. In essence, that’s what an outline does. So why not frame it as such? 

4. Help them edit and format their work. 

You can help technical types achieve strong, unambiguous writing by working with them to eliminate jargon and edit unclear sentences. The first draft of a report may contain too much technical language and too many passive-voice constructions, as well as too few and/or too many disclaimers. That doesn’t mean the report’s ideas are not sound. 

Simple rules exist on how to eliminate the passive voice, for example, or how to substitute smaller words for bigger ones. Furthermore, computerized word-processing tools, while far from perfect, allow such rules to be applied quickly and comprehensively. But this best done after the rough draft is complete—there’s no need to get the writer bogged in too many details until she has got something down on paper.  

Once the document is nearly complete, help the writer format it so that its information is more accessible. Highlighting the most important ideas with headings, lists, and boldface can help drive home the points that you want the document to make. An added bonus is that such formatting can distract from weak supporting prose.

 

Home  Resume White Papers  Presentations

 

Hosted by www.Geocities.ws