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:Sarah Carroll <sarahc -at- INDIGO -dot- IE> Date:Fri, 30 Jan 1998 17:19:55 +0000
At 10:54 30/01/98 -0500, Anita Collins wrote:
>It sounds to me (and I'm reading a lot into your message, so ignore this if
>it's off base) that you may not be happy with the performance of the writer
>in question, and you're wondering whether to write it off to lack of
>experience or perhaps to lack of direction.
My impression from reading the introduction was that the
poster was the "new hire". This because of the phrase:
>You've given them no information on what is expected of them, but you
>have given them a variety of assignments.
It's not often you will hear the hirer make a statement like that. In
that context, I would look at the job description (if there was one),
think about what I claimed to be competent in during the interview
process, and if out of my depth, tell the manager. Ask for some
help. Ask others in the department.
Depending on the type of experience the new hire had, I would
expect them to be able to:
>Convert to documents to on-line.
if they had experience in doing this, with the package we use.
>Index a new manual.
if they had done this before, and I'd seen a sample of an index
they had created. I don't think I'd leave an entire index to a new
hire with 1-2 years experience, but then, I think the index is a
critical factor in whether or not technical documentation is good.
>Input edits marked-up by your technical editor.
absolutely
>Write a documentation plan.
might do this during their first month to see how they think,
how analytical they are, attention to detail and to familiarise
them with a new product.
>Write a manual.
depends how big and what it encompasses. Installation guide
perhaps.
>Write a white paper.
depends on their background, if it was academic, probably, if
industry perhaps not.