Escalation

Description

"Escalation" is the classic arms-race archetype. Two actors, such as systems, teams, or companies, compete for dominance, safety, or resources. One actor feels threatened and arms up, technologically or politically. The other actor sees the buildup, feels threatened in return, and escalates as well, often even harder in order to win. Both sides whip each other upward in a vicious cycle, waste enormous resources in an irrational struggle, and leave scorched earth behind even though neither side gains any objective benefit from the escalation.

Feedback Loops

The engine of escalation is as simple as it is brutal: a reinforcing loop built from the relative difference between Actor A and Actor B. If A buys a new weapon, B's perceived safety drops. B buys two weapons, and A's safety drops in response. The loop usually contains very short delays in reaction, which is why the behavior becomes toxic at exponential speed. The system behaves exactly like two children arguing: "But they started it."

Architecture Example

Two tech tribes share a monolithic database. Tribe A worries about performance and introduces a connection pool that aggressively grabs a large number of connections during startup. Tribe B starts getting connection timeouts. Annoyed, Tribe B configures its own service to request and block twice as many connections as Tribe A. The next day Tribe A sees timeouts again and drives its pooling limit through the roof. The result is total database failure from connection exhaustion. Both services die because they turned the codebase into an arms race.

Organizational Example

Two departments, project management and operations, are at war. The PM team forces a risky release into production. Ops spends the weekend firefighting. As a reaction, Ops introduces a strict rule: every release now needs signatures from three Ops managers. The PM team is furious about the delay, escalates to the executive level, and labels urgent tickets as Sev-1 incidents to bypass the rule. Ops notices and revokes the PM team's CI/CD access entirely. The escalation spiral stops only when the hostile teams are reorganized or broken apart.

Diagnostic Questions

1.Where are we trying to win an architectural stalemate by simply throwing even more aggressive code at it, such as more retries, higher throttle limits, or more CPU?

2.Are shadow IT systems emerging because business departments and information security are trapped in an absurd arms race of more restrictions versus more workarounds?

3.Which departments dislike each other so much that decisions are made mainly to hurt the other side instead of helping the company?

Diagram

How to Recognize the Pattern in Daily Work

Escalation structures can never be solved by achieving victory within the structure. If you try to arm up harder, you only spin the wheel faster. The only systemic way out is paradoxical: unilateral de-escalation paired with transparency. You have to step out of the game. Systems thinkers advise not seeing the opponent as an enemy, but as another prisoner of the exact same structural loop. The structure forces both sides into behavior that looks rational locally but is disastrous globally.

What Distinguishes the Pattern from Similar Dynamics

Unlike *Accidental Adversaries*, where actors unintentionally damage a shared resource while trying to cooperate, behavior in *Escalation* is directly aimed against the other side. It is the pure logic of arms buildup. The mistake is the zero-sum illusion: if they win, we lose.

How to Move from Pattern to Response

If you identify escalation structures in software architecture, for example two services fighting over resources or two teams blocking each other in code, de-escalate radically at the level of architecture policy. Force both services into an explicit, fair, centrally managed quota system. Remove the weapon that allows local systems to push their limits upward on their own. Build a balancing governance loop that breaks the reinforcing arms-race loop.

First Next Steps

Reject winner-loser narratives in the architecture board. If architecture decisions are pushed through by majority vote against one team, escalation of workarounds starts the next day.

How to Recognize the Pattern with Confidence

For conflict-heavy resources such as cloud costs, do we have a clear governance framework accepted by everyone, or are we just shifting budgets back and forth operationally depending on who yells loudest?

Sources

The Systems Thinker: Escalation

Daniel Kim - Systems Archetypes at a Glance

Wikipedia: Escalation of Commitment