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.
Randi Figueredo provided a stellar bad example
<<Republishing opens the publish screen and you need to
tell it to find the new keyword you just assigned, so press
the Update Keys button. Then you will see your new
keyword(s) listed in the keywords field of the publish
screen, and then press Publish.>>
You're not being too picky... it's horrible. The problems
extend beyond the grammatical (e.g., run-on sentences) too.
This is far too much to hide in a single bulleted step...
it's a multistep procedure, and the causes and effects are
hopelessly intermingled. Worse, there's absolutely no
consistency in formatting. There's a lot of work there, and
you'll have to rewrite it accordingly.
It sounds like your real problem is that the full-time
writer you're working with isn't very good. That's not to
say that you can't fix the problem without sacking the
other writer. The best bet is to show this bad example to
your client, show how you'd rewrite it (and why), and
propose that the new version become corporate style. If the
other writer has done a good job of collecting the
necessary information (i.e., has good research and
interviewing skills) and can learn the new style (i.e.,
could become a decent writer with some minor retraining),
both the writer and the company will benefit, and you won't
have made any enemies. In fact, given the amount of work
that will result, you'll probably benefit too (via a
contract extension).
If you can't get some buy-in for making the changes without
alienating the other writer, you've a considerably trickier
problem. It'll take a fair bit of skill to point out the
problem without blaming the other writer, even if blame is
appropriate. Try a nice-guy approach first, and get back to
us if it doesn't work. One thing that comes to mind is to
show the other writer what's wrong, and let the writer do
the sales job: that way, the other guy comes out as a good
employee, you don't make any enemies, and you're not
directly responsible for the extra work. Something like "I
just learned a new way to do things, and it's great. I'd
like to do it everywhere... but it's going to take us a
while to do." should work just fine. The only downside is
that if you really want to knock the other writer out of
the company and take the job yourself. I won't go there...
--Geoff Hart @8^{)} geoff-h -at- mtl -dot- feric -dot- ca
Disclaimer: Speaking for myself, not FERIC.
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
