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 [long, non-rant ;-] From:Dan Brinegar <vr2link -at- VR2LINK -dot- COM> Date:Tue, 23 Mar 1999 07:10:43 -0700
I was worried that Matt Ion had scooped me:
>Indeed; this one, I picked up from my Dad. He's been in construction for
>30 years.... :)
But he didn't actually go where I was thinking 8-)
Remember: SMEs and engineers, marketing weenies and product developers all
have perspectives which are in wide variance from the perspective *you*
have (which is probably that of a naieve but enthusiastic user): a user may
wonder "what does 'Robust' mean?" but won't ask "can't you use some other
word besides 'Robust'? "
In the US and Canada, you can see a practical example of "playing dumb" by
_Bob Vila's Home Again_ on the Discovery Channel.... Bob frequently plays
*really* dumb to get an expert
(HVAC Guy, concrete guru, carpenter, etc.) to talk about some facet of home
repair or construction, and most of the time one hardly notices that he's
faking it, because he's asking *just* the sort of question you wanted to
but lacked the "gestalt" of the trade to know how to ask...
(gosh, what a clumsy sentence!)
Now, some viewers (hi Dad!) just can't *stand* Bob Vila, because he
obviously *does* know the answers to the questions, and he's rushing the
expert thru an explaination: often finishing the guy's sentence for him....
and I will admit that when I was doing tech support I just couldn't watch
him -- I'd see the look on the SME's face as he's thinking "Well, Bob, you
*know* this!!! You've been doing it as long as I have...." and I'd had my
daily dose of dumb questions for the day... When they click, tho, Bob will
prompt the guy with lines like "Y'know when I was apprenticing with my dad
in the 50's he wanted it done this way or that: how do ya do it today?"
and the guy just opens up with *really* good answers...
If you can come up with analogies to something you've done before when
trying to interview an SME, you can often get some amazing results ( like
describing how ya used to reprogram the jumper wires and check balls in the
valve body of the US/AN KL007 Framistatic Cryptographic File Transfer
Module, and the SME shows ya how that's all taken care of in ten lines of
code these days, you've discovered a source for life).
Be advised though, that if your analogies are way off, and you sound more
like Cliff Claven than Bob Vila, you'll be that guy nobody wants to see in
their cubes ;-)
I guess these interviewing techniques also depend on how much time you
have: if you have the luxury of playing with the thing you're trying to
document to get some feel for it before you meet the SME, you may get a
better grasp of the kinds of questions to ask.... again it depends on time,
however -- if you land in a contract where they expect the first 250 pages
formatted the first day, you're probably gonna have to do something
different: and if you inform them that there's no actual *content* in the
first 250 pages, and you've *got* to see an SME today; don't get too
excited when the project manager sez he's turning the whole project over to
you (mostly because he's told his bosses that you're still gonna be able to
do 250 pages a day, and then it's *all* up to you for figuring out which
SME to talk to and finding out where that SME actually *is* can be a
nightmare -- everybody knows where Stan is but you ;-). If you need the SME
just to get the darn thing fired up on your machine, you'll have to start
with the very basic "luser" questions and the SME just doesn't have three
hours a day to spend with you and a tape recorder.
Another note.... over the last couple of contracts, I've noticed that if an
SME isn't proud of the work, or is burned out, or has simply inherited this
product from the company they just bought out, and doesn't know much more
than you do -- well, you'll never get good answers -- I recently got to
work with one SME who couldn't have cared less about inheriting Barbie's
First Process Control System (tm), and a new engineer/manager who started
on the project the same time as I did -- we're sitting in my cube one day,
still unable to get BFPCS(tm) to actually *work* and I saw burn-out drop
across the E/Ms face just-like-a-curtain... but I think the operations
tempo of rapidly-conglomerated hi-tech companies is probably fodder for
>I suppose it's not so much "playing dumb" as it is showing a small "gap"
>in the knowledge you want to extract. For example, if I was doing
>illustrations and knew that someone had particular expertise in the
>graphics package I'm using, I might ask for just a little help in getting
>one particular function to operate properly, or in finding a shortcut. A
>look of awe, a "whoa, that's cool, where'd you learn that?" as the
>"expert" struts his stuff can often be parlayed into a brief training
>session in handy tips'n'tricks.
>Heh... it's worked FOR me as well as ON me. Heck, isn't that what happens
>all the time on this list?
Yep.... even more-so on "rec.models.scale" where no question goes
unanswered, and except for political ones, never gets flamed no matter how
"dumb" it is 8-)
Another thread we might consider covers the problems associated with
users/customers whose sole training on a product consists of two hours on
hold, and a thrity second session with a harried Tech Support "bob" -- they
don't actually *absorb* anything, just learn the basics by rote and now are
afraid to ask deep questions because they figure *any* question will get
them snapped-at 'cos it's dumb.... and in the case of email attachments and
so on, dumb questions not-asked really *do* lead to dumb mistakes. "It's a
fair cop, but the culture is to blame."
"Right: We'll be arresting that instead."
Dan BRINEGAR, Info Developer/Research Droid
CCDB Vr2Link Performance S u p p o r t Svcs.