The question comes up over and over again: How many technical writers should there be in your organization relative to the number of developers? It seems so simple, so reasonable to ask. Why can’t we provide a single, objective number to answer it?
Because the answers vary as widely as organizations do.
In this 2019 Write the Docs newsletter, for example, a review of the literature pointed to ratios of 1:7 and 1:12 as fairly standard, then noted ratios as high as 1:51. The newsletter concludes: “[The ratio] varies because needs vary: a developer team focused on performance improvements won’t generate much doc work, whereas two working on big UI changes might create lots.”
More recently, in a November 2023 Write the Docs Slack thread, one commenter referenced a blog post by Astasia Myers, who, in conversation with a seasoned tech comm manager, reported that 1:10 is the optimal ratio. Another commenter quoted from the Bureau of Labor and Statistics to highlight that in 2021 the ratio was 30:1. Perhaps most insane of all, this 2023 Write the Docs presentation by Kari Halsted discusses how her organization “survives, nay, thrives” with a ratio of 200:1.
Color me skeptical.
The ratio question came up for me in a concrete way quite recently. In response to an executive-level inquiry, my manager and I looked around for an industry standard, but because there are so many variables—organizational factors, professional judgment, and simple benchmarking—there isn’t any official number or range. We looked to Joan Hackos’ book Information Development: Managing Your Documentation Projects, Portfolio, and People, which contains a detailed chapter on staffing and budgeting, and found a similar variety of ratios—along with a similar lack of standardization. Hackos writes:
“Your budget might also be expressed as a ratio of headcount in product development to headcount in information development. Some organizations decide that they should have one information developer for every three, seven, ten, or fifty product developers. In our benchmark studies of these ratios, I find that seven to one is a fairly common ratio in software-related organizations, and a higher ratio is common in hardware-related organizations.”
Which of course is not an industry standard, is based on benchmarking rather than extensive industry or scholarly research data, and is probably only marginally more “official” than the resources mentioned above. Indeed, Hackos herself expresses skepticism of the ratio question due to the murkier factor of the business culture surrounding the documentation team:
“[…] I find little logic in determining these percentages or ratios. They are most likely to be determined by the value those who control the budgets place on information development. If information is considered vital to the usability of the product, it is awarded a higher percentage of development costs or has a lower ratio of product to information developers than if it is considered a necessary evil.”
The commenters in the Write the Docs Slack thread above started to come a similar conclusion, with statements like the following: “I’ve never heard of a reliable ratio”, “it’ll be hard to present a quantitative case”, “if the engineers actually write”, and “The ideal ratio will depend on them company’s docs culture and processes.”
As one contributor put it, maybe a ratio of 100:1 is fine for you because many non-writers are happy to contribute. Conversely you may have 5:1 and it’s still hard to be productive because documentation has a bad rap. Several people suggested that it may be best to think in terms of how many Scrum teams a writer can support. One writer for every two or three Scrum teams seems reasonable, right?
The ideal ratio, in short, is a myth. Even if it were real, your organization could react to it in different ways. Depending on the perceived value of documentation, the leadership might ignore or downplay the ratio, or try to get away with as little investment in documentation as possible. An organization that highly values documentation, on the other hand, might be more open to hiring more writers to work towards a better ratio. But without digging deeper into the reasons behind the ratio in the first place, well, who’s to say what is reasonable?
Now, it could be argued that a range of ratios is nice to have as an approximate comparison. For example, knowing that some software organizations are at 10:1 and others are at 30:1 and you’re at 20:1 could be nice a validation because you feel like you’re right in the middle, and the optics are good. (“Look, we’re not asking for too much or too little!”) But in the end that information is still limited in its usefulness because it doesn’t really tell you if you have too many, too few, or just enough writers to add maximum value in your particular organizational context. In reality your writers could be constantly overwhelmed by a large backlog, struggling to keep pace with maintaining thousands of pages of documentation and having little time to innovate or truly improve upon it or do a quality job with the tasks they are given.
So I think the question needs to be re-framed, and in this regard there’s a helpful blog post from 2016: What is the Optimal Writer:Developer Ratio? The author, Rob Woodgate, argues that the “ideal ratio” is a mirage, and takes a step back to ask the question in a different way: What information do you need to know before you can decide how many writers you need? He then provides heuristics which are more likely to produce a good answer because they focus attention on assessing the team dynamics and business needs unique to your context. Here’s his list:
- Are your writers part of a scrum team?
- How are you handling peer review?
- How much documentation do you need?
- What kinds of documentation are needed?
- Who is responsible for bringing together the finished documentation set?
- How good is your design team?
- How much technical debt does your product have?
- What SHOULD your writers be doing, vs what ARE they doing?
Go read the whole thing. Each item has a good analysis, especially the ones about how much documentation you need for your products or services, what kinds or types of documentation you need (for example, do you just need a user guide and release notes, or do you also need API docs and/or other deliverables?), and how good the UX design team is (a well-designed, usable product is not only easier to understand and document—it typically requires less documentation).
Another way of saying it is this. Rather than asking what data you can collect to come up with an optimal or official industry standard to compare against, ask what knowledge exactly your business needs, how documentation is currently produced to meet those needs, and if/how additional writers could bring value to the business to meet those needs. This certainly doesn’t mean that benchmarking is pointless. It could still be helpful to know the ratio of writers to developers at a similar type of organization (if such information is available) so you have some basis for comparison. But this is really just a starting point, and a cautionary one at that, because all sorts of questions will begin to arise about what specific knowledge problems your organization needs to solve and whether or not another writer will help to solve them so as to justify the investment.
Richard Rabil, Jr. 