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:David Jones <dvjones -at- KSBE -dot- EDU> Date:Tue, 3 Dec 1996 10:30:00 -1000
What a wonderful opportunity you have! You can educate your
co-workers, help replace any misconceptions and/or lack of
imagination they may have about TWing, help them learn new ways of
working efficiently with TWers, etc., etc. If you include a
question/answer session as part of the presentation, you'll get some
clues identifying co-workers who need more education or have more
difficulty accepting what a TW really does ...
"How should I handle it?" you say? With great enthusiasm and joy.
I envy you, Ginna!
On 3 Dec 96 at 11:22, Ginna Watts wrote:
> Hi all,
> I am fairly new in my job, at a company where I am the first (and
> only) tech writer. We have gone through some fairly significant
> hiring in the last little while, so I am not alone in being new. The
> manager of the R&D group is also new, and he has asked me to do
> something I'm not very comfortable with.
> First, some background: The company is in the middle of a major
> upgrade of its software, from DOS 5 to NT 4. We have tentatively
> decided that the documentation will be significantly upgraded as
> well. There exists now a good reference manual for the DOS version,
> but no online help and no user guide as such.
> I would like to update the reference guide, create a context
> sensitive help system, and design a user guide. 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?
David Jones, Technical Writer
dvjones -at- ksbe -dot- edu
Thought for the day:
Advertising (n): the science of arresting the human
intelligence for long enough to get money from it.
-- Stephen Leacock.
DISCLAIMER:
The views described herein are the views of the author, and
do not represent the views or opinions of Kamehameha Schools
Bishop Estate, nor is there any approval or authorization of
this material, express or implied, by the Kamehameha Schools
Bishop Estate. If you suspect that any of the material in
this message or attachments thereto is in violation of a
copyright, please notify the Webmaster immediately by e-mail
at "Webmaster -at- ksbe -dot- edu".
