|
|
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.
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:
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
|