Engagement survey comments about on-call had been getting worse for three straight quarters. We finally treated dread as a metric with a root cause, not a mood.

"Dreading my week" showed up in free-text survey comments 34 times in Q4 2025, up from 9 the year before. We could have written that off as vibes. Instead we asked people to rate their dread level before each shift started, and correlated it against everything we could measure.

What dread actually correlated with

It wasn't page volume — teams with more pages per week didn't report more dread. It was predictability. The single strongest correlate was whether an engineer knew, going into the shift, roughly what kind of pages to expect and whether the runbooks for the top three noisy alerts were current. Unpredictable pages at 3am felt worse than frequent, well-understood ones at a reasonable hour.

pre_shift_dread_survey (1 question, sent 2hrs before shift start)
"On a scale of 1-5, how much are you dreading this shift?"
Correlated against:
  - pages_last_30_days: r = 0.11 (weak)
  - runbook_freshness_top3_alerts: r = -0.61 (strong, inverse)
  - had_a_page_outside_documented_pattern_last_shift: r = 0.58 (strong)

What we fixed

We stopped chasing raw alert-count reduction, which had plateaued anyway, and instead put a standing weekly hour on the calendar — same time, every week, owned by a rotating volunteer, not assigned as extra work — dedicated purely to auditing and refreshing runbooks for whatever alerts fired most that week.

"I don't mind getting paged for something I know how to fix. I mind getting paged for something I've never seen, with a runbook last touched by someone who left the company."

The number that moved

Average pre-shift dread score dropped from 3.2 to 2.1 over two quarters, without page volume changing meaningfully at all. We didn't make the job less busy. We made it less unpredictable, and that turned out to be the thing people were actually reacting to.

We were surprised how little resistance the weekly hour got once we framed it as protected time rather than extra work. Nobody had ever explicitly told engineers it was acceptable to spend an hour on documentation instead of feature velocity; once we did, several teams volunteered to extend it on their own, unprompted, because the payoff was visible within their own rotation almost immediately.

  • Measure dread directly and correlate it — don't assume it tracks page volume, because it often doesn't.
  • Runbook freshness is a stronger predictor of on-call misery than how many times you get paged.
  • A small, protected, recurring maintenance hour beats a one-time runbook cleanup sprint that decays within a quarter.