Accidental Adversaries

Beschreibung

"Unbeabsichtigte Gegner" (Accidental Adversaries) beschreibt eine Dynamik, in der zwei Akteure eigentlich kooperieren wollen, sich aber durch lokale Schutzmaßnahmen gegenseitig behindern. Team A gerät unter Druck und verändert etwas, um sich selbst zu entlasten. Diese Maßnahme verschlechtert unbeabsichtigt die Situation von Team B. Team B reagiert ebenfalls lokal, wodurch wiederum Team A belastet wird. So entsteht ein Konflikt zwischen Parteien, die ursprünglich gemeinsame Ziele hatten.

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) wirkt 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 wirkt. Ein schädlicher 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 klar an (lokale Optimierung). Wenn nun Traffic-Spitzen kommen, drosselt Payment die Anfragen klar (Rate Limiting). Das Order-Team erhält plötzlich haufenweise Timeouts. Um ihre eigene SLA zu retten (lokale Optimierung), bauen sie stark aggressive Retry-Schleifen, die konsequent auf Payment stark belasten. Payment wird durch die Retries zusätzlich überlastet. Beide Services haben durch "Best Practices" effektiv eine problematische Lastspirale 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 beeinträchtigt. 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 konsequente 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. Der Konflikt entsteht unabsichtlich durch blinde lokale Optimierung ohne Rücksprache.

Wie du vom Muster zur Reaktion kommst

Wenn du diesen Archetyp erkennst, sollten die beteiligten Teams ihre lokalen Probleme gemeinsam visualisieren. Zeichnet die jeweiligen Maßnahmen, Nebenwirkungen und Verzögerungen auf ein gemeinsames Whiteboard. Der wichtige Moment entsteht, wenn beide Seiten sehen, dass ihre lokalen Lösungen beim anderen Team neue Belastung erzeugen. Danach kann eine gemeinsame Lösung entstehen, etwa ein abgestimmtes 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