Growth and Underinvestment

Beschreibung

Der Archetyp "Wachstum und Unterinvestition" (Growth and Underinvestment) ist der Firmen-Killer schlechthin im Cloud-Zeitalter. Ein Produkt oder System wächst rasend schnell. Irgendwann stößt dieses Wachstum an Kapazitätsgrenzen (System wird langsam, Bugs häufen sich). Die völlig logische kybernetische Antwort wäre: Massiv in die Systemkapazität investieren (Refactoring, bessere Server, tiefes Onboarding). Doch das Management scheut die Kosten, wartet "erstmal ab", oder investiert viel zu spät. Da die Leistung schlecht bleibt, springen Kunden ab, das Wachstum stoppt und sinkt. Das Management sieht die sinkenden Zahlen und fühlt sich im Nachhinein bestätigt: "Gut, dass wir nicht so viel investiert haben, das Wachstum ist ja zurückgegangen!". Ein selbstmörderischer Fehlschluss.

Feedback Loops

Die Struktur folgt dem klassischen Limits to Growth Muster. Ein Reinforcing Loop verstärkt den Erfolg. Dieser aktiviert jedoch zügig einen Balancing Loop, weil Performance-Limits den Erfolg abbremsen. Die Besonderheit liegt in einem dritten Ast: einem Verzögerungs-Loop, der die Grenze eigentlich erweitern sollte, etwa durch Investitionen in Hardware oder Architektur. Wenn das Management Signale fehlinterpretiert oder das Delay in der Aufrüstung zu groß ist, wirkt dieser dritte Loop nicht rechtzeitig. Die Leistungsabnahme schwächt das weitere Wachstum.

Architekturbeispiel

Eine Firma baut ein riesiges Data-Warehouse für ML-Training. Die Architektur ist simpel gestrickt und wächst phänomenal (es läuft erfolgreich). Je mehr Abteilungen das DWH nutzen, desto schlechter werden die Latenzen der Queries (das Performance-Limit kickt ein). Anstatt ein deutliches Re-Architecture Budget freizugeben (Migration auf eine echte Streaming-Architektur oder Data Mesh), befiehlt das Management "erstmal nur das Nötigste zu patchen". Latenzen bleiben schlecht. Daraufhin migrieren die Fachabteilungen frustriert auf ihre eigenen Excel- und lokalen SQL-Spiegel (Nutzer wandern ab). Die Nutzung des DWH sinkt. Das DWH-Team verliert seine Budgets, weil "die Plattform ja eh weniger genutzt wird".

Organisationsbeispiel

Ein aufstrebendes Startup skaliert die Feature-Teams immens (mehr Devs = stärkere Feature-Factory). Was sie versäumen, ist die Unterinvestition in Developer-Experience (DX) und CI/CD-Pipelines (die unsichtbare Kapazität). Das Management will Budgets nur für "sichtbare Features", nicht für unsichtbare "Plattform-Hygiene" ausgeben. Irgendwann steigen die Build-Zeiten stark an, Pull-Requests liegen Wochen rum, Entwickler weichen frustriert aus oder kündigen (Das Wachstum kollabiert). Das Management schiebt den Misserfolg auf "schlechte Arbeitsmoral", Thesen wie "wir dürfen Plattform nicht vernachlässigen" werden lachend abgelehnt, weil die Metriken ja schon im Sturzflug sind.

Diagnosefragen

1.Deuten wir gerade einen Rückgang von Nutzungskennzahlen fälschlicherweise als "Weniger Nachfrage am Markt", obwohl wir eigentlich durch schlechte Performance und furchtbare Stabilität selbst die Kunden verjagt haben?

2.Haben wir eklatante Delays (Verzögerungen) beim Freigeben von Budget für Basis-Infrastruktur-Umbauten?

3.Reden wir uns ein, dass wir die Architektur erst refactoren "wenn wir groß und profitabel sind", ignorieren aber, dass wir ohne das Refactoring nicht groß und profitabel werden können?

Diagramm

Wie du das Muster im Alltag erkennst

Diese Dysfunktion zeigt schonungslos, dass "Visionen" allein ein System nicht retten. Wachstum erfordert vorausschauende Weichenstellung in grundlegende Kapazität (Architektur-Erweiterung), lange bevor das operative System qualmt. In IT-Projekten ist das klassische Under-Investment das Versäumnis, früh in Automatisierung, Observability und Entkopplung zu investieren. Wenn die Architektur-Problemsituation da ist, hast du nicht mehr die organisatorische Bandbreite (Kapazität), um den Hebel umzuwerfen.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Growth and Underinvestment ist de facto die detailliertere, wirtschaftliche Erweiterung des reinen Limits to Growth Archetyps. Es beleuchtet den menschlichen "Ausweich-Reflex" (das Nicht-Erkennen, dass man sich in Kapazität investieren müsste).

Wie du vom Muster zur Reaktion kommst

Wenn du die Warnzeichen liest (Qualität sinkt, Metriken brechen leicht ein, Frust steigt), existiert nur eine legitime Handlungsoption: Du musst exzellente Warn-Metriken etablieren und auf Verdacht in die Struktur investieren, auch wenn die Kurve schon stagniert. Für Architekten bedeutet das: Verteidige das "Plattform-Engineering-Budget" mit Zähnen und Klauen. Plattformarbeit ist kein Luxus-Abfallprodukt, sie ist die einzige physische Kapazitätserweiterung, die zukünftiges Wachstum überhaupt erst ermöglicht.

Erste nächste Schritte

Verbinde Kapazitätsindikatoren starr mit Geschäftssignalen. Wenn die Nutzerzahl M übersteigt, blockiert das Architekturboard im Master-Review automatisch jedes geplante Feature X, biss Architektur-Investment Y sichergestellt ist.

Woran du das Muster sicher erkennst

Tappen wir in die Falle, den Misserfolg eines schlecht gewarteten internen Tools darauf zu schieben, "dass es ja eh keiner haben wollte", anstatt zuzugeben, dass es durch unser Under-Investment schlichtweg unbenutzbar langsam wurde?

Quellen

The Systems Thinker: Growth and Underinvestment

Peter Senge — The Fifth Discipline, Kap. 6

Daniel Kim — Systems Archetypes at a Glance