At what point can I pass the buck?

Subject: At what point can I pass the buck?
From: Geoff Hart <ghart -at- videotron -dot- ca>
To: TECHWR-L Writing <techwr-l -at- lists -dot- techwr-l -dot- com>, David Downing <david -dot- downing -at- Fiserv -dot- com>
Date: Wed, 18 Mar 2009 09:52:51 -0400

David Downing wondered: <<For awhile now, I've had some coworkers come
to me with questions about our product, some of which seem like they
should have been taken directly to an SME. In fact, I ended up passing
some of the questions on to an SME. On the other hand, as the person
who documents the product, maybe I should be able to answer some of
these questions.>>

The "always" point to pass the buck: when you don't know the answer.
The "sometimes" point to pass the buck: when an endless stream of
colleagues nagging the SMEs about the incomprehensibility of a
particular interface feature will prove to the SMEs that it's not just
you, and that everyone has the same problem with their looney-tunes
design. The "never" point to pass the buck: when watching how people
interact with the product (i.e., what they do and don't understand)
gives you insights into how to design your documentation to improve
that interaction.

Personally, I was always flattered when colleagues came to ask me
about a product: it meant that they respected my opinion and found my
continued existence useful. That gave me a chance to develop some
productive working relationships with these people, both because doing
so made life at work more pleasant and because many of them could help
me in return when I need a future favor.

<<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?>>

See above. To me, the ideal approach is to combine the always,
sometimes, and never: help the people to the extent of your abilities,
document their problems (names and details) so that you have
statistics you can use to motivate the developers to change something
ineffective, and send the colleagues on to the developers (if
appropriate) so that the developers receive ongoing feedback about
problems with their design and you're not the only one complaining.
Then figure out how to help solve the problem and take that to the
developers so you become their ally, not the annoying nagging voice
they learn to dread.

Geoff Hart (
ghart -at- videotron -dot- ca / geoffhart -at- mac -dot- com
Effective Onscreen Editing:


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:


At what point can I pass the buck?: From: Downing, David

Previous by Author: Text in tables -- smaller than or same size as regular body text?
Next by Author: Grammar question?
Previous by Thread: At what point can I pass the buck?
Next by Thread: RE: At what point can I pass the buck?

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

Sponsored Ads