Managers often ask: “Who owns the documentation?” Our response, of course, is another question: “What do you mean by own?”

Legally own?
If by “own” you mean, who legally owns the documentation, the answer is the company that you work for. They hire you to create the document, therefore they own you, or least the time that you spend working for them. Everything that you create during that time is theirs.

Owning the maintenance?
If by “own” you mean, who is responsible for maintaining and updating the documentation, the answer had better be the technical communicator. However, this question leads to a more important one: Who is responsible for ensuring that the technical writer is made aware of all the changes so that the writer can make the necessary documentation changes? This question is a bit more complicated to answer.

In a perfect world, the writers would be made aware of all the changes. In the real world, this simply does not happen. It’s not that the changes are deliberately withheld; it’s simply that the product development group is often so busy that they do not have time to make the writers aware, or that they are not aware that they need to make the writers aware.

In addition, even when writers are made aware of a change, it can result in other documentation changes which development would not know or care about. These kinds of changes writers must own.

For example, I was documenting a product that had two types of search functions: simple and complex. I was told that the simple search function had been removed. However, the change to the documentation was not just simply removing the topic that described the simple search function. I also had to update other related topics that referred to both of these function types so that the documentation simply described “searching” and not “different ways to search”. I also had to update the TOC and index, and various cross-references.

Development owns the responsibility of informing the technical communicator about product changes, but the technical communicator owns the responsibility of making the change in all the areas that it applies. However, the situation becomes more complicated if the content is shared by more than one technical communicator.

In a workgroup environment, where several technical communicator have access to the content through a content management system (CMS), ownership is even less clear. If any one can edit the content, then who is the owner of the content? That is why every doc team must have a leader who either makes the change or has the authority to delegate it to someone else. This leader then becomes the owner.

Owning the final say?
If by “own” you mean, who has the final decision as to what appears in the released document, the answer is whoever has the authority to make the final decision as to what appears in the released product. Typically, this is a product manager or business analyst. This means that they can make decisions you may not agree with, but so what? They also make decisions that product developers may disagree with; why should it be any different for information developers?

So, if the product manager insists on including text such as “the system knows that you are logged on”, you can advise against it, but ultimately it is not your decision.

The question behind the question
This question is actually a cover for the real question that managers want to ask:
Who is responsible for the quality and accuracy of the documentation so that we know who to blame if there is a screwup?

There is no simple answer to that question. However, because the principles that apply to product development also apply to information development, we can restate the question as:
Who is responsible for the quality and accuracy of the product so that we know who to blame if there is a screwup?

And the answer to that question is: everyone is responsible: development, QA, documentation,  product management, and so on. The danger, of course, is that if everyone is responsible, no one is.

The only solution is to be as proactive as possible in discovering and destroying all potential problems. Although development should make the documentation department aware of all changes, we cannot assume that they will. Therefore, we should, if possible, proactively review the current version of the product to see if there are changes. You would be amazed what you discover accidentally.

Now, often there may not be the time to review the product, especially if it is large and complex. However, if you can discover changes without relying on others, you will greatly increase your value as a technical communicator. You will gain a reputation as as a “fixer” who solves problems before they start. If everyone in a company relied less on others, the quality of the product would improve, because more defects would be found and fixed.

So returning to the original question: who owns the documentation? Although the technical writer can technically answer: it depends what you mean by “own”, this answer will not get us far in the business world. The better answer is as: as much as we can, we own the documentation.

Documentation has value. If we don’t own it, we have no value.

And if have no value, we have no worth to a company.