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.
In article <199309151919 -dot- AA24912 -at- stevens -dot- unx -dot- sas -dot- com>,
Len Olszewski <saslpo -at- unx -dot- sas -dot- com> wrote:
> After a while, of course, you understand the drill. But it's always a
> little kick in the pants every time you see review comments on one of
> your drafts for the first time.
Ya-ha. Sometimes Bob Seger's sentiment comes to mind: "Wish I
didn't know now what I didn't know then." Nevertheless, here's
what I would tell a novice about reviews. None of this is rocket
science, but it's nonetheless learned with effort and trauma.
1. Some reviewers will do a good job spontaneously. Others
you'll need to harass; still others you'll need to grab
for a real-time "walk-through." Even if reviewing documents
is part of their job description, they still can't be
counted on to either enjoy it or take it seriously.
2. Minimize the number of review loops. If it takes more than
one or two loops (modulo the number of major changes made
to the product :), then one or more of three things is
going wrong: (2a) the writer is doggin' it in the research/
writing phase and making too many mistakes, or (2b) the
subject-matter experts aren't reviewing thoroughly enough
(see #1), or (2c) somebody doesn't have enough confidence
in the writers' abilities and is falling into micromanagement.
3. Minimize the verticality of review loops. When you get more
than one or two levels above the programmers or engineers or
whoever else actually spends the day putting a line on paper
instead of shuffling quarterly projections, you've left most
of the technical expertise behind; you'll get, at best, a
"policy review" and should structure your request accordingly.
Unless, of course, you're trapped in (2c).
4. Some people are missing the gene that tells them what "draft"
means. Deal with this through a combination of being careful
with the stage and level of quality at which you release for
review and developing a thick skin.
5. Be understanding. You deal with documents, and the review and
correction thereof, every day. Your subject-matter expert
does not, and may in fact be doing it for the first time. And
she, like anyone else, will be learning new things about the
material through the writing process.
Good luck,
Joe
"The pallid pimp of the dead-line/The enervate of the pen" --Robert Service