Whose job is it to update outdated documentation?

This question surfaces about eighteen months into every growing operation, usually right after somebody follows a procedure that turned out to be wrong. The answer given in the moment is nearly always one of three, and all three fail for the same structural reason.

They assign the work to a role, a moment, or a virtue. Roles get vacated, moments end, and virtues are not a schedule.

The three answers that never hold

The first is the intern, or whoever is most junior and least busy. This fails on knowledge rather than effort. Updating a procedure requires knowing what the correct version is, and the most junior person is the least equipped to tell a deliberate process change from somebody doing it wrong. They will faithfully document whatever they observe, including the mistakes.

The second is the new-hire onboarding task. Every new support hire is asked to update the docs as they learn. This is appealing because it looks like it solves two problems at once, and it does work briefly. It fails because onboarding ends. You get a burst of accuracy every time you hire and nothing in between, which means your documentation quality tracks your hiring schedule rather than your rate of change.

The third is whoever notices. This is the most common answer and the weakest, because it assigns responsibility for noticing, and noticing is the single thing humans are worst at when the work in front of them is already done. The person who spots that the SOP is stale has, by definition, already got the answer they needed. Fixing the document is unpaid work performed after their problem is solved.

Why role-based ownership breaks

The apparently mature version of this is to name an owner per procedure. This is better and it still fails in a specific way: teams name a role rather than a person.

A procedure that says escalate to the ops lead reads as well-owned right up until the ops lead leaves in March. Then it is owned by nobody, and worse, it still looks owned. Anyone auditing the library sees an owner field that is filled in.

A named person fails loudly. When Priya leaves, every document with her name on it is visibly orphaned, and orphaned documents get reassigned during offboarding because somebody is already going through her responsibilities. A role fails silently and stays broken for a year.

Use a name. Accept that names go stale, because stale names are a problem you can see.

Own the change, not the document

This is the shift that makes ownership stick, and it is not how most teams set it up.

Ownership usually attaches to the document: whoever wrote the refund SOP owns the refund SOP. The problem is that the author is rarely the person who changes the process. Your marketing lead rebuilds the Klaviyo welcome flow in April. The person who owns the Klaviyo SOP is somebody in support who wrote it in January and has no idea anything moved.

Attach ownership to the change instead. Whoever changes a process owns updating the documentation for it, on the day they change it. The marketing lead who rebuilt the flow updates the flow SOP. They are the only person who knows it changed, and the day of the change is the only moment they still have the details in their head.

This sounds like more work distributed across more people. It is dramatically less work in total, because updating a procedure you just changed takes about four minutes, and reconstructing what changed three months later takes an afternoon of asking around.

An owner without a trigger is decoration

Naming an owner and stopping there is the most common half-measure in documentation. It puts a person's name on a document and then relies on that person to spontaneously remember, which returns you to the whoever-notices problem with extra steps.

Ownership only works when something tells the owner it is their turn. Three triggers cover most cases.

• Time. The document has not been verified in 90 days and the owner gets told. Crude, but it catches procedures that quietly stopped being true without any visible event.
• Change. Somebody edits the Klaviyo flow, changes a Gorgias macro, or updates the returns policy, and the SOPs tagged to that tool surface for review. This is the highest-signal trigger because it fires on the actual cause.
• Use. Somebody runs the procedure and reports that a step did not match. The person executing the work is the cheapest sensor you have, provided reporting a mismatch takes one click rather than a message to a manager.

Any one of the three beats none. Most teams have none, which is why their ownership assignments read as accurate and produce nothing.

How many SOPs one person can hold

Ownership fails quietly at scale. Somebody who owns eight procedures reviews them. Somebody who owns forty owns nothing, they have forty names on documents and a reasonable excuse.

As a working number, one person can genuinely hold ten to fifteen procedures in a domain they already work in daily. Past that the review becomes a formality: they open each one, skim, and mark it reviewed without running it, which is worse than no review because it resets the freshness date on a document nobody checked.

If your library has 60 procedures and two owners, you do not have ownership. You have two people with an impossible obligation, and the honest fix is either more owners or fewer procedures. Fewer procedures is usually the right answer and almost never the chosen one.

Why one library-wide owner fails

The instinct at 15 to 30 people is to appoint one person as the documentation owner. It is clean, it is one name, and it removes the question from everyone else's plate.

It fails because that person cannot evaluate most of what they own. A documentation owner sitting in operations cannot tell whether the Klaviyo segmentation SOP is still correct, because they do not work in Klaviyo. They can chase people, track review dates, and produce a dashboard. They cannot verify anything, which means the library's accuracy still depends entirely on the people they are chasing.

Scope ownership to the department that does the work. Support owns the support procedures, marketing owns the flow procedures, ops owns fulfillment and 3PL. One coordinator can hold the process together, but the verification has to sit with people who touch the tool, because verification is the only part that matters.

What happens when the owner leaves

Departures expose whether ownership was ever real, and this is worth planning for once rather than handling five times.

Add documentation to your offboarding checklist, next to laptop return and account deactivation. Every procedure owned by the departing person gets reassigned before their last day, and the reassignment includes one pass through the document with them present. Twenty minutes with the person who still knows the answers is worth more than the next owner reverse-engineering it in August.

The failure mode to avoid is bulk reassignment to a manager. It clears the orphan list and creates the forty-procedure problem from two sections ago. Distribute to the people who do the work, even where that means the new owner is junior. A junior person who runs the procedure weekly is a better owner than a senior person who has never run it.

A one-hour ownership pass

You do not need a project for this. One hour with the library open covers most of it.

1. List every procedure and put a person's name against each. Not a role, not a team. If you cannot think of a name, that procedure is unowned and it goes on a shortlist.
2. Look at the shortlist and decide honestly whether each one is worth keeping. Unowned procedures are usually unowned because nobody needs them, and deleting one is a legitimate outcome that most teams never allow themselves.
3. Count the procedures against each name. Anyone above roughly fifteen gets redistributed now, because they will not review them and you will believe they did.
4. Pick one trigger and turn it on. A 90-day verification reminder is the crudest and takes minutes to set up. It beats the plan for a better trigger that you implement next quarter.
5. Add a line to your offboarding checklist so this survives the next departure without a second pass.

That is the whole thing. The reason it keeps getting deferred is that it looks like it should be a bigger project, so it waits for a week nobody has. It is an hour, and it is the highest-leverage hour available to a documentation library that has started to rot.