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.
> Now unless an Uber-Writer wants to explain to us all how we are supposed to
take
> 100% responsibility and attain 100% accuracy and become 100% clairvoyant in a
> dynamic environment where the writer is not in control of the development or
> release schedule or process, I would kindly suggest they take their grudges
and
> prejudices elsewhere.
That would be me.
Let's align some facts and concepts first.
1. Mistakes happen. This is normal, natural, and expected. Errors and omissions
will always be a part of any writing. Editing, reviewing, and maintaining docs
is the way to ensure that material is kept fresh and accurate.
2. Responsibility rests with the author. When a journalist publishes a story
with a mistake, the paper and the author assume responsibility and publish a
correction. They do not publish a "well, the source told us the wrong thing, so
its his fault, not ours" article.
The problem I am pointing out is this desire, of some writers, to reassign
blame. They want to be free of the responsibility for content accuracy. Thus,
my response is as such:
If you want to be released from the responsibilty of the content, then expect
to simultaneously be released from a certain degree of professional respect or
pay. If you want to be a mere cog in a machine, where you shoulder no (or very
limited) responsibility for the sucessful outcome, then you will be paid and
respected at an appropriate level. This is why file clerks and mail room
sorters don't make $90K a year and get to hob knob with CEOs. They have
minimal responsibility and hence, minimal pay/respect.
However, if you want to be a respected and well paid member of a team, you have
to be willing to accept responsibility. This means that when there is an error,
you do not spend 5 weeks trying to blame that error on an SME, you take
responsibility, fix the mistake, and move along.
It is my experience, that how a person responds to mistakes says a lot about
their level of skill and professionalism:
At the highest levels, a true professional will accept full responsibility when
an error happens and immediately plot a course to correct the problem. Blame
is, for the most part, irrelevant. Fixing the problem is the primary concern.
At the mid-levels, the cog in the wheel will try to offload responsibility to
somebody else but will begrudgingly work on solving the problem. Blame is used
to feel better, fixing the problem is done only after blame has been
successfully applied and publiciszed.
And at the lowest levels (where amateurs reside), all forms of responsibility
are off loaded and solutions are vehemently shot down. Blame is critical and is
given intense focus, repairing the problem is virtually irrelevant.
Thus, what got me about the article, is not the latter half where the author
describes some mechanisms to help improve and catch mistakes. Its the notion
that mistakes are not (always) the authors fault. This is a bad argument at two
levels. First, it is concerned with the concept of blame in general. In my
opinion, blame is a game for the weak and stupid. Second, its trying to
redirect responsibility to other people, when the person ultimately responsible
for the value of a document is always the author.
I realize its popular and perfectly acceptable in many organizations to ?blame
the process.? Every time there is a problem, employees sit around and try to
blame the company, management, or some procedure.
The fact is a process (or organization for that matter) is only as good as the
people using it. If blame must be assigned, it is the people doing the work.
It may make you feel better (and hence less at fault) to blame the process. But
the fact is, when a doc has an error, it?s the writer?s job to fix it and make
sure it does happen again.
And if some writers put as much energy in ensuring accuracy as they put into
designing single-source systems and complaining about a lack of respect, they
might not have as many problems with mistakes.
Processes don?t make mistakes. People do.
Andrew Plato
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Purchase RoboHelp X3 in April and receive a $100 mail-in
rebate, plus FREE RoboScreenCapture and WebHelp Merge Module.
Order here: http://www.ehelp.com/techwr-l
Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at http://www.raycomm.com/techwhirl/special/contests/
Happy birthday to you, happy birthday to you, happy birthday TECHWR-L....
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.