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:Developer wants to take over documentation From:Steven Jong <SteveFJong -at- AOL -dot- COM> Date:Fri, 2 May 1997 10:28:04 -0400
John Wilcox <wilcoxj -at- WDNI -dot- COM> asks for advice on the thorny problem of
engineers wanting to take over documentation of their products. I find it
ironic that in one message John says his company has adopted Information
Mapping (R) as a corporate standard, and in the next he reports this mess.
Can I assume the engineers are going to take the IM course? 8^)
I think the fundamental point is that once an organization grows to the point
that it acquires specialists instead of relying on generalists, it shouldn't
regress. You should argue forcefully that you do a better job of technical
writing than the engineers do (or can). Management wouldn't accept a
counterproposal that you do both documentation and engineering, would they?
They shouldn't accept the argument that the engineers can do the
documentation just as well.
If there is a problem with resource allocation--you can't do all the work
that's on your plate--then perhaps the engineers have a point that the
turnaround time is too slow, but then the solution would be to hire
additional writing resources. However, it doesn't sound like that's the
problem from your description.
The root cause sounds like the organization thinks documentation is a rushed
response to an unplanned event (a product update). Don't think of it as a
sprint from a starting point; think of it as a project with an ending point.
The time it takes to ship the document to the engineer should be invisible to
the customers; it should happen before the customer expects to receive the
update. If this spint model fits the documentation cycle at your company, I
would suggest you get another job. Otherwise, I second the idea that you get
some planning into the cycle.
Actually, there's no cycle in evidence at all. If a one-day delay in getting
the manual from the writer to the engineer is unacceptable, does that mean
there's no time built in for review? What about production of printed/online
material?
Do you have a manager whose support you can enlist? Sometimes managers can be
useful 8^)
Anyway, I hope these thoughts help. Let us know how your situation is
resolved!
-- Steve
=============================================================
Steven Jong, Documentation Group Leader ("Typo? What tpyo?")
Lightbridge, Inc, 281 Winter St., Waltham, MA 02154 USA
<jong -at- lightbridge -dot- com>, 617.672.4902 [voice], 617.890.2681 [FAX]
Home Sweet Homepage: http://members.aol.com/SteveFJong
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
