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:Job titles From:Anatole Wilson <awilson -at- VNET -dot- IBM -dot- COM> Date:Wed, 16 Mar 1994 14:01:42 PST
Andreas Ramos writes:
>I'm waiting to be called a "Documentations Engineer" :)
>I prefer (for myself) the simple techwriter.
>I don't think the title matters much, because it's one of those things
>that the public never realizes; it's like, who wrote the manual for your
>Honda? Totally anonymous. There are no credits at all. (No "thanks to my
>mother, my cat," nothing.)
Well, no, the titles we use to represent ourselves in our companies
don't mean much to the person reading our manuals, using our on-line
help, or appreciating the user-friendly interface we helped design.
Let's face it--none of us will ever become as famous as Tom Clancy
simply by creating technical materials.
Titles *do* help us, however, when we're trying to explain exactly
what it is we do within our roles as technical communicators,
technical writers, information developers, or whatever. It also
helps us when we're searching for jobs or trying to justify our
salaries to some corporate high muckety-muck who thinks that the
engineers write everything.
At my first job, my title was "Editor." The mother of a friend of mine
then asked, "oh, so you're the person we write to if we want to comment
on the articles in your magazine." From then on my title was "Technical
I'm not a "Technical Writer" because that *implies* (correctly or
incorrectly) writing technical manuals or other hard copy materials.
But like so many other people in our field, I find that actually
sitting down and writing a manual is, perhaps, 25% of my job. As I
suggested up above, I'm also expected to work with the software
developers to develop the user interface and confront other usability
issues, to help with presentations, to create on-line help, to
keep track of our competitors' products, and (add your own favorite
list of non-writing duties here). I'm developing the information that
helps the software developers create their product and also helps the
end-user use it. Hey--I'm an *Information Developer*!
I spent a lot of time learning how to do these things
(and will continue to improve those skills), and I'm not going to limit
myself by using a narrow title that creates misconceptions in my peers,
co-workers, or potential employers.
>And we all know that the day that the
>software houses do a study and find out the truth: that NOBODY
>reads the manuals, then we're all going to be history. Garbagemen
>are called sanitation engineers, but they are still garbagemen.
I assuming this was written with at least a modicum of sarcasm. While
I seriously doubt anyone reads through a manual completely, I think I
can safely assert that most people will refer to the manual to learn
how to perform a certain task or to find out what that funny blinking
red light on the car dashboard means.
The goal of a lot of software companies these days is, in fact, to
reduce or even eliminate the manuals. But this doesn't mean they're
abandoning documentation. Instead, the trend seems to be towards
creating more complete, more easily accessible on-line help, and to
make the interfaces as self-explanatory and intuitive as possible.
Yeah, the "tech writers" who allow themselves to be limited to a
single medium or function will find it more and more difficult to
be successful, at least in the computer field. (Let's never forget
that technical information is needed in almost every industry, with
nearly an infinite number of non-computer related subjects.) But
if we regard ourselves as more than just providers of written
instructions, we can adapt to the needs of our employers and customers
and continue to be useful long after paper goes the way of clay tablets.
Anatole Wilson "Mountains' walking is just like
Sr. Assoc. Information Developer human walking. Accordingly, do not
IBM, Santa Teresa Labs doubt mountains' walking even
awilson -at- vnet -dot- ibm -dot- com thought it does not look the same
as human walking."
all company disclaimers apply --Zen Master Dogen