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.
Subject:Re: Getting information From:Lynn McGee <LynnMc -at- EXABYTE -dot- COM> Date:Mon, 22 Mar 1999 14:33:22 -0700
Regarding the problem of extracting information from SMEs, Ben Kovitz wrote:
I think the biggest cause is that on most
projects in software companies, the more important the
information, the less likely are people to commit it to
writing. Consequently, there's usually only one person who
understands how everything fits together.
A secondary problem is that often people simply haven't thought
through the information that we need.
In the case of the first problem, to me it's like managing a group: you have
to treat individuals differently. The same thing doesn't float everybody's
boat. Some people like to give just the facts, while others want their egos
stroked. Which brings to mind another role in which tech writers are
under-rated and under-recognized: as diplomats on behalf of the user.
The secondary problem mentioned by Ben also speaks to the tech writer's
role: some have called it liaison or diplomat, some a boundary spanner. I
have a fellow tech writer friend who simply says that his middle name is
Nag. We are the user advocate and are naturally the ones who will think of
questions that the designers won't. As such, we are obligated to get those
questions answered on the user's behalf.
But I'd be very interested to hear some people post some of their
favorite techniques for extracting information out of people.
Again, it seems to depend on the individual from whom you attempt to extract
information. With some people, playing dumb works because they can speak at
a user's level. With other, more high-level types, the focused list of
questions works better because you don't want to know where the concept of
subnet masks originated, you just want to know why they made the subnet mask
field read-only... I also find that some people respond better by phone,
some in person, some by e-mail, etc. For me, it's a "getting to know you"
kind of thing. I really try to develop a relationship with the individual.
And since we all tend to show our worst sides under stress, I try to develop
a relationship that is sustaining enough that it holds up during deadline
phases as well as development phases.
The problem of obtaining information may be helped or hindered by the
general corporate culture where you work. I feel very fortunate because I
work in a place that allows for human relationships between the tech writers
and the engineers. Our Tech Pubs department also has a reputation for
turning out quality documentation. We make it our job to be as informed as
possible. Sometimes we even impart "new" information to the SMEs (partly
because they don't talk to each other!), which furthers an overall
relationship of mutual respect.
On a personal level, though, I focus mainly on getting through to the
individual. Most people with a shred of humanity respond. And I don't break
my head over the ones who don't. Bottom line is that I still need the
information! In some difficult cases, I have resorted to e-mail with my
manager's name placed obviously on the cc: line. But that hasn't happened
very often. I'm usually able to find a way to make the one-on-one
communication work.