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 the programmers to come to you From:Lisa Higgins <lisa -at- DRDDO1 -dot- EI -dot- LUCENT -dot- COM> Date:Thu, 13 Mar 1997 10:14:02 +0000
OK. I give. I can't not say something about this issue.
I agree that it's sort of pathetic for tech writers to feel that they
have to bribe SMEs for information...BUT there are a lot of factors
that come into play here.
1. Contracting. Contractors and freelancers are outsiders, and are
often the 'enemy.' Especially if you're filling an outsourced
position, employees will tend to have a little animosity toward you.
So you do everything you can to get yourself into the loop for the
duration of the project. This has little to do with the fact that
you're a tech writer.
2. The nature of most technical writing is that it is not the primary
business for the companies we work for. Documentation departments are
frequently designated as cost centers. And usually, we do perform a
support function, as the customers are generally paying for the
software, not the documentation. I know as well as anyone else, of
course, that customers DO pay for the documentation,
and that what we do increases the value of the end product; but the
harsh reality is that it usually is not the sellable product. QA
generally has the same problem. They're not cranking out code,
either. They're ensuring the usability of the code, and consequently
holding up the "code-cranking" process. It's a short-sighted,
microcosmic view of software, but it's still fairly common in the
industry. If you find yourself subject to these interpretations, you
deal with them until you can get out.
3. Tech writers are a bunch of whiny, prissy, uptight little
bureaucrats, and nobody likes them. Really. There's a tech writer
pathology that absolutely every tech writer I've known, including me,
has suffered from to some extent, to different degrees at different
times. We almost all have a little chip on our shoulders. We're asked
to type memos, we're designated as a cost center, we're ignored,
spoken down to, underpaid, and so forth. So we go on the defensive.
We dress more formally than the rest of the company, we create little
forms that we make developers fill out, we wear our resumes on our
sleeves (I went to college! I know C! I'm published! I'm not a
typist, dang it!) Maybe you haven't done this with the people you
work with now, but someone else may have. And just like so many tech
writers walk into a new job with preconceived notions about the
engineers they'll be working with, engineers do that with tech
writers. I've followed in the footsteps of a lot of anal-retentive,
annoying tech writers; and I've probably been the anal-retentive,
annoying tech writer that others have had to follow, too.
Sure, you can require that your SMEs fill out certain forms and
provide you with certain types of information, but you'll never
really excel that way. You miss the undercurrents, the rumour and
innuendo that will give you the edge in your field. You can get all
the facts by making people fill out forms, but a lot of this field is
"squishy." If you know the personalities and cultural undercurrents
associated with those facts, you're going to be able to predict your
project's needs better.
The way to get those intangibles is to fit in. That doesn't mean to
change who you are. It just means to provide some assurance that you
are enough of a professional in your field that you don't feel the
need to prove it constantly or to tattle on those who aren't
immediately cooperative. Understand that the people who are reticent
about talking to you have probably had bad experiences in the past,
just like you have.
So you approach them, you chat with them, and you give them some
incentive to trust you and treat you as a colleague. Not because
you're somehow less important than they are, but because you're
usually going to be better at that than they are (if this email
weren't so long already, I'd cue my "Hard Sciences are for Wimps"
rant now, but I won't.)
Lisa.
lhiggins -at- lucent -dot- com
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html