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:Writers' Wish List--Summary (Long) From:Nancy Walsh <Nancy_Walsh -at- MSN -dot- COM> Date:Fri, 28 Feb 1997 22:23:03 UT
A few weeks ago I posted a query to this list, asking what writers want from
editors. I asked people to respond to me privately. I received wonderful
responses, along with quite a few requests to post a summary of this
information to the list. So be it.
Comment from a fellow editor:
I enjoyed editors who:
(1) Corrected my work neatly
(2) Provided positive feedback along with the criticism, using humor to
up the edits
(3) Tried to teach me to correct my bad habits, giving me tips and tricks to
recognize it and fix it ahead of time
(4) Didn't rewrite entire passages, but suggested what might be wrong so that
could rewrite it
Additional Comments: It is so easy to get into "critical mode" and provide
comments that are too harsh, that are not always helpful, and
that can damage a working relationship. I try very hard to be encouraging,
positive, and "suggest" changes. Writers have egos and you have an ego, and
you need to get the egos working together and not against one another.
Comment from writers:
I really don't care how many marks an editor makes on my document as long as
they are not condescending about it. As long as the editing marks are
straightforward and not accompanied by derogatory comments it's OK with me.
I think it's most important for editors and writers to work as a team toward a
common goal -- collaboration is the key word. It helps greatly if the editor
makes requirements clear to writers up front. When writers can write to
requirements, it reduces the need for massive rewrites and lowers the
frustration most of us naturally feel when someone -- anyone -- edits our
Give your writers a style guide, either one you develop or the authority you
follow in editing. I'd also suggest defining the roles clearly. Let writers
know your concerns and pet peeves (all editors have them!). Let them know
what you will do with every piece of writing that comes across your desk.
Take a strong position on important issues, but be flexible about those that
don't affect the quality of the final product. I think another excellent idea
have regular editorial meetings, not only to monitor project work, but
to discuss writing and editing questions, share ideas, and learn from
What I like in an editor:
- she finds/marks EVERYTHING
- she does it in a non-offensive way (e.g., "I suggest doing it like xxx")
- she's able to point out inconsistencies, no matter how small
- she gives me a style guide for each project - it's very brief but helps
me know what she did
- she considers it to be her function to make me look even better than I
would if I were only one to read my docs
What I don't like in an editor:
- smart remarks
- very few comments
- incorrect use of proofreader's symbols (confusing to wade through)
Will you be editing for the same writer exclusively? I think you can
start by asking what he/she prefers. Sometimes I have found that writers
want editors to use pencils or pens or not blue ink or only red ink. Some
don't like notes in the corners of the page. Little preference things
like that. I guess what I am saying is don't always remember what you
learned and do it that way - ask if there is a preference.
One general comment: at the very beginning, have a meeting with the writers
and discuss your expectations of each other, and how you want to work. Be
assured that each of you will have different ideas and assumptions on what
an editor does or should do. It's best to air these (even the "obvious")
and agree on a working relationship. The writers can be reasssured that you
are there to help them, not fight with them -- particularly important if
they have had any problems with editors in the past. (Note: This writer also
provided me with a comprehensive document outlining the editor-writer
I get careless in the last stages of the process. In the course of
finding out those last few tidbits of information (or last few
changes), I miss things like term consistency. I know I do this, and I
try to fight it, but it's nice to have an editor pick up the pieces
and provide a fresh eye.
I like editors who catch grammatical errors, organizational errors
(early on! don't tell me about a major organizational error on the
last day of the project), and generally keep me from looking stupid.
I dislike editors who don't have sound reasons for changes (I had one
who changed "get" to "obtain" because it "sounded better"). I hate
editors who were great academics but are clueless about the field of
technical writing. The rules change for technical writing. For
example, second person (make it implied if you don't like it) is OK.
Bulleted lists and enumerated lists are better than lengthy
paragraphs. Fancy words are out. Repeating words is OK - a lot of
synonyms are confusing in technical documentation.
Be aware of your bugaboos and let the writers know - if you hate
overuse of "the," give us a chance to eradicate it beforehand. It
saves everyone a lot of time and aggravation.
Being an editor is a tough job, since so many people put a lot of ego
into it. Personally, I look at a good editor as an ally to keep me
from looking like a moron and as someone who will help me improve my
skills. Therefore, an editor who shares reasons for changes is always
Others, however, look at an editor as someone who is going to pick on
the lifeblood of their existence. I haven't found a good way to deal
with those people (I do peer editing for few of them). Trying to
establish a good personal relationship is probably a good place to
I guess the first thing is consistency. That is the top of the list.
Then it depends on the document. If it is something that is part of an
overall presentation (one of hundreds of user manuals, etc.) and not a
'one of a kind' document, we want it to feel like the others. I guess
the most important part is to talk to your writer and try and make the
document a team effort--it is not you against me, but you with me.
Together we make it better than either of us could do alone.
I want a collegue. I want someone who will look at my
writing--structure, grammar, overall effectiveness--and provide
suggestions. This someone should be able to back up what they're
saying, just as I hope I can.
I don't want someone whose comments on word choices or writing style are
based on personal preference. I don't want comments backed up by "it
just sounds better this way."
I DON'T want someone who sees every suggestion as a power struggle, or
who cares just a little too much about the placement of a comma. I
don't want someone who gets obvious pleasure out of spotting other
I do want someone who complements my abilities. I've developed some
good editing skills, but I don't really enjoy (i.e., don't take care as
much as I should with) the nitty gritty, 5th-time-around grammar check.
I do want someone who cares about the overall product, who gives me a
measure of respect and demands the same in return. Personally, I'd like
to work with someone who also takes the initiative to learn new
things--ideas, software, techniques--and is interested in being a little
experimental, a little better than above average.
I think much of how you approach your writers is going to depend on
the company attitude towards tech pubs. If you're dealing w/
professional writers, they might be more used to dealing w/ an editor.
They might also resent you (after all =they= know the format . . . )
If you're dealing w/ non-writers, you'll run up against the "no admin
is going to tell ME how to run my business." You've probably already
run across the attitude.
On the whole, go with your instincts. And, I'll throw in the
advice I give to reviewers. Make your comments as specific as possible,
use questions as little as possible, and provide references if you think
your author will be difficult.
Thanks to the following technical writer subscribers who contributed to this
Nancy Lynn Hayes
That's all folks....
Nancy_Walsh -at- msn -dot- com
writer/editor for Key Services Corporation in Albany, NY