Success to the Successful

Beschreibung

Der Archetyp "Wer hat, dem wird gegeben" (Success to the Successful), in der Soziologie als Matthäus-Effekt bekannt, illustriert das Scheitern von fairer Konkurrenz innerhalb von geschlossenen Umgebungen (wie einer Firma). Zwei Parteien (Tools, Teams, Projekte) konkurrieren um einen limitierten Ressourcenpool. Partei A erhält am Anfang durch puren Zufall oder minimale Startvorteile minimal mehr Erfolg. Das Management liest Metriken dumm ab: "Projekt A performt besser als B, also pumpen wir mehr Budget in A". A wächst gigantisch, während Projekt B durch Budgetentzug zu Tode gehungert wird, obwohl B potenziell technologisch oder architektonisch die überlegene Wahl gewesen wäre.

Feedback Loops

Die Engine besteht aus zwei konkurrierenden *Reinforcing Loops*, die in Form einer umgekehrten Acht (einem Zero-Sum-Game) gekoppelt sind.

Obere Schleife (Der Gewinner): Team A liefert ein Feature minimal schneller. Es erhält den "Erfolgs-Bonus" (Mehr Budget, freiere Ressourcenwahl). Mehr Budget führt zu besserer Entwicklererfahrung, wodurch Team A noch schneller liefert.

Untere Schleife (Der Verlierer): Weil das System Budget aus einer fixen Quelle abschöpft, geht das Geld von A von Team B ab. Team B hat weniger Budget. Ihre Entwickler-Erfahrung wird grässlich. Ihr Output sinkt. Daher kürzt das Management ihr Budget beim nächsten Review noch weiter. Ein unaufhaltsamer Abstieg.

Architekturbeispiel

In einem Konzern konkurrieren zwei Cloud-Migration-Frameworks, "Alte Schule (Lift&Shift)" VS "Cloud Native (Serverless)". Das Lift&Shift-Modell gewinnt den ersten kleinen POC-Wettstreit um eine simple Anwendung (weil es einfach ein dummer Kopierprozess ist). Die Enterprise Architects jubeln und allokieren massive Cloud-Budgets, Schulungen und Onboarding-Tickets für Lift&Shift. Das Cloud-Native Team erhält keine Cloud-Credits für Serverless-Lambdas, kann keine komplexen POCs beenden und wirkt aus Sicht des Managements langsam und nutzlos. Drei Jahre später betreibt die Firma 500 Legacy-VMs extrem ineffizient in AWS, während das moderne Architektur-Framework tot ist. Das scheinbar erfolgreichste Projekt hat die Firma architektonisch in die Zukunftslosigkeit katapultiert.

Organisationsbeispiel

"Star"-Entwickler vs der Rest des Teams. Ein Entwickler liefert einen hochsichtbaren, aber extrem schmutzigen Code ab ("The Hero"). Das Management bewertet diesen Entwickler als "Top Performer" und überträgt ihm alle "spannenden R&D Aufgaben". Die anderen Entwickler rutschen rein in die Bugfixing- und Wartungshölle (das Management verweigert ihnen die Chance auf neue Glanz-Aufgaben). Weil die Entwickler in Bugs ersticken, leuchtet der Star-Entwickler mit seinem dreckigen Code nur noch heller, da er von den Wartungen freigesprochen wurde. Die Firma verliert durch diesen Loop langfristig alle anderen talentierten Devs, weil sie zu Unrecht auf das Verlierer-Gleis rangiert wurden.

Diagnosefragen

1.Haben wir intern "Star-Projekte" (z.B. GenAI Pilot), die blind alle Ressourcen abgreifen dürfen, während die essenzielle System-Hygiene (Datenbasis aufräumen) finanziell massiv verdurstet?

2.Beurteilen wir die Leistung zweier konkurrierender Architekturansätze wirklich nach ihrem strukturellen Mehrwert, oder einfach nur danach, auf welchen Ansatz das Management initial historisch mehr Gießkannen-Geld geschüttet hat?

3.Züchten wir unbewusst "Rockstar Programmierer", indem wir sie durch Bevorzugung von Bugfixing und Support Tickets systematisch entkoppeln und damit zum Gewinner einer dysfunktionalen Kultur machen?

Diagramm

Wie du das Muster im Alltag erkennst

Der wichtigste kybernetische Leitsatz für Architekten bei diesem Muster ist: "Verwechsle strukturellen Erfolg niemals mit systemgekoppelter Startbevorzugung". Wenn Manager interne Wettbewerbe ausrufen ("Lasst die besten Ideen gewinnen"), gewinnen in einem ungesteuerten System meist nicht die besten Ideen, sondern die mit dem schnellsten Feedback-Rhythmus, der dann verstärkend wirkt. Die eigentliche Aufgabe des Designs ist es, strategische Ziele künstlich vom kompetitiven "Survival of the Fittest" abzukoppeln, wenn das Gewinner-Potenzial eine hohe *Inkubationszeit* (Delay) benötigt.

Wodurch sich das Muster von ähnlichen Dynamiken unterscheidet

Success to the Successful ist eine Zero-Sum Thematik (Was der eine gewinnt, verliert der andere physisch ressourcenmäßig). Es grenzt sich stark von *Escalation* ab, in welchem beide Akteure in Rüstung investieren (keine Limits verhandeln, sondern externe Budgets blind hochskalieren) und dadurch in ein gefährliches Gleichgewicht des Schreckens treiben.

Wie du vom Muster zur Reaktion kommst

Umbrich die Verbindung! Wenn du zwei konkurrierende Architektur-Pflichtenbündel hast (Innovation/Features vs. Refactoring/Tech Debt), dann stelle niemalsteilig ein Budget dafür hin und rufe "Liefert, dann gibts mehr!". Entkoppele die Entitäten (z.B. feste 20% Tech-Debt Quota pro Sprint), um den Zero-Sum Wettbewerb brachial zu sprengen. Wer die Regeln entkoppelt, bricht den Loop, der andernfalls unweigerlich das kurzfristig leichtere Thema als ewigen Champion pusht.

Erste nächste Schritte

Ein überlegenes, aber langsamer anlaufendes Architektur-Framework benötigt absolute Schonräume ("Safe to Fail"), ein hart gesetztes Grundbudget und ein längeres Delay bei der Bewertung gegen ein etabliertes, kurzlebiges Framework.

Woran du das Muster sicher erkennst

Überprüfen wir kritisch in Retrospektiven, ob die "High Performer" Teams in der Release-Train-Messung wirklich durch exzellentes Handwerk glänzen, oder ob sie heimlich auf einer Welle historischer Budget- und Ressourcenbevorzugung des Jahres 2021 reiten?

Quellen

The Systems Thinker: Success to the Successful

Daniel Kim — Systems Archetypes at a Glance

Wikipedia: Matthew Effect