RE: This too is technical communication

Subject: RE: This too is technical communication
From: "Combs, Richard" <richard -dot- combs -at- Polycom -dot- com>
To: "Mike Starr" <mike -at- writestarr -dot- com>, "Stuart Burnfield" <slb -at- westnet -dot- com -dot- au>
Date: Wed, 6 Jun 2007 10:00:33 -0600

Mike Starr wrote:

> My usual approach is to go to an SME and ask one or two
> pointed questions about specific details of the product.
> However, there are times when I need to learn things from the
> ground up, like when I'm learning a totally new technology. <snip>

Absolutely. But in that case, you're not _feigning_ ignorance, and your
ignorance isn't some sort of _advantage_ (as some others have suggested)
-- it's an _obstacle_ to be _removed_ as quickly as possible.

> But at the same time, I learned a long time ago that we
> technical writers can't bluff our way through it or pretend
> we understand complex products when we really don't. If we
> don't understand it almost well enough to join the
> development team, we'll have a hard time explaining it to the
> customer.

Couldn't agree more! You simply can't write clearly about something you
don't understand. That always leads to ambiguities, confusing
statements, and weasel-words.

Lack of knowledge is never an asset, so neither being dumb nor playing
dumb is a good idea. If you don't already have the necessary foundation
knowledge in an area you need to write about, by all means acquire it.
But if you _do_ have that foundation knowledge, use it to ask smarter
questions! (If you're a competent tech writer, you'll figure out how
much of the foundation knowledge to include for your audience without
having to role-play a forklift driver.)

Stuart Burnfield wrote:

> I don't understand where playing dumb comes into it. I know
> some things about the product and the users, I don't know
> others. I ask questions to find out the things that I need to
> know but don't.
> The SME has a lot of information. Some of it I already know,
> some I need to know, some I don't need directly but may be
> useful as background. I need to use my TW skills to pass the
> useful info on to the readers in a clear and accessible
> format. No-one in this transaction is an idiot or a forklift
> driver--not the SME, not me, not the users.

Exactly. Most of the time, we're busy here. We don't play "let's
pretend" I'm ignorant. If I'm ignorant of something, I don't celebrate
it or defend it as an asset. It's a liability that needs to be

I do my best to correct my ignorance on my own, so that it imposes the
least burden possible on others. Anything else would be inconsiderate.

"It's my opinion and it's very true." :-)


Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
rgcombs AT gmailDOTcom


Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more.

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity!

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.

Re: This too is technical communication: From: Mike Starr

Previous by Author: RE: Visuals in work instructions: how many is too much?
Next by Author: RE: FrameMaker Conditional Text issue
Previous by Thread: Re: This too is technical communication
Next by Thread: Re: This too is technical communication

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

Sponsored Ads