Managing the Unexpected: Resilient Performance in an Age of Uncertainty (2nd Edition)

1. 1Before committing to a plan, articulate explicitly the mistakes you don't want to make (e.g., "misjudge the complexity of this burn"), then trace how each simplification feeds into resources deployed, resources on standby, and contingency plans — the three linked elements a bad rating corrupts.
2. 2Rate complexity on its component elements separately — for prescribed burns: threats to boundaries, fuels and fire behavior, and objectives — rather than accepting a single summary score, because an overall rating hides which individual element was underestimated.
3. 3Treat any recognition of "we've seen this before" as a trigger for concern, not comfort. When someone labels an event "in-family" or routine, deliberately hunt for the deeper differences the superficial similarity is masking.
4. 4Build in re-evaluation on the day of action, not only weeks in advance. Ratings completed in advance decay; if policy doesn't require updating, add the update yourself using fresh data (a test burn, current conditions).
5. 5Actively recruit diverse experience and skepticism toward received wisdom, and use negotiating tactics that reconcile differing opinions without collapsing the nuances that different people detected.
6. 6Carry categories lightly: hold your current classification of the situation as provisional, and keep continuously refining and differentiating your expectations as new experience arrives.
7. 7When you interpret new data mid-project, check whether you're reading it to confirm the plan you've already committed to — the pull toward confirmation is strongest exactly when resources and people are staged to go.

At Cerro Grande, planners rated a burn plan built to handle a low-complexity event, but the burn was in fact high-complexity — which meant the resources needed to hold the fire and the number on standby were both greater than the number actually requested. The simplification compounded: planners misjudged the intensity of individual elements summed into the overall rating (at least one of the three categories — threats to boundaries, fuels and fire behavior, or objectives), each error tilting toward underestimating difficulty. All ratings were completed weeks before the burn and never reevaluated on the day, because policy didn't require it. The crew did show some reluctance to simplify by running a 1-acre test burn at 7:20 P.M. to check whether the grass was dry enough — data that could have updated the earlier complexity judgment. But with twenty people standing ready to ignite, it was hard to read the new data as a sign that burning was unwise; the test was called successful and ignition began at 8:00 P.M. The chain the Board of Inquiry named — complexity rating to resources to contingency plans — was misspecified at the first link, and the brutal audit followed.

• If you catch yourself recognizing an event as familiar or "in-family," then treat that recognition as a warning and search for deeper differences before acting.
• If a single overall rating drives your resource and contingency decisions, then decompose it into its component elements and check each one for underestimation.
• If a plan's ratings were made in advance and conditions or data have since changed, then re-evaluate before executing — even when no policy requires it.
• If new mid-project data seems to confirm exactly what you already planned to do, then assume confirmation bias and deliberately look for the disconfirming reading.
• If diverse or skeptical viewpoints are being smoothed over to reach agreement, then preserve the nuances those people detected rather than trading them away for consensus.

• Simplifying casually, habitually, or instantly instead of deliberately — the tell is that no one can state which mistakes the current categorization is designed to avoid.
• Summing component judgments into one score while each component quietly errs toward underestimating difficulty — the tell is a clean overall rating masking uneven, optimistic parts.
• Letting the label do the thinking: calling an event "largely analyzed, reportable, and understood" (as NASA did with the Columbia debris strike) so recognition breeds comfort rather than concern.
• Reading fresh data to confirm expectations — the tell is that a check meant to test a decision is interpreted favorably precisely because people and resources are already staged to proceed.
• Freezing early categories in place and never updating them, so weak signals are handled with weak responses and small failures pile up before anyone reclassifies the situation.

• ▸Decision/plan under review: name the single action about to be committed.
• ▸Mistakes I refuse to make: list the specific errors this plan must not produce.
• ▸Component elements & rating: score each element separately, not just the overall.
• ▸Underestimation audit: for each element, note which direction the error would tilt.
• ▸Linked consequences: map how the rating feeds resources deployed, resources on standby, and contingency plans.
• ▸Recognition flag: where am I saying 'seen this before' — and what deeper difference might it hide?
• ▸Day-of re-evaluation: what current data (test result, conditions) updates the advance rating?
• ▸Confirmation check: am I reading new data to confirm the plan? State the disconfirming reading.
• ▸Dissent preserved: which diverse/skeptical viewpoints and nuances am I keeping in play?

1. 1Go to the front line where the real work happens and build a situational (not strategic) big picture of the current moment — what is actually happening right now, not what the plan says should happen.
2. 2Actively solicit symptoms of operations from frontline workers; if the symptoms are withheld, treat that as a system failure because 'you can't develop a big picture of operations if the symptoms of those operations are withheld.'
3. 3Reduce fear, ignorance, and indifference in relationships, because sensitivity to operations depends on sensitivity to relationships — people who won't speak up leave the system knowing less than it needs to know.
4. 4Watch for small clues that accumulate over time; catch anomalies while they are still tractable and can be isolated, before they enlarge into full-blown issues.
5. 5Make continuous small adjustments as the situation changes rather than waiting for a scheduled review or a formal crisis declaration.
6. 6Audit your support systems (budgets, standby resources, activation protocols) for insensitivity to operations: can standby resources activate instantly, is 'standby' defined the same way by everyone, do you understand your own bottlenecks?
7. 7Look for stalemates at agency, division, silo, or jurisdiction boundaries — treat 'normal trouble' at these seams as a live threat that dissolves coordination the moment an unexpected audit hits.

