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.
Go to an encyclopedia and find some obscure animal. Then sit down with
your manager and ask him/her to describe the animal, tell about its eating
habits, environment, reproductive processes, place in the animal kingdom,
etc. Your manager will look at you like you are an alien from another
planet and will probably tell you that you're out of your mind. Smile and
say, "point well taken, Mr./Ms. Manager. If you had one of these animals
in your back yard you could tell me that, couldn't you? In that same way,
I have to have access to the software in order to write about it." Then
sit back, don't say another word, and stare at your manager's face. Wait.
Also, again very rationally and reasonably, tell (don't ask) your manager
to put you on the notification list for the meetings. Say, "Since I'm the
only writer, I'll need to be aware of deadlines and changes as they are
made in order to make the most efficient use of my time. I'll also need to
identify my subject matter experts so that I can set up appointments at
their convenience for getting the information I'll need." Again, you've
tossed the ball in the manager's court. If your manager is reasonable,
he/she should respond reasonably.... few managers would want to bring in a
new writer at this stage of the game.
Also, get the book, "Planning Your Documentation Projects" by JoAnn
Hackos. Read it (not at work), earmark it, highlight it, paste sticky
notes all over it, and then leave it VISIBLE on your desk. But don't
insist your company follows it to the letter (few, if any, do). Rather
it's a guidebook, not a cookbook. For a new writer it's important to look
like you know what you're talking about.
I don't know what Andrew Plato was talking about when he said, "Every
minute you waste obsessing over whether the fonts are correct or if you
fulfilled the needs of your internationally recognized process methodology
are minutes totally wasted." You didn't mention any of that in your
message. If you are expected to write ...from scratch... 1000 page
documents, I'd think you'd BETTER have some kind of plan. You're a new
writer and to be the equivalent of a "coding cowboy" you have to have a
little more experience. But Plato is correct that you shouldn't obsess
over it. Just lay it out and discuss it with your manager. At least your
manager will see that you're trying to get your arms around it and putting
some thought into it.
----- Original Message -----
From: "Lori Lake" <thelakes -at- sympatico -dot- ca>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Sent: Thursday, September 07, 2000 9:51 PM
Subject: New writer needing advice
> Hello All,
> I would really, really appreciate any advice with this situation.
> I am woking for a small software development company who has decided
> the documentation department is too costly, so they've let 4 out 6
> and the 5th person has quit two weeks ago--that leaves me. This is my
> job as tech writer and I've only been with this company for a few
> I am not being included in the weekly Manager's meetings, I don't have
> access to the latest build of the software, the next release is only two
> months away, I'm not sure when, if at all, another writer will be
> the department, and there has been some major changes to the interface.
> Oh yeah, the biggest problem I'm facing--I'm a newbie!
> Where do I start? What is the best way to determine whether or not I'll
> the deadline (there are two 1,000 page manuals--printed, pdf, and
> Without having access to the interface, should I document what's in the
> external designs and verify later?
> Again, thank you for your advice.