Warum Teams aufhören, sich zu kümmern
In stagnierenden Softwareprojekten verändert sich nicht nur die Architektur des Systems.
Auch das Verhalten der Teams verändert sich.
Entwickler, die früher aktiv Verbesserungen angestoßen haben, beginnen plötzlich schwierige Bereiche zu vermeiden.
Diskussionen über Architektur verschwinden.
Probleme werden akzeptiert, statt gelöst.
Dieser Zustand wirkt oft wie Gleichgültigkeit.
In den meisten Fällen ist er jedoch das Ergebnis eines längeren Lernprozesses innerhalb der Organisation.
Kernaussage
Teams hören selten aus Desinteresse auf, sich zu kümmern.
Sie hören auf, weil sie gelernt haben, dass Verbesserung keine Wirkung hat oder zu hohe Risiken erzeugt.
Der Verlust der Wirksamkeit
Motivation in Engineering-Teams entsteht häufig aus einem einfachen Zusammenhang:
Verbesserung → sichtbarer Effekt.
Beispiele:
- eine bessere Struktur reduziert Komplexität
- Refactoring erleichtert zukünftige Änderungen
- Architekturentscheidungen verbessern die Wartbarkeit
Wenn dieser Zusammenhang über längere Zeit ausbleibt, entsteht ein anderes Lernmuster:
Verbesserung → Konflikt oder Risiko.
Typische Erfahrungen:
- Architekturvorschläge werden ignoriert
- Refactoring wird zugunsten kurzfristiger Features gestoppt
- technische Probleme bleiben dauerhaft ungelöst
Teams lernen daraus, dass Engagement wenig Wirkung hat.
Anpassung statt Gleichgültigkeit
In dieser Situation reagieren Entwickler häufig rational.
Statt Energie in erfolglose Verbesserungsversuche zu investieren, passen sie ihr Verhalten an.
Typische Anpassungen sind:
- schwierige Diskussionen vermeiden
- nur notwendige Änderungen durchführen
- riskante Verbesserungen unterlassen
- Fokus auf kurzfristige Aufgaben legen
Nach außen wirkt dies wie fehlendes Engagement.
Tatsächlich handelt es sich oft um organisatorische Anpassung.
Die Rolle von wiederholter Frustration
Ein einzelnes gescheitertes Verbesserungsprojekt führt selten zu Resignation.
Problematisch wird die Situation, wenn sich bestimmte Erfahrungen wiederholen:
- Verbesserungsversuche werden blockiert
- strukturelle Probleme bleiben ungelöst
- Entscheidungen erscheinen nicht beeinflussbar
Mit jeder Wiederholung sinkt die Bereitschaft, Energie in Veränderungen zu investieren.
Fluktuation als Folge
In vielen Projekten reagieren Entwickler unterschiedlich auf diese Situation.
Ein Teil des Teams verlässt das Projekt oder das Unternehmen.
Andere passen sich an und bleiben.
Dadurch entsteht häufig ein Team, das gelernt hat, mit den Einschränkungen des Systems zu leben, statt sie zu verändern.
Diese Anpassung stabilisiert das bestehende System weiter.
Warum dieser Zustand schwer zu erkennen ist
Von außen kann ein Team weiterhin produktiv wirken:
- Aufgaben werden erledigt
- Meetings finden statt
- Releases werden durchgeführt
Was fehlt, ist die Energie für strukturelle Verbesserung.
Architektur wird nicht mehr aktiv weiterentwickelt.
Probleme werden akzeptiert statt hinterfragt.
Zusammenhang mit Stable Failure
Das Verhalten von Teams ist ein zentraler Faktor im Zustand Stable Failure.
Sobald Teams aufhören, strukturelle Verbesserungen anzustoßen, verliert ein System einen wichtigen Mechanismus zur Selbstkorrektur.
Das Projekt kann weiterhin betrieben werden – doch seine Fähigkeit zur Weiterentwicklung nimmt zunehmend ab.
Bedeutung für technische Führung
Technische Führung besteht nicht nur darin, Architektur zu gestalten.
Sie besteht auch darin, ein Umfeld zu schaffen, in dem Verbesserungen möglich und wirksam sind.
Wenn Teams erleben, dass ihre Initiativen Wirkung haben, entsteht Engagement.
Wenn Verbesserungsversuche regelmäßig scheitern, entsteht Anpassung.
Langfristig entscheidet diese Dynamik darüber, ob ein System sich weiterentwickelt – oder langsam in stabile Dysfunktion übergeht.