RE: About Responsibility and Fault

Subject: RE: About Responsibility and Fault
From: "Robert Plamondon" <robert -at- plamondon -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Mon, 7 Apr 2003 20:42:43 -0700

I guess I have a different take on this sort of thing.

I have sometimes been asked to write semiconductor data books without
communicating with the design engineers at all. Instead, I had to rely on
reverse-engineering the internal specification and other random engineering
documents, and hoping (often in vain) that questions I relay through my
marketing contact will eventually be answered.

No one would intentionally set up their company so data books got written
this way, but start-ups often over-book their key technical people to the
point where ugly trade-offs must be made. Making this particular ugly
trade-off work is one of my specialties.

I could argue that such data books are either my best work or my worst. It
all depends on the standards you want to use. In terms of triumphing over
adversity, these are by far my best work. By what some people rather
optimistically call objective standards, they don't stand up so well.

Some people would probably call these flexible standards unprofessional. To
me, professionalism is about getting the job done. If clients need a
second-rate data book created under trying circumstances, I'm their man. If
they need a first-rate data book and are willing to pony up the necessary
support, I'm their man.

The key is to always be realistic about what the end product is likely to
be: its overall quality, its known weaknesses and rough spots, and the
places where as-yet undiscovered problems are most likely to reveal
themselves. All this must be shared with the client. If a level of quality
they are willing to accept can be extracted from the level of support they
are willing to provide, then business can be done.

Who is responsible for the document? In my line of work, I see myself as
being responsible for providing the best document possible UNDER THE
CIRCUMSTANCES. The circumstances are provided by the client.

Sometimes the client doesn't pony up the promised level of support. What I
do then is report the omission, along with its likely consequences, and what
I'm doing, if anything, to paper over the gap. A client that doesn't provide
the promised level of support can end up with a document that's thinner or
later -- but rarely cheaper -- than originally planned.

I don't find fault with my clients. If they fail to answer questions or do a
decent job reviewing the document, they're the ones who have to live with
the consequences. I find it simpler to take them on their own terms. So
far, they haven't found fault with me, either, so maybe I'm onto something.
Or just lucky.

I think that there's a place for exquisitely turned-out documentation. I
certainly enjoy being involved in its creation. But a really rough piece of
work -- in the right place at the right time -- can also do a lot of good.

-- Robert
Robert Plamondon
President, High-Tech Technical Writing
robert -at- plamondon -dot- com

Purchase RoboHelp X3 in April and receive a $100 mail-in
rebate, plus FREE RoboScreenCapture and WebHelp Merge Module.
Order here:

Help celebrate TECHWR-L's 10th Anniversary starting this month!
Check out the contests at
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 for more resources and info.

Previous by Author: Re: Principles for procedure writing - grade levels
Next by Author: Re: Skills Matrix
Previous by Thread: RE: About responsibility and fault
Next by Thread: RE: About Responsibility and Fault

What this post helpful? Share it with friends and colleagues:

Sponsored Ads