Escalation

Description

"Escalation" describes a dynamic in which two actors, such as systems, teams, or companies, compete for dominance, safety, or resources. One side increases its protective or assertive measures. The other side interprets this as a threat and responds with stronger measures of its own. This creates a reinforcing loop in which both sides bind resources without increasing overall value.

Feedback Loops

The engine of escalation is a reinforcing loop built from the relative difference between Actor A and Actor B. If A increases capacity, control, or restriction, B's perceived safety drops. B responds with its own increase, which creates new pressure for A. Short reaction delays intensify the dynamic.

Architecture Example

Two tech tribes share a monolithic database. Tribe A has performance problems and increases its reserved database connections. Tribe B then sees more connection timeouts and increases its own limit as well. Tribe A reacts with another increase. In the end, the shared database is overloaded by the sum of local protective measures. Both teams acted understandably from their own perspective, but together they created an escalation spiral.

Organizational Example

Two departments, project management and operations, enter a conflict. The PM team brings a risky release into production. Ops has to stabilize it over the weekend. In response, Ops introduces a strict rule: every release now needs signatures from three Ops managers. The PM team is frustrated by the delay, escalates to the executive level, and labels urgent tickets as Sev-1 incidents to bypass the rule. Ops notices and removes the PM team's CI/CD access. The escalation spiral stops only when the teams jointly reorder their rules, incentives, and decision rights.

Diagnostic Questions

1.Where are we trying to resolve an architectural stalemate through ever stronger local measures, such as more retries, higher throttle limits, or more CPU?

2.Are shadow IT systems emerging because business departments and information security respond to each other with more rules and more workarounds?

3.Which departments are in such a strong conflict that decisions serve separation from the other side more than the company?

Diagram

How to Recognize the Pattern in Daily Work

Escalation structures are rarely solved by achieving victory within the structure. Each additional countermeasure can reinforce the loop further. A systemic way out often combines de-escalation, transparency, and shared rules. Systems thinkers do not view the other side primarily as an opponent, but as part of the same structure. The structure creates behavior that appears locally rational but can be harmful 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 at the level of architecture policy. Both services can receive an explicit, fair, centrally managed quota system. Local systems should not be able to raise their limits arbitrarily. A balancing governance loop interrupts the reinforcing dynamic.

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