FW: Dividing the Tech writer job

[Lynn Perry <CLPerry -at- WALLDATA -dot- COM>]

Here is a description of my situation.  I hope it helps you with your
situation.

I started my career in technical writing by being the only person in the
office who was willing to try to make changes to a document during lunch
hour when the regular word processing staff was out to lunch.  That was
20 years ago (egad!).  I had a degree in English, no typing skills, and
a known ability to learn things quickly.

I've been in both boats: doing everything myself (from running the
software, figuring out what it did, creating online and print help,
writing the text, capturing screenshots, compiling the help, laying out
the document, editing and proofing, checking in the files, and providing
the file to the printer) to inputting just the text and leaving the rest
to two or three others.

My first job was more like what you have now: highly degreed engineers
would bring text to our word processing group who would input the text.
I would edit the docs for grammar and spelling only (this is before
spell checkers on computers), and return the docs to the word processing
group.  They would input the corrections and then deliver the docs to
the engineers, who would mark up the docs and the whole process began
again.

The job I have now is more like what I think you may want: the technical
publications group gets functional specifications from the programmers.
We run the software, figure out what it does (in cases where the specs
aren't enough), do the writing and screen captures, create online help
(WinHelp, HTML, and PDF), edit among ourselves, and deliver help files
to configuration management and print engineering.

The advantage of this arrangement is that I have a lot of control over
the process.  The disadvantage is that I must not only understand the
product but also remember that our headings should be in sentence caps,
we use two spaces after a period, and our color scheme for the Web
should use #800000.

Melissa wrote:
>So I do not have high hopes that these girls would be able
>to grow into tech writers within the next year or so.)
>We are trying to devlope a plan in which definitive roles are
established so that
>everyone knows what their jobs are.

If I were in your place and I didn't expect the "girls" to be able to
learn substantially more, I would first determine whether their
contribution could be helpful.  If it might, I would begin by assigning
them to specific, measurable tasks, things that it would be difficult to
screw up or that if they got screwed up would not matter as much.  Maybe
you could assign them tasks you wish you had time to do, such as create
a project style sheet or create a set of templates, something that is
basically what I call "grunt" work but that can have a high return on
the investment.  Maybe they could do screen captures or write
procedures.  Maybe they can do proofreading or research.

In my experience, it takes a lot of up-front work to mentor the kind of
tech writer you want.  You should probably be sure you have the time or
money to hire someone with the skills you need.  The fact that you have
management buyin is a huge head start, IMO.  Good luck.

C. Lynn Perry
clperry -at- walldata -dot- com
Opinions expressed are mine alone
Wall Data Incorporated, Seattle  WA
Some days it doesn't pay to gnaw through the straps

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=