Escalation

Beschreibung

"Eskalation" (Escalation) ist der klassische Rüstungswettlauf-Archetyp. Zwei Akteure (Systeme, Teams oder Firmen) konkurrieren um Dominanz, Sicherheit oder Ressourcen. Einer der Akteure fühlt sich bedroht und rüstet auf (technologisch oder politisch). Der andere Akteur sieht diese Aufrüstung, fühlt sich nun seinerseits bedroht und rüstet ebenfalls auf – oft noch stärker, um zu "gewinnen". Beide Parteien peitschen sich in einem Teufelskreis nach oben, verschwenden massive Ressourcen in einen irrationalen Kampf und hinterlassen verbrannte Erde, obwohl keine der Seiten einen objektiven Nutzen aus der Eskalation zieht.

Feedback Loops

Der Motor der Eskalation ist so simpel wie brutal: Ein *Reinforcing Loop* (Verstärkende Schleife), gebildet aus der puren relativen Differenz zwischen Akteur A und Akteur B. Wenn A eine neue Waffe kauft, ist die gefühlte Sicherheit von B im Minus. B kauft zwei Waffen, das zieht die Sicherheit von A ins Minus. Der Loop hat meist extrem kurze *Delays* bei der Reaktion, weshalb das Verhalten exponentiell schnell toxische Ausmaße annimmt. Das System verhält sich exakt wie zwei Kinder, die streiten: "Der hat aber angefangen!".

Architekturbeispiel

Zwei verschiedene Tech-Tribes (Tribe A und Tribe B) teilen sich eine Monolith-Datenbank. Tribe A hat Performance-Sorgen und baut einen Connection-Pool, der sich beim Startup extrem viele Connections aggressiv im Vorfeld sichert. Dadurch bekommt Tribe B Connection-Timeouts. Tribe B ärgert sich und konfiguriert seinen Service so, dass er doppelt so viele Connections anfragt (und blockiert) wie Tribe A. Tribe A sieht am nächsten Tag wieder Timeouts bei sich und schraubt sein Pooling-Limit komplett durch die Decke. Die Folge: Die Datenbank stürzt komplett wegen Connection-Erschöpfung ab. Beide Services sind tot, weil sie sich in einen Code-Rüstungswettlauf gesteigert haben.

Organisationsbeispiel

Zwei Abteilungen (Projektmanagement und Operations) bekriegen sich. Das PM-Team zwingt einen riskanten Release in Produktion. Ops verbringt das Wochenende mit Löschen. Als Reaktion (Eskalation) führt Ops eine strikte Regel ein: "Alle Releases brauchen ab sofort die Unterschrift von drei Ops-Managern". Das PM-Team ist wütend über die Verzögerung, eskaliert auf Geschäftsführer-Ebene und fälscht Dringlichkeits-Tickets als "Sev-1 Incident", um die Ops-Regel auszuhebeln. Ops merkt das und sperrt dem PM-Team sämtliche Tool-Zugänge fürs CI/CD. Die Eskalationsspirale endet erst, wenn die verfeindeten Teams komplett umorganisiert oder gefeuert werden.

Diagnosefragen

1.Wo versuchen wir "mit dem Kopf durch die Wand" ein architektonisches Patt zu gewinnen, indem wir einfach nur noch aggressiveren Code (mehr Retries, mehr Throttle-Limits, mehr CPU) dagegen werfen?

2.Entstehen in unserem Unternehmen "Schatten-ITs", weil sich Fachabteilungen und IT-Sicherheit in einem absurden Rüstungswettlauf (Immer mehr Verbote vs. Immer mehr Hacker-Workarounds) befinden?

3.Welche Abteilungen hassen sich so sehr, dass sie Entscheidungen nur noch treffen, um primär "der anderen Seite zu schaden" anstatt dem Unternehmen zu nützen?

Diagramm

Wie du das Muster im Alltag erkennst

Eskalations-Strukturen lassen sich niemals durch einen "Sieg" innerhalb der Struktur lösen. Wenn du versuchst, härter zu rüsten, gibst du dem Rad nur mehr Schwung. Der einzige systemische Weg aus der Eskalation ist paradox: Einseitige Abrüstung gepaart mit Transparenz. Du musst aussteigen. Systemdenker raten dazu, den Gegner nicht als Feind zu sehen, sondern zu begreifen, dass beide Seiten Gefangene exakt desselben Struktur-Loops sind. Die Struktur zwingt beiden ein Verhalten auf, das für den Einzelnen logisch erscheint, global aber fatal ist.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Im Gegensatz zu *Accidental Adversaries*, bei dem die Akteure unabsichtlich eine gemeinsame Ressource zerstören, weil sie kooperieren wollten, ist das Verhalten bei *Escalation* direkt gegeneinander gerichtet. Es ist die reine Logik des Aufrüstens. Der Fehler liegt in der Nullsummen-Illusion ("Wenn die anderen gewinnen, verlieren wir").

Wie du vom Muster zur Reaktion kommst

Wenn du Eskalationstsrukturen in der Software-Architektur identifizierst (zwei Services, die um Ressourcen kämpfen, zwei Teams, die sich im Code blockieren), dann de-eskaliere radikal auf Ebene der Architektur-Policies. Zwinge beide Services auf ein explizites, faires und zentral gemanagtes Quota-System (Zuteilung). Entziehe den lokalen Systemen die Waffe, selbstständig ihre Limits aggressiv nach oben skalieren zu dürfen. Baue eine ausgleichende Schleife (Governance Limit) ein, die die verstärkende Schleife des Rüstungswettlaufs sprengt.

Erste nächste Schritte

Lehne "Gewinner/Verlierer" Narrative im Architektur-Board kategorisch ab. Wenn Architektur-Entscheidungen per Mehrheitsvotum "gegen" ein Team durchgedrückt werden, beginnt am nächsten Tag die Eskalation der Workarounds.

Woran du das Muster sicher erkennst

Haben für Konflikt-Ressourcen (z.B. Cloud-Kosten) ein klares, von allen akzeptiertes Governance-Regelwerk, oder schieben wir die Budgets nur operativ hin und her, je nachdem wer am lautesten schreit?

Quellen

The Systems Thinker: Escalation

Daniel Kim — Systems Archetypes at a Glance

Wikipedia: Escalation of Commitment