Who Should Own Documentation?

A named person accountable for each area of your documentation, a clear split between who writes and who is answerable for accuracy, and an agreed rule about what an owner is allowed to delete.

Before you start

Ownership is four different jobs wearing one label: deciding what should exist, writing it, verifying it is still true, and deciding when it goes. Most arguments about documentation ownership are people assigning different jobs from that list and assuming they agree.

Write the four down and work out who does each one today, including the honest answer of "nobody". That list is the input to every step below.

Steps

1. Assign accountability by area, not by article.
   One owner per product area, section or surface. Per-article ownership looks precise and collapses the first time somebody leaves, because nobody inherits a hundred individual assignments.

2. Split authorship from accountability explicitly.
   The person who shipped a change is the cheapest possible author - they already know what changed and why. The owner's job is to notice when an article has become wrong, not to write every word of it.

3. Give ownership to someone who can see the product change.
   An owner without access to the pull requests, the release notes or the roadmap finds out that an article is wrong when a customer says so. That is not ownership, it is triage.

4. Record the owner where the article lives.
   A field on the article, or a file in the repository that maps sections to people. An owner nobody can look up in ten seconds is not an owner, and reorganisations quietly erase the ones that only existed in somebody's head.

5. Give the owner authority to delete.
   An owner who can only add is running an archive. Deletion is the decision that keeps a help centre trustworthy, and it has to sit with the same person who is accountable for accuracy.

6. Make support the demand signal rather than the author.
   Support sees which answers are missing, which is the most valuable input you have. Routing that to owners as a prioritised queue is a completely different arrangement from making support write everything after hours.

7. Set a review cadence per area and put it in a calendar.
   Tie it to your release rhythm rather than the month. An area that ships weekly needs looking at more often than one that has not changed since last year.

8. Agree the escalation path for a disputed article.
   When the owner and the engineer disagree about what the product does, somebody has to decide. Naming that person in advance takes a minute and saves a fortnight.

Every candidate is wrong in a way that makes handing it to the next one look sensible.

Common mistakes

Making it everyone's job. Shared ownership of documentation reliably produces documentation nobody has read since it was merged. Name a person, publish the name.

Hiring a writer with no access. A technical writer who cannot read the code, join the standup or see the release plan spends most of their week interviewing people instead of writing.

Making support accountable for accuracy without visibility. Support knows what customers ask. Without sight of what shipped, they cannot know an article went stale until a customer is already stuck.

Ownership without authority to delete. An owner who can only add ends up curating a growing pile of pages they know are wrong, which is worse for readers than a smaller help centre.

Naming a team rather than a person. Teams do not open review reminders. A team name in an owner field is the same as leaving it blank, with the added disadvantage that it looks assigned.

When this stops scaling

A single named owner works while one person can hold the whole product in their head. That is roughly one product surface and a team small enough to share a standup. Below that line, one owner with delete authority and a monthly review beats any process you could design.

The threshold is not headcount, it is surface area. Once there are areas the owner never uses, they stop being able to judge whether an article is still true and start forwarding questions instead. That is the point to split ownership by area and accept that the reviewing owner and the writing author are usually different people.

What does not change at any size is that the expensive half is authorship. Ownership schemes fail less because nobody will take responsibility and more because taking it means volunteering to write. SupportPages drafts articles from the codebase so the owner's job becomes review and approval rather than a blank page. That does not decide who should own documentation, but it makes the job small enough that someone will accept it.