How to Actually Use Predictable Surprise Frameworks in Your Organization
I spent about four years working on emergency response coordination for a county government. We had quarterly drills, binders full of procedures, and a whole team that knew how to fill out forms under pressure. Then a flash flood knocked out our primary communications hub during a real event. Nobody had anticipated the cascade failure because the risk matrix only looked at individual component failures, not the combination of a power loss at the same time as a cell tower malfunction. That's exactly the kind of predictable surprise Gary Klein writes about in Predictable Surprises: The Disasters You Should Have Seen Coming And How To Prevent Them, published by the Center for Public Leadership. The basic premise is straightforward enough. Organizations develop blind spots not because they lack data, but because their existing processes filter out the signals that matter. Your incident reporting system might capture what broke, but it won't capture the slow erosion of communication between departments. Your budget review catches cost overruns, not the fact that two teams are unknowingly duplicating work. The framework is designed to surface those gaps before they become emergencies.
Predictable Surprises The Disasters You Should Have Seen Coming And How To Prevent Them Center For Public Leadership
Klein's approach revolves around what he calls "leading indicators" rather than lagging ones. Most public organizations track things like response times, budget variance, or complaint volume. These tell you something already went wrong. Leading indicators look at the conditions that make success more or less likely. One example from the field: tracking the ratio of experienced staff to new hires in a particular unit. When that ratio drops below a certain threshold, the probability of procedural errors goes up significantly. It's not dramatic, but it's measurable and it's early. The practical method involves three steps that happen repeatedly, not just once a year. First, you conduct a predisaster review. This is different from a postmortem. In a postmortem, everyone is already in agreement about what happened. In a predisaster review, you're looking at scenarios where things could go sideways even though nothing has gone wrong yet. I found the most effective way to run these was to bring together people from different units who rarely interacted. The powerplant engineer, the budget analyst, the front desk supervisor. They'd spot connections nobody else would. A single two-hour session could surface risks that a single department audit would miss entirely. Second, you build feedback loops. This is where most organizations stumble. They identify a risk and then assign someone to "monitor it." But monitoring without a clear trigger for action is just watching paint dry. A real feedback loop has a defined signal and a defined response. For instance, if overtime hours in a critical unit exceed 15 percent above baseline for two consecutive months, the director gets an automatic briefing. Not a suggestion. An automatic requirement. The specific numbers matter less than the fact that there's an unbroken chain from signal to decision.
Third, you stress-test your assumptions. Every operational plan rests on assumptions. "The backup generator will start." "The alternate site will be available." "Staff will show up." Most of these are never tested. The workaround I developed for this was what I called the "pre-mortem." Before launching any new initiative, the team writes a brief scenario where the initiative has failed spectacularly. Not a vague failure. A specific, detailed one. Then you work backward to figure out which assumption broke. This takes about twenty minutes and usually reveals at least one assumption nobody had seriously questioned. There's a common pitfall here that I want to flag. People tend to treat predictable surprises as a checklist exercise. They run the review, fill out the form, move on. But the value isn't in the output. It's in the cognitive shift. After running these exercises consistently, people start noticing weak signals in their daily work. They ask different questions in meetings. The framework changes how you think, not just what you document. If you're not seeing that shift after three or four cycles, you're probably doing it wrong. Another nuance that doesn't get enough attention: the difference between known unknowns and unknown unknowns. The predictable surprise framework handles known unknowns well. You can build safeguards against risks you can imagine. But it also has a mechanism for the harder category. That's the surprise debrief. When an unexpected event occurs, you don't just fix the immediate problem. You hold a structured debrief to determine whether the event was truly unpredictable or whether there were early signals that got filtered out by your existing processes. In my experience, about sixty to seventy percent of so-called unpredictable events turn out to have had early indicators that were ignored or misinterpreted. The other thirty percent are genuinely novel, and those require a different kind of organizational learning.
Get the Full Details
The Center for Public Leadership's version of this framework is adapted specifically for government and public sector contexts. That means it accounts for things like political cycles, procurement rules, and the fact that accountability often flows upward rather than toward the public. Private sector risk management tools don't always translate cleanly. A private company can pivot quickly. A public organization often can't, and the framework acknowledges that constraint. I should note where this approach falls short. It doesn't replace competent leadership. If your organization has a culture of blaming individuals rather than examining systems, running predictable surprise exercises will just become another bureaucratic ritual. People will go through the motions without actually engaging with the questions. I've seen this happen. The only thing that moves the needle is when leadership consistently treats the findings seriously and acts on them, even when the findings are uncomfortable. That's harder than it sounds in a political environment where acknowledging a systemic risk can be interpreted as admitting institutional failure. Another limitation: the framework works best when you have baseline data. If you're starting from scratch with no historical information about your operations, your leading indicators will be guesses until you collect enough data. That's not a flaw in the methodology, but it's worth managing expectations. The first cycle will feel unsatisfyingly vague. By the third or fourth cycle, the signals become much sharper.
If you want to implement this, the Center for Public Leadership materials are available through their website and through several university partnerships. The core toolkit includes scenario templates, interview protocols for gathering frontline intelligence, and guidance on designing feedback loops. I'd recommend starting small. Pick one high-risk function in your organization and run a full cycle through all three steps. Don't try to roll it out everywhere at once. You'll learn more from one serious application than from ten superficial ones. The real test of whether this is working isn't whether you've completed the exercises. It's whether the people closest to the work feel comfortable flagging concerns without fear of retaliation. That's the cultural change that makes the whole framework functional. Without it, you're just producing documents. With it, you build an organization that can see problems coming and adjust before they become disasters.
