Description-Over-Explanation Questioning

Six responders arrive at a debrief and three of them have already agreed in the channel that the cause was a bad config push. They are not wrong. They are finished, and a group that starts from a cause spends ninety minutes collecting evidence for it.

The alternative is not a different conclusion, it is a different kind of question. Asking "why did you not check the dashboard" invites a justification, and a justification is assembled after the person knows how the story ended. Asking "what did you see on your screen when you joined" returns the information they actually held at the time, which is the only part that generalises to an incident nobody has had yet.

Why it matters

Hindsight rewrites the record before anyone writes it down. Once the outcome is known, every action taken before it looks like either the right move or an obvious error, and the signals that were genuinely ambiguous at 02:40 are remembered as clear. A debrief that collects explanations therefore produces a tidy narrative that nobody could have acted on in advance.

The practical consequence is where the money is: the organisation's model of its own system is wrong in the places where responders were confused, and confusion is only visible in descriptions. An incident where everyone knew what to do and did it slowly is a staffing problem. An incident where two senior engineers describe the same minute differently is a design problem, and only the descriptive format surfaces it.

Implementation patterns

• Park the agreed cause visibly at the start, with a promise to return to it. Banning it makes people defend it; parking it makes it safe to set down.
• One person at a time, in the order they joined the incident, so later responders do not anchor earlier ones.
• Four description questions: what did you see, what did you do next, what did you expect that to do, what made you think it had worked.
• Write down conflicting accounts of the same minute side by side. These are the output. A debrief that surfaces no disagreement has reproduced the story the room walked in with and can end early.
• Ask the dumb question about jargon and shortcuts, which is how undocumented expertise becomes visible.
• A facilitator outside the responders' reporting line who was not on the incident, because people do not describe a confusing twenty minutes in front of the person who writes their performance review.

Industry example

Etsy published its Debriefing Facilitation Guide in 2016, written by John Allspaw, Morgan Evans and Daniel Schauenberg and released as an open document. Its stated premise is that a debriefing is first a learning opportunity, that groups frequently arrive with a rationalised story already settled, and that what is learned depends on the questions the facilitator asks rather than on the objective data available. Its section headings include "The Art of Asking Questions", "Remember to Look for Descriptions, Not Explanations", "Probe for the Invisible Parts of Expertise" and "Ask Dumb Questions". The guide builds on the safety-research tradition that separates the account constructed after an outcome from the account available during it.

Failure scenarios

• The counterfactual question - "why did you not roll back sooner" - which produces a defence and ends the person's useful contribution for the rest of the session.
• The manager in the room, after which every description becomes a justification addressed to them.
• Group timeline construction, where the loudest account becomes the record and quieter contradictions never surface.
• Action-item accounting: a session judged by tickets created, which rewards cause-first reviews and starves the descriptive format of air.
• The facilitator who was there and fills gaps from memory rather than eliciting them, producing a transcript of their own recollection.

Trade-offs

This format is slower and produces fewer action items. Six responders for 90 minutes plus a facilitator is on the order of 10 hours of senior engineering time per incident, and most of the output is understanding rather than work. An organisation that measures debriefs by tickets filed will rate it as the worse meeting, every time, and that is the honest cost.

What it buys is the class of finding that no other practice produces: the places where the mental model and the system have diverged. Those are the incidents that repeat with different surface symptoms, so the return shows up as incidents that do not recur rather than as fixes shipped.

When not to use it

When the surprise is low. A certificate expired, nobody was confused, the remedy is a renewal alarm: run the short cause-first review and schedule the work. The same applies when the incident is the fourth instance of a known class with an agreed fix waiting on prioritisation, where the useful meeting is about priority rather than about understanding. Reserve the format for events where responders were genuinely uncertain about what they were seeing, because that uncertainty is the signal it is built to find.

Interview question

Q: You are facilitating a debrief for an outage where the on-call engineer ran a command that made things worse, and their manager is in the room and wants to know why they did not follow the runbook. How do you run the first fifteen minutes?

What a strong answer covers: reframing the manager's question into a description question before it is asked out loud - what did the runbook say at the moment you read it, what did you see that made this seem to apply - and, where possible, keeping the reporting line out of the room entirely. A strong answer explains the mechanism rather than appealing to psychological safety as a value: the manager's question cannot be answered truthfully under observation, so asking it destroys the data the session exists to collect. It also names the likely finding - the runbook was ambiguous or stale - and says how that disagreement gets written down.

Quick check

Quiz: Why does "why did you not check the dashboard" produce worse debrief data than "what did you see on your screen"? Because a why-question about an action asks for a reason constructed after the outcome was known; a what-did-you-see question returns the information the person actually held at the time.

Flashcard: What is the signal that a debrief is working? Two accounts of the same minute that disagree - a session with no disagreement has reproduced the story the room arrived with.