Your Team Sees the Next Outage Coming

Your system pays them to keep it to themselves.

A nuclear plant runs for decades without a meltdown. An airline flies millions of times a year without a crash. Your tech stack logged three “minor incidents” last month, and not one of them surprised the people closest to the work.

Those operations aren’t running simpler systems than yours. They’ve built teams that catch failure as it forms and stop it before it travels, and they’ve made that an ordinary Tuesday rather than a heroic save. Karl Weick and Kathleen Sutcliffe studied how that works across nuclear plants, airlines, and aircraft carriers, and named five marks those operations share. Each one has an opposite, the everyday habit that grinds it down.

Sensitivity to operations

A dashboard reports what already happened. The early warning lives with the people in the work: the transfers piling up between two groups, the workaround that resurfaces a month after you killed it, the agent who pauses before escalating because something doesn’t sit right. Small signals, legible only to someone close enough to read them.

Ask three people on the front line what’s felt harder than it should have this week. The answer points at where the next failure is already forming.

Reluctance to simplify

Support teams grab the fastest fix because that’s what the metrics pay for. The issue that keeps coming back, though, rarely sits where the fast fix lands. It sits a stage upstream, at a handoff that drops context, a tool limit nobody mapped, an assumption that quit being true a year ago. Close the ticket at the first explanation and you spend the quarter treating the symptom.

Take one problem your team sees constantly and trace the path the work actually travels, not the path the ticket records. Find where the confusion started, who touched it, and why. The cause is almost always sitting in a seam no single group owns.

Preoccupation with failure

Most teams record what broke. The strongest ones study what almost broke: the delay that didn’t quite escalate, the fix that held through the weekend by a thread. A near-miss is the system showing you where it’s already strained, while you still have time to move.

Open a channel where people log the close calls with no blame attached, and capture the conditions every time. What happened, what caught it, what would make the next catch come easier.

Deference to expertise

Swarming is one of the stronger things modern support has built. It gets the right people onto a hard problem fast and cuts across the org chart to do it. Under pressure, though, it tends to let the wrong voice lead, because the room defers to the highest title, or to whoever spoke first, or to whoever owns the number, while the engineer who has solved this exact thing twice stays quiet at the edge of the call.

High-reliability operations build against that drift. They don’t trust the right knowledge to surface on its own; they go find it and hand it the call. In your next incident, give one person a single job: find whoever has solved this before, and let that person run it whatever their title says. Then count how much faster it closes when experience runs the room.

Commitment to resilience

These operations rehearse the failure they hope never comes, so the response is already in muscle memory when it does. If your team hasn’t run an unannounced incident drill in the last quarter, you don’t know how they’ll hold up. You’re hoping.

Pick one system and break it on purpose, in a controlled drill, with no warning to the team. Watch what fails first, and watch who steps forward when the runbook runs out. That tells you where the next investment goes.

The real problem

We bought the high-velocity tools, the swarming and the DevOps and the real-time collaboration, and kept a set of slow-velocity assumptions running underneath them. We still build the work around resolving incidents instead of preventing them.

Support sees the early warnings first, and it’s often the one place where a single person follows a problem across systems, handoffs, and workarounds from end to end. Treat that person as a ticket-closer and the flags stop coming, because the flags never bought them anything. Bring that person into how the operation runs and you get a read on the system that nobody else in the building has.

Watch who has gone quiet in your post-mortems. The engineer who used to name the pattern out loud learned what it costs to be the one who names it, and that silence is more expensive than any single outage on your board.

Reliability comes before AI

Every tech operation is a high-risk operation now, and AI doesn’t bend the odds your way. It learns from how your operation runs and scales what it finds, the strained handoffs and the near-misses nobody logged right along with everything else. Put it on top of an operation that ignores its own early warnings and the blindness runs faster and reaches everyone at once.

The advantage won’t land with whoever buys the most compute. It lands with whoever runs an operation steady enough to trust AI on top of it, and that steadiness is built out of what you catch early, not what you fix late.

Start small

Pick one of the five and start this week. Ask the team what felt harder than it should have. Rule out “it’s probably nothing” in the incident channel. Open the close-calls log and write the first entry yourself.

If you’ve watched your best people see the next outage coming and say nothing about it, that’s the conversation worth having.

Book a call with Phil.

---

The people who see trouble coming also know where the work is hardest. The ServiceDNA™ Diagnostic asks them, and gives you actionable results in about thirty days.