Every team eventually writes the on-call doc. It has a rotation schedule, an escalation path, a runbook link that is three months stale, and a line about psychological safety someone added after a bad week. Read enough of these and you stop seeing a process. You start seeing an admission.
The admission is this: nobody with the authority to fix the underlying thing has fixed it, so the fix has been delegated downward, after midnight, to whoever drew the assignment this week.
What the rotation actually measures
A healthy on-call rotation is quiet. Not because the engineers are heroic, but because the system does not generate urgent problems often enough to need heroism. A loud rotation is not a training gap. It is a backlog with a pulse, and that pulse is a person's sleep schedule.
You can tell how a company's management actually feels about reliability by whether pager volume ever makes it into a headcount conversation, or whether it just makes it into a channel called incidents that everyone learns to mute.
This is why "we need better on-call tooling" is usually the wrong ask. Tooling makes the page easier to acknowledge. It does not make the page stop arriving. The instinct to soften the symptom, rather than address the source, is the same instinct that optimizes a handoff while leaving the broken workflow intact.
The actual lever
If you want the rotation to get quiet, put the person who owns the roadmap on it. Not symbolically: actually pageable, actually accountable, actually close enough to the pain to decide that reliability work is not a favor engineers do for the org.
Everything else, the runbooks, escalation charts, and retro templates, is bookkeeping for a decision that was never really about process. It was about who has to be awake when the thing breaks, and whether that fact is allowed to reach anyone who could change it.