Re: At what point can I pass the buck?

Subject: Re: At what point can I pass the buck?
From: Fox Cole <foxcole -at- gmail -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Thu, 19 Mar 2009 11:19:22 -0500

David Downing wrote:

> Obviously, questions that deal specifically with clarifying
> something in the documentation are my responsibility -- e.g., "On p.
> 34, you have a statement that's ambiguous. Did you mean A or B?"
> But some of the questions I'm getting are on the order of, "The
> documentation says it's supposed to work this way, but that
> contradicts what's happening when the client tries to do such-and-
> such. Is the product misbehaving, is the documentation wrong, or am
> I misreading the documentation?"
> Of course, if the documentation is inaccurate or ambiguous, I need
> to know that, but to what extent is it my responsibility to explain
> why the product is (possibly) behaving in an anomalous fashion. At
> what point am I justified in passing the buck to the SME?

Like you, I always listen to questions people are asking (and request that
tech support send me any questions they've logged on products I've
documented) for two reasons: to learn whether my documentation has failed,
and to learn what more the users need to know.

However, I am not the product designer or developer or support expert. I'm
not using the product every day, so even though I have delved into it and
worked with it hands-on and become intimate with it, I'm neither qualified
nor authorized to answer questions about its use, except where documentation
is concerned.

It's also happened before that the product changed or some new or different
functionality was introduced after the documented release, but no one
thought to notify me to update the documentation. I wouldn't want to be
passing along wrong information or guessing about why something didn't work
as expected, and my employer would certainly not be amused if I did.

I'd address anything directly related to the documentation, then take the
asker to the appropriate support person and participate in their
question-and-answer meeting. (I realize this isn't an option for everyone.)
Sometimes I come away with a project to document some new functionality.
Sometimes I come away with a better understanding of the user's needs and
can set up a task to improve the documentation with the next release.
Sometimes the issue has nothing to do with documentation but with an error
in data or in backend processing. In any case, I know I've done my best to
fulfill my role responsibly, not overstep it, yet help the person get the
information they need from the proper source.


If the world were a logical place, men would ride side saddle. -- Rita Mae

ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals.

Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control!

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Please move off-topic discussions to the Chat list, at:

Previous by Author: Re: Lovely Wang WPS Font
Next by Author: RE: Greek Letters in Frame
Previous by Thread: Re: At what point can I pass the buck?
Next by Thread: News story: GB gov't improves communication standards

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

Sponsored Ads