Accidental Adversaries

Beschreibung

"Unbeabsichtigte Gegner" (Accidental Adversaries) ist ein tückischer System-Archetyp. Zwei Akteure (Teams, Services, Abteilungen) beginnen eine kooperative Partnerschaft, um gemeinsame Wachstumsziele zu erreichen. Irgendwann gerät Team A leicht unter Druck und ergreift eine lokale Maßnahme, um sich selbst zu entlasten. Diese Maßnahme sabotiert unabsichtlich den Erfolg von Team B. Team B, nun ebenfalls unter Druck, reagiert mit eigenen egoistischen Schutzmaßnahmen, die wiederum Team A massiv schaden. Eine destruktive Abwärtsspirale beginnt, an deren Ende zwei Parteien stehen, die sich hassen, obwohl sie eigentlich dasselbe wollen.

Feedback Loops

Die Struktur beginnt oft mit einem positiven *Reinforcing Loop* gemeinsamen Wachstums. Dann entsteht ein lokaler *Balancing Loop* (Team A optimiert seinen eigenen Engpass). Dieser Balancing Loop hat jedoch einen unbemerkten Seitenarm: Eine negative *Verzögerung* (Delay) feuert drüben bei Team B ein und kappt deren Leistung. Team B antwortet mit einem eigenen lokalen Balancing Loop, dessen Seitenarm rüber zu Team A feuert. Ein toxischer Ping-Pong-Effekt von Schadensverursachung entsteht.

Architekturbeispiel

Zwei Microservices ("Order" und "Payment") arbeiten gut als verteiltes System zusammen. Das Payment-Team bekommt Performance-Probleme und zieht seine Skalierungsgrenzen hart an (lokale Optimierung). Wenn nun Traffic-Spitzen kommen, drosselt Payment die Anfragen hart (Rate Limiting). Das Order-Team erhält plötzlich haufenweise Timeouts. Um ihre eigene SLA zu retten (lokale Optimierung), bauen sie extrem aggressive Retry-Schleifen, die gnadenlos auf Payment einhämmern. Payment stürzt durch die Retrys komplett ab. Beide Services haben durch "Best Practices" effektiv eine DDos-Attacke gegeneinander orchestriert.

Organisationsbeispiel

DevOps-Team (Ops) und Plattform-Engineering-Team (Dev) wollen Entwicklern helfen. Dev entwickelt ein neues K8s-Deployment-Feature, bringt es aber mit schlechter Dokumentation heraus, um ihren Sprint zu schaffen. Ops wird mit Fehlertickets überflutet. Um sich zu schützen, weigert sich Ops, weitere Updates der Devs auszurollen, bevor nicht strikte 10-seitige Handbücher vorab eingereicht werden. Dev ist nun genervt vom bürokratischen Ops-Widerstand und umgeht die Ops-Pipelines über Schatten-Tools. Das Vertrauen ist vollends zerstört. Beide Teams blockieren sich gegenseitig.

Diagnosefragen

1.Haben wir Teams, die sich in Meetings ständig gegenseitig die Schuld zuschieben, obwohl sie vom Management das gleiche Jahresziel bekommen haben?

2.Wo bauen wir im Code gerade aggressive "Schutzmechanismen" (Circuit Breaker, Rate Limits) gegen interne Nachbarservices, anstatt uns mit dem Nachbarteam zusammenzusetzen?

3.Verwechseln wir böswillige Absicht einzelner Entwickler mit einer ungünstigen Struktur der Anreizsysteme, die jeden fast zwingt, "egoistisch" zu handeln?

Diagramm

Wie du das Muster im Alltag erkennst

Der Ausweg aus diesem Archetyp erfordert radikale Deeskalation und De-Siloing. Es bringt nichts, wenn das Management nur ruft "Arbeitet doch endlich zusammen!". Beide Parteien müssen begreifen, dass ihre scheinbar logischen, lokalen Abwehrmechanismen das Gesamtproblem mathematisch vergrößern. Die *Systemgrenze* (System Boundary) muss im Kopf der Akteure ausgeweitet werden: Sie dürfen ihr Problem nicht mehr isoliert betrachten, sondern müssen die Schleife durch das andere Team in ihr eigenes mentales Modell integrieren.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Im Gegensatz zum Archetyp *Escalation*, bei dem zwei Parteien von vornherein in einem bewussten Konkurrenz- oder Rüstungswettlauf stehen (Wer baut das bessere Produkt), starten *Accidental Adversaries* als Partner. Die Gegnerschaft entsteht unabsichtlich durch blinde lokale Optimierung ohne Rücksprache.

Wie du vom Muster zur Reaktion kommst

Wenn du diesen Archetyp erkennst, musst du die Akteure sofort physisch zusammenbringen. Lasse beide Teams ihre lokalen Probleme auf ein Whiteboard zeichnen. Verbindet die Kästchen beider Teams. Der Aha-Moment entsteht, wenn beide erkennen, wie ihre "Lösungen" dem anderen exakt den Schmerz bereiten, vor dem er gerade wegrennt. Löst dann die lokalen Schutzmaßnahmen auf und sucht eine *globale* Lösung, die beide Kapazitäten berücksichtigt (z.B. ein gemeinsames Backpressure-Handling im Code).

Erste nächste Schritte

Miss den Erfolg der Zusammenarbeit an einer kombinierten End-to-End Metrik (Lead Time to Production), nicht an lokalen Team-Metriken ("Unser Service hatte 100% Uptime, mir egal dass euer Service brannte").

Woran du das Muster sicher erkennst

Wurde bei der Einführung des neuen aggressiven Retry-Verhaltens im API-Gateway bedacht, dass wir damit im dümmsten Fall unsere eigene Legacy-Datenbank abschießen?

Quellen

Peter Senge — The Fifth Discipline, Kap. 6: Archetypes

The Systems Thinker: Accidental Adversaries

Wikipedia: System Archetypes