My last post on structured reflection dealt with one half of the discipline: the reflection you do afterwards — in the retro or the post-incident review, with a model like Gibbs to give it a spine. There’s a second half, and during a live incident it’s the one that decides how the night goes.
Donald Schön drew the line in 1983, in The Reflective Practitioner. Reflection-on-action is what you do after the fact: step back, reconstruct what happened, learn from it. Reflection-in-action is thinking while you act — the practitioner adjusting mid-stream, noticing that what’s in front of them doesn’t match the model they walked in with, and changing course on the spot. Schön called it a “conversation with the situation.” His own examples came from architecture studios and therapy rooms, but the idea travels: Orit Hazzan argued in 2002 that software engineering should be taught the same way. Any engineer who has worked a live incident has had that conversation, usually at an hour they’d rather not name.
Reflection-in-action is the 2am skill
The after-the-fact review gets all the process — the templates, the blameless framing, the action log. The in-the-moment kind gets almost none, even though it’s where the incident is actually won or lost. It’s the difference between an engineer who chases the first plausible cause into the ground and one who pauses three minutes in and says “the timeline doesn’t fit — this started before the deploy, so it isn’t the deploy.”
That pause is reflection-in-action, and it’s a genuine skill, not a personality trait. It’s also the first thing stress takes away. Under pressure the mind narrows: you fixate on the first hypothesis, read the graphs as confirming it because you want them to, and pour effort into a theory that stopped fitting the evidence ten minutes ago. Tunnel vision isn’t a failure of intelligence; it’s what the stress response does to everybody.
AI is a newer threat to it. Paste the alerts into an assistant mid-incident and it will hand you a plausible cause in seconds, stated with complete confidence — which is exactly the first hypothesis tunnel vision locks onto, now with an outside voice agreeing. The pause that says “the timeline doesn’t fit” is the step the tool makes easiest to skip. And the skill only gets built in the incidents you work yourself: hand the routine ones to the model and you meet the novel one, the one it can’t diagnose, with less practice than ever. I’ve made the general case and the debugging case before; this is the same trap at the worst possible hour. Treat the model as another voice in the channel, whose hypothesis gets tested like anyone else’s — not as the person holding the wider picture.
Which makes the useful question a design one: how do you set up the conditions so that reflection-in-action survives contact with a real incident — stress, tools and all?
What actually supports it
A few things, none of them heroic:
- Say the hypothesis out loud. “I think it’s the cache.” Spoken, it becomes falsifiable; kept in your head, it quietly hardens into fact. This is most of what a good incident channel is really for. It only works if being wrong out loud is safe. On a team where a wrong guess in the channel gets remembered, people keep their hypotheses to themselves, and the quietest person on the call — the one who noticed the timeline didn’t fit — says nothing. Psychological safety sounds like a soft extra until you watch it decide how long an outage lasts.
- Separate the driving from the thinking. The reason the incident-commander role exists is that the person with hands on the keyboard is the least able to reflect-in-action — they’re deep in the doing. A second person whose only job is to hold the wider picture is reflection-in-action, outsourced to someone with the spare attention to do it.
- Free up working memory. Checklists and runbooks aren’t there to insult your competence; they carry the routine so your attention is spare for the parts that are genuinely novel. Reflection needs headroom, and a panicking brain has none to lend.
- Build in a deliberate pause. Some teams force a regular “step back — is this still our best theory?” checkpoint during a long incident. It feels like a waste of seconds you don’t have. It’s the opposite: it’s what stops you spending the next hour on a dead theory.
The trap at the other end
There’s a failure mode in the other direction, worth naming so this doesn’t read as “always reflect more.” You can reflect-in-action yourself into paralysis — endlessly re-examining the hypothesis while the system stays down and the clock runs. Mid-incident the decision is genuinely “it depends”: when the priority is stopping the bleeding, act on the good-enough theory and reflect properly afterwards; when you’re about to do something irreversible, stop and think first. Knowing which mode you’re in is itself an act of reflection-in-action. The skill isn’t thinking more — it’s noticing which the moment needs.
The two halves feed each other
Schön’s pairing is the honest picture because the two kinds are a loop, not alternatives. Reflection-in-action generates the raw material — the moment you noticed the timeline didn’t fit, the assumption that turned out wrong, the reluctance to escalate. Reflection-on-action, done properly with the structure from the last post, is where that material becomes a changed model you carry into the next incident — so that next time the “wait, that doesn’t fit” arrives ten minutes sooner.
Neglect the after-action review and every incident teaches you nothing — and the evidence for doing it is unusually good: Tannenbaum and Cerasoli’s 2013 meta-analysis, pooling 46 samples, found that debriefs improved performance by around a quarter on average. But neglect the in-the-moment kind and you’ve polished the paperwork of learning while ignoring the place the learning is actually spent. Most teams are far better at the first than the second. The retro has a template; the 2am conversation with the situation has nothing but the person having it — and that, it turns out, is a thing you can practise.