Just Write Click

Technical writing with Continuous Integration and docs-as-code

  • JustWriteClick
  • Contact
  • Books by Anne Gentle
  • Introducing Docs Like Code
You are here: Home / talk.bmc / Best practices in tech comm for fit in the organization

February 22, 2006 by annegentle

Best practices in tech comm for fit in the organization

Discussion of where a tech pubs department best fits in a company, and what staffing levels are best suited for success

This post is another part in a series about best practices in technical publications for software companies. Other posts include “ Questions for best practices in technical publications” and “Best practices for document management systems.”

A couple of the best practices listed in the article, “Tech writers as sales reps?” that we referred to for our Austin STC Meeting in October 2005 are related to where a tech pubs department best fits in a company, and what staffing levels are best suited for success. Specifically, the three best practices that the article mentions are:

#4: Have a reasonable ratio of writers to developers.
#5: Place technical writers somewhere sensible in your org chart.

#7: Encourage technical writers to meet customers.
#8: Use customer advisory boards to get feedback on documentation.

I then asked each manager to answer the questions below from their perspective. Here are summaries of the answers and wisdom given.

Q: The author of this article places technical writers in customer support. Is that the right placement for your company and team?

A: All three managers have teams that are located not in customer support, but rather are located in research and development, although the writers at smallest company sit near their technical consultants. So, their interpretation for the article was that perhaps customer support played a very strong role in that particular company, so from a power standpoint, it was a good placement in his case. One manager noted that regardless of where you are in the org chart, you can be physically located near development in order to build rapport and get information that you need.

All the managers realize that having the documentation team close to a group that drives the company can be a positive position. They noted that this positioning can also be a double-edged sword, because a shift in power can place a layoff target on the documentation team.

Q: Do you agree with the author’s 8:1 developer:writer approach? How do you estimate your ratios? What’s the right ratio? How have you used this ratio when asking for resources?

As the article notes that even 20 or 30 developers to each writer can exist, the managers stated that these figures can vary. At the smallest company, a 5 to 1 ratio is in effect, which works very well. The range was anywhere from 5:1 to 10:1, but the managers agreed that the age and maturity of the product being documented should really affect this number. Newer products should have fewer developers per writer. This idea sounded good to me, that the ratio really depends on the new material needed versus maintenance of established documentation.

Related

Filed Under: talk.bmc Tagged With: best practices, technical writing

More reading

Bubble graph showing sources of developer support data

I’ve been thinking a lot about developer support at Cisco recently, especially for the way the world works today with multiple cloud providers. This post is a re-publish of my talk from over five years ago, but the techniques and tools for listening and helping others are still true today. At Rackspace, we watched several […]

Cisco DevNet is our developer program for outreach, education, and tools for developers at Cisco. From the beginning, the team has had a vision for how to run a developer program. Customers are first, and the team implements what Cisco customers need for automation, configuration, and deployment of our various offerings. Plus, the DevNet team […]

I had a great talk with Ellis Pratt of Cherryleaf Technical Writing consulting last week. Here are the show notes, full of links to all the topics we covered. Podcasts are great fun to listen to and participate in, if a bit nerve-wracking to think on your feet and make sure you answer questions succinctly […]

At the beginning of this year, I worked hard to summarize my thoughts on API documentation, continuous publishing, and technical accuracy for developer documentation. The result is an article on InfoQ.com, edited by Deepak Nadig, who also was forward-thinking in having me speak to a few teams at Intuit about API documentation coupled with code. Always […]

Recently on Just Write Click

  • A Flight of Static Site Generators: Sampling the Best for Documentation
  • Try a GPT about “Docs Like Code” to ask questions
  • Discipline and Diplomacy: Docs in the Open
  • Let’s Find Out: When Do Static Site Generators Do Rendering?
  • GitHub for Managing Tech Docs

Just Write Click in your Inbox

Enter your email address to subscribe to Just Write Click and receive notifications of new posts by email.

Read More

  • Privacy Policy
  • About Anne Gentle, developer experience expert
  • Books by Anne Gentle
    • Conversation and Community
    • Docs Like Code, a Book for Developers and Tech Writers
  • Woman in Tech Speaker Profile
  • Contact

Books

  • JustWriteClick
  • Contact
  • Books by Anne Gentle
  • Introducing Docs Like Code

Copyright © 2025 · WordPress · Log in