Capability Building over Fixes

Systemproblem

Entwicklungs-Teams sind abhängig von dem "schnellen Fix" (Shifting the Burden / Fixes that Fail). Wenn ein Datenbank-Query langsam ist, baut der Lead Dev schnell einen Redis-Cache davor. Das Symptom verschwindet kurzfristig. Das Problem der Abhängigkeit: Das Team hat nicht die zugrundeliegende Fähigkeit (Capability) aufgebaut, saubere Index-Strategien zu schreiben. Beim nächsten Problem benötigen sie wieder den externen externe Hilfe oder ein neues Tool. Das System wird komplexer und fragiler und die Entwickler verlernen das konzeptionelle Denken.

Intervention

"Capability Building over Fixes" ist ein Management-Veto. Jeder Quick-Fix wird rigoros mit der Rückfrage begegnet: "Welche systemische Fähigkeit fehlt dem betroffenen Team, um dieses Problem gar nicht erst entstehen zu lassen?" Anstatt dem Junior-Dev den Bugfix-Pull-Request abzunehmen, wird der Bugfix blockiert, bis der Senior sich hinsetzt und mit dem Junior stundenlanges Pair-Programming für Unit-Testing absolviert. Die Intervention investiert Zeit, um die "Self-Service" oder "Lern-Infrastruktur" der Firma zu härten.

Erwartete Wirkung

Kurzfristig sinkt die Velocity deutlich ab (Worsening Before Better), da Entwickler nun Dinge grundlegend "richtig" reparieren müssen. Langfristig passiert das "Accelerate"-Wunder: Teams lösen nicht mehr nur Vorfälle in der Operations-Queue, sie automatisieren die Problemlösungswege deutlich weg (z.B. durch CI/CD Toolkits, Infrastruktur-as-Code Vorlagen). Die Support-Tickets an die Plattform-Architekten kollabieren gegen Null, da die Teams dezentral und eigenständig agieren können.

Nebenwirkungen und Risiken

Der Druck des Marktes auf das C-Level. "Capability Building" benötigt massenhaft Ressourcen und verlangsamt Release-Cycles um Wochen oder Monate. Wenn ein Start-Up mit dem Rücken zur Wand steht, ist das konsequente Bestehen auf "Fähigkeitsaufbau" problematisch (Startup fällt aus, bevor das Wissen skaliert ist). Die Kunst der Architektur ist es, klug zu bewerten, an welchem kritischen Engpass sich eine "Capability" lohnt und in welchen Legacy-Modulen ein "dreckiger Fix" aus wichtigem Pragmatismus akzeptabel ist.

Diagramm

Wann diese Intervention wirksam wird

In der DevOps-Forschung (DORA Metrics / Buch Accelerate) ist "Capability" das wichtige Mess-Fundament starker Organisationen. Schlechte Firmen haben einen Architektur-Katalog von einzuhaltenden "Technologien", gute Firmen haben einen Katalog von "Capabilities" (z.B. die Fähigkeit, automatisiert testen zu können, oder die Fähigkeit, das System binnen 1 Stunde recovern zu können). Tools ändern sich alle 2 Jahre; Capabilities bestehen über Dekaden hinweg.

Wodurch sich diese Intervention von anderen Hebeln unterscheidet

Die Intervention Delay-Aware Governance regelt die Feedbackschleifen des Managements in diesen Capability-Phasen, um zu verhindern, dass Manager überhastet reagieren, wenn die Performance während der Umstellungsphase absackt. Die pure Ersetzung von Heroentum durch Selbsthilfefähigkeit ist aber der Hebel von "Capability Building".

Wie du die Intervention sauber einleitest

Etabliere die "Do-It-For-Me" (DIFM) vs "Do-It-Yourself" (DIY) Governance bei Plattform-Teams. Plattform-Teams dürfen Entwickler-Tickets nur bearbeiten (DIFM), wenn ein akuter Produktionsvorfall vorliegt. Ihr einziger Job ist es ansonsten, APIs, Docs und Tools bereitzustellen, damit das Entwickler-Team das Problem eigenständig fixen kann (DIY).

Erste Umsetzungsschritte

Mache den Erwerb von Capabilities messbar. Erstelle eine IT-Skills-Heatmap oder setze DORA-Metriken (MTTR, Lead Time for Changes) als verbindliche OKRs ein. Ein Tribe-Leader wird nicht mehr dafür befördert, dass er pünktlich Releases ausliefert (während sein Team an Burnout leidet), sondern dafür, dass er die "Continuous Delivery Capability"-Skala seines Teams von Level 2 auf Level 4 gehoben hat.

Woran du Wirkung erkennst

Wird in den Retrospektiven exakt unterschieden, ob die Teams gerade in "Workaround"-Strukturen investieren (Local Fix), oder ob echte, nachhaltige Fähigkeiten im Engineering-Kern aufgebaut wurden, die auch bei Verdoppelung des Traffics standhalten?

Quellen

Peter Senge — The Fifth Discipline, Kap. 7: Shifting the Burden

Donella Meadows — Thinking in Systems, Kap. 6: Living in a World of Systems

Gene Kim et al. — Accelerate, Kap. 4: Capabilities (IT Revolution, 2018)