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: defining your role From:Marilyn O'Leary <moleary -at- LSUVM -dot- SNCC -dot- LSU -dot- EDU> Date:Wed, 4 Dec 1996 08:40:00 -0500
In reply to Ginna Watts
Subject: Defining your role
I understand your discomfort, Ginna, but this isn't all negative. The fact
that many employees are new means that you can seize this opportunity to
build a team. Don't simply justify your existence. Instead, concentrate on
describing how you, the tech writer, will interact with various other
people on projects. Your manager might actually be ignorant about the broad
range of your skills and the ways in which your work overlaps, accents,
enhances, and improves others work -- and vice versa. Give him a boost
too--he either hired you or agreed to your position on this team. You're a
writer, so you can craft this in a positive manner to show how your skills
help every team member and their skills help you. In the end, you will
get the benefit because you will have defined the way this new group of
people works together on this first project. Hope my few words help you a
little. Marilyn.
---Ginna wrote:
...The manager told me yesterday that I need
to 'bring the programmers and customer support people on board.' To that
end, he has asked me to write the 'definitive documentation on
documentation' (yes, that's a quote). In other words, defend my existence
and job to the rest of the team. That is (i.e.? ;), I am to write out a
description of exactly what a tech writer does, what the difference between
user and reference guides are, how online help differs from an electronic
manual etc. When it is complete, I am to give it out, and then make a
presentation to the rest of the team. This is not a presentation on what
I'd like to do with this specific project, but rather a more general, 'this
is what I do and why you should support me' talk.
Am I wrong in being uncomfortable with this? I feel that it should not be
up to me to bring the rest of the team on board. If the documentation
decisions are based on time, money etc., then I could live with doing less,
but I hate feeling like I have to defend my job, especially when I'm so
new.
How should I handle this - any thoughts?
Ginna Watts |
Pacific International Mapping Corp.
4218 Commerce Circle
Victoria, BC Canada V8Z 6N6
Tel (250) 727-0727 Fax (250) 727-3153
maps3d -at- pim -dot- bc -dot- ca
Marilyn Barrett O'Leary
Louisiana Sea Grant College Program
Louisiana State University
Baton Rouge, LA
moleary -at- lsuvm -dot- sncc -dot- lsu -dot- edu