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: This too is technical communication From:Troy Klukewich <tklukewich -at- sbcglobal -dot- net> To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Tue, 5 Jun 2007 17:40:30 -0700 (PDT)
<quote>
I certainly don't use the "clueless idiot" or "high-school dropout forklift driver" approach for every encounter with engineers or programmers.
</quote>
Time for a story. :-)
I used to work for a software company (that shall remain nameless) with a strong developer ethic. They hired a whole group of incredibly intelligent writers. They really considered themselves to be developers first (some of them in fact were former developers) and writers second.
They not only considered themselves the technical equal of development, continually proving their own genius, but openly criticized design decisions, including internal implementations with vehemence. They constantly got into arguments with development over technical minutia. And it got personal. When I came on board, development hardly even talked with documentation and wanted as little do with the writers as possible.
I came on board with some other very professional, seasoned writers who took a completely different approach. We made it clear that we weren't there to compete on knowledge or show-up anyone. We couldn't care less about IQ points. We just wanted to get our jobs done and we even "played dumb" at times. It takes guts to sometimes say, "Hey, I don't know." But we also readily defended our documentation design decisions as professionals.
It didn't take long for key developers to figure out that we knew what we were talking about. Sure, we didn't know as much as the other writers who had been there longer, at least at first, but we knew how to ask the right questions. If you ask the right kind of questions, people know whether you are smart or not.
I took great pleasure when a senior architect and a couple of other leading developers told me how much they preferred to work with the new writers. It was a different culture.
By the way, for software, I found one of the easiest, most effective communication techniques is to build a simple demo and run existing and new functionality against it. I'd then go to the developer and say, "Hey, can you give me a hand with this? I'm building this simple demo so I better understand how feature X works and I'm blocked. I'm probably doing something wrong." I play dumb. Most of the time, there's some nasty bug blocking progress and the developers get all over it.
It's amazing how much dialog opens up and the developers genuinely respect you for taking the trouble to walk their baby.
I guess we've wandered a bit from the origins of the thread, but this too is technical communication in the truest sense. ;-)
Troy Klukewich
Information Architect
Oracle
----- Original Message ----
From: Mike Starr <mikestarr-techwr-l -at- writestarr -dot- com>
To: Mike Starr <mike -at- writestarr -dot- com>
Cc: techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Tuesday, June 5, 2007 4:49:06 PM
Subject: Re: This too is technical communication
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. Sometimes I need to ask the SME to give me the simplified
version so I can understand how the technology works in order to explain it
to the user. I certainly don't use the "clueless idiot" or "high-school
dropout forklift driver" approach for every encounter with engineers or
programmers.
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.
Mike
--
Mike Starr WriteStarr Information Services
Technical Writer - Online Help Developer - Website developer
Graphic Designer - Desktop Publisher - MS Office Expert
Phone: (262) 694-1028 - Tollfree: (877) 892-1028 - Fax:(262) 697-6334
Email: mike -at- writestarr -dot- com - Web: http://www.writestarr.com
----- Original Message -----
From: "Ned Bedinger" <doc -at- edwordsmith -dot- com>
To: "Mike Starr" <mike -at- writestarr -dot- com>
Cc: <techwr-l -at- lists -dot- techwr-l -dot- com>
Sent: Tuesday, June 05, 2007 6:26 PM
Subject: Re: This too is technical communication
> Mike Starr wrote:
>> John, you're missing the point here... I want the SMEs to explain things
>> to
>> me like it was *ME* who's the high-school dropout forklift driver.
>
> I've been reading this 'idiot' interview technique thing as hyperbole,
> not something you would actually try to do. But if you're actually going
> to SMEs and saying "Start at the beginning, explain it to me as if I
> know nothing about it," then I hope it is with the understanding that
> you'll stop them when you've found your grip on the topic.
>
> Otherwise, I can't think of how you keep them from thinking you're
> helpless. My SMEs don't appreciate helplessness in a tech writer. They'd
> be saying "Uh oh, the village idiot wants an hour, I'll tell him I'm
> slammed and busy for the rest of the month."
>
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. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as tklukewich -at- sbcglobal -dot- net -dot-
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 http://www.techwr-l.com/ for more resources and info.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
