Re: Desiging your Documentation/Writing Department

[John Garison <john -at- garisons -dot- com>]

Having started and managed a good half-dozen writing departments, I'd 
have to figure out what the work load was, how often product releases 
happened, what the product itself was like, what the people were like, 
what the software/product development life cycle was like, and figure 
out if anyone in charge of development could say "No" to the developers 
and stick to it. Then and only then would I have enough information to 
begin making a decent decision about what the doc group should be like.

However, I can say that there are some lessons I have learned.

First, find a copy of (the late) Peter Hartman's book "Starting a 
Documentation Group" (ISBN 0-9674179-0-2) and read it. Memorize it if 
possible.

Look at what your strengths are, and put together a team that reinforces 
your strengths, but also fills in your weaknesses.

It's always a good idea to hire one writer who's very technical.

If possible, try to hire someone who loves the tools side of things.

Hire people with innate curiosity. You won't be able to stop them from 
figuring out how things work.

I always look for people with good writing skills. They can learn the 
rest, but being able to write well is not something easily taught.

Don't fret about tools. Tools is tools.

Devise a good way of keeping track of everything, new and old.

Be flexible Be able to adapt to changing circumstances.

Keep one eye on the horizon. You're the leader, so know where you're 
going and lead your group there. They'll follow.

Be willing to take on any task. I always did the release notes because 
everyone else hated doing them.

Get to know your people, give them good challenging work to do, 
recognize their efforts, and they will surprise you with what they can do.

That's my 2¢,


John Garison