concepts

Policy Resistance

Komplexen Systemen wohnt oft eine Abwehrkraft inne, die jeden gut gemeinten Lösungsversuch kontert und abblockt.

organizationtechnology·3 min Lesezeit

Was ist das?

Komplexen Systemen wohnt oft eine Abwehrkraft inne, die jeden gut gemeinten Lösungsversuch kontert und abblockt.

Warum relevant?

Nutze dieses Konzept, um beobachtbares Verhalten nicht nur zu benennen, sondern strukturell zu erklären.

Nächster Schritt

Prüfe danach, welcher Archetyp oder welche Diagnose das Muster im konkreten System sichtbar macht.

~4 Min. Lesezeit

Definition

Policy Resistance (oft auch Regulierungsresistenz oder Systemabwehr) ist das Phänomen, dass das Eingreifen in ein komplexes System häufig scheitert, fehlschlägt oder das Problem sogar drastisch verschlimmert. Es entsteht, weil wir versuchen, ein System isoliert von oben herab durch eine starre "Policy" (Regel, Vorgabe, Tool-Zwang) in eine Richtung zu drücken, die der inneren Logik und den ausgleichenden Feedback-Schleifen der restlichen Systemakteure widerspricht.

Systemmechanismus

Jedes laufende System wird durch das Gleichgewicht ("Balancing Loops") vieler unabhängiger Akteure und Interessen zusammengehalten. Führen wir eine neue Policy ein (z.B. "Jeder Entwickler muss künftig lückenlose Zeiterfassung nutzen"), stört das den Status Quo. Die Akteure (Entwickler) wehren sich nicht zwingend aus Bosheit, sondern aktivieren ausgleichende Schleifen, um ihre eigenen Ziele (z.B. pünktlicher Projektabschluss) zu schützen. Sie erfinden Workarounds, "Fantasie"-Zeiterfassungen oder buchen alles auf ein Sammelkonto. Die Policy wird assimiliert und wirkungslos gemacht. Das System zieht sich wie ein Gummiband in den Urzustand zurück.

Architekturbeispiel

Das Architektur-Board (Enterprise Architekten) beschließt top-down eine neue "Cloud-Sicherheits-Policy": Alle neuen Services müssen durch drei manuelle Review-Instanzen, bevor sie deployt werden. Die Entwickler reagieren auf den dadurch entstandenen massiven Engpass (Flaschenhals), indem sie Änderungen nicht mehr als Microservices releasen, sondern die alten Legacy-Monolithen extrem aufblähen (weil diese bereits genehmigt sind). Die Policy, die eigentlich die Cloud sichern sollte, hat durch Systemabwehr dazu geführt, dass ein gigantischer, unsicherer Blob aus Shadow-IT herangezüchtet wurde.

Organisationsbeispiel

Zwei Abteilungen sollen zur Kostensenkung zusammengelegt werden (Reorg-Policy). Das Management erwartet 15% Effizienzsteigerung. Durch die Zusammenlegung bangen jedoch Manager beider Seiten um ihren Status und blockieren sich gegenseitig in zahllosen Abstimmungsrunden. Die Teams verbringen Wochen in Unklarheit. Am Ende sinkt die Produktivität drastisch und wertvolle Ingenieure kündigen. Das System leistete der groben Policy maximalen Widerstand.

Diagnosefragen

1.Bei welchen neuen Architekturvorgaben oder Tools haben die Teams sofort begonnen, clevere "Workarounds" (Schatten-Prozesse) zu erfinden?

2.Warum haben die Akteure im System gute, rationale Gründe, sich genau gegenteilig zu dem zu verhalten, was unsere neue Richtlinie (Policy) fordert?

3.Kämpfen wir aktuell anymptomatisch gegen die Resistenz unserer Mitarbeiter an, ohne das tiefere Zielbild (Incentives) im Hintergrund anzupassen?

Diagramm

Warum dieses Konzept in Architektur hilft

Der Kardinalfehler im Umgang mit Policy Resistance ist das "Pushing Harder" (Mit Gewalt durchsetzen). Wenn Entwickler Workarounds bauen, verschärft das Management oft die Strafen oder baut noch mehr bürokratische Kontrollen auf. Dies erhöht nur die Gegenwehr. Systemischer Fortschritt erzielt man, indem man das zugrunde liegende Ziehen am Gummiband beendet (Let Go!). Du musst Policies so designen, dass sie die Ziele der handelnden Akteure *bündeln* und in die gleiche Richtung leiten (Shared Purpose), anstatt sich quer zu stellen.

Woran du das Konzept von ähnlichen Themen unterscheidest

Policy Resistance ist das übergeordnete Phänomen mangelnder Machbarkeit. Die klassischen System-Archetypen *Fixes that Fail* und *Shifting the Burden* sind spezifische Muster, die aufzeigen, wie genau diese Policy Resistance in der Praxis abläuft und das Problem eskalieren lässt.

Wie du das Konzept praktisch nutzt

1.Höre auf, gegen das System anzukämpfen. Setze auf Partizipation: Architekturentscheidungen müssen Bottom-up eingebettet (Communtiy of Practice) statt Top-down diktiert werden ("Architecture Board").

2.Ergründe den "Purpose" (Zweck) der Akteure. Welche existierenden Metriken / Ziele hindern das Team aktuell rational daran, deiner Policy zu folgen?

3.Reduziere Command-and-Control und setze stattdessen weiche Anreize und Leitplanken (Guardrails, Paved Roads, Golden Paths).

Erste Umsetzungsschritte

Ein guter Architekt entwirft den "Paved Road" (den goldenen, reibungslosen Weg) so, dass es für Entwickler einfacher ist, sich an die sichere Architektur zu halten, als einen Workaround zu bauen. So eliminiert man Policy Resistance präventiv.

Woran du Wirkung erkennst

Unterstützt unsere Governance-Struktur eher Regeln, Verbote und Kontrollen (hohes Risiko für Resistenz) oder "Enabling" und Hilfestellungen für die Produkt-Teams?