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: HELP! Negativity towards the techwhirler! From:Jim Purcell <jimpur -at- MICROSOFT -dot- COM> Date:Thu, 3 Apr 1997 11:55:14 -0800
Jennifer Kraus inquires (I'm paraphrasing here):
>>I want to do clean up the manual for a soon-to-be-released line of
faucets, and the product manager and the marketing manager and the
graphics people don't want me to. We have an entirely new product line
coming out in the fall, and making these changes now will be beneficial
for the fall product release. What should I do?<<
If the writing problems are minor, even if they are pervasive, I can see
why everybody is resisting: nobody wants to rework something at the last
minute for anything less than a showstopper problem. Changes that seem
purely grammatical to you will still require an additional technical
review to be sure that new errors haven't been introduced. If the
current documentation has been blessed as "good enough," management will
rightly go with good enough.
Your best bet would be to accept the status quo for the present and
start negotiating now for the changes you want for the fall product
line. Do not take the approach that "I can improve the writing." Your
bosses will not care about that. You have to show the suits what's in it
for them. If the manual as written results in more product support
calls, you can argue that the revisions will lower support costs. If
there are inconsistencies in the way similar things are documented in
different products, you can point out that some well-chosen boilerplate
will serve for all products and so reduce the overall costs for the next
generation of product documents.
Seek input from the graphics people on presentation. Maybe there are
some changes they've been wanting, too. If they have the power and
inclination to block you, you'll do better if they have a stake in what
you're trying to accomplish.
Finally, Jennifer asks (I'm paraphrasing again):
>>I've been here only two months and my predecessor was sort of a stiff.
Nevertheless, shouldn't management defer to my professional expertise?<<
I doubt it. If you're a rookie and your predecessor left everybody with
a bad attitude toward writers, it will be your job to rehabilitate your
position. It may not be fair, but it is the case. It's a difficult
situation, but not an impossible one. Keep the focus where it belongs:
on reducing support costs and adding value to the product. When you're
making your pitch, keep in mind that every do-it-yourselfer who installs
a faucet without problems will think well of your company; everyone who
ends up calling product support (or a plumber) will buy a Price-Pfister
next time.
Jim Purcell
jimpur -at- microsoft -dot- com
My opinions, not Microsoft's
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html