Shifting the Burden to the Intervenor

Beschreibung

Diese Variante von "Shifting the Burden" rückt externe Hilfe ins Zentrum der Abhängigkeit. Ein IT-System hat ein strukturelles Problem. Ein externes Team, ein Plattformteam oder ein Consultant löst das akute Problem schnell. Kurzfristig hilft das. Wenn die Lösung jedoch dauerhaft für das interne Team ausgeführt wird, baut dieses Team die nötige Fähigkeit nicht selbst auf. Beim nächsten ähnlichen Problem wird erneut externe Hilfe benötigt.

Feedback Loops

Zwei Balancing Loops kämpfen um die Problembehebung:

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

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

Der zentrale Reinforcing Loop bildet sich auf der Fähigkeitsebene: Je öfter ein Team externe Hilfe nutzt, desto weniger übt es die eigene Problembewältigung. Die abnehmende Fähigkeit erhöht die Wahrscheinlichkeit, beim nächsten ähnlichen Problem erneut Hilfe anzufordern. So entsteht eine stabile Abhängigkeit.

Architekturbeispiel

Ein Feature-Team hat Probleme mit einem komplexen Kubernetes-Deployment und bittet das Platform Engineering Team um Hilfe. Ein erfahrener Platform Engineer korrigiert die Helm-Charts. Drei Wochen später bricht das Deployment nach einer neuen Library erneut. Weil das Feature-Team die Lösung nicht selbst verstanden hat, erstellt es wieder ein Ticket. Aus einem unterstützenden Plattformteam wird schrittweise ein operatives Ausführungsteam für andere Teams.

Organisationsbeispiel

Ein ähnliches Muster kann mit externen Agile Coaches entstehen. Ein Unternehmen hat Leadership-Probleme, beauftragt aber dauerhaft externe Moderation. Bei Konflikten übernimmt der Coach, statt dass interne Führungskräfte Konfliktfähigkeit aufbauen. Die Organisation wird abhängig von der Intervention, obwohl das ursprüngliche Problem in der internen Führungsfähigkeit liegt.

Diagnosefragen

1.Haben wir Support-Teams, die vor allem Aufgaben für andere ausführen, statt Self-Service-Werkzeuge und Enablement bereitzustellen?

2.Wo dulden wir Senior-Entwickler-Abhängigkeit? Wenn ein Server ausfällt, rufen alle dieselbe Person an, statt Debugging-Wissen im Team aufzubauen?

3.Welche Abteilungen benötigen bei jedem größeren Release dauerhafte Begleitung durch Vendoren oder Spezialteams?

Diagramm

Wie du das Muster im Alltag erkennst

Diese Abhängigkeit kann auch durch die Helferrolle selbst stabilisiert werden. Wer dauerhaft gebraucht wird, hat oft wenig Anreiz, die eigene Rolle überflüssig zu machen. Gute Hilfe baut deshalb Selbsthilfefähigkeit auf: Dokumentation, Pairing, Self-Service, Trainings und klare Übergaben. Jede Dienstleistung, die dauerhaft interne Fähigkeit ersetzt, erzeugt eine strukturelle Abhängigkeit.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Shifting the Burden beschreibt die Verlagerung auf eine symptomatische Lösung, etwa zusätzliche Hardware. Shifting the Burden to the Intervenor beschreibt die Verlagerung auf einen menschlichen Akteur oder ein externes Team, wodurch institutionelle Lernfähigkeit abnimmt.

Wie du vom Muster zur Reaktion kommst

Wenn ein DevOps Team, Security Team oder externer Consultant unterstützt, sollte Erfolg nicht nur an gelösten Tickets gemessen werden. Die wichtigere Metrik ist Fähigkeitsaufbau im Host-Team. Ein Security Team ist langfristig erfolgreicher, wenn es ein Self-Service-Portal bereitstellt und Entwickler sichere Konfigurationen selbst anwenden können, statt jede Firewall manuell zu konfigurieren.

Erste nächste Schritte

Plane den Übergang bewusst. Wenn externe Hilfe reduziert wird, kann die Leistung kurzfristig sinken, weil das Team die fehlende Fähigkeit erst wieder aufbauen muss. Dieser Zeitraum sollte begleitet werden: durch Pairing, klare Lernziele, begrenzten Support und explizite Erfolgskriterien für Eigenständigkeit.

Woran du das Muster sicher erkennst

Ist in der Rolle des Platform Enablement Teams klar beschrieben, dass Enablement, Self-Service und Fähigkeitsaufbau wichtiger sind als dauerhafte Ausführung für Feature-Teams?

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