Win the Battle. Lose the System.
The Adversary Wasn’t Playing "Your Game."
What Dr. Ike Wilson’s newest essay on the Iran campaign has in common with the resilience arguments we’ve been developing through StormWiSE.
Dr. Ike Wilson’s latest essay takes on the recent US campaign against Iran and argues that the conventional scorecard misses the actual contest. By any operational measure, the campaign is/was a clear success: infrastructure destroyed, leadership degraded, command networks disrupted. Wilson doesn’t dispute any of that; his argument is that Iran was never trying to win the war. Tehran pursued what he calls strategic irreducibility, absorbing damage while using persistence, asymmetry, and institutional patience to remain an indispensable variable in the region’s future regardless of what got destroyed along the way. He calls the analytical failure mirror-imaging: assuming an adversary is keeping score on your terms, then mistaking your own metrics for the outcome that actually mattered.
From there Wilson generalizes to a broader claim about security itself. Security, he writes, is not invulnerability: it is the capacity of interconnected systems to keep performing their essential functions under sustained stress. Distributed systems, ones where no single function sits in one place, absorb shocks and reroute faster than centralized ones. And he draws a distinction that does most of the work in the piece: institutions built for a stable, known environment optimize, but institutions built for an environment that keeps shifting have to adapt continuously. Confusing the two, treating a system built to optimize as though it were also built to adapt, is what produces campaigns that win every engagement and still lose the war.
One Node, Too Much Weight.
That distinction is one we’ve been circling for months, just from a different entry point. When we first started applying Wilson’s thinking on strategic stability to our own ecosystem mapping work, we noticed a structural pattern: systems often depend on a single node quietly carrying several stabilizing functions at once, and stability doesn’t erode gradually when that node becomes unreliable, it breaks. We had already seen a smaller version of the same thing in entrepreneurial ecosystems, where a critical function like capital, mentorship, or connection, concentrated in a single actor, can look perfectly healthy right up until that actor moves, at which point there’s nowhere for the system to reroute.
The Function Doesn’t Disappear. It Moves.
The reason that gap matters is that losing a node rarely means losing the function it served. More often, something else absorbs it, the way an ecosystem reorganizes around a removed keystone species, and what fills the gap is not guaranteed to be an improvement. Wilson’s new piece supplies the mechanism underneath that pattern: distributed systems reconfigure and substitute functions across nodes precisely because no single node is indispensable to the system, even when it was indispensable to whoever relied on it.
Once you see resilience that way, the practical question stops being about how many resources to add and becomes a question about structure: which connections, if strengthened, would propagate benefit furthest through the network, and which nodes, if lost, would cascade the most damage. That is a topology question before it is a funding question, whether you are trying to stabilize a startup ecosystem or figure out what a security campaign actually put at stake.
Optimized for One, Adapted for the Other.
Wilson’s optimize-versus-adapt distinction is what ties all of this together. It explains why applying more force or more resources to a system engineered for stability doesn’t make it more resilient, if the environment it actually operates in keeps moving. Resilience isn’t a quantity you add. It’s a property that comes from structure, how distributed and legible the critical functions are, and from orientation, whether the system was designed to hold a fixed state or to keep adapting as that state shifts. Mistaking one for the other isn’t a minor error. It’s the pattern underneath a surprising number of the systems we study here, whether the domain is national security, an entrepreneurial ecosystem, or an organization caught somewhere in between.
If your organization’s resilience planning still assumes an environment stable enough to fully engineer around, that assumption is worth testing before you invest further in it. Storm King Analytics is glad to help you map where the actual structure is. Reach out at info@stormkinganalytics.com.