Two posts in: a handoff drops the reasons nobody knew they were holding, and the person receiving it has to reconstruct them from evidence. Both are true and both are treatable, but they share a hidden assumption worth attacking — that the handoff is a discrete event that happens on a particular Tuesday.

Why the Transfer Document Fails

Consider when it gets written. Somebody is leaving the team, or the rotation is changing, or a project is being reassigned. They sit down in their last week and write everything they know.

This is the worst possible moment to ask for it. They’re mentally halfway out. They’re writing from memory rather than from contact with the system, and memory smooths. The oddities that would have jumped out during a normal week of work have already faded into “that’s just how it is.” Worse, they’re writing for an imagined reader whose questions they cannot anticipate, because the actual questions only surface when someone tries to do the work.

So the document lists the services, the dashboards, the on-call rotation, and the deploy procedure — all the things a person could find on their own — while omitting the eleven false alarms from one partner’s batch job, which nobody could.

Continuous Transfer

The alternative isn’t a better document. It’s arranging for knowledge to move during normal operation, so there is less to transfer when the moment comes.

The mechanisms are unglamorous and mostly already exist:

Review by someone who didn’t write it. Not as a quality gate — as a knowledge pump. A reviewer who has to ask “why three seconds?” extracts the reason at the moment the author still has it.

Rotate who responds. The knowledge that never survives a handoff is pattern-knowledge, and pattern-knowledge only forms from repeated exposure. If the same person always takes the alert because they’re fastest, the org is buying speed with concentration risk.

Debug in the open. A thread where someone reasons through a problem in public teaches more about a system than any architecture document, because it shows the reasoning, the wrong turns, and which signals actually mattered.

Write the reason where the code is. Repeating this from the first post because it’s the highest-leverage habit available: the comment costs thirty seconds and survives every reorg.

None of these are handoff activities. That’s the point. They’re normal work arranged so knowledge is already distributed by the time anyone needs it to be.

The Honest Measure

The useful question isn’t “do we have documentation.” It’s: if the person who knows this best were unavailable for a month, what would get slower, and what would get wrong?

Slower is fine. Slower is what a team looks like when one member is out. Wrong is the signal — it means the knowledge wasn’t distributed, it was stored, and the store had exactly one copy.

You cannot fix that in a transfer document written the week someone leaves. You fix it in the months before, by making sure more than one person ever had the context in the first place.