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:Ratio of tech writers to developers From:Bill Swallow <bill_swallow -at- yahoo -dot- com> To:TECHWR-L listserv <TECHWR-L -at- lists -dot- raycomm -dot- com> Date:Fri, 30 Jun 2000 05:39:59 -0700 (PDT)
OK... I've sat back and watched the responses roll
in... Who makes up these freakin' numbers in the first
There is no ideal writer to programmer ratio. Why?
Because there's no ideal work situation! Well, sure,
there may be for one company or one product division,
but you simply cannot apply these numbers across the
I'll give you an example using my own experience:
At my former job, we had 15 writers trying to play
catch-up to over 150 developers. Now, I'm the only
writer and I'm keeping up with the 80 or so developers
just fine. What's different? Everything.
Why are you looking for an ideal number to begin with?
Are you that desperate to hire more people? I surely
hope you're not taking these numbers to management and
saying "this is proof that we need more writers".
Here's how you begin to assess how many writers you
1. Speed of development - what is your release
schedule like? How big are the changes?
2. Type of application - is it an intuitive web-based
GUI or a character-based monster system?
3. Catch-up factor - are you playing catch-up to years
of development, or are you fairly current with
4. Doc types - are you responsible for user guides,
systems doc, training doc, QRGs, Help, all the above,
none of the above?
If releases are far apart, changes are minor, the app
is intuitive (well-designed), you're not too far
behind development and you are producing one or two
types of documentation, you're probably OK and maybe
could use another writer to get things done a bit
quicker and give the rest of you some breathing space.
If you're in the opposite situation, you probably need
Now for the final factor: profitability.
Does your documentation turn a profit for the company?
If so, how? Does a lack of adequate documentation lead
to more paid support? On the flip side, does the
comprehensiveness of the documentation lower support
calls and reduce overhead? Do your developers and
other employees benefit from the documentation,
allowing them to do their jobs better? Do you produce
additional documentation for a fee?
You may not want to hear it, but no manager wants to
run a division that lowers company profits. Remember,
though bad documentation costs the company money, so
do writers. Instead of arguing numbers and ratios, try
approaching your manager with a plan that will lower
overhead or increase profits. Show them that
additional writers, though eating up more salary, will
do good for the company's bottom line in the short run
and in the long run.
Just my thoughts on the issue.
- Bill Swallow
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/