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.
>That reaction alone helps. However, there's other reasons why I feel
>welcome:
>
>--I'm paid programmers' wages.
>--if I need equipment or software, I'm listened to if I make a business
>case.The same will go, I'm told, for educational requests once I'm
>hired.
>--I'm consulted about areas within or around my areas of expertise, both
>about writing and design and about the software I'm documenting.
>--The work I do is being shown to prospective clients as part of the
>presentation package.
When I first started working for my company, the first 2 items on Bruce's
list satisfied me. I mean, if they're paying me well and willing to spend
money on me, then they must value me, right?
Two years later, however, it is the last two items that I crave. While I
still hear the noises about how they appreciate me and the great job I'm
doing, etc., I have yet to be consulted for my opinion on anything (except,
oddly, marketing ideas). And while my documentation is sent out to
prospective clients with demos, I recently discovered that no one had
actually read the a crucial user guide before they started sending it out!
You might think that it's because they (the managers and programmers I work
with) trust me, but I disagree. I think it's because they see
documentation only as a little box to be checked off a list of requirements.
They don't *really* grasp the true value that documentation can have.
As a result, I never get to do true audience/task analyses, usability
studies on documentation, or any of the other things that can make
documentation better.
And this is my fault more than theirs, I think. While my manager and the
senior scientist bought off on the necessity of documentation, which is why
they hired me, they simply have no clue about what good documentation can
achieve. The concept of audience analysis is foreign to them. They don't
know the many varied things I, as a communicator and an instructor, can
contribute. And if that's the case, then I guess I've failed to communicate
that to them.
This is one of those introspective posts, I guess--not providing advice or
instruction, but merely personal insight. I think the last two items on
Bruce's list will be my goal for the next year. Thanks, Bruce!
Sella Rush mailto:sellar -at- apptechsys -dot- com
Applied Technical Systems (ATS)
Bremerton, Washington
Developers of the CCM Database
