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.
FW: Appealing to or introducing Tech Comm "best practices"
Subject:FW: Appealing to or introducing Tech Comm "best practices" From:"Kevin McGowan" <mcgowan -at- loran -dot- com> To:"Techwr-L" <TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM> Date:Fri, 22 Oct 1999 16:40:55 -0400
Wow, I love philisophical questions.
There is something to be said for creating your own path, not following
standards etc. However, sometimes it is a GOOD idea to follow common
practices. For example, how many people on this list have the Chicago Manual
of Style and/or the Microsoft Manual of Style? We do this for the sake of
With the person in question, I see two possibilities:
1- if this is a crusty, difficult type of individual, who is adamant against
change...it might be time for a little tough love. "Look, your ideas are
good, but so are mine (and those of others on the team). By refusing to do
things the way the team/corporation/world wants them done, you're holding up
the show. We need to get this work done, so do it or split."
2- if this person is at all open minded, and just hasn't been exposed to the
'standards' of technical documentation, perhaps some training is necessary.
If you are the team leader/manager, maybe you can give send this person to a
seminar, or hand over a couple of your books and say "read this. we'll
discuss it next week."
Person #1 will be a total PITA. I've seen it. The individual I worked with
flat-out refused to follow even corporate standards! he just didn't like
them! No amount of explanation or discussion would change his steel-trap
Person #2 might be a smaller PITA, but with more training and exposure to
the world of tech writing, he/she could be salvaged as a contributing team
All that being said, it's a two-edged sword. One must also make sure that
"knowing the standards of technical communication" etc does not stop one
from hearing good ideas from others on your team, just because they don't
have the same level of training. Always be ready to try something new!
No one likes to be told to change (I know I don't!), but be prepared to
change a few of your habits in exchange for him/her changing some of theirs.
Cheers, and have a good weekend!
From: bounce-techwr-l-9731 -at- lists -dot- raycomm -dot- com
[mailto:bounce-techwr-l-9731 -at- lists -dot- raycomm -dot- com] On Behalf Of Anonymous
Sent: Friday, October 22, 1999 1:09 PM
Subject: FWD: Appealing to or introducing Tech Comm "best practices"
As a technical communicator in the software industry, I rely heavily on
resources such as this listserv, STC and ACM SIGDOC publications, books by
tech writing gurus (JoAnn Hackos, William Horton, Karen Schriver), etc. to
make sure I'm on the right track and not missing out on better ways to
But I keep running into technical communicators who, generally because
they "fell into" the field, have no knowledge of these resources and who
to prefer to make up their profession and their documents as they go. While
these folks are plenty smart, mean well, and have expertise to share,
their documents often show a lack of exposure to the "standards" or "best
practices" of the field. (Not that any two tech writers could ever
completely agree on what the standards are, but there is at least some
consensus on some issues.) Also, maybe because these tech writers invented
their work without help from outside sources, they feel great ownership of
their work and can be highly defensive toward suggestions for improvement.
Does anybody out there have thoughts or advice on how to build a good
working relationship with such a colleague, while also encouraging them to
open up to the standards and best practices of the field, as described and
discussed in the major resources of the field (STC and ACM pubs, TECHWR-L,
I don't want to be griping or to start a gripe session here. I do want to
hear others' perspectives and suggestions. For me, this is a difficult,
serious situation, and I welcome input.
Forwarded anonymously on request. If you want the
original poster to see your response, you must reply
to the TECHWR-L list. All direct replies to this
message are automatically discarded. Contact Eric
ejray -at- raycomm -dot- com with questions.
Sponsored by Weisner Associates Inc., Online Information Services
Moving your documentation online? We can help with standards, planning,
or training. Visit us at http://www.weisner.com or mailto:info -at- weisner -dot- com -dot-
Sponsored by IEEE Professional Communication Society, supporting
technical communicators as they work to enhance their written, oral,
and visual communication skills. Learn more at http://www.ieeepcs.org.
You are currently subscribed to techwr-l as: mcgowan -at- LORAN -dot- COM
To unsubscribe send a blank email to $subst('Email.Unsub')
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.