Drifting Goals

Beschreibung

Der Archetyp "Drifting Goals" (Wandernde Ziele), auch bekannt als "Boiled Frog Syndrome" (Der gekochte Frosch), beschreibt einen hochgefährlichen Verfall von System-Standards. Er tritt auf, wenn eine schwer schließbare Lücke zwischen dem gewünschten Idealzustand (Soll) und der schmerzhaften Realität (Ist) existiert. Anstatt die immense Energie aufzuwenden, um das zähe System nach oben zum Ideal hin zu korrigieren, beginnt die Organisation stattdessen (oft unbewusst), das eigentliche Ideal schrittweise nach unten an die deprimierende Realität anzupassen.

Feedback Loops

Der Mechanismus basiert auf zwei konkurrierenden ausgleichenden Schleifen (Balancing Loops).

*Loop 1 (Gewünscht):* Entdeckt einen Fehler, tätigt eine harte Korrekturmaßnahme, zieht die reale Performance hoch an das Soll.

*Loop 2 (Der Verräter):* Das System wehrt sich (Delay oder Policy Resistance). Die Leute frustrieren. Loop 2 löst den Druck, indem er ganz simpel das mentale Bild des Ziels absenkt ("So schlecht sind wir doch gar nicht").

Das teuflische: Loop 2 erfordert null physikalische Anstrengung und wirkt augenblicklich. Der Frosch merkt nicht, dass das Wasser kocht, weil die Temperatur in winzigen Graden steigt.

Architekturbeispiel

Ein Team strebt eine 99.9% Uptime SLA an ("Wir müssen exzellent sein"). Im Q1 fallen sie auf 99.5% ab. Die Fehleranalyse ist zäh, architekturweite Refactorings wären anstrengend. Das Management winkt ab: "Na ja, für dieses spezielle Legacy-Modul sind 99.5% auch schon extrem gut im Industriestandard." (Absenkung des Ziels). In Q2 knallt es erneut, die Uptime sinkt auf 98.0%. Die Entwickler zucken die Schultern: "In diesem dreckigen Monolithen ist das völlig normal. Solange wir nicht unter 95% fallen, brennt nichts." Die Architekturstandards sind gestorben, weil die Lügen der Entwickler lauter waren als ihr Handwerksethos.

Organisationsbeispiel

Ein Tribe führt "Zero Bug Policy" in seinen Sprints ein. Jeder Bug muss fixiert werden, bevor neue Features gebaut werden. Weil das Produkt extrem wackelig aufgebaut wurde, schlagen hunderte Bugs auf. Der Sprint bleibt drei Wochen am Stück stehen, das Business tobt. Um dem emotionalen Druck zu entfliehen, passen die Teams den Begriff "Bug" an: Plötzlich werden Bugs in "Enhancements" und "Geringfügige Störungen" und "Known Issues" umdeklariert, die man auch später machen kann. Das Ziel wurde linguistisch pervertiert und wegrationalisiert.

Diagnosefragen

1.Haben wir in letzter Zeit unsere firmenweiten Kennzahlen (DORA, Uptime, Security Ratings) einfach klammheimlich neu kalibriert, weil wir die alten Ziele nicht erreichen konnten?

2.Wo dulden wir im Code inzwischen Wartezeiten (Build-Zeiten > 40 Minuten), über die wir vor drei Jahren noch auf der Stelle rebelliert hätten?

3.Sagen unsere Senior Devs häufig den Satz: "Das ist in dieser Firma halt so, gewöhn dich ran." (Der Frosch fängt an zu kochen).

Diagramm

Wie du das Muster im Alltag erkennst

Diese Dysfunktion zu knacken, erfordert immense mentale Stärke in der Führung. Die Organisation sucht immer den Pfad des geringsten Widerstands. Die "Drift" deines Qualitätsstandards geschieht nicht in Riesenschritten, sondern stetig über Jahre. Systemdenker verankern ihr Soll-Bild daher nicht an historischen Werten der letzten drei Monate (denn die verwässern bereits), sondern koppeln ihre Ziele tiefgreifend an externe, unverrückbare Marker (Best Practices, Branchenführer, hart kodierte SLA-Verträge mit Strafzahlungen).

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

*Drifting Goals* ist das Spiegelbild von *Escalation*. Bei der Eskalation treiben Teams die Anstrengung immer weiter nach oben. Bei *Drifting Goals* wird das Spielfeld immer flacher gemacht, bis keiner mehr rennen muss. Es hat außerdem extreme Überlappungen mit *Eroding Goals* (oft nahezu synonym verwendet).

Wie du vom Muster zur Reaktion kommst

Akteure müssen "Goal Erosion" (Ziel-Erosion) den Krieg erklären. Wenn die Build-Pipeline plötzlich 5 Minuten länger braucht, muss sofort ein Alarm geschlagen werden. Mache die Verankerung (Anchoring) der Qualitätsziele extern, absolut und felsenfest. Wenn Ziele unerreichbar sind, muss das als ehrliches Defizit kommuniziert und hingenommen ("Wir sind gerade schlecht") oder die Basis-Architektur umgerissen werden, anstatt sich selbst in die Tasche zu lügen.

Erste nächste Schritte

Verhindere "Alert Fatigue" in euren Observability-Tools. Wenn Entwickler Warnmeldungen nur noch wegklicken, weil "das immer kurz so aufpoppt", dann hat das System erfolgreich das mentale Qualitätsziel der Entwickler reduziert.

Woran du das Muster sicher erkennst

Können wir heute noch mit derselben Schärfe erklären, aus welchem harten Kundenfokus unsere Architekturziele entsprungen sind, oder haben wir diese nur als interne Papiertiger angelegt?

Quellen

The Systems Thinker: Drifting Goals

Daniel Kim — Systems Archetypes at a Glance

Wikipedia: System Archetypes