SUMMARY: Growing a Department 2 of 3 (LONG)

[Barb Ostapina <Barb -dot- Ostapina -at- METROMAIL -dot- COM>]

Here's part 2...
**********
> Has anybody out there...
>   * been the first ever tech writer/communicator hired in your company,
 Well not exactly. The company had had a Tech Writer in the past,
but had to lay her off during a financial crisis. When the crisis passed,
the original writer had moved on, so they hired me.
>   * stayed the "lone ranger" for a year or two,
 Yes. I've been the only writer on staff for almost 4 years.
>   * recognized the need (vs. desire) for additional tech
writer/communicators,
 Yes. Or rather, predicted. I had a discussion a few months back with my
 boss where I described my current
 workload. Then I pointed out that as our company was growing and taking on
  more projects, I would need
 more help. i.e., I didn't wait until I was already swamped -- I predicted
 when we would need another
 writer (within the next year), and why (increased workload). The
 alternative would have been to
 reduce the amount of documentation done per project.
>   * tried to make a case for turning yourself into a department and
hiring additional staff,
 Yes. In fact, I hardly had to mention it. Documentation needs got included
  in the overall plan for
 increasing the size of the company.
>   * and been successful?
 Yes. I've just been given the go-ahead to hire another writer. I hope to
 find someone in the next month
 or two. Then we'll be a department of two. This will mean some changes in
 the way I work -- we'll need to
have some formal standards/guidelines in place that I haven't needed before
  now, and some sort of
fair system for making sure everything gets done. I'm looking forward to
 it.
> If so, would you mind sharing your story? Especially the successfully
grew a department part.
 I think this is why this worked for me:
 - Our company is growing and taking on more projects. This made it easy
 for me to make a logical case
   for needing another writer on staff.
 - I've established myself and Documentation as a necessary part of our
 product
 - My management is very reasonable.
 - I had been successfully handling the current workload. I think this
 helped give me more credibility.
**********
Barb--Basically what I did was live at work (except Saturdays, when I lived
 at home, but took work there)
six days a week for four and a half months to get the documentation out for
 our product. I was always
honest about what I thought my limitations as one person were, then I
proceeded to use my back, nights,
weekends, and goodwill from my family to exceed those limitations. When we
released, I told them I'd never
do it again, so when we started to sell the product I better damn well get
some help or I'd move back to
[city] where I could enjoy winters. Since then, I told management what I'd
like to do with the documentation,
got them all excited about it, then told them what I could produce, which
was substantially less.
     We've (hopefully) got some money coming in in the next month or so and
I'm supposed to get help. Though management sometimes drives me to
distractions on little things, I trust them on this. Assuming they do what
they said they'd do, that's how I proceeded. I hope this is helpful.
     PS -- if you quote me, please do it anonymously on this one.
**********
Hi Barb, Yep, I've been there and done that in a small way, but I wouldn't
say that I had a success story
to tell you.  So it may be useful to you.
     The company I worked for was small software company, and I was working
sixty to eighty hour weeks to meet my dead lines.  My frazzled appearance
helped convince them that the need for at least one more technical writer
was genuine.  They gave me the task of managing the new writers.
     Around this time they were going for quality accreditation, so I was
in the fortunate position of being able to write the documentation
department's procedures.  I was happy, it meant that when new technical
writers came on board  I had already prepared procedures to be followed and
standards to be adhered to, and I think a style guide to be followed as
well.  I was ready.
     We advertised and received at least ten really good applicants.  The
company was interested in having visually exciting and beautiful manuals,
so applicants who had some graphic design in their background were looked
on favourably. And, I argued, that it would improve the user interface as
well.
     I was asked to assist in  the interview process, and assessing the
interviewed applicants.
     The directors of the company really liked this guy who was a graphic
artist. They really liked his graphic stuff and really wanted to hire him.
I had asked him in the interview if he was willing to learn technical
writing.  Yeah, sure, he said keenly (he was about 23).    I said later, I
can see why you like him but can he write?  Conscious that my sixty to
eighty hour weeks were not going to decrease very soon.  Oh, you can teach
him, they said.
     This guy was the most arrogant SOB I had ever come across from the
moment he stepped in the door.  He was really interested in proving that he
could teach himself technical writing, it seemed to be important to him
that he could do it himself.
     I learned a lot about graphic design from him, finished my manuals and
