Talk it through with Aurelius
Library›Aurelius›The problem
Aurelius · Work & Leadership
Knowledge + Guidance

Why does on-call just mean firefighting, never fixing?

Your pager goes off. You patch it. You go back to bed, or back to your real work. Next week, the same system fails the same way. You call this on-call. It is actually a loop your team built, and keeps feeding. No one chooses to get paged at 3am. But your pod chooses, every single week, what happens in the hour after. You can write a fix that removes the cause. Or you can close the ticket and wait for it to happen again. That choice is yours. The outage was not. Stop asking how to handle the stress better during an incident. Ask what your pod decided not to fix last time, and why you let it slide.

◆ How this problem reads on the two dials
GuidanceKnowledge
More coaching
Some to learn
1:1 with AureliusWith others (a Pod)
Some one-to-one
Practise with peers
There are real practices worth teaching (postmortems, tracking repeats), but the hard part is the team actually choosing to act on them week after week, so guidance carries more weight.
How the two dials adapt to you →
What’s really going on

The stress is not your real problem. The real problem is your pod treats every fire as new, when most are old fires coming back. On-call will not improve because you get calmer during it. It improves when your team chooses, every week, to fix one cause instead of only patching the symptom.

🔒 What you’ll build togetherUnlock by starting
A moveAfter every page, write one sentence: what will we change so this does not happen again.
A moveEach week, pick one repeating fire and kill it before you take on new work.
A moveDo not close an incident ticket until someone names the fix, not just the patch.
A moveCount how many times the same alert fires. A repeat is a signal, not noise.
A moveIn every retro, ask each other: what did we decide not to fix last time, and why.
PractiseFire Count · a Pod of 4 · 30 min

What changes unlock by starting

  • Fewer repeat pages for the same root cause within a few weeks.
  • A real list of fixes your pod has finished, not just logged.
  • Less dread before on-call shifts, because fires shrink instead of multiply.
  • A team that treats incidents as information, not just interruptions.
One object, two jobs: a public answer to a real problem, and — the moment you start the chat — Aurelius’s live plan for your version of it.