archetypes

Drifting Goals

Teams passen ihre Standards schrittweise an unzureichendes Systemverhalten an, anstatt die Ursachen des Verhaltens zu verbessern.

teamsorganization·3 min Lesezeit

Warum relevant?

Ein Archetyp hilft dir, wiederkehrende Dynamiken hinter lokalen Symptomen zu erkennen.

Nächster Schritt

Gehe als naechstes in eine Diagnosemethode, um die vermutete Struktur mit Beobachtungen zu pruefen.

~4 Min. Lesezeit

Beschreibung

Der Archetyp "Drifting Goals" (Wandernde Ziele) beschreibt, wie Standards schrittweise abgesenkt werden, wenn die Lücke zwischen Anspruch und Realität über längere Zeit bestehen bleibt. Statt die Struktur zu verändern, die das gewünschte Ziel verhindert, passt die Organisation den Zielwert an die aktuelle Leistungsfähigkeit an. Dadurch wirkt die Abweichung kurzfristig kleiner, während der ursprüngliche Anspruch langfristig verloren geht.

Feedback Loops

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

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

Loop 2 (Zielanpassung): Das System reagiert träge oder widersetzt sich der Änderung (Delay oder Policy Resistance). Der Druck sinkt, indem das mentale Bild des Ziels abgesenkt wird: "So schlecht sind wir doch gar nicht."

Die zweite Schleife ist besonders wirksam, weil sie sofort Entlastung erzeugt: Das Ziel wird angepasst, und die wahrgenommene Lücke verschwindet. Gerade dadurch bleibt die strukturelle Ursache bestehen.

Architekturbeispiel

Ein Team strebt eine 99,9% Uptime-SLA an. Im ersten Quartal erreicht es nur 99,5%. Die Fehleranalyse ist aufwendig, architekturweite Refactorings wären anspruchsvoll. Das Management bewertet 99,5% für dieses Legacy-Modul als ausreichend. Im nächsten Quartal sinkt die Uptime weiter. Schrittweise wird ein ursprünglich anspruchsvoller Standard zu einem niedrigeren Normalzustand, ohne dass die technische Ursache behoben wurde.

Organisationsbeispiel

Ein Tribe führt eine "Zero Bug Policy" in seinen Sprints ein. Jeder Bug soll behoben werden, bevor neue Features gebaut werden. Weil das Produkt instabil ist, werden viele Fehler sichtbar und der Sprint verlangsamt sich deutlich. Um den Druck zu reduzieren, passen die Teams den Begriff "Bug" an: Einige Fehler werden nun als "Enhancements", "geringfügige Störungen" oder "Known Issues" behandelt. Das Ziel bleibt formal bestehen, verliert aber seine praktische Wirkung.

Diagnosefragen

1.Haben wir in letzter Zeit firmenweite Kennzahlen wie DORA, Uptime oder Security Ratings neu kalibriert, weil wir die alten Ziele nicht erreichen konnten?

2.Wo dulden wir im Code inzwischen Wartezeiten, etwa Build-Zeiten über 40 Minuten, die vor einigen Jahren noch als klares Problem gegolten hätten?

3.Sagen erfahrene Entwickler häufig: "Das ist in dieser Firma halt so"?

Diagramm

Wie du das Muster im Alltag erkennst

Das Muster wird sichtbar, wenn Qualitätsziele nicht mehr aus Kundenbedarf, Risiko oder technischer Notwendigkeit abgeleitet werden, sondern aus der zuletzt erreichten Leistung. Ziel-Drift geschieht selten in großen Sprüngen, sondern schrittweise über längere Zeit. Systemdenker verankern Zielbilder daher nicht nur an historischen Werten, sondern auch an externen Referenzen wie Best Practices, Branchenstandards oder klaren SLA-Verträgen.

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 starke Überlappungen mit Eroding Goals (oft nahezu synonym verwendet).

Wie du vom Muster zur Reaktion kommst

Behandle Ziel-Erosion als sichtbares Architekturthema. Wenn die Build-Pipeline regelmäßig länger braucht, sollte das früh diskutiert werden. Verankere Qualitätsziele nachvollziehbar und extern begründbar. Wenn Ziele aktuell unerreichbar sind, sollte das ehrlich als Defizit benannt werden; anschließend braucht es entweder einen Plan zur strukturellen Verbesserung oder eine bewusst dokumentierte Zieländerung.

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 klaren Kundenfokus unsere Architekturziele entsprungen sind, oder haben wir diese nur als interne Zielbilder angelegt?