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.
Getting that info (was Re: The Case Against Working at Home
Subject:Getting that info (was Re: The Case Against Working at Home From:Editor in Chief <editorialstandards -at- gmail -dot- com> To:William Sherman <bsherman77 -at- embarqmail -dot- com> Date:Sun, 3 Mar 2013 01:33:12 -0500
On Fri, Mar 1, 2013 at 12:17 PM, William Sherman
<bsherman77 -at- embarqmail -dot- com>wrote:
>
> [...]
>
>
>
> If I email someone for information on the Illudium PU-36 Space Modulator
> revision that he designed, I should not have to chase him down a hall,
> tackle him, and drag him hogtied back to his cube for me to get it. One
> email request, and it should be on its way to me in a reasonable amount of
> time.
> [...]
Well, yeah, if you want a very specific piece of info, or three.
But things get a bit more grey (gray?) if you are looking for
interpretation, background, or just info the engineer has, but nobody has
ever asked him/her about it from the perspective that you introduced.
I do that. I usually get good, timely responses, but sometimes I get
foot-dragging. It's really never that the SME is unwilling to provide the
info, but it might be that he genuinely doesn't know how to do so. I find
that further prompting DOES help, when I re-word, or try to tie the
question more to the SME's perspective, or to the task he-or-she's been
working on.
About a year ago, I had requests to add more info to a table of error codes
and messages. It was like pulling teeth. The difficulty was that the
people asking were field technical reps (support and pre-sales), and they
were asking from the perspective of a customer using the system with their
own (or third-party) applications. The engineer I was dealing with could
tell you/me/anybody what each error code or message meant, in terms of what
was going on inside the product. But what field people and customers were
interested in were the situations in real life that might be represented by
those codes.
What kind of situation or actions might some big application be involved in
that could trigger this-or-that code or message? It was especially
important to do that kind of mapping when the customer was using someone
else's app, and therefore did not know which library calls and other
actions were occurring - they just knew the macro situation and their
inputs. My eventual solution was to get a strong field guy in a room with
the SME. They happily bounced off each other for a couple of days, and some
nice summaries emerged for the codes and cryptic messages. All I had to do
was a bit of editing.
It wasn't arrogance that was the reason for initial foot-dragging, it was
insecurity and puzzlement. The SME didn't have a good handle on where to
start. Once he was talking to a kindred soul with related skills and plenty
of experience on the customer side, he was pleased to participate.
My experience is that most people are glad, proud, to feel useful. Either I
use my own skills to create the right environment for them to do so, or I
find somebody who can help.
Generally, I can't say enough good things about our tech-support guys and
our Sales-Eng people. For all kinds of reasons, the above being just one.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
EPUB Webinar: Join STC Vice President Nicky Bleiel as she discusses tips for creating EPUB, the file format used for e-readers, tablets, smartphones, and more.
