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: Process kills the dot.com From:"Rock, Megan" <Megan -dot- Rock -at- fanucrobotics -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 27 Oct 2000 10:50:40 -0400
Andrew Plato said:
> > I feel that tech writers should own 100% their work. That means they are
100%
> > responsible for the content. If something is incorrect - it is the
writer's problem.
David Berg said:
> For Pete's sake Andrew, you should know that much of the time
> TWs can't comprehensive understanding of a topic as an SME.
David went on to describe a medical Web site he worked on that dealt with
neurology, a topic that David was not an expert in. David relied on a
medical doctor to answer his questions and verify that the final content was
accurate.
-----
I suspect that the point Andrew was making is that writers need to take
responsibility for the content and ask questions and do their own research
in order to get the content as close as possible to being 100% correct. At
that point, the writer asks the SME to read over the documentation, verify
that the content is complete and accurate, and sign off accordingly. If
anything is inaccurate or missing, the SME would convey that to the writer
who would make the necessary changes. This "[process]" (insert your own
term if you don't care for "process") might take place once or twice or even
a dozen times in the course of a review cycle.
At my company, we produce fairly good-sized manuals in our software
documentation group. Much of the content stays the same or is modified only
slightly from release to release, and sometimes entirely new chapters or
sections are added. For the sake of efficiency, the writers ask the SMEs to
mark up existing documentation whenever possible. We also save time by
creating new sections based on the structure of existing sections whenever
we can. And sometimes we start from scratch with nothing more than a
functional spec or design spec--provided to us by the SME.
It may seem that we're relying heavily on the SMEs for our content, but our
product development management staff feels very strongly that the SMEs are
ultimately responsible for the accuracy of the documentation. The writers
do the best job possible to give the SMEs complete and accurate drafts to
review, but as most of you know, products change. A draft that was accurate
yesterday morning might be inaccurate today because somebody changed the
code last evening after I went home. That's why the final sign-off is up to
the people who are in there mucking with the code.
We're called Technical Writers. That means we're supposed to have an
aptitude for technical things and be able to make technical concepts easier
for non-technical folks to understand and apply.
Sometimes when I'm sick my doctor isn't available so I see the Physician's
Assistant. She might have "physician" in her job title, but that doesn't
make her an MD. I might be comfortable having her prescribe me an
antibiotic, but I wouldn't expect her to be capable of performing brain
surgery. She knows something about swabbing my throat and prescribing
something to make it better, but that's the kind of thing she was trained to
do. She wasn't trained to remove part of my skull and prod around in my
gray matter.
It's just as absurd to criticize a writer who can't fill the shoes of a
programmer. I for one wasn't trained to write code, I was trained to write
about the products created from the code. Even our SMEs have tool-specific
expertise. Nobody at my company is bad-mouthing the material handling tool
manager because he's not an expert in arc welding. Management expects him
to be an expert in material handling, because that's his job. At the same
time, they expect me to be an expert at documenting arc welding, material
handling, and whatever else makes its way onto my work plan in a given week,
because that's MY job.
Happy Friday!
Megan E. Rock
Technical Writer
megan -dot- rock -at- fanucrobotics -dot- com
All views expressed are entirely my own and are not necessarily shared by my
friends, co-workers, or employer.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Learn how to develop HTML-based Help with Macromedia Dreamweaver!
Dec. 7-8, 2000, Orlando, FL -- $100 discount for STC members. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Your web site localized into 32 languages? Maybe not now, but sooner than
you think. Download ForeignExchange's FREE paper, "3 steps to successful
translation management" at http://www.fxtrans.com/3steps.html?tw.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.