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.
A couple of days ago (as well as a couple of weeks ago and a couple of
months ago), we heard the common complaint about technical people making
editorial changes.
Our typical response is telling them that we are supposed to handle all
editorial issues and they should only focus on technical issues.
And to that I say--BUNK!!!!!!!!!!!!!!!!!!!!!
First, humans have two urges: to love and to edit. Do we want to deprive
our technical people of one of their basic urges?
Second, the technical people are, in many instances, paying the bill and if
they want to mark an editorial change, I say, let them. For a lot of them,
they feel ownership in the document you're writing because it's their subject
matter. Some of them hold dreams of writing themselves. Although we don't
have to encourage such feelings, we could at least recognize them. Technical
people want to feel a part of our work--even though few of them want to
go through the inconvenience of actually reviewing it.
Third, technical people often find editorial mistakes or clarify things that
we--in all honesty--couldn't. YES--I know that we've all dealt with
technical people who made information worse with their editorial meddling,
but I think that many of us can sincerely state that we've also dealt
with technical people who have helped us forge a better document. And if
you haven't had that experience, I hope you have one. Nothing can make
you feel better about your work than a close collaboration with a technical
person who is committed to the success of an information product.
Finally, should a technical person suggest a change that is editorially
incorrect, the worst way you show your professionalism is by saying
they shouldn't have marked the point in the first place. It's like
a parent justifying a punishment by saying, "Because I said so."
The way to demonstrate your professionalism is to provide a convincing
argument for your side. In many instances, the technical people are BLOWN
AWAY by some of the psychological reasons behind choices. For example,
I never let anyone get away with passive voice unless we really want to hide
the agent. I convince them by explaining the inefficiencies of
processing passive sentences, which increase the likelihood of
mis-comprehension (I might add, that's something I learned at my first
STC Annual Conference). That leaves the technical people speechless.
Ultimately, the technical communicators that succeed with technical folks
are the ones who listen to the them, validate them, and develop credibility
with them.
I think we need to get past the turf wars of "editorial matters are my
domain; technical matters are yours." As long as we take an us-them
approach, we'll never build credibility.
And by the way, how do you think they feel when we tell them how to
program (especially interfaces)?
"
Saul Carliner Ph.D. Student
Instructional Technology Geo. State Univ.
Note new userid----> mstsacx -at- gsuvm1 -dot- gsu -dot- edu 404/892-3945
