TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: TECHWR-L Digest - 5 Jan 1995 to 6 Jan 1995 From:"Usability Expertise Center ph.603.881.2430" <raven -at- USABLE -dot- ENET -dot- DEC -dot- COM> Date:Mon, 9 Jan 1995 09:45:03 EST
Re: Dealing with Engineers' Input
This is from Mary Beth Raven
I have a few suggestions, and an anecdotefrom my
dissertation--an ethnographic study of how engineers and technical
writers communicate during the creation of a document.
First, I recommend that the "face to face" input session be
formalized in some way. That is, call a draft review and get all the
engineers who reviewed your document into one conference room
together. (This saves a lot of your time--instead of meetin gwith each
and getting conflicting comments and then running back and forth
between them all to resolve it). Some people use a very formal
document inspection method--but I don't really know where to send you
to get more info about that, other than to Roger Grice's dissertation,
and I don't have the citation, he's at 73444 -dot- 3234 -at- compuserve -dot- com).
PUblicly declare that you must resolve any techincal discrepancies
between engineers during that meeting--it saves you and the company
lots of time and frustration!
Second, prepare the engineers for the draft reviews by
explaining to them exactly what you want them to look for--I usually
put this in a coverletter. Then at the beginning of the meeting I
reiterate that this is a meeting to review technical accuracy of the
document rather than issues of layout, organization, or style. Many
engineers have never had any training in how to review a document, and
they get caught up in the little things like typos. I usually tell
them that their time is very valuable, and they need to concentrate on
technical accuracy and leave style and typos and things to the editor.
Now--the anecdote--In two writers that I studied, both had
"problems" with engineers who wanted to comment on everything and felt
it was their domain to demand changes in things like layout and style.
I"m sure many of us have been there--engineers insisting that they
change active voice to PASSIVE voice, and things like that. As soon as
possible, make it clear that as the technical communicator, YOU, not
the engineers, are in charge of things like grammar, style,
presentation (e.g. deciding whether the book shoudl be 7x9 or 8.5x11)
and stuff like that.
My 2 bits,
MAry Beth Raven
Digital Equipment Corporation
Nashua, NH