At Cerro Grande, the prescribed burn of a 300-acre area exceeded control after unexpected winds forced crews to suppress an active fire instead of managing an intentional one. When Santa Fe dispatch finally picked up the phone at 7:30 A.M. Friday, the burn boss requested a fresh twenty-person crew to back up his exhausted frontline workers. Dispatch responded not with support but with a bureaucratic gate: 'Are you declaring this an escaped fire?' The burn boss replied, 'No, I'm trying to prevent it from becoming' one — the request was to keep the anomaly tractable before it enlarged. The system was insensitive to operations three times over: it couldn't instantly activate standby resources, it held conflicting definitions of what 'standby' even meant, and its own budgeting bottlenecks were poorly understood. Someone even injected budget concerns into a fire emergency, prompting the reply, 'Do the money thing later.' The tenuous coordination between agencies dissolved exactly when the unexpected audit hit, turning normal trouble into $1 billion of damage.

• If a frontline worker withholds a symptom out of fear, ignorance, or indifference, then treat the relational problem as an operations problem and fix the speaking-up, not just the incident.
• If you notice an anomaly while it is still small and isolatable, then act now to contain it — don't wait until it becomes a full-blown, declared event.
• If a support process (budget, staffing, activation) cannot instantly back up the front line, then flag it as insensitive to operations before you need it.
• If a term like 'standby resources' carries conflicting definitions across parties, then resolve the definition in advance, because ambiguity becomes big trouble under an unexpected audit.
• If your big picture is strategic rather than situational, then you have the wrong picture — reground it in the messy reality of the current moment.

• Taking frontline operations for granted — the tell is that leaders discuss strategy and plans while small clues on the front line go unexamined (as with the troubled organizations where 'frontline operations were taken for granted').
• Injecting the wrong priority mid-operation, like raising budget during an active fire — the tell is a support function asking procedural or accounting questions when the front line needs immediate resources.
• Forcing a binary declaration ('are you declaring this an escaped fire?') before releasing help — the tell is that support is gated on labels instead of the actual situation, blocking action meant to prevent escalation.
• Only attending to what happens 'inside individual heads' and ignoring what happens 'between heads' — the tell is being perpetually puzzled by individual behavior while relational silences and stalemates go unexamined.
• Accepting insensitivity at silo and jurisdiction boundaries as merely 'normal and natural trouble' — the tell is that coordination looks fine in calm conditions but collapses the instant an unexpected event tests it.

• ▸Current situational picture: describe what is actually happening on the front line right now (not the plan).
• ▸Small clues accumulating: list weak signals and anomalies noticed while still tractable.
• ▸Withheld symptoms: what is the front line not telling you, and is it fear, ignorance, or indifference?
• ▸Standby resources: can they activate instantly, and does everyone define 'standby' the same way?
• ▸Support-system bottlenecks: name the internal choke points (budget, staffing, dispatch) you may be blind to.
• ▸Boundary stalemates: which agency/silo/jurisdiction seams could dissolve coordination under stress?
• ▸Continuous adjustment made today: the small correction you took to keep an error from enlarging.
• ▸Declaration gates: any procedural labels blocking help that is meant to prevent escalation?

1. 1Accept that no system is perfect and errors are inevitable in an indeterminate world; shift your goal from 'error-free' to 'errors don't disable us.' Build capability to detect, contain, and bounce back rather than trying only to prevent.
2. 2Pursue both pathways to resilience simultaneously: keep errors small (catch developments early) and improvise workarounds that let the system keep functioning after a mishap.
3. 3Invest in the raw material of resilience: training, personnel with deep and varied experience, and skills of recombination and making do with whatever is at hand — these are what makes swift workarounds possible.
4. 4Run your own equivalent of fire drills. Imagine worst-case conditions and mentally simulate potential adversity before it arrives, as the most effective fire commanders do through 'rich fantasy lives.'
5. 5Set up standby resources with a single, shared definition and make them instantly activatable to back up frontline workers — otherwise conflicting definitions of 'standby' stall your recovery at the moment you need it.
6. 6Treat recovery as skilled work, not routine. When something goes wrong, avoid the reflex that 'recovery is routine'; instead deploy varied response repertoires and error-acknowledging communication.
7. 7Secure top-management support to allocate resources to early detection, cure-as-well-as-prevention, and commitment to mindfulness at all levels, so resilience is not an individual heroics problem.

During the Cerro Grande prescribed burn, the managing system was insensitive to operations three times over, and this directly undercut resilience. First, it was insensitive to the need for instant activation of standby resources to back up frontline workers. Second, 'standby resources' carried conflicting definitions — some read it as 'available in the area,' others as 'unassigned to other activities and available for immediate support.' Third, the budgeting operations themselves were poorly understood, so the system was blind to its own bottlenecks. When the burn unexpectedly became more active and complex, small misjudgments grew into larger problems that were easy to detect but hard to solve, because the capacity to activate backup and improvise had already dissolved. A resilient version would have had backup resources defined identically and instantly deployable, personnel practiced through worst-case simulation, and workarounds ready — keeping the errors small instead of letting a mild audit turn brutal.

• If small clues are accumulating and 'aren't going away,' then treat it as an active audit of your resilience now — don't wait for a full-blown issue to emerge.
• If a mishap has occurred, then ask 'can we keep operating?' and improvise a workaround, rather than halting until the cause is fully diagnosed.
• If two groups can interpret a shared resource term (like 'standby') differently, then force one operational definition before you need it.
• If you find yourself treating recovery as routine or deferring to authorities rather than experts, then stop — those are the exact reflexes that magnified damage at troubled organizations.
• If complacency or hubris is setting in after a run of success, then re-run worst-case simulations, since these are the two biggest enemies of reliable performance.

• Chasing an error-free record instead of a disable-proof system — the tell: you measure success by zero errors and are surprised (and paralyzed) when one slips through.
• Overlooking capabilities for resilience by attending only to prevention/planning — the tell: no fire drills, no worst-case rehearsal, no rehearsed workarounds exist.
• Treating recovery as routine — the tell: no dedicated response repertoire; people assume 'we'll handle it' and improvise from scratch under pressure.
• Standby/backup resources exist on paper but can't be activated instantly, or mean different things to different people — the tell: at crunch time nobody agrees who is available or coordination dissolves.
• Thin bench of experience and no recombination skills — the tell: when the unexpected hits, staff can't 'make do with what's at hand' and the system stalls on missing tools or people.

