Capability Building over Fixes

Systemproblem

Entwicklungs-Teams sind süchtig nach dem "schnellen Fix" (Shifting the Burden / Fixes that Fail). Wenn ein Datenbank-Query langsam ist, baut der Lead Dev schnell einen Redis-Cache davor. Der Schmerz ist kurzfristig weg. Das Problem der Sucht: 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 Retter oder ein neues Tool. Das System wird immer komplexer, 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 brutal ab (Worsening Before Better), da Entwickler nun Dinge extrem fundamental "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 massiv 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 radikale Bestehen auf "Fähigkeitsaufbau" tödlich (Startup crasht, 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 absolutem Pragmatismus akzeptabel ist.

Diagramm

Wann diese Intervention wirksam wird

In der DevOps-Forschung (DORA Metrics / Buch Accelerate) ist "Capability" das absolute 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 in Panik verfallen, 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 das Haus buchstäblich brennt. 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 harte 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)