PIOSEE: A Field Reference

The six PIOSEE steps in order, each with the question it asks: Problem, what is actually broken; Information, what do we know and who knows it; Options, what could we do, name more than one; Select, which one, on what evidence, abort when; Execute, who is doing it and reporting back; Evaluate, did it work, now and again later. A dashed return arrow runs from Evaluate back to Information, labelled what you just learned

This is the working reference for PIOSEE, split out of the essay When the System’s on Fire so the mechanics stay usable without the argument wrapped around them. The essay explains why a structured decision cycle helps and tells the story of the outage that convinced me. This page is what you would put on the wall.

A caveat that belongs at the top of both: PIOSEE is not a regulatory standard. You won’t find it in the FAA’s handbooks the way you’ll find the DECIDE model. It circulates in commercial aviation training, and it belongs to a family of structured decision aids that airlines and flight schools have built up over the last forty years, several of which are close enough to be the same model with a different mnemonic. Treat it as a well-worn practitioner’s tool rather than a certified procedure.

StepThe questionWhat it should produce
ProblemWhat is actually broken?One sentence everyone on the call agrees with
InformationWhat do we know, and who knows it?Observations from systems and from people
OptionsWhat could we do?More than one, with the cost of each if it’s wrong
SelectWhich one, on what evidence, abort when?A choice, its reasoning, and a trigger to abandon it
ExecuteWho is doing it, and reporting back?A named owner and an expected signal
EvaluateDid it work? Now, and again later?A live check, then a separate written review

Say these out loud. Half the value is that other people hear the question.

Problem

  • What exactly is broken? Not what caused it, what can we observe?
  • How do we know it’s broken? Which signal are we trusting?
  • What’s the user-facing impact, in a sentence?
  • When did it start?

Information

  • What changed since we were last known-good? (Not “in the last hour.” The window you pick can exclude the answer.)
  • What do the logs and metrics show, as opposed to what do we assume they show?
  • Who on this call has seen this pattern before?
  • What do we know that isn’t written down anywhere?
  • What’s not affected? The boundary is information too.

Options

  • What are at least three approaches, including doing nothing for now?
  • For each one: what does it cost if we’re wrong?
  • Which of these can we undo, and how fast?
  • What’s the blast radius if it goes badly?

Select

  • Which piece of information points at this option?
  • What are we giving up by not choosing the others?
  • What has to be true, by when, for us to keep going?
  • What do we do instead if that doesn’t happen?

Execute

  • Who is running it, by name?
  • What should we see, and how soon?
  • Who is watching for it, and who are they telling?
  • Who is updating stakeholders so the person fixing it doesn’t have to?

Evaluate

  • Did the thing we predicted would happen actually happen?
  • If not, are we at the abort trigger yet?
  • What goes in the timeline while we still remember it?
  • What’s the separate, later review, and who owns it?

PIOSEE has siblings, and their differences are more instructive than their similarities.

ModelStepsEmphasis
PIOSEEProblem, Information, Options, Select, Execute, EvaluateSimplicity and recall; works at multiple levels of an incident
FOR-DECFacts, Options, Risks and benefits, Decision, Execution, CheckExplicit weighing of risks and benefits before committing
T-DODARTime, Diagnose, Options, Decide, Assign, ReviewTime budget first; explicit assignment and review
DECIDEDetect, Estimate, Choose, Identify, Do, EvaluateThe FAA’s general-aviation formulation

FOR-DEC was developed in the 1990s by the German Aerospace Center (DLR) with Lufthansa, and it’s the most deliberately structured of the group. Its “Risks and benefits” step does work the others leave implicit. PIOSEE’s Select can degenerate into picking a favorite; FOR-DEC makes you argue both sides of every option out loud. The tradeoff is that it needs time, and it’s explicitly a poor fit when there’s an established procedure or when you’re seconds from the ground.

T-DODAR is the one worth stealing from for incident response. It opens with T: how much time do we actually have? That single question calibrates everything downstream, and it’s the question that never gets asked on a bridge call. It also breaks out Assign as its own step, which covers the failure mode where an incident commander decides something and nobody does it because everyone assumed someone else was.

PIOSEE’s advantage is that it’s short enough to say out loud and apply at several levels of the same incident at once. Its weakness is that time pressure and risk assessment are implicit rather than named. If you adopt it, consider borrowing T-DODAR’s opening question and FOR-DEC’s insistence on stating the downside.

OODA is deliberately absent. It’s a fine model, but it answers a different question: how to compete against an adversary who is also deciding. Stretching it to cover a database outage is where a lot of muddy thinking starts.

Any framework presented without its limits is being oversold. Here are PIOSEE’s.

It doesn’t replace expertise or runbooks. The cycle organizes what you know; it doesn’t supply it. If nobody on the call understands your replication topology, no amount of structure will produce a good failover decision. When a documented procedure covers the situation, run the procedure.

Some actions start before the cycle finishes. Aviation handles this with memory items: the handful of immediate actions a crew performs before anyone opens a checklist or debates anything. Operations has the equivalent: page the DBA, stop the deploy pipeline, start the incident channel and the timeline. Do those in parallel with Information. They’re cheap, reversible, and they don’t wait on consensus.

Fast and reversible sometimes beats slow and certain. “Correct beats quick” is a nice line and it’s not always true. If an action is cheap to undo and you can tell within a minute whether it helped, taking it and watching is often better information-gathering than another round of discussion. Reserve the deliberate cycle for the choices you can’t take back.

It’s a loop, not a line. New information arrives mid-execution and invalidates your problem statement. Expect to be wrong at least once per incident, and pick options that make being wrong survivable.

It also nests. You might be running a cycle at the strategic level (our infrastructure can’t scale) while running tighter ones inside it at the tactical level (this service keeps timing out). The evaluation from an inner loop feeds the information-gathering of the outer one, which is how the lessons compound.

The failures are consistent enough to tabulate.

Skipped stepFailure modeCorrective question
Problem — “we already know what’s wrong”Three people are solving three different problems and nobody notices for twenty minutes“Say the problem in one sentence. Does everyone agree with that sentence?”
Information — “no time, we have to act”You fix a symptom, make the real fault worse, or lose the evidence you needed“What would we check in the next ninety seconds that could change what we do?”
Options — decision already madeAlternatives are listed for appearances; the backup plan doesn’t exist when the first choice fails“What’s our second option, and what would make us switch to it?”
Select — gut feel over evidenceThe chosen action doesn’t connect to anything observed; nobody can explain it afterward“Which piece of information points at this option?”
Execute — no named ownerEveryone assumes someone else is running the command“Who is doing it, and when do they report back?”
Evaluate — “we’re too busy”The same incident recurs next month“What’s our abort criterion, and who’s writing the timeline?”

That last row is a leadership problem more than a process one. A structure like this makes reasoning visible, requires admitting uncertainty, and creates a record of who decided what. That’s a feature if you want good outcomes and an irritant if you want unconstrained authority. I’ve written about that dynamic at more length in The Metrics Game and When Confidence Becomes Dangerous.

You can’t announce “we’re doing PIOSEE now” and expect it to survive contact with a real incident. It has to be practiced somewhere low-stakes before it’s available somewhere high-stakes. A rough progression that works:

Weeks 1 to 2, postmortems. The cheapest practice available, because the decisions are already made and nobody’s under pressure. Walk an old timeline through the six steps and ask what information the team had and when they had it. The gaps show up immediately and nobody has to defend them in the moment.

Weeks 3 to 4, planning meetings. When someone proposes a solution, ask what problem it solves and what information would tell us whether it’s the right one. Forcing the sequence when there’s no time pressure is how it becomes available when there is. This is also where you find out which of your recurring meetings were skipping straight to Execute all along.

Weeks 5 to 6, tabletop exercises. Simulate an outage and walk the cycle as a team. Muscle memory without the cortisol. Rotate who runs it, so the framework doesn’t become one person’s habit.

Ongoing, in real incidents. Put the six steps in the incident channel topic and as a template in your incident tooling. Say something when a step gets skipped: if someone jumps from Problem straight to Execute, pause them. That isn’t pedantry, it’s the incident commander’s job.

Four objections you will hear, and what actually answers them:

  • “We don’t have time for this in an emergency.” The Problem step costs thirty seconds and routinely reveals that people were describing different failures. Time the next one.
  • “It’s too rigid.” It’s a decision aid, not a procedure. The time you spend in each step is yours to set, and some steps collapse to a sentence.
  • “Senior people won’t use it.” They often already do, silently. Naming the steps mostly makes an existing habit legible to everyone else on the call.
  • “People forget under pressure.” That’s what the wall card and the channel topic are for. Forgetting under load is the assumption the whole approach is built on.

The sequence doesn’t change with the stakes. The clock does. Rough orders of magnitude, not prescriptions:

ScenarioProblemInformationOptionsSelectExecuteEvaluate
Production outagesecondsminutesminutessecondsminuteslive, then a written review
Infrastructure migrationa weekweeksa weekdaysmonthsagainst predicted numbers
Hiring decisiondaysa weekdaysdaysweeksmonths after start