RE: anyone else in the same boat?

["Sella Rush" <sellar -at- mail -dot- apptechsys -dot- com>]

My first formal tech writing job was very similar.  I'd had some experience
working in a publications team, but this job was for a small software
development group that had never had a tech writer before.  I had to figure
out what the job was and what my role was as part of my orientation.  Based
on that experience, here are some insights that may be applicable, followed
by some suggestions.

Insights:

1.  Your new managers probably know *in theory* that they need a tech
writer, but may not have a concrete plan--may not have any idea what you can
do for them.  In fact, they may be relying on you to tell them.

2.  They probably have one or two specific projects they know they want
accomplished--this is probably what drove the effort to hire you.

3.  While the managers may not know a lot about what a tech writer does,
your coworkers (developers, sys admins, etc.) may have lots of experience
from other jobs.  Surprisingly, they can inadvertently give you pointers
(you can ask them if they've worked with tech writers before, and what kind
of routines were they comfortable with).

4.  Inevitably, there will be 10 times more work needed to be done than you
can do.  So just worry about what you can do.

Suggestions:

1.  You need to keep thinking both short and long range.  This can get
complicated, but it's important.

Initially, the short range are those concrete projects the manager
identified.  These are your absolute, number one first priority and should
*not* be bogged down while you set up templates and processes.  If the
manager doesn't have a project, pick one for yourself.  As Andrew
said--start small.  And he doesn't mean an organizational project--he means
a project that has tangible value to your employer--a white paper, some web
content, a useful graphic or diagram.  You want your manager to feel they
were right to hire you.

[In my case, my company needed content for potential customers or interested
parties.  I compiled the written matter produced by the team (stuff that I
had to find and read anyway), organized it into shape for public
consumption.  I cleaned up the graphics, edited the text, added professional
formating.  The job wasn't neat, it was done using a process or a plan or a
template.  This was a quick and dirty effort to provide them with some
useful results.  It was also a step I could build on in the future.]

Once that first short term project is done or on its way, start working on
the next short term project.  *Always* have a short term project--and not an
overhead/organizational project.

While you're working on your short term projects, make your long terms
plans.  Long term plans should include:  (a) learning your employer's
business--the technology or whatever, (b) getting to know your colleagues
and your sources (subject matter experts), and (c) setting up those tech
writing processes such as plans, templates, style sheets, etc.  Other long
term issues will rise up as you go along.   Implement your long term plans
as you're doing your short term projects.

Our tendency (most of us anyway) is to want to stop all work until we get
organized, until we get a plan fixed and then move ahead using our plan.
Try to resist this.  In this type of lone writer unorganized situation,
there is literally too much for one person to organize; you have to learn
how to deal with working in chaos and then how to instill organization
little by little.  The first time you create a report for someone, you're
going to be making decisions about document format, grammar issues, etc.
Everytime you make a decision, you add one more rule to your style guide.
The visual format becomes your template for that type of document, and the
logo in the bottom right corner of the cover page now always goes in the
bottom right corner.  When you start a major documentation project, don't
start by trying to create your own project plan template--begin using
Hackos' documentation plan template, and then adapt it with each new project
until it becomes your standard.

2.  Depending on your personality and the personality of your new team, be
creative about what kind of work you do.  In a small, loosely run company,
rigid job descriptions just don't cut it.  Employees are expected to do
whatever needs to be done.  If the head of the company wants you to edit a
letter to his congressman, spend the ten minutes and be glad you could make
such a good impression so easily.  Do as much as you can without
compromising the documentation projects you're working on.

3.  Be sensitive to the need for internal documentation.  This is where I
fell down on the job because it simply didn't occur to me.  We all know
about documentation that needs to accompany a product; we know about
marketing material and communicating with our clients and potential
customers or investors.  But there is a very definite need for communication
within your own team. One team member solves a problem or develops a neat
little utility that's useful to everyone.  You can help by helping the team
member document it or disseminate the info.  Internal training also requires
good internal documentation.  This is very important because it lessens the
ramp up time for a new employee and it lessens the burden on the experienced
staff.

4.  Finally, if, like me, the first concrete project your manager hands you
is the entire SDK documentation set for the company's flagship project, get
your foot off the bridge railing and take a deep breath.  You'll have to
break that first mega project down into managable bits.  The best way to do
this is to find a document similar to whatever you're working on and try to
come up with an outline.  Then get your manager to prioritize it.


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Take XML and Tech Writing courses online!  Our instructor-led courses
(4-6 hrs/wk) give you "hands on" experience at your convenience. STC members
get 20% off!  http://www.online-learning.com/index.html.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.