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: FWD: Scenario: You're hired a new writer... From:Martha J Davidson <editrix -at- SLIP -dot- NET> Date:Fri, 30 Jan 1998 18:12:48 -0800
At 09:05 PM 1/29/98 -0700, an anonymous poster asked:
>
>What do you expect <a new tech writer> to be able to do with
>the following assignments:
Before I address the specifics, I agree with others who mentioned that
communication between the manager and the newly hired writer is crucial.
If I hire a writer who has less than 2 years of experience, I consider it
my responsibility to spell out what I expect, and to ask the writer what he
or she feels able to do. It is important for writers of all levels of
experience to be willing and able to learn, but it is equally important for
managers and colleagues to provide support and supervision when it is needed.
Throwing a new writer into a project without monitoring the writer's
progress shows a lack in the manager, not the writer, from where I sit.
That said, I'll take on the specifics...
>Convert to documents to on-line.
Depends on the writer's previous experience. I would expect a new writer
to be able to learn how to do this, and I would expect one who was not
familiar with the process to ask me how I wanted it done.
>Index a new manual.
If the writer had worked with indexes in the past, I might assign this. If
she had no indexing experience, I would not expect her to be able to
produce an index from scratch.
>Input edits marked-up by your technical editor.
Absolutely. And until I knew the new writer's style, I'd go over her
changes and compare them with the marked-up copy. I wouldn't expect to
have to do this more than once, but I would want to look at how the new
writer had done the edits at least the first time.
>Write a documentation plan.
Probably not, unless she told me she'd done them before. I might ask her
to try it, though, so I could see how she'd approach both the task of
writing the plan and planning the project.
>Write a manual.
A small one, maybe, but more likely, I'd start her with a new chapter of an
existing manual before giving her a whole new one.
>Write a white paper.
Unlikely, unless she had specific experience writing them.
>Update a manual.
Definitely. And again, I'd offer to answer questions as she worked, and
I'd go over her work afterwards to learn about she approached the task.
martha
--
Martha Jane {Kolman | Davidson} mailto:editrix -at- slip -dot- net
Senior Technical Writer
"If I am not for myself, who will be for me?
If I am only for myself, what am I?
If not now, when?"
--Hillel, "Mishna, Sayings of the Fathers 1:13"