• ▸Likely mishap: name one weak-signal problem that could cumulate into a brutal audit
• ▸Detection cue: the specific small clue that tells you it's starting
• ▸Keep-it-small move: how you catch/contain this development early
• ▸Workaround: the improvised path that keeps operations running if it breaks
• ▸Standby resources: what/who backs up the frontline — with ONE shared definition
• ▸Activation: exact step to activate backup instantly (who, how, how fast)
• ▸Skill inventory: whose deep/varied experience and recombination skills you'd draw on
• ▸Drill date: when you last ran a worst-case simulation of this scenario
• ▸Top-management support: resource commitment secured for early detection and recovery

1. 1When an unexpected event breaks routine, name the specific knowledge the event demands (not the seniority it interrupts) and ask: who here has dealt with this exact configuration? Route the decision there, not upward.
2. 2Let the decision migrate. Treat authority as mobile: as the situation shifts, re-ask who holds the most relevant knowledge and move the call to them, regardless of rank. On carriers this looks like decisions that 'search' for the expert around the organization.
3. 3Distinguish expertise from experience. Before deferring, check whether the candidate has elaborated their repetitions or merely repeated the same experience; the same event lived over and over without reflection is not expertise.
4. 4Practice deference downward and sideways, not just upward. Push decision making 'down and around' so front-line people who see operational detail can make and implement the call.
5. 5Protect against over-deference to a legend. When one expert dominates, explicitly require others to keep voicing their own read of the situation so their details aren't discounted ('if Gleason doesn't see it, it's not happening' is the failure to avoid).
6. 6Say when you're at the limit of your knowledge and ask for help; make asking a signaled, expected move rather than an admission of weakness.
7. 7Close the loop from decision to implementation: after the expert decides, confirm the call was actually executed on the front line, because good decisions that go unimplemented change nothing.

At Cerro Grande, Paul Gleason — a legend in the fire world — received the deference his expertise earned. He intervened on the impasse over fresh resources, took over as burn boss Friday morning so Mike Powell could sleep, became incident commander when the fire escaped Friday at 1:00, and stayed in that role when it exploded Sunday until a full incident command team arrived. Yet two failures show deference is not automatically protective. First, Gleason made good decisions but many were never implemented — deference to the right person did not produce action on the front line. Second, the sheer power of his stature may have drawn too much deference: others may have relaxed their own monitoring, assuming that if something were wrong a person of his stature would catch it, and in venerating him they discounted their own impressions of the fire that could have caught details he missed. The lesson: deference must flow to knowledge and remain paired with everyone continuing to voice what they see.

• If an event has a unique configuration and the accurate call requires specific knowledge, then let the decision migrate to the person with that knowledge, not to the highest rank.
• If a candidate has 'the most experience' but has done little to elaborate those repetitions, then treat experience as no guarantee of expertise and verify before deferring.
• If one dominant expert is present, then require others to keep reporting their own read; if people stop monitoring because the legend is watching, over-deference has set in.
• If you are operating at the edge of your own knowledge, then ask for help rather than proceed on rank or pride.
• If an expert's decision has been made but not implemented on the front line, then treat the loop as open and escalate execution, because the decision has not yet mattered.

• Deferring to rank instead of knowledge — errors at higher levels combine with lower-level errors, making problems bigger and more prone to escalation. Tell: the person deciding can't describe the specific event, only their authority to decide it.
• Confusing experience with expertise. Tell: the deferred-to person cites years or repetition, not elaborated understanding of this particular situation.
• Over-deference to a legend. Tell: others stop voicing their own impressions and monitoring slacks — 'if the expert doesn't see it, it's not happening.'
• Deferring correctly but never confirming implementation. Tell: good decisions are made and then simply don't happen on the front line, as at Cerro Grande.
• Deference only travels upward. Tell: front-line people with the operational detail never get the call routed to them, so weak signals they hold never reach the decision.

• ▸Event / anomaly: name the specific unexpected thing happening now
• ▸Knowledge required: what specific expertise does this event demand?
• ▸Who holds it: person with most relevant knowledge (not most rank/experience)
• ▸Expertise vs. experience check: has this person elaborated the situation, or just repeated it?
• ▸Decision owner now: where the call is routed this moment (re-check as it shifts)
• ▸Dissenting reads: impressions from others that differ from the expert's — recorded, not discarded
• ▸Help requested: what am I at the limit of, and whom did I ask?
• ▸Implementation confirmed: was the decision actually executed on the front line? (Y/N + who verified)

1. 1Convert your operating expectations into an explicit, written list before the event begins: what the plan requires, what resources you assume are available, what conditions must hold. Seal it, then reread it as the event unfolds and flag every expectation that goes unconfirmed.
2. 2Run a shakiness checklist to find where expectations are fragile: recent changes in supervision, issues delegated without follow-up, lack of a questioning attitude, missed procedure steps, people not on the same page, staff spread thin, distraction from schedule pressures.
3. 3Locate your 'maintenance-equivalent' observers — the people who touch failures earliest (maintenance, customer service, tech support, warranty returns) — and build a channel so their small observations reach decision-makers instead of dying in silos.
4. 4When a weak signal appears, deliberately override the reflex to make a weak response. Treat a one-inch problem as a potential $1 billion problem and mount a strong response early, while options are still open and the fix is cheap.
5. 5Apply Reason's three questions to prioritize where to watch: which activities have the most direct human contact with the system (hands-on), which pose the greatest risk if done poorly (criticality), and how often they occur (frequency).
6. 6Protect the crew's capacity to cope: track work-rest cycles against the 2-to-1 standard (sixteen on, eight off) and treat fatigue as a containment resource being spent down, because exhausted people cannot recover, contain, or think freshly.
7. 7Route urgent judgments to whoever holds the relevant expertise, not to whoever holds rank — the on-scene person face-to-face with the problem outranks a remote or temporary dispatcher on live conditions, and waiting for a superior to arrive is deferring to authority instead of expertise.

