archetypes

Escalation

Zwei Parteien reagieren aufeinander mit immer stärkeren Maßnahmen, weil jede Seite die andere übertreffen oder absichern möchte.

teamsorganization·3 min Lesezeit

Warum relevant?

Ein Archetyp hilft dir, wiederkehrende Dynamiken hinter lokalen Symptomen zu erkennen.

Nächster Schritt

Gehe als naechstes in eine Diagnosemethode, um die vermutete Struktur mit Beobachtungen zu pruefen.

~4 Min. Lesezeit

Beschreibung

"Eskalation" (Escalation) beschreibt eine Dynamik, in der zwei Akteure, etwa Systeme, Teams oder Firmen, um Dominanz, Sicherheit oder Ressourcen konkurrieren. Eine Seite erhöht ihre Schutz- oder Durchsetzungsmaßnahmen. Die andere Seite interpretiert das als Bedrohung und reagiert ebenfalls mit stärkeren Maßnahmen. So entsteht eine verstärkende Schleife, in der beide Seiten Ressourcen binden, ohne dass der Gesamtnutzen steigt.

Feedback Loops

Der Motor der Eskalation ist ein Reinforcing Loop (verstärkende Schleife), der aus der relativen Differenz zwischen Akteur A und Akteur B entsteht. Wenn A seine Kapazität, Kontrolle oder Einschränkung erhöht, sinkt die wahrgenommene Sicherheit von B. B reagiert mit einer eigenen Erhöhung, wodurch A erneut Handlungsdruck spürt. Kurze Reaktionszeiten verstärken diese Dynamik.

Architekturbeispiel

Zwei Tech-Tribes teilen sich eine Monolith-Datenbank. Tribe A hat Performance-Probleme und erhöht die Zahl reservierter Datenbankverbindungen. Dadurch erhält Tribe B häufiger Connection-Timeouts und erhöht ebenfalls sein eigenes Limit. Tribe A reagiert darauf mit einer weiteren Erhöhung. Am Ende ist die gemeinsame Datenbank durch die Summe lokaler Schutzmaßnahmen überlastet. Beide Teams haben aus ihrer Perspektive nachvollziehbar gehandelt, aber gemeinsam eine Eskalationsspirale erzeugt.

Organisationsbeispiel

Zwei Abteilungen (Projektmanagement und Operations) geraten in einen Konflikt. Das PM-Team bringt einen riskanten Release in Produktion. Ops muss am Wochenende stabilisieren. Als Reaktion führt Ops eine strikte Regel ein: "Alle Releases brauchen ab sofort die Unterschrift von drei Ops-Managern". Das PM-Team ist über die Verzögerung verärgert, eskaliert auf Geschäftsführer-Ebene und nutzt Dringlichkeits-Tickets als "Sev-1 Incident", um die Ops-Regel zu umgehen. Ops merkt das und sperrt dem PM-Team Tool-Zugänge fürs CI/CD. Die Eskalationsspirale endet erst, wenn die Teams ihre Regeln, Anreize und Entscheidungsrechte gemeinsam neu ordnen.

Diagnosefragen

1.Wo versuchen wir ein architektonisches Patt durch immer stärkere lokale Maßnahmen zu gewinnen, etwa mehr Retries, höhere Throttle-Limits oder mehr CPU?

2.Entstehen in unserem Unternehmen Schatten-ITs, weil Fachabteilungen und IT-Sicherheit aufeinander mit immer mehr Regeln und Workarounds reagieren?

3.Welche Abteilungen stehen in einem so starken Konflikt, dass Entscheidungen eher der Abgrenzung zur anderen Seite dienen als dem Unternehmen?

Diagramm

Wie du das Muster im Alltag erkennst

Eskalationsstrukturen lassen sich selten durch einen "Sieg" innerhalb der Struktur lösen. Jede zusätzliche Gegenmaßnahme kann die Schleife weiter verstärken. Ein systemischer Ausweg besteht häufig aus Deeskalation, Transparenz und gemeinsamen Regeln. Systemdenker betrachten die andere Seite nicht primär als Gegner, sondern als Teil derselben Struktur. Die Struktur erzeugt Verhalten, das lokal nachvollziehbar wirkt, aber global schädlich sein kann.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Im Gegensatz zu Accidental Adversaries, bei dem die Akteure unabsichtlich eine gemeinsame Ressource beeinträchtigen, 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 Eskalationsstrukturen in der Softwarearchitektur identifizierst, etwa zwei Services, die um Ressourcen kämpfen, oder zwei Teams, die sich im Code blockieren, deeskaliere auf Ebene der Architektur-Policies. Beide Services können zum Beispiel ein explizites, faires und zentral gemanagtes Quota-System erhalten. Lokale Systeme sollten ihre Limits nicht beliebig selbst erhöhen können. Eine ausgleichende Governance-Schleife unterbricht die verstärkende Dynamik.

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?