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:Re: First day advice. From:"Wing, Michael J" <mjwing -at- INGR -dot- COM> Date:Wed, 31 Dec 1997 13:20:31 -0600
> I start my first real job straight out of college on Monday.
> Dec. 19) I spoke on the telephone to an old friend last night who is 6
> months into working an advertising job for a law publication. She told
> about some of her downfalls since starting. Anyone have any brief
> for a promising new tech writer for his first day/week/month on the
> Jonathan J. Soukup
> jsoukup -at- eskimo -dot- tamu -dot- edu
First, congratulations on your Technical Writing job.
My main advice is to erase any preconceived notions you may have on what
the job and your duties will be. Chances are they will be completely
different. Take a good look at the amount of time that writers actually
spend writing, how available the information is, the workload and
deadlines, the tools that you have to learn, and so forth. Then there
is the general work environment, group dynamics, pecking order, and so
Take a look at the hierarchy within your group (assuming you are not the
lone writer). Are there levels of writers (writer -> senior writer ->
principal writer)? See if you can get a description of the duties and
expectations at each level. Get a feel for who is approachable and who
feels 'put upon' to answer questions. Notice if there are some
personal/professional conflicts within the group and how the manager
It may be tough to start in an established group. You never know what
went into the decision to hire you. Did other writers have a input?
You might have been a unanimous choice. Or, you may also have been
hired because recent grads cost less than experienced writers. Or,
maybe someone in the group had a relative, friend, co-worker, or fellow
alumnus whom they felt deserved your job. Maybe they wanted another
candidate. Who knows? But until you weave your way into the department
fabric, be aware of undertones.
Working with Subject Matter Experts:
There should be a real-life course for this in college. You, know bring
in Technical Writers from the corporate world to describe war stories,
successes, failures, techniques, and to show scars. Kind of like the
"scared straight" program in some inner city schools ;^)
Actually, this is probably one of the biggest eye-openers in learning
the job. In school, you may learn interview techniques, how to organize
and filter information, and how to construct it in a meaningful way. In
this scenario, the SME gushes tons of information, looks at what you are
writing, cheerfully corrects misinformation, and stamps their approval
on the document. In most cases, you will approach a harried, overworked
Engineer/Programmer/Scientist who may view you as an interruption, as
someone heaping more work on them, and/or someone who couldn't possibly
understand what they are doing.
It is best to talk with your manager and co-writers about the best way
to approach SMEs. Find out if the manager takes an active and
effective role in the flow of information or do they expect you to
handle it. Also, ask the manager (or a co-writer) to introduce you to
the SMEs. In the introduction, you can ask the SMEs how they like to
Tools and Duties:
My biggest advice here is not to be defensive about things you do not
know. If it is a necessary software program, subject matter, or so
forth, let the manager know what you can handle with and without
training/experience. Also, if you feel uncomfortable with saying, "I
don't know how to use that program", or "I know very little about this
subject", make comparisons to your background. For example, you could
say, "I never used FrameMaker. But I have used WordPerfect and Word so
I am comfortable with basic word processing functions". When I started
at a software writing job for applications that made computer-generated
maps, I was asked if I had a cartography background. I said that I
didn't; however, I told them that I had worked with and documented some
electronic measurement devices used by survey and mapping companies and
that there was quite a bit of topographic data analysis done through the
You're not going to be fired because you don't know the tools and
subject matter right off the bat (unless it was requisite for the job
and you padded your resume;^0). However, if six months later you still
don't know the tools or you had told the manager "No problem" and then
got over your head, you may be fired.
Don't draw fences around your duties by saying, "I'm a writer and I only
want to write". Learn as much of the subject matter as you can.
Remember, your audience is not comprised of writers. They are using
your product or services to facilitate their work. They can tell if the
author is interpreting the information from a basic understanding or has
been spoon-fed the information.
Also, with the expansion of on-line document tools and products, the
edges between writing, design, and programming are blurring. You will
spend as much time and effort in getting your document to work as you
will in writing it. If you detest non-writing duties, you will not like
I think that one of the largest obstacles that a new writer faces is
pace and discerning useful information. Many new writers want to work
linearly. That is, Chapter 1 - researched, written, ,revised, approved,
and put to bed. OK, Chapter 2 . . . . What happens is that the product
changes and the writer reworks Chapter 1 over and over. Furthermore,
everybody has an opinion of what information goes in or comes out. The
SME wants less, customer support wants more, and Marketing wants a logo
on every page. A new writer can get very uncomfortable with letting a
chapter set while it is imperfect so that they can get onto other
sections. Meanwhile, the deadline grows nearer, none of the other
chapters are started, and Chapter 1 is still not perfect.
My suggestion is to learn to assess what is solid and what is mutable as
the product is developed. Work on those sections that are the most
solid but write knowing that even they could change. To me, the
document is like one of those on-line images that pixelize. First, only
snowy shapes appear, then the shapes are somewhat discernable but
distorted, and finally it is in focus.