A 30-day cadence for retiring your first five runbooks

Most documentation programmes start the same way: an energetic two-week sprint, a fresh wiki structure, a team of volunteers, and a strong collective sense that things are finally going to be different. What they rarely include is any mechanism for taking things out. The programmes that actually survive are the ones that subtract as well as add. The ones that don’t end up with a wiki that everyone adds to and nobody cleans, growing a little heavier with each quarter until it collapses under its own inertia.

The 30-day cadence described here is not a substitute for a broader documentation strategy. It is a forcing function: a repeatable, low-overhead rhythm for identifying the runbooks that are doing more harm than good and giving them a dignified exit. Start with five. That number is intentional; it is achievable in a month without a project team or a dedicated owner.

01 · The costThe cost of a dead runbook

A dead runbook does not cost much in storage. It costs in decision friction, and that cost is paid by everyone who encounters it and cannot be sure whether it is still live.

Consider a composite operations team we observed at a seventy-person consultancy in Manchester. They had three different onboarding runbooks. The most recent was eighteen months old. The oldest dated to a restructure in 2022. All three were accessible. None was marked as authoritative. When a new hire arrived, the question “which runbook do I follow?” was answered differently by three different team members, all with equal confidence, none of whom knew they disagreed. The result was not catastrophe; it was a slow drain on the onboarding experience, a low-level anxiety in every new starter, and a recurring Slack thread every time the question came up.

The team eventually merged the three documents, but only after someone finally asked, aloud, whether any of the old ones should simply be removed. The answer turned out to be: yes, all of them. The new version was better than all three predecessors combined, partly because its authors had no obligation to preserve anything. Permission to delete is harder to give than it sounds. The 30-day cadence makes giving it routine.

02 · Week oneWeek one: inventory

Before you can retire anything, you need to know what you have. The goal of week one is not a full documentation audit; it is a list with four columns:

• Name. The title of the runbook, exactly as it appears.
• Last edited. Pull this from your wiki or version history; do not guess.
• Last read. Most platforms track views or access. If yours does not, note this as unknown and treat it conservatively.
• Stated owner. The name on the document. Not who should own it; who does, on paper.

Aim for completeness but do not let perfect be the obstacle. A list of thirty runbooks with honest data is more useful than a list of fifty with gaps filled in by guesswork. If you do not have view tracking, make a note to add it before the next cycle.

The output of week one is a spreadsheet or table. Nothing more. Resist the urge to annotate, flag, or reorganise during this stage. You are collecting, not curating.

03 · Week twoWeek two: triage

With the inventory in front of you, apply a three-way rubric to each entry.

Kill. A runbook is a candidate for retirement if: it has not been edited in twelve months or more; it has no recorded reads in the last six months; its owner has left the company or explicitly disclaimed ownership; or a newer runbook covers the same ground. Any two of these conditions together is usually sufficient.

Keep. A runbook earns its place if it is edited regularly, actively read, owned by a named person who still works there, and not duplicated elsewhere. Keep means keep as-is. Not keep with minor revisions; that is the third category.

Rewrite. A runbook goes into the rewrite queue if the underlying process it describes is still live but the document is materially out of date. Rewrite is not an immediate commitment; it is a promise to return. Flag it with a review date and an owner before moving on. A rewrite with no deadline is a museum exhibit with a different name.

By the end of week two you should have five candidates in the Kill column. If you have more, pick the five with the weakest case for survival. If you have fewer, lower the thresholds slightly: six months without an edit, rather than twelve, is still a strong signal.

04 · Weeks 3–4Weeks three and four: retire

Retiring a runbook has three steps, in this order.

Redirect. Before you touch anything, create a short redirect page or a stub at the runbook’s original URL. The redirect should explain, in one or two sentences, what this runbook was, why it has been retired, and where people should look instead. If there is no clear successor, say so plainly. “This runbook described a process that is no longer in use following our 2024 reorganisation” is an honest and sufficient explanation.

Announce. Send a single message to the relevant teams: Slack, email, or whatever channel those teams actually read. Include the name of the retired runbook, a one-line explanation, and the URL of the redirect. Keep it brief. If people have questions, they will ask. If nobody asks, that is information too.

Archive. Move the original document to an archive folder or mark it with a clear label such as “Retired — April 2026.” Do not delete it. Old links should land somewhere explanatory, and archived content has a way of being unexpectedly useful when auditors or new hires ask historical questions.

The five retirements you complete in this first cycle are not the end. They are the proof-of-concept that the cadence works. In month two, run it again with a lighter hand: the inventory is already done, the triage will go faster, and the team will have lost the anxiety that comes from doing something irreversible for the first time.

The goal is not to arrive at a perfectly curated documentation library. The goal is to make subtraction as normal as addition, so that the library stays alive rather than accumulating weight. A programme that adds five runbooks per quarter and retires none will, within two years, have a documentation estate that nobody trusts. A programme that adds five and retires five will, over the same period, have a smaller and more credible one. The difference is not effort. It is habit.