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: Engineers as Writers From:Len Olszewski <saslpo -at- UNX -dot- SAS -dot- COM> Date:Wed, 18 Aug 1993 12:39:05 -0500
Pam Tatge writes about working with SME's (much good insight deleted):
> Of course, some projects fall between these two extremes. We
> treat these as opportunities to show the SMEs how we can
> make their lives easier. (We can't just tell them that we
> write better than they do--that will only make them angry.)
> The more people who can communicate well, the better. If you're
> helping engineers and scientists to become effective communicators,
> great. But to me, the word "yield" implies an "us-and-them"
> situation, which is counterproductive. Good documentation is
> a team effort.
Naturally, Pam is correct. For many, however, a documentation project
which is a true team effort with SME's is a goal, not a reality. Our
colleagues who contract and sub-contract for a living come to mind, as
do those who are "first" technical writers in a company, usually
underpaid, just out of school, etc.
Ironically, engineers and software developers each complain about the
same sort of thing; trying to meet the needs of clients or managers who
under-specify an end product, who trivialize the effort it takes to
change a working sub-system, or who insist on adding features that are
not functional, increase inefficiency, are difficult to develop, have
an inadequate development time frame, and that come at the wrong part of
the development cycle.
I suspect the team approach would work well in these cases, too.
Scientists, engineers and programmers are *not* the only ones who need
to communicate well; managers and clients should, too. And those of us
who communicate well for a living must undertake the responsibility to
communicate *even better* with those who may not communicate as well as
we do. Looking at it from the other side of the aisle, SME's tend to
have their hands full a lot of the time too. The poor guys 8-).
Realistically, though, even in places where a team approach is in place,
it can be us-and-them again in a heartbeat if just one SME or one
technical writer cops an attitude. Human nature being what it is, this
happens a fair piece of the time. I guess it's better if you can
recognize it, look for it and know a few ways to address it. Pam points
out several in her original post.
|Len Olszewski, Technical Writer |"That boy's about as sharp as a sack|
|saslpo -at- unx -dot- sas -dot- com|Cary, NC, USA|o' wet mice." - Foghorn Leghorn |
| Opinions this ludicrous are mine. Reasonable opinions will cost you.|