then left.  I had no support from my management in trying to get his
writing quality up to standard, because they were only interested in how it
looked, and implied that my standards were too high.  As long as words were
there.
     In short, the experience could be a major headache.
**********
Hi Barb, I was not the first technical communicator in our company, but
when I was hired, the company had not filled that position in 2 months. And
so it _felt_ as if there had been no one before me. :-)
     And yes, I did stay on as a single tech writer for about 9 months
before recognizing the need for another tech writer. The main reason for
this being, the increasing demand for my services within the company and
because I had (at that time) started up a big project for a major client.
So I needed some one to help out with the in-house projects.
     It was pretty easy to convince my manager (who is also the Illinois
Operations Manager) to hire
one more tech writer. Actually he suggested it to me after seeing me teeter
 under a heavy load.
     Brief background:- [Company] is a technology consulting company with
250+ employees. [Co.} has five branches. Each branch has its own tech
writing department, though right now the [XX] branch is looking for a tech
writer, and [XX] is just starting up.
**********
Hi Barb, I did this.  A year ago I was a contractor presenting this concept
to management with 2 other "newbie" contractors.  Today I supervise a unit
of 3 full-time and 4-6 contract writers and 3 full-time trainers.
     Basically, our division knew they needed policies and procedures to
please the big 3 automotive
companies, but they didn't want to invest. They hired a contractor here, a
contractor there, etc., but the
results were inconsistent and the quality was questionable.  I started to
broach the subject with our
manager and director... they told us to work as a "team."  Yeah, right.  We
 did.  We worked as a team to
nag them to death and give them business proposals and presentations until
they finally relented and saw
the light.
     I'd be happy to answer questions via e-mail, but I'm getting out of
the techwr list for a while.
     Also, I'll be publishing a fairly academic paper about my experience
on the Web (I think) and maybe
even in a publication.  I'm presenting it next week at a national English
teachers' conference.  Let me
know if you want the data on the paper.
**********
Hi Barb! I've done this once and now I'm doing it again. (Except in my
first job I was only a lone
ranger for 8 months, and here I've was the lone ranger for a little over a
year.)
     I suspect what you're looking for is ammunition to make a case to your
management that
you need staff. Here's some ideas to help out.
* Point out how many hours per week you put in. I suspect it is over 40.
Point out that management studies show that people lose efficiency when
worked over 40/wk for more than six weeks. I have more detail if you need
it.
* Point out that you are entitled to a life outside of work, and the extra
hours affect your ability to enjoy life.
* If you are documenting software, use the metric of 5-10 programmers per
writer. Most of my writing has been software-oriented and I have found that
1 writer per 7 programmers works well in our environment. Other companies
have different ratios, so develop one for yourself. Apple, for example used
to have 2 writers per EACH programmer! The main reason for their odd ratio
was because the writers doubled as testers, and were expected to spend more
time reporting bugs than writing! Once you get management to accept a ratio
as a good metric, then justifying new hiring requisitions becomes
automatic.
* Point out what is NOT getting done right now. Some of my arguments have
included: full-scale indexes (I only had time for basic ones),
task-oriented chapters that explain how to get full use of the products as
opposed to merely documenting how they work. Online help keywords (online
help version of indexing!), assisting programmers in developing specs and
design documents, developing training materials, assisting marketing with
brochure text (getting it technically accurate!), getting docs done on a
schedule (as opposed to just barely squeaking it in under deadline),
providing coverage in case of major illness/accident/urgent priority
project.
* Expand your scope. Right now you do writing, but when conditions are
right you can delve into other areas. In my current job I have two other
functional areas: training and customer support. Most writers get shut in a
cube or office and never meet clients. Because we're a young and growing
company, I asked for (and got) the permission to include training and
support in my "department" (kind of silly when it was just me for a while).
All three areas are related: they all provide information to the customers.
Ever had the experience of being trained on a product and learn one thing,
the docs say another, and the call to customer support yields a third an
swer? I won't let that happen here. By bringing it under one department I
hope to ensure that we always give the same consistent information to our
customers. Every one I hire (I now have three people working for me) needs
to be able to work in at least two of the three areas. I have a
Writer/Trainer (writing is her first priority, training second), a
Trainer/Writer (reverse priorities), and a Customer Support/Trainer. (and
me, I do all three!) (oh, and an open req for a Customer Support/Writer.
**********
--Barb
barb -dot- ostapina -at- metromail -dot- com
...speaking only for myself.