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:Maybe We Need a New Job Title From:Dianne Blake <write-it -at- home -dot- com> To:Techwriter <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 07 Apr 2000 10:55:16 -0700
As an aside to the "How Skilled Are You?" thread, I've been thinking
about why employers want the software skills. I've come to the
following conclusion.
I believe that what is happening is that employers don't want to train a
writer on their business. They also don't want to interrupt their
programming staff with questions. So, if they can find someone who can
pick up the code after just a brief architectural overview and begin
writing then they have struck GOLD.
This has been true on some of the projects I've worked on. The writer
can also test the client interface as well. Okay, they say its to get
the screen shots and flow of the software for the "customer", but it is
just one more set of hands doing QA work. And believe me, the QA staff
usually gets paid more than the technical writer. (Not to say that the
QA staff doesn't earn their pay - they do - they have to know all those
QA tools for scripting, etc. and end up working really wierd hours.)
On one recent project I did, I also played referee between marketing and
the programming staff on what the client interface would look like, what
features they would get, and how to word the menus, drop-down items,
etc. I helped them to determine how usable the product was and was
constantly helping to keep the programming staff from making
"unscheduled" changes to the product.
To get control of the situation, I claimed that I couldn't keep the
documents up-to-date because they were making so many "tweaks" to the
product without notifying anyone. I found myself deeply involved in the
daily QA of the product just so I could ferret out all the changes they
were making. I wanted the documentation to be correct after all.
In the end, most people commented that I probably knew the product
better than anyone else in the company. (I think that is true of most
technical writers - if they are involved as much as I was.)
So by wearing multiple hats and pulling together what no one else knows
in the company, you create a master piece for the company. But they
just don't want to pay for it. Maybe we need to change our job title to
something more important sounding so that we can be paid what we are
really worth.