: tech communication career

Subject: : tech communication career
From: "Blount, Patricia A" <Patricia -dot- Blount -at- ca -dot- com>
To: <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 29 Jun 2006 09:17:39 -0400

Roy,

I hope I'm able to help you make your decision.

1) What is a typical day like?

The typical day depends entirely on whether you are a fulltime permanent
employee or a freelancer working on a project by project basis. In the
former case, you'll likely be juggling several writing projects at once
while in the latter, you'll work one project through to completion.

In my experience, you will seldom start at page 1 and write until page
End...instead, you'll likely tackle topics to the greatest extent that
source information is available at that particular time. I've worked on
both user docs and training docs. The concept of the 'topic' will vary
from firm to firm but generally, topics typically cover the performance
of a single task using the subject tool - be it a new software program
or the latest hand tool on a Home Depot shelf.

You'll be expected to determine what those topics should be, and group
them into related chapters, modules or units (depending on your firm's
in-house style. (We used the 'module'.)

2) What are hours like? Do you find it takes time
away from your family beyond 50 hours a week or so?

Hours are also dependent upon the firm. If you're well-organized, this
can be a nine-to-five job but expect the hours to expand as you approach
deadlines, particularly in software documentation roles. You will be
waiting on developers, QA experts, and reviewers to hand off their work
right up until the deadline.


3) What are some of the major pluses and minuses of
the career?

On the plus side, it's a corporate setting that permits me to be
creative. I find the writing process to be cathartic. I love finding the
best words to put to paper and make my instruction as unambiguous as
possible, given the constraints of a given project.

On the minus side, people who are not writers by trade think anybody can
do what we do...after all, they teach grammar in school, don't they? I
have spent years dispelling that myth, manager by manager. It's only
after I dissect some white paper or other copy these folks have written,
making suggestions, pointing out confusion, offering analogies that
illustrate certain points...that's when they finally look at me with
appreciation. In fact, I was once asked to train a group of graphic
artists as writers. These poor people looked at me like I'd just walked
off a UFO when I asked them to find the verb in a sentence. "Verb?
What's a verb?" But I digress...


4) What are typical entry level salaries and later
salaries? Are you happy with your compensation?

I'm not sure anyone is ever happy with their compensation, but you will
find a wide range of salary potential depending upon your region. In NY,
starting salaries for entry level tech writing are around mid -
thirties... which also happens to put you at poverty level, given our
high cost of living. The STC does a salary survey every year that I've
used to great advantage in negotiations.


5) What is most exciting to you about the job?

For me, learning new tricks is my favorite part about the job. I've
documented software, robotic hardware, policies and procedures, and
classroom instruction. Was I expert at any of these things?

Nope.

But I was either put in touch with the people who were experts or found
them on my own. By interviewing them, watching them work, and asking
them for input into what most confounds them about the subject matter, I
was able to fill a need.

6) How vital is a degree in technical communication?
Is competition for jobs intense? I ask this since
while I have some technical knowledge, I am sure it is
not enough to start a career in technical
communication right off the bat. I would need a
certificate at the very least, plus an internship.



I've managed about eighteen writers over the course of one particular
position. The best of them were writers first, technicians last. While
it certainly helps if you understand the subject matter, I find it's not
always essential. That's why we have SMEs or subject matter experts.
Generally, I've found that by asking the proverbial 'stupid questions,'
I'm able to get the experts to think like a novice, ensuring I write to
the knowledge levels of my target audience. Of course, not all target
audiences are at the novice level. In situations where I was expected to
write for experts or power users, I was able to write to that level with
the help of my SMBs. I start by doing some research first: job analyses,
or interviews with actual, real-life end users. I find out what they do
all day - regardless of the software systems in place. Next, I analyze
the current tool in use. What features and functions does it offer and
which ones are used to do that job role? I then match the software
features/functions to the job responsibilities and that becomes my
project outline. I often propose sets of user documentation: a starter
book for novice end users, an administrator's guide for the techs who
must manage it...and so on. I make them as job-specific as possible.

Here's an example: Suppose you have a new software program, Gee Whiz
1.0. Gee Whiz has all kinds of cool features and functions. I find that
lazy writers will simply grab a feature and call it a Topic: "Using the
Gizmo Actuator" when no novice user picking up this book would know what
a Gizmo Actuator is yet.

I'll go to the SME and say, "What can I do with the Gizmo Actuator
feature in Gee Whiz?" And, they'll gush like proud parents and rattle
off all the cool things it does. Next, I'll narrow down their scope and
ask, "What could a person with a <insert job title> role do with it?
And, the SMEs will pick the few job-related tasks that fit. Those become
my topic headings. "Writing Report Queries with the Gizmo Actuator" or
"Generating an Index using the Gizmo Actuator" - you see the point?

What good does an index full of features and functions do for the end
user if they have never seen or used any of them before?


7) How is the career undergoing changes, and in what
ways will that impact the job market for technical
writing?

The internet's introduction and wide-spread adoption have changed this
market and will continue to do so, as the technology becomes more
pervasive and faster to use. Instead of writing manuals, now we're
writing online help systems and info nuggets that can be downloaded to
PDAs and even phones. You must write clear instruction in as few words
as possible, using software that makes your copy available in an
electronic world.

Good luck!
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.DocToHelp.com/TechwrlList

---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40infoinfocus.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.


Previous by Author: Re: frustrated
Next by Author: RE: word or rtf
Previous by Thread: Quick Poll - Document Change Notes
Next by Thread: Thanks and thanks again!


What this post helpful? Share it with friends and colleagues:


Sponsored Ads