Shifting the Burden to the Intervenor

Beschreibung

Diese perfide Varianate von "Shifting the Burden" (Sucht-Archetyp) rückt den *Retter* ins Zentrum der Dysfunktion. Ein IT-System hat ein tiefgehendes strukturelles Problem. Ein externes Team oder ein dedizierter "Hero-Consultant" wird herbeigerufen, um zu helfen (der Intervenor). Der Held löst das akute Problem schnell und effektiv. Alle sind glücklich. Doch weil der Held die Lösung *für* das interne Team ausgeführt hat, weigert sich das Team unbewusst, das eigene fehlende Wissen aufzubauen. Beim nächsten Problem rufen sie einfach sofort wieder den Retter an. Das Team verfällt in vollkommene "Erlernte Hilflosigkeit".

Feedback Loops

Zwei *Balancing Loops* kämpfen um die Problembehebung:

1.Das Team löst es selbst (harter, langsamer Aufbau eigener Fähigkeiten).

2.Der Intervenor löst es für das Team (schneller Quick-Fix = Symptombehebung).

Der alles entscheidende, toxische *Reinforcing Loop* (Verstärkend) bildet sich auf der unteren Ebene: Je öfter Team 1 den Retter ruft, desto stärker verkümmert ihre *eigene* Fähigkeit (Atrophie) zur Problembewältigung. Diese abnehmende eigene Fähigkeit zwingt sie dazu, den Retter beim nächsten Mal noch schneller zu rufen. Ein Abhängigkeits-Teufelskreis wie bei einer Heroin-Sucht.

Architekturbeispiel

Ein Feature-Team hat riesige Probleme, sein komplexes Kubernetes-Deployment ans Fliegen zu kriegen. Sie greifen auf das "Platform Engineering Team" (den Intervenor) zurück. Der erfahrene Platform-Ingenieur übernimmt das Keyboard und fixt schnell alle Helm-Charts. Drei Wochen später bricht das Deployment nach einer neuen Library wieder. Das Feature-Team versucht es erst gar nicht (die eigene yaml-Kompetenz ist mittlerweile komplett verkümmert). Sie werfen ein Ticket bei Platform Engineering über den Zaun: "Deployt das mal bitte". Aus dem helfenden Platform-Team ist heimlich eine "Ops-Task-Force" geworden, an der alle Feature-Teams in vollkommener Unfähigkeit saugen.

Organisationsbeispiel

"Agile Coaches" als externe Berater. Ein Unternehmen hat massive Leadership-Probleme (Root Cause). Sie heuern hochbezahlte externe Agile Mentoren an (Intervenor). Wann immer es nun in einem Tribe knallt, geht nicht mehr der interne Manager hin, sondern man schickt den externen Coach, um "die Scrum-Wogen zu glätten". Die Manager verlernen völlig den Mut zur unangenehmen Führung. Die Firma kann die externen Berater nicht mehr kündigen, weil die internen Projektleiter ohne diese "Helfer" sofort weinend kollabieren würden.

Diagnosefragen

1.Haben wir "Support"-Teams (z.B. Database-Admins, Security-Architekten), die keine Werkzeuge für andere bauen (Self-Service), sondern 80% ihrer Zeit damit verbringen, Handlanger-Jobs für unfähige Entwickler auszuführen?

2.Wo dulden wir im System das geniale "Senior Entwickler Heldentum"? Wenn ein Server brennt, rufen alle nur den *einen* Senior an, anstatt dass der Senior das Ticket storniert und dem Team das Debugging beibringt?

3.Welche Abteilungen deklarieren bei jedem größeren Release "Freeze-Zustände" und betteln um ständige Händchen-Halt-Betreuung durch den Vendor?

Diagramm

Wie du das Muster im Alltag erkennst

Diese Sucht-Spirale wird interessanterweise meist von den Rettern selbst gepflegt! Der Intervenor hat einen massiven Anreiz, das Muster am Leben zu erhalten, denn es garantiert seinen Job, seinen Lohn und streichelt massiv das Helfer-Ego ("Ohne mich lauft ihr hier vor die Wand"). Systemdenker wissen: Ein guter Helfer interveniert so, dass er sich selbst systemisch überflüssig macht. Jede Dienstleistung, die dauerhaft das interne System lähmt, anstatt ihm bei der Heilung zu helfen, ist institutionelles Gift.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

*Shifting the Burden* (Die pure Symptomlösung wie "Mehr Hardware") vs. *Shifting the Burden to the Intervenor* (Der Fokus liegt auf dem *Menschlichen Akteur*, der als Pflaster eingesetzt wird, und dabei institutionelle Lernfähigkeit stielt).

Wie du vom Muster zur Reaktion kommst

Wenn du einen "Helfer" (sei es ein DevOps Team, Security Team, oder externe Consultants) beauftragst, darf die Metrik für den Erfolg *niemals* die Anzahl gelöster Probleme (Tickets) sein. Die radikale KPI für das Helfer-Team muss lauten: "Fähigkeitsaufbau beim Host-Team". Wenn das Security Team 50 Firewalls konfiguriert hat, haben sie versagt. Wenn das Security Team ein Self-Service Portal gebaut hat und die Entwickler 50 Firewalls völlig sicher selbst aufbauen konnten, waren sie erfolgreich. Verwehre den Intervenoren physisch den Zugang zur "Quick-Fix" Ausführung, indem du ihnen den Schreibzugriff nimmst.

Erste nächste Schritte

Mache dir klar, dass der Reentzug (das Verweigern des Intervenors) radikal wehtut. Wenn du dem Feature-Team den DevOps-Babysitter wegnimmst, werden ihre nächsten Deployments spektakulär crashen. Diesen Schmerz (Delay) musst du als Manager mental aushalten, während sie ihre eigene Fähigkeit wiederaufbauen.

Woran du das Muster sicher erkennst

Wird in der Job-Beschreibung des "Platform Enablement Teams" explizit festgehalten, dass es ihnen unter Androhung der Kündigung verboten ist, als verlängerte Hand-Werk-Bank für produktive Feature-Entwicklung zu agieren?

Quellen

The Systems Thinker: Shifting the Burden to the Intervenor

Donella Meadows — Thinking in Systems, Kap. 5: Addiction

Daniel Kim — Systems Archetypes at a Glance