TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Technical Writers per Developer From:Don Child <Don_Child -dot- DATAHOUSE -at- DATAHOUSE -dot- COM> Date:Fri, 13 Jan 1995 07:15:58 HS
Chris Grierson writes, "The Technical Communications Department here is
interested in determining some kind of "standard" or accepted figure for the
number of technical writers that a company should have per developer. The
Society for Technical Communications was unable to help, and a search of the
literature did not produce any results. Any numbers from other organizations,
or any ideas on how to find this data would be appreciated."
Here at DataHouse, I am sometimes the only technical writer for 50 to 60
developers, who may be jointly working on as many as 20 projects at a time. I
have been aided at times by as many as 2 other writers. My duties also include
newsletters, PR, white papers, presentations, training, graphics, developing
Web home pages in HTML, etc. I get the feeling there is a sizeable community of
tech writers and trainers who have to wear several hats. Note that DataHouse is
an employee-owned company, so everyone in the company has a big stake in
corporate profitibility. I could ask for more tech writing support, but found
it better to establish documentation standards and an ad hoc in-house style,
then train analysts to write their own documentation as far as possible. I
frequently see a document for the first time in the 95% draft stage. When that
happens, I make editorial suggestions and provide guidance that will make the
documentation more usable the next time around. Some analysts just cannot be
trained though. For them, I keep a pulse on their project, and try to budget
time when I know they have a project that will need some end-user
documentation.
I might also mention that this many-hats and train-the-analyst approach works
in part because we provide a lot of local support, being far and away the
largest independent consulting firm in Honolulu. The documentation for a
project may be targeted at a very limited audience of users who know the
members of the development team, and who know they can call on us if they have
problems. When we develop a product for wider commercial release, or develop a
major system, for the State government for example, I have to dedicate more
time to the project, or find another writer to support me.
I'd be curious to know how many other technical writers have to spread
themselves thin. I would guess there are regional differences, and differences
depending on industry.
Don Child
DataHouse
don_child -dot- datahouse -at- datahouse -dot- com