Dawn Stevens, Comtech Services

It appears to be an age-old question: what is the ideal ratio of writing resources to product developers? A simple internet search finds articles and forums addressing this topic dating back at least 18 years to a 1999 study conducted by Comtech Services. That article, When Are We Going to Stop Talking About Ratios? by JoAnn and Bill Hackos itself indicates that the study was motivated by at least 20 additional years of people raising the question.

Each article gives an answer – typically, a range of extremes and an average or ideal number – yet the question continues to be raised again and again. Why? Is there an expectation that the ratio has changed? Is it simply that we don’t like the answer?

In a survey of articles and forums about this issue, the numbers do not appear to have changed significantly over the years:

  • The 1999 study found the ratio to be between 1:1 and 1:23. Leaving off the extremes, the number fell between 1:3 and 1:10, with an average of 1:7.
  • In 2001, Scriptorium suggested a ratio of 1:8 in their Software Development Executive’s Guide to Managing Technical Publications.
  • In 2002, Tekom found a ratio of 1:6 in Germany.
  • In 2003, Cherryleaft research found that a 1:12 ratio was common for organizations with fewer than 500 developers, and recommended an optimal of 5-7 developers per writer. It also referenced a 1960’s research project than indicated writers at a mainframe manufacturer could support 3 to 6 programmers.
  • In 2006, the Suncoast STC found an average of 1:42, a surprisingly high number, but tempered that average by pointing out the median was actually 1:24 or less.
  • Two independent studies in 2007 found the average to be between 10 and 12 supported developers.

These steady numbers over time, primarily between 1:7 and 1:12, would seem to indicate a reliable number on which to base staffing decisions. Nevertheless, it seems counter-intuitive. With technical developments in the last 10 years allowing information developers to easily conditionalize text, reuse information across topics, and create multiple output formats from the same content, it is logical to expect that the average information developer could do more in the same amount of time and therefore support more product developers.

In fact, ratios may have actually increased, but there is a lack of published research to provide this information. As seen in the list of sources above, articles written after 2007 stop short of giving actual ratios. Instead, they provide compelling arguments about why an ideal ratio does not exist.

First, we must call into question the word “ideal.” From what perspective are we answering the question? Ideal to the company? To the developers? To the writers? To the end users? Each view likely results in different answers. Clearly, the company would prefer to hire as few writers as possible simply from a budget perspective. Developers themselves may prefer a greater number of writers if only to avoid writing content themselves, but this must be balanced against the potential of having multiple people clamoring for reviews and answers to questions. Writers ideally want the smallest ratio of all, arguing that a smaller ratio allows better communication and rapport with each developer that ultimately leads to more accurate information.

Perhaps left out of the entire equation, however, is what is best for the end user. As the Hackos’ article points out, “If our budgets and staffing are determined by the number of developers, we are likely to emphasize supporting the developers and creating product-oriented, system-focused information.” The number of information developers required to provide what is best for the end user may have no correlation whatsoever to the number of product developers. Instead, it is more closely related to the complexity of the product and the audiences that must be addressed.

When talking about complexity, it must be clear that the measure relates to usability, not development complexity. A vast number of product developers may be required to create an intuitive, easy-to-use product that is easily documented. Thus a large ratio of developers to writers might exist. However, the converse is also true. A small number of product developers might be able to create a less usable product that requires a larger documentation effort to ensure user success, and the ratio therefore must shrink. This point also applies to a popular substitute for the writer to developer ratio – the number of products or projects a writer can support. Complexity cannot be ignored in either case.

The number of user types being supported also directly affects the developer to writer ratio. The same product development effort might be required for a product designed for a single audience as one designed for multiple audiences; however, documentation efforts increase for each additional audience supported. Similarly, the number of output types, such as print, embedded help, web portal, and training, must also be a factor in the ratio.

Some companies are redefining the ratio question to instead ask how many Agile teams a single writer can support. Agile experts will say that an individual cannot be considered an active team member without contributing at least 50% of his or her time to the team. Because Agile is based on self-organizing, collaborative teams, trying to support any more than that affects the writer’s integration onto the team and diminishes collaboration and effectiveness. In CIDM’s 2016 member benchmark study on Agile practices, 55% of departments supporting Agile development efforts reported that their writers were assigned to no more than two Agile teams. While not a vast majority, it is a good place to start as a standard for defining the number of information developers required.

Accepting the 1:2 ratio of writers to Agile teams, interestingly, can effectively lead us back to the same writer to developer ratios already discussed. In Scrum, the recommended team size is between 5 and 9 people, meaning that an individual writer on two teams supports between 8 and 16 people. On most Agile teams, these people are not all developers. Allowing for at least one QA tester and one other non-developer per team, the writer is supporting between 4 and 12 developers – and we’re back to the same writer-to-developer ratios reported 20 years ago. Here, however, complexity, number of audiences, and number of output types are not a factor. The ratio stays the same, while the number of story points assigned to a user story varies based on those factors and therefore the productivity (defined by the number of stories completed in a sprint) achieved from that ratio may change from sprint to sprint.

The Agile approach also takes into account sustainability, a key principle of the Agile methodology. A writer may be able to support a large number of developers (i.e. greater than 20) for a short period of time (i.e. less than 6 months). However, this is not sustainable; eventually the writer will burn out or quality may diminish. One goal of Agile is a sustainable work rate, which by virtue of team size puts a limit on the number of developers that a single writer can realistically support.

Finally, the Agile approach builds in a method of prioritization. A team can’t do everything in the backlog at one time and therefore goes through a process each sprint to determine what it can do. In effect, a writer isn’t required to support a full project, which in a waterfall development effort might have 20 developers working simultaneously on all features. In such an environment, the writer is expected to support all features simultaneously as all are considered equally important. In the Agile approach, however, developers as well as writers prioritize in the sprint planning process, and a manageable chunk of work is allocated within each sprint.

Based on these factors, therefore, whether you are in an Agile environment or not, Agile practices still seem to provide a reasonable metric for the question of staffing ratios:

  • In an Agile environment, the goal should be one writer for no more than two Agile teams.
  • Outside of Agile, use the average Agile team size and composition to justify no more than a 1:12 writer-to-developer ratio.