Re: Where does Documentation belong?
Hello All
I am having some discussions with others in the company about the place of
the Documentation section. Here is the scenario:
OK, I see everybody has an opinion on this one -- including me of course. Proper disclosure: my track record in corporate politics stinks, so take what I say with a grain of salt.
We are a recent start-up, software company of about 90 people. I came on
board 4 years ago as the only technical writer, producing user manuals and
Help, and was placed within the R&D department. At that time we had 13
employees. Now we have grown to 90 or so, and are likely to grow to 150 in
the next couple of years. We now have a second full-time technical writer.
Ouch! Your overall staffing has grown almost 7 times, yet your pubs staffing has only doubled.
While we still work mostly for R&D, we find that other departments
increasingly make demands on us. This includes process design, template
production and maintenance, reports, training materials, etc. As the
compnay grows there is more and more scope for our talents, that may
include financial report writing, policies and procedures, etc. If we are
not involved in these areas, there will be a lot of duplication of effort
taking place.
Well, maybe. Though every company I've worked for has had a department that specialized in technical communications, with separate groups for things like marketing and corporate comm. If you feel qualified to do several kinds of writing, more power to you. But many of us prefer to specialize. I personally like to write about nit-picky little technical stuff, and I wouldn't want to spend a lot of time in meetings where marcom was the question at hand.
There *are* functions that its wasteful to duplicate, especially if you plan to hire people to do art work, manage print production, etc. And it would also seem logical for your web team to be tied to your pubs teams somehow, though that hardly ever seems to happen in real life.
My ideal would be a pubs department at the VP or Director level (I'm using U.S. corporate jargon -- I gather the terms are different in Canada). This unit would "sell" pubs services to the reas of the company or division. Within this unit you'd have people specializing in tech comm, marcom, production, web monkeying, etc. These might or might not be divided further into specialized departments, depending mainly on the size of the unit.
Of course, this ideal has to be tempered by the practical reality in your company. I doubt if it's a good idea for you (I assume you're the senior writer and/or pubs manager) to go to the VPs and Directors and say, "I want to carve out a bureaucratic entity out of pieces of the company that currently belong to you guys." On the other hand, you might be able to sell them on the basic concept of centralizing pubs services in one department.
But is doing so a top prioirty? Yeah, you're avoiding duplicating services, there are other issues. Some managers won't want to give up control of functions that are central to their own orgs. This may be out of practicality, or it may be simply not wanting to give up something they "own". Either way, you'll have to consider carefully exactly how hard you want to press for centralization, and what it'll cost you to do so.
One of the issues we face is the question of advocacy when it comes to
budget allocations, etc. I don't think R&D really understand what we do,
anyway (they just accept that manuals are produced), but wherever we fit
we would need someone to fight our corner.
A *very* common problem. And finding yourself a new home in the corporate hierarchy is one way to approach it. But that still leaves you with bad relations with the R&D people -- and that is not a good thing. If you want your technical content to be correct, complete, and current, you need your writers and developers talking to each other. So even if you end up totally divorced from R&D, I'd urge you to work at repairing that communication gap. Do a dog and pony show, talk about the pubs process, explain how good docs help sell the product and reduce support costs. You guys may not like each other, but you do need each other.
So we are looking at where Documentation belongs, and I'd like to draw on
the opinions of those who have gone this route. We're clearly not talking
about the IBMs or GMs of this world, but if you work for a small-to-medium
company, I'd be interested to know where you fit in.
Well, 90 people isn't Sun or SGI (both of whom I've worked for). But structurally, a small company like yours is not that different, structurally, from a product division at a major tech company. (Sun, in fact, used to call its divisions "Operating Companies", though that changed when they realized the opcos were getting *too* independent.)
Previous by Author:
Re: Javadoc resources for tech writers?
Next by Author:
Re: Where does Documentation belong?
Previous by Thread:
Re: Where does Documentation belong?
Next by Thread:
Re: Where does Documentation belong?
Search our Technical Writing Archives & Magazine
Visit TechWhirl's Other Sites
Sponsored Ads