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.
As far as I can tell, people are missing the point of Elaine's question.
She may not be doing "usability" and "audience analysis" or using the cool
tools, but she's not doing any writing either, and that's what she's
concerned about:
> Currently, the engineers write the information for our systems and then
hand it to > me for production. I insert the text into our standard Word
template, do the
> formatting, editing, and clarifying. I insert the graphics, which are
> already captured and saved in a folder for me. I also create visio
drawings
> for architectures, and create marketing material from project profiles
> completed by the engineers.
My question, Elaine: do you edit the text the engineers give you? Any
copyediting (fixing small grammar errors, dealing with citations, etc.) or
substantive editing (reorganization)? (I'm not sure what you meant by
clarifying.) If so, then you are certainly getting experience as a
technical editor, although not strictly as a tech writer. At a very
minimum, tech writers write.
This is not to say that the job you're doing is not valuable, admirable, and
interesting. What you are doing is lumped into what we now call "technical
communication", which covers a wide range of professionals including
editors, writers, graphic artists, etc. (While some people like to claim
their specialty is the most valuable, most elite, they're just full of crap
and the rest of us know it.)
The question you have to ask yourself is if you love the job you have right
now, or if you want to do other stuff, such as writing and researching, and
all the other things we talk about on this list.
If you love your job and want to stay there forever, then it doesn't really
matter what you're title is, although for your own comfort level you could
ask to have it changed, possibly to Tech Editor.
But you will have a problem when you go to find a new job and apply for
other "tech writing" jobs, because you'll find almost all those jobs demand
more research and more writing from a tech writer. And prospective
employers will want to see writing samples--stuff you actually wrote, as
opposed to formatted or edited.
On the other hand, if you look beyond titles, you will be able to find jobs
similar to the one you have now. Quite possibly they'll be listed under
technical editor, document specialist (although I know writers with this
title) or even--now don't get huffy--"word processor". (I had a job very
similar to yours at an environmental engineering firm, and that's what our
titles were, in the "Production" department. While there I did many things,
including formatting documents, extensive copyediting, creating and editing
graphics, etc., and even a little writing when I could wrangle it.)
If, on the other hand, you want to do technical writing, then I would say
you are not helping your career with this job. The job itself is not career
suicide--although it would be it you stay there very long--but rather the
first stepping stone. If you want to progress along the tech editor or tech
writer path, you'll want to move into a job that's focused in either of
these areas, possibly in a situation where you can work with a team of tech
comm people.
Now your challenge is to get away from job title fixation. Don't apply for
tech writing or editing jobs on the strength of your years of experience
with the label "tech writer", apply on the strength of what skills you've
gained and how those skills apply to the job of tech writing or editing.
For example, you have experience working with technical documents and with
technical people; you have experience with layout, production; you're
familiar with some commonly used tools (which certainly does not have to
include Framemaker or Photoshop); you've done some editing; and you probably
are quite comfortable working to deadline. You should be able to parlay
your current job into a writing or editing opportunity at the entry level.
And from there you're on your way.
Finally, you ask about what areas to work on. If you're interested in tech
writing, look for opportunities to write something. Maybe at work--look
around for things that need to be written--maybe some marketing stuff,
internal procedures? Or outside work--take a piece of software and document
parts of it. Write a brochure for or a paper on a topic that interests
you--environmental stuff, mountain biking, crocheting? This will not only
give you experience, but will also give you samples to show at interviews.
If you're interested in tech editing, you might take a class in it, which at
the very least will give you a good overview of the profession and the range
of opportunities (also true for a writing class), maybe pick up a freelance
job or two. (Last year I edited a text book on CADD for an engineer I met
on an AOL job board--very good for the resume!).
In your position, I wouldn't waste time learning tools and I probably
wouldn't try to dive into advanced subjects like usability, but would try to
go back and emphasize the basics of technical writing or editing, including
doing research and project management (setting up a schedule and sticking
with it).
One other thing you might do, if you're working or aiming at the software
industry: learn HTML. At the very least, this will make you twice as
marketable.
Here are a couple of books that helped me immensely:
Technical Editing, Carolyn D. Rude
How to Communicate Technical Information, Jonathan Price and Henry Korman
Handbook of Technical Writing, Charles T. Brusaw, et al. (focus on
computers)
Style: Ten Lessons in Clarity and Grace, Joseph M. Williams
Managing Your Documentation Projects, Joann Hackos
Sella Rush mailto:sellar -at- apptechsys -dot- com
Applied Technical Systems (ATS)
Silverdale, Washington
Developers of the CCM Database
Demo: www.apptechsys.com/demo