---
title: "Creating Good Content Requires Cross-Department Collaboration"
date: 2013-09-06
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2013/09/06/creating-good-content-requires-cross-department-collaboration/
---
# Creating Good Content Requires Cross-Department Collaboration
We know that stereotype is a recipe for failure. Collaborating and sharing information across departments is essential for creating the right content. But exactly *how* we are to collaborate across departments isn't as well defined.

In this post, I'll identify 5 ways that you can leverage knowledge from other departments to help you write better content. Especially in an agile environment, the faster you can compile the right knowledge, the better job you'll do as a technical writer.

![collaboration](https://s3.us-west-1.wasabisys.com/idbwmedia.com/images/collaboration.png)

Note that all of these techniques are critical for creating quality content. When you neglect any of them, content quality either suffers or you create more work for yourself. Also, this post will focus on departments in a software development shop.

## Interacting with Quality Assurance

Quality assurance engineers (the people who test the code engineers build) can be a goldmine of information for writing documentation. QA engineers usually have a list of test cases to run against the latest build to make sure the features work correctly. You can pull from these test cases to get a better sense of how features are supposed to work, as well as any constraints or limitations with the features.

For example, suppose your ACME Software 2.3 version is set for release in two weeks (the pace of agile). You may have a notion of the features to be included, but QA knows precisely how these features are supposed to work. They may have already developed specific API calls to run against the features, or enumerated the possible values users might enter for fields, and so on. QA probably has an extensive list of tasks (called "test cases") to try out to make sure everything works.

These test cases can help prime your awareness of how the features work and give you a jump start in writing documentation for the features.

## Interacting with Support

Your Support group (the ones who interact with customers to troubleshoot problems) almost always have a ticketing system where they track incidents/calls. By mining the support database for the most recent incidents, you can inform yourself about various issues users are dealing with. This information gives you a clear direction about important documentation features to focus on. It also lets you know problem areas that may require more documentation.