At Cerro Grande a one-inch-wide band of fire crept across the fireline into fresh grass and kept flaring up every time firefighters thought it was out — and that spot fire eventually produced about $1 billion in damage. This is the signature pattern: a small discrepancy giving off a weak clue that was easy to treat when tiny and far harder once visible. The crew's ability to contain it had already been drained: they had reported at 7:00 A.M. Thursday, hauled heavy equipment up a 90-minute steep slope several times, had the burn postponed, lost the Black Mesa holding crew at midnight, and worked close to thirty hours before relief arrived late Friday. When Powell called the dispatcher at 3:00 A.M. requesting fresh resources, the dispatcher waited for his superior's 7:00 A.M. arrival rather than fill an urgent on-scene need — deference to authority over expertise. It's not even clear the dispatcher knew Black Mesa had already left the mountain. Every early containment lever — fresh thinking, recovery capacity, expert-driven decisions, strong response to the weak signal — had been quietly disabled before the spot fire escalated.

• If a written expectation goes unconfirmed, then treat it as a signal of trouble and investigate immediately — especially since failures in interdependent systems come in clusters.
• If the signal is weak but the activity is high-criticality or high-contact, then mount a strong response now rather than matching response strength to signal strength.
• If the person face-to-face with the problem and the person with formal authority disagree, then defer to the located expertise, not the rank or the schedule.
• If a crew has approached or exceeded the 2-to-1 work-rest ratio, then treat their containment and recovery capacity as compromised and secure fresh resources before, not after, the next surprise.
• If a problematic condition is persisting rather than resolving, then escalate — the longer it lasts, the less predictable and controllable the system interactions become, and the fewer options remain.

• Making a weak response to a weak signal: the tell is people saying 'we thought we'd put it out' about a small recurring discrepancy while treating it as insignificant rather than as a clue to system health.
• Venerating an expert until others discount their own impressions ('if Gleason doesn't see it, it's not happening'): the tell is frontline observers going silent because they assume the authority figure would have caught anything real.
• Letting early-warning observations die in silos: the tell is that maintenance, customer service, or tech-support people see the surprises but no one treats their observations as relevant to the wider system.
• Deferring urgent decisions upward to authority: the tell is a decision waiting for a superior to arrive at 7:00 A.M. while an on-scene need goes unmet at 3:00 A.M.
• Spending down human capacity invisibly: the tell is crews working far past normal cycles with no tracking, so recovery and fresh thinking are gone exactly when the unexpected breaks through.

• ▸Event/operation and start time — name what you are about to do
• ▸Written expectations (be specific) — list what you assume will hold: plan, resources, conditions, communications
• ▸Hands-on activities — where humans most directly touch the system
• ▸Criticality flags — which activities pose greatest risk if done less than adequately
• ▸Shakiness checklist hits — mark any: supervision change, delegated-without-follow-up, no questioning attitude, missed step, not on same page, spread thin, schedule pressure
• ▸Early-observer channel — who holds the maintenance-equivalent view and how their signals reach you
• ▸Work-rest status — hours worked vs. 2-to-1 standard for the coping crew
• ▸Unconfirmed expectations log — reread the sealed list; note each expectation not met and the strong response triggered

1. 1Answer the three reliability questions before anything else: what do people count on, what do they expect from it, and in what ways can it fail. Write these down for each system component so you know what you don't want to go wrong.
2. 2Build a small-failure tracking routine: treat each weak signal as a possible sign of a larger scenario. When you spot a discrepancy, imagine the harrowing situation it could be the first marker of, then respond vigorously rather than matching a weak signal with a weak response.
3. 3Watch the process of the Swiss-cheese slices lining up, not just the final accident. Treat each aligned hole as a failed expectation and an opportunity to stop the progression toward a brutal audit.
4. 4Engineer resilience before the crisis by building structures that survive mismatch: broaden your repertoire of action and experience, practice recombining fragments of past experience into novel responses, drill emotional control, and deepen knowledge of how the system functions.
5. 5Institute mutual adjustment as an operating norm—when one parameter changes, compensate in another. Assign explicit responsibility for tracking these compensations so reliability is preserved as a dynamic nonevent, not assumed from quiet periods.
6. 6Redistribute authority so decisions migrate to expertise: let junior members override standard priorities when following an order would risk safety, and assess penalties for mindlessness rather than for surfacing problems.
7. 7After any audit, run the failure as a system ('what') question, not a blame ('who') question, and extract the lesson so mindful practice accelerates recovery and learning.

The Cerro Grande fire shows a brutal audit exposing everything left unprepared. A crew planned a prescribed burn of a hazardous 300-acre area at Bandelier National Monument, but the system started with vague notions of contingency resources, incomplete knowledge of itself, unexpected changes in staffing, uneven communication, quotas, and shifting command structures. When unexpected winds swirled in, the task inverted: instead of managing an intentional burn, people suddenly had to suppress an active fire that had escaped its boundaries. The structures developed before the crisis did not match the crisis that unfolded, so weaknesses rushed to the forefront and the fire caused $1 billion in damage to Los Alamos and the adjacent national laboratories in May 2000. The lesson is that the vagueness and unprepared fragments—not the wind alone—produced the collapse. Mindful organizing that tracked the small discrepancies and preserved resilience would have reduced the severity of that audit and sped recovery.

• If a signal is weak but plausible, then respond vigorously and imagine the larger scenario it could mark—do not match a weak signal with a weak response.
• If you catch yourself trusting a quiet period, then treat it with skepticism and suspicion, because constant outcomes hide continuous mutual adjustment, not the absence of danger.
• If following a standard order would risk crew or system safety, then let the person closest to the operation change priorities regardless of rank.
• If one system parameter shifts (slippery deck, breaking radio signal, heavy seas), then compensate by changing another parameter and record the change.
• If a failure occurs, then frame it as a 'what' can be learned system question, not a 'who' is to blame question.

• Attending to success, simplicities, strategy, planning, and superiors—the 'pleasures'—instead of failures and operations; the tell is that reports emphasize what went right and shortcuts passed responsibility upward.
• Treating reliability as continuous repetition rather than a dynamic nonevent; the tell is nobody is watching because 'nothing is happening' while unmonitored mutual adjustments accumulate.
• Planning for an envisioned crisis that seldom resembles the one that unfolds; the tell is that structures and SWAT-team resources fit a scenario that never arrives while real weaknesses go uncovered.
• Reading discrepancies only in hindsight and missing them at the time; the tell is that after an accident the aligned holes look obvious but no one flagged them as failed expectations along the way.
• Complacency and hubris—overconfidence that you have deduced all failure modes; the tell is dismissing HRO struggle as 'having it right' and stopping the ongoing effort to get it right.

• ▸Component / system: name the thing people rely on
• ▸Count-on: what people count on it to do or not do
• ▸Expectation: what performance you expect from it
• ▸Failure modes: the specific ways it can fail (misspecification, misestimation, misunderstanding)
• ▸Weak signals: small discrepancies that would precede failure and how they're detected
• ▸Compensating adjustment: which parameter you change when this one shifts, and who records it
• ▸Expertise migration: who can override standard priorities here and under what condition
• ▸Resilience repertoire: past experiences/skills available to recombine into a novel response
• ▸Recovery/learning step: how you'll extract the lesson as a 'what' not a 'who' after an audit

1. 1Start with a specific business issue, not with a vision to 'change the culture.' Name the reliability problem you face (weak-signal detection, error concealment, budget insensitivity), then ask whether current culture aids or hinders resolving it.
2. 2Inventory existing cultural strengths first. Treat culture as the residue of past successes and identify which mindful practices already exist in pockets so you build on them rather than replacing them.
3. 3Signal core values through visible behavior and symbols, not just statements. Change a symbol first (an artifact), let values get articulated around it, then let assumptions align — start with easy symbolic changes as leverage for deeper ones.
4. 4Reward the mindful behaviors you want repeated: reward people who speak up about errors, who ask for help when past the limits of their knowledge, and who treat a small anomaly as the possible sign of a larger failure.
5. 5Institutionalize deference to expertise structurally. Establish operating dynamics that let leadership and decisions migrate down to whoever currently has the answer, and legitimize asking for help as a sign of strength.
6. 6Attack culture change at all three levels: organizationwide (leader-centered intentions), subunit (local translations of what 'speaking up' means), and issue-specific fragmented behaviors. Skipping any level leaves the change incomplete.
7. 7Protect trust as the primary product. Convey that reliable, mindful practices exist to sustain civic and market trust in managers' competence, since without trust there is no production.
8. 8Expect relapse. Culture change is hard, slow, and subject to frequent relapse, so re-signal values repeatedly and keep monitoring whether the new practices persist under production and budget pressure.

At Cerro Grande, the reliability failure was that budgets were insensitive to operations three times over: unable to instantly activate standby resources, carrying conflicting definitions of 'standby,' and blind to bottlenecks in their own functioning. While managers haggled over budget authority, the fire grew and the exhausted skeleton crew struggled to keep it from circling behind them. Paul Gleason named the cultural value the leadership had failed to hold in place: 'If someone phones and needs help, don't talk budget. This is fire! Do the money thing later.' A leader supporting mindfulness would treat that line as the symbol to change first — making 'operations over budget in a crisis' a rewarded, saliently stated norm. That reframes what people expect around here, so front-line workers defer to the operational reality rather than to the chain of command. The tell of missing cultural support is exactly what happened: coordination that was tenuous to begin with dissolved the moment an unexpected demand arrived.

• If you want to change how the organization works, then start with the concrete issue and build on existing cultural strengths — never start with 'change the culture' as the goal.
• If lives or high stakes are immediately at risk and data is uncertain, then defer to engineers/experts using qualitative and intuitive standards rather than protocol and chain of command.
• If someone admits they've reached the limit of their knowledge and asks for help, then reward it as strength — because punishing it teaches concealment.
• If the change is 'get people to speak up about errors,' then define what counts as a reportable incident locally in each unit, because 'speaking up' means different things in different units.
• If you can only make one move, then change a symbol/artifact first and let values and assumptions align around it, rather than announcing new values abstractly.

• Launching organizationwide, leader-driven culture change while ignoring subunit and fragmented levels — the tell: leaders declare the value adopted, but 'speaking up' still means nothing consistent on the front line.
• Treating dysfunctional-looking elements as targets to eliminate — the tell: you discard practices that were actually strengths among a large set, weakening the very residue of past success.
• Discrediting the credible manager instead of hearing the message — the tell: uncomfortable expert warnings get dismissed by attacking who raised them, as at NASA.
• Rewarding rank over expertise so decisions can't migrate to whoever has the answer — the tell: help isn't asked for because a macho world frowns on admitting you're in over your head.
• Letting budget or production pressure override operational reality — the tell: people 'talk budget' during an emergency and tenuous coordination collapses under an unexpected audit.

• ▸Business issue at stake: name the specific reliability problem, not 'culture.'
• ▸Existing cultural strength to build on: what past success already supports mindfulness here.
• ▸Core value to signal: the mindful behavior top management must convey saliently.
• ▸Symbol/artifact to change first: the concrete easy change that leverages deeper alignment.
• ▸Behavior to reward: the mindful act (speaking up, asking for help, treating anomalies) you will visibly recognize.
• ▸Local translation check: how each subunit interprets this value/incident differently.
• ▸Expertise migration rule: how leadership/decisions shift to whoever currently has the answer.
• ▸Trust at risk: whose trust in your competence is the primary product being protected.
• ▸Relapse safeguard: how you will re-signal and monitor persistence under pressure.

1. 1Name your maintenance-equivalent roles explicitly. Identify who in your organization encounters failures at their earliest stage — maintenance workers, warranty returns, customer service, tech support hotlines — and route their observations directly into learning channels rather than letting them stay local.
2. 2Fix the 'no news' default. Replace any standing order that treats silence as safety (like Herald of Free Enterprise Order 01.09) with a rule that requires an active positive report and requires the recipient to inquire when a report is missing. Treat absence of a report as a possible danger signal, not an all-clear.
3. 3Build the reporting culture through candor from the top down. Have leaders openly name their own failed expectations first; this encourages others to be candid, improves the data available for learning, and surfaces corrections while problems are still manageable.
4. 4Separate the knowledge hierarchy from the authority hierarchy. Establish deference-downward practices: when a problem arises, defer decisions to those with hands-on expertise regardless of rank, as when the Diablo Canyon plant manager stayed out of the control room and relied on root-cause analyses by senior operators.
5. 5Guard against category-driven blindness. Audit your classification labels (like NASA's 'in-family' / 'out-of-family') because established words limit what people see and report; require redefinition when a familiar label is being applied to a genuinely unexpected event.
6. 6Convert near misses into lessons, not reassurance. Treat every lapse as a symptom of a systemic problem and elaborate each near miss for what it teaches; be explicitly wary of success, which breeds complacency, reduced safety margins, and drift into automatic processing.
7. 7Run the sealed-envelope exercise for learning. Before a foreseeable event, write down specifically what you expect to happen, seal it, and after the event compare — treat any disconfirmed expectation as a trouble signal, since failures in interdependent systems cluster.
8. 8Sustain dense interaction. Hold interdisciplinary, interdepartmental briefings throughout operations (as Diablo Canyon does during outages) so problems get rapid attention at all levels and everyone stays informed of how interventions are progressing.

At Davis-Besse, maintenance personnel were positioned to spot trouble early — they normally encounter failures at earlier stages and see vulnerabilities in technology, sloppiness in operations, and gaps in procedures. But the plant failed because rust accumulation was not treated as a significant failure, and missing it was not seen as 'a mistake we can't make.' Speaking up and sharing information were not encouraged, so the early signal never became a lesson. Contrast this with Diablo Canyon, where, when the number two reactor shut down automatically, the plant manager deliberately stayed out of the control room and deferred to root-cause analyses by his senior people, who relied on their own subordinates. The difference is not talent but culture: one plant lacked the safety culture that would have made candor, reporting, and downward deference routine; the other institutionalized them. An informed culture would have flagged the rust as a reportable symptom and pushed the observation up the learning chain instead of letting it die at the workbench.

• If you hear no report, then inquire actively — never assume silence means safety, because the reporter may be incapacitated (the tell of great danger).
• If a decision touches operational detail, then defer it to the person with hands-on expertise even if they wear 'dirty overalls and greasy hands,' because the authority ladder does not reliably match the knowledge ladder.
• If someone labels an event as familiar or 'in-family,' then challenge whether the category is concealing an unexpected event, because established words limit what people see and report.
• If a lapse or near miss occurs, then treat it as a window on system health and elaborate it for lessons, rather than closing it out as an isolated success or fluke.
• If an expectation you wrote down goes unconfirmed, then raise vigilance immediately, because failures in interdependent systems tend to arrive in clusters.

• Silence-equals-safety defaults. A standing order (like Order 01.09) that treats absence of a report as 'ready for sea' — the tell is that no one is required either to report or to ask, so an incapacitated reporter goes unnoticed.
• Status outclassing knowledge. Senior officials protected by bureaucratic structure make technical calls instead of frontline engineers — the tell is an 'informal chain of command' where location in the hierarchy empowers some to speak and silences others (as with the Columbia tile expert).
• Normalizing via categories. Too many events get labeled 'in-family' or dismissed as insignificant — the tell is that a recurring anomaly like rust accumulation is never treated as 'a mistake we can't make.'
• Success breeds complacency. The organization drifts into automatic processing and trims safety margins after a run of good outcomes — the tell is reduced vigilance and shrinking margins of safety justified by past success.
• Learning stays local. Early-warning roles (maintenance, customer service, tech support) see the surprises but their observations never feed organizational learning — the tell is that speaking up and information-sharing are not actively encouraged.

• ▸Signal source: which early-warning role (maintenance / warranty / customer service / other) observed it
• ▸No-news check: is a positive report required here, and who must inquire if it's absent?
• ▸Event / near miss described: what actually happened, in operational detail
• ▸Category applied vs. reality: what label was used and could it be masking an unexpected event?
• ▸Knowledge vs. authority: who has the hands-on expertise, and who is actually deciding?
• ▸Candor entry: what failed expectation are you naming openly to invite others' candor?
• ▸Lesson extracted: what does this reveal about system health, and what changes now?
• ▸Cluster watch: what interdependent failures might accompany this one?
• ▸Follow-up owner and date: who converts the lesson into changed action, by when

1. 1Score your work unit against Audit 5.3's nine statements: count agrees and disagrees. The more disagrees, the more interactively complex and tightly coupled your system is, and the more mindfulness matters.
2. 2Assess coupling directly: ask whether a process, once started, proceeds rapidly and irreversibly with little slack, no storage of incomplete work, and few alternative pathways. If yes, you are tightly coupled.
3. 3Assess interactive complexity separately: map whether components interact only in direct linear sequence (like an assembly line) or through hidden, nonlinear feedback loops that no one can fully anticipate or observe.
4. 4Locate the human-system interface and time-dependent junctions — maintenance work, handoffs, coordinated actions requiring many operators — because these are where 'ugly' surprises surface.
5. 5Where you find high coupling plus high complexity, install strong-response-to-weak-signal practices: treat superficially familiar events as suspect, and reevaluate assumptions on the day of execution rather than trusting ratings made weeks earlier.
6. 6Balance centralization and decentralization: tight social coupling around a few core values, looser coupling around the means, so local containment survives without losing coordination of wider threats.
7. 7Use mindfulness for early anomaly detection. It cannot comprehend the incomprehensible, but it catches early anomalies before they spiral into seemingly impossible outcomes.

At Cerro Grande, the burn was a tightly coupled, complexity-sensitive process where ratings drove everything downstream. Burn boss Powell rated individual contingencies on a 1-2-3 scale where 3 was high complexity, but the correct National Park Service scale was 1-3-5 where 5 was high. He used the wrong scale because it was posted online and no one at the five federal agencies caught the error. The wrong scale estimated low-to-moderate complexity; the correct one would have summed to moderate-to-high — the difference between a burn Powell was qualified to direct and one he was not, and between the resources requested and the greater standby resources actually needed. Because complexity, resources deployed, and contingency plans are tightly linked, this single simplification propagated irreversibly. Ratings were also completed weeks ahead and never updated on burn day, because policy did not require it, so early clues that expectations were failing piled up unseen.

• If a process, once initiated, proceeds rapidly and irreversibly with no slack or storage, then treat it as tightly coupled and build in reevaluation checkpoints, not just upfront plans.
• If feedback is indirect, components are unobservable, and interactions are nonlinear, then assume hidden failure paths exist and require diverse observers rather than a single expert.
• If you 'recognize' an event as one you've seen and understood before, then treat that recognition as a source of concern, not comfort — surface similarity can mask fatal deeper differences.
• If a rating or plan drives downstream resource and contingency decisions, then verify the instrument itself and update ratings at execution time, not weeks prior.
• If the same principles must hold under high coupling, then hold expectations lightly so disconfirmation is less disruptive — but staff more attention because weak expectations give less guidance.

• Making weak responses to weak signals. The tell: early anomalies get noted but not acted on because they aren't 'heroic' enough to justify escalation.
• Interpreting new data to confirm existing expectations — the Cerro Grande test burn data 'can be used' to update judgments but rarely is when twenty people stand ready to start. The tell: fresh evidence never changes the plan.
• Trusting a rating or tool without verifying it, like the wrong 1-2-3 scale posted online. The tell: no one owns validation of the instruments that drive decisions.
• Classifying a novel event as 'in-family' — NASA called the Columbia debris strike 'almost in-family,' meaning analyzed and understood. They were wrong. The tell: comfort language ('routine,' 'seen it before') used for events not yet examined.
• Simplifying casually, habitually, or instantly rather than deliberately, and failing to articulate the specific mistakes you don't want to make. The tell: complexity is reduced to a single number no one interrogates.

• ▸Process/unit name: what activity are you assessing?
• ▸Coupling check: once started, can it be delayed, rerouted, or reversed? (yes = looser)
• ▸Slack present: is there buffer, storage, or improvisation room when things go wrong?
• ▸Interaction type: linear sequence or hidden nonlinear feedback loops?
• ▸Observability: can you directly observe all components in the production process?
• ▸Understanding: is the work process fully understood, or are aspects (like nuclear physics) still unknown?
• ▸Disagree count from Audit 5.3 (0-9): higher = more tightly coupled and complex.
• ▸Instruments driving decisions: which ratings/tools feed resources and contingencies, and who validated them?
• ▸Mindfulness action: what weak signal will trigger a strong response, and when will assumptions be reevaluated?

1. 1List your operating expectations explicitly before acting: write down each thing you are counting on to happen or not happen. At Cerro Grande the crew counted on a doable plan, low-to-moderate complexity, capable crew, a responsive dispatch system, standby contingency resources, permissive weather, and safe local conditions — none of which were stated as testable claims.
2. 2Reframe each expectation as a hypothesis with a disconfirming test: 'a stray bolt on the deck is no big deal' becomes 'nothing bad results from a bolt lying around' — then define the evidence that would prove it wrong (a bolt ingested into an engine).
3. 3Run a scheduled search for disconfirming evidence, not confirming evidence. Copy the FOD walkdown: everyone, regardless of rank, physically walks the full length of the operation several times a day looking specifically for what could go wrong.
4. 4Treat every small failure as a signal that requires a response stronger than the signal's size suggests. Make strong responses to weak signals — count discrepancies that keep flaring up (the one-inch band of fire that kept reigniting) as symptoms, not nuisances.
5. 5Audit your routines and plans as expectations too. For each standing routine, ask: what has changed since this routine was first learned, and what data would compel us to update it? Force yourself to gather data that could disconfirm the plan.
6. 6Watch for pressure amplifying confirmation seeking. When time, staffing, or momentum rises (twenty people standing around ready to ignite), deliberately slow the interpretation of new data and assign someone to argue the disconfirming case.
7. 7Use a test or trial to update judgments, and pre-commit to acting on adverse results before the trial runs, so the data can't simply be read as confirming what you already planned.

On a carrier deck, crews once treated a stray bolt as no big deal — an implicit hypothesis that nothing bad would result from leaving one lying around. That hypothesis was disconfirmed the hard way when a bolt was ingested into a jet engine and the engine exploded during deployment. The crews did not treat this as a one-off; they built a routine to hunt the disconfirming evidence deliberately. Now they run foreign-object damage (FOD) walkdowns several times a day, and everyone regardless of rank walks the full length of the deck picking up anything that could be sucked into an engine. This inverts normal confirmation seeking: instead of scanning for reasons the deck is fine, the whole crew scans for the one small thing that proves it isn't. The FOD walkdown is a microcosm of how expectations create blind spots and how their disconfirmation becomes a basis for learning rather than disaster.

• If the signal of trouble is weak but recurring (a spot fire that keeps flaring after you think it's out), then respond as if it were strong — mobilize fresh resources rather than matching the response to the apparent size.
• If you 'recognize' a situation as something you've seen before, then treat the recognition as a source of concern, not comfort — superficial similarity may mask deeper differences.
• If pressure or momentum is rising and people are ready to proceed, then deliberately slow down and search for disconfirming evidence, because pressure increases confirmation seeking and ignoring inconsistent information.
• If new data (like a test burn) can be read either as confirming or challenging your plan, then default to the interpretation that would compel updating, because people are prone to read new data as confirming existing expectations.
• If small failures are beginning to pile up (failed containment, reduced staffing, an unresponsive dispatcher), then stop and re-mobilize before the clues become large and hard to treat.

• Being too generous with confirming evidence — the tell is that you accept vague or partial signs that the plan is working and stop looking, so accumulating contrary evidence goes unnoticed.
• Mistaking having a routine for understanding the problem — the tell is 'we have a procedure for this,' with no recent effort to update the routine against current conditions; confirmation grows from fewer and fewer data.
• Weak response to weak signals — the tell is treating a recurring small discrepancy as routine (extinguish the spot fire again, release the crew at midnight) instead of escalating.
• Reading trial or test data through the lens of the plan — the tell is that a test burn's results are folded into the existing complexity rating rather than used to challenge it, especially when a crew is standing by ready to go.
• Casual, instant simplification of complexity — the tell is a rough single-number complexity rating that then locks in resources and contingency plans, so misjudging complexity guarantees a brutal audit.

• ▸Expectation stated as a claim: what you are counting on to happen or not happen
• ▸Restated as a hypothesis: the testable 'nothing bad results if...' version
• ▸Disconfirming evidence to watch for: the specific observation that proves it wrong
• ▸Scheduled disconfirmation check: who looks, how often, walking which 'full length of the deck'
• ▸Weak signals observed so far: recurring small discrepancies and whether they've piled up
• ▸Pressure level now: is momentum/time/staffing pushing you toward confirmation seeking?
• ▸Response strength vs. signal: is your planned response stronger than the signal seems to warrant?
• ▸Routine/plan update trigger: what change since this was learned should force an update?
• ▸Decision: proceed, slow down, or re-mobilize fresh resources — and why

1. 1Treat every lapse as a symptom, not an isolated event: when something small goes wrong, ask what the failure reveals about the system that could have severe consequences if several small errors happened to coincide.
2. 2Hunt weak signals actively by fighting your own expectations. Where you expect confirmation, deliberately look for disconfirming cues — the way landing-signal officers, who assume pilots are calm, still listen even more closely to voice quality for subtle tension.
3. 3Build error reporting that people actually use: encourage reporting of errors and treat near misses as data to elaborate for what can be learned, not as events to be closed and forgotten.
4. 4Doubt your most-confirmed expectations most. Because confirmation-seeking is a well-honed human tendency, put the routines you rarely question at the top of your review list rather than the bottom.
5. 5Guard against the liabilities of success: name and monitor complacency, the temptation to reduce margins of safety, and drift into automatic processing — the three enemies that grow precisely when things go well.
6. 6Make a continuing effort to articulate the specific mistakes you must never make, then assess whether current strategies increase the risk of triggering those mistakes.
7. 7Track accumulating clues over time. Since most lapses build slowly as small clues that don't go away, keep a running record so a pile-up becomes visible before it turns a mild audit brutal.

At Bhopal on December 3, 1984, Union Carbide released 40 tons of methyl isocyanate gas, killing three thousand people initially. No single failure caused it; a chain of small errors coincided: a water isolation plate was not reinserted, storage tanks malfunctioned, gauges and alarms were inoperative, safety manuals were in English that plant personnel could not read, and high turnover had drained experienced staff. A preoccupied-with-failure organization would have treated each of these individually minor lapses — a missing plate, a dead gauge, an unreadable manual — as a symptom that something was wrong with the whole system. The book's warning is that these small failures went unnoticed and simple diagnoses were accepted until they coincided catastrophically. The lesson is to attend to each weak signal on its own terms before it combines with others.

• If an expectation is confirmed most often, then subject it to the most doubt — frequent confirmation is a warning, not reassurance.
• If a lapse looks isolated and trivial, then treat it as a symptom of a broader systemic problem until you can prove otherwise.
• If a near miss occurs, then elaborate it for what can be learned rather than closing it as a non-event.
• If performance is running smoothly and success is accumulating, then actively watch for complacency, eroding safety margins, and automatic processing.
• If a strategy is proposed, then check whether it increases the likelihood of triggering a mistake you have already said you must never make.

• Attending to the 'pleasures' of success rather than failure — the tell is that reviews celebrate what went right and small failures go unnoticed.
• Accepting simple diagnoses of small problems — the tell is a single quick explanation is offered and no one asks what else the lapse might signal.
• Seeking confirmation and avoiding disconfirming evidence — the tell is that a plan is defended by narrowing the search for data instead of testing it.
• Treating recovery as routine — the tell is that near misses are logged and closed without being elaborated for lessons.
• Letting complacency and hubris set in during good runs — the tell is that margins of safety get quietly reduced and processing drifts onto autopilot.

• ▸Lapse observed: describe the small failure or near miss in one line.
• ▸System symptom: what broader problem might this lapse indicate?
• ▸Coincidence risk: which other small errors could combine with this to cause severe consequences?
• ▸Confirmation check: which confirmed expectation should I now doubt because of this?
• ▸Reporting status: has this been reported openly, and by whom?
• ▸Success liability present: mark any complacency, reduced safety margin, or automatic processing at play.
• ▸Mistake-not-to-make link: which named must-never-happen mistake does this move us toward?
• ▸Follow-up action: the specific step taken to update the routine and compel further checking.