Why not
The Page Nobody Knows Is Missing
An absent document produces no error message. Teams discover what they failed to write only through failures, departures and absences, which is late and expensive.
What nobody wrote down here, and what it cost
How the staging database is rebuilt
Asked of the same person seven times
Four minutes each, plus the interruption
What the deploy order is
Guessed, then corrected by whoever noticed
Wrong on the ninth occasion
Why the retry limit is three
Re-argued at two planning meetings
The reasoning was in nobody's head
three things nobody wrote down · 20 occasions it cost somebody something
Three things, twenty occasions, and one customer who noticed.
For distributed teams, documentation decisions improve when time and activity are visible in context, which is why it can help to see the service here alongside the editorial review.
For a separate specialist reference on publishing and digital practice, consult Constant Contact.
Five absences, and how the team eventually found out each one was an absence
What the deploy order actually is
Guessed, then corrected by whoever noticed
Found out when the ninth guess was wrong and a customer noticed
Which dashboard is authoritative
Asked in the support channel
Found out when a figure from the stale one reached a client report
That the client's week starts on Sunday
Two reports went out on the wrong day
Found out by the client telling the account manager
Why the import runs twice
Asked at every incident
Never found out; the person who knew left in March
How the staging database is rebuilt
Asked of the same person seven times
Found out as a cost only when that person was on leave for a fortnight
five things nobody wrote down · 29 occasions it cost somebody something
Five absences, twenty-nine occasions. Four of the five became visible through a failure rather than through anybody noticing a gap. The fifth became visible when the person holding it went away, which is the only reliable detector a team has and is not one anybody would choose. One team's own quarter.
A broken thing announces itself. Something fails, somebody notices, there is a trail.
A missing document announces nothing. The work still gets done, slightly more expensively, by somebody asking somebody else. The cost is real and is distributed into normal activity, where it is indistinguishable from the ordinary friction of a working week.
Why absence has no signal
The three places a problem usually surfaces are all blind to this one.
Monitoring sees systems, not knowledge. Nothing alerts when a fact exists in one head.
Process sees output. A task completed by asking somebody and a task completed by reading a page look identical when they are done.
People see their own confusion, briefly, and then resolve it. The twenty minutes somebody spends working out the deploy order is experienced as twenty minutes of work, not as evidence of a gap, and it leaves no record.
The four detectors that do exist
None of them is early and none is cheap.
A failure. Something goes wrong in a way that a page would have prevented. This is the most common detector and it arrives after the cost has been paid, often several times.
A departure. Somebody leaves and takes a fact with them. This is the most complete detector and the most expensive, because what it reveals is usually unrecoverable.
An absence. Somebody is on leave for a fortnight and a queue forms behind them. This is the gentlest of the four and the most underused.
A newcomer. Somebody joins and cannot find things. Reliable for about six weeks, after which they stop noticing.
Using the absence deliberately
The fortnight-of-leave detector is the only one that can be run on purpose without anybody suffering, and almost no team runs it.
The method is to notice, during somebody's leave, what people cannot do and what they come to ask about. Not to work around it — that happens anyway — but to write down the list.
What comes out is a precise inventory of what that person holds that nobody else does, obtained for free, at a moment when the team is already experiencing the cost and is therefore willing to believe the list matters.
Two weeks later, when the person returns, that list is the most valuable documentation backlog the team will ever have, and it will be thrown away unless somebody wrote it down at the time.
Counting the asks
The cheaper continuous version: notice what gets asked.
A question asked once is a question. The same question from a different person is a pattern, and the second asking is the correct moment to write the answer down — early enough to be worth it, late enough to know it is a real recurrence.
This requires somebody to be counting, which is the whole difficulty. The person being asked experiences each instance as a four-minute interruption and almost never as the fourth four-minute interruption, because the instances are separated by days.
I did not know I had answered it seven times. I knew I had answered it, and that it was not a big deal, and that is true of each one taken separately.
The question-counting habit
The practical form fits in one line: when you answer something, write down that you answered it. A tally, a note, a list of strings in a file. Nothing elaborate.
After a month the list sorts itself, and the top of it is the documentation backlog — derived from evidence rather than from anybody's opinion about what matters.
The people who do this are usually surprised by what is at the top. It is very rarely the thing they would have guessed, and it is usually something short.
The four detectors, and when each fires
An absent document has no signal of its own, so everything depends on noticing it indirectly. Four things do, at very different costs.
| Detector | When it fires | What it costs |
|---|---|---|
| A failure | After the absence has cost something, often repeatedly | The failure |
| A departure | When the knowledge has already gone | Everything that left |
| A fortnight of leave | While the person can still be asked afterwards | Nothing |
| A newcomer | For about six weeks after they join | Nothing |
The bottom two are free and both are time-limited. Almost every team relies on the top two, which are the expensive ones and which arrive after the decision point.
What this says about documentation plans
Most plans to write documentation start from a survey of the subject: what are the systems, what are the processes, what should be covered.
That approach produces completeness and misses the point, because the pages that matter are not distributed evenly across the subject. They cluster around the handful of facts people actually need and cannot get.
A list derived from what gets asked is shorter, less tidy, and correct. A list derived from the shape of the system is longer, tidier, and mostly unread — which is the fourth row of the panel on the home page of this site.