Success to the Successful

Beschreibung

Der Archetyp "Wer hat, dem wird gegeben" (Success to the Successful), in der Soziologie als Matthäus-Effekt bekannt, beschreibt eine Dynamik in geschlossenen Umgebungen wie Unternehmen. Zwei Parteien, etwa Tools, Teams oder Projekte, konkurrieren um einen begrenzten Ressourcenpool. Partei A erhält zu Beginn durch Zufall, Sichtbarkeit oder einen kleinen Startvorteil etwas mehr Erfolg. Wenn das Management diese frühen Metriken als eindeutigen Leistungsnachweis interpretiert, fließen weitere Ressourcen zu A. Dadurch wächst A weiter, während B weniger Gelegenheit erhält, das eigene Potenzial zu zeigen.

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 (Die benachteiligte Alternative): Weil beide Schleifen aus derselben begrenzten Quelle schöpfen, reduziert der Zugewinn von A die Möglichkeiten von B. Team B erhält weniger Budget, die Entwicklererfahrung verschlechtert sich, der Output sinkt und die nächste Bewertung bestätigt scheinbar die ursprüngliche Ressourcenentscheidung.

Architekturbeispiel

In einem Konzern konkurrieren zwei Cloud-Migration-Ansätze: klassisches Lift-and-Shift und cloud-native Serverless-Architektur. Das Lift-and-Shift-Modell gewinnt den ersten kleinen Proof of Concept, weil es für eine einfache Anwendung schneller umzusetzen ist. Daraufhin fließen mehr Cloud-Budget, Schulungen und Onboarding-Aufwand in diesen Ansatz. Das cloud-native Team erhält weniger Experimentierraum und kann anspruchsvollere Proofs of Concept nicht abschließen. In der Wahrnehmung des Managements wirkt es dadurch langsamer, obwohl sein Ansatz langfristig architektonisch wertvoller sein könnte.

Organisationsbeispiel

Ein sichtbarer "Star"-Entwickler erhält regelmäßig die interessantesten Aufgaben, weil frühere Ergebnisse positiv wahrgenommen wurden. Andere Entwickler übernehmen zunehmend Wartung, Bugfixing und weniger sichtbare Arbeit. Dadurch sinken ihre Chancen, ähnlich sichtbare Erfolge zu erzielen. Das Management bestätigt dann seine ursprüngliche Einschätzung und verstärkt die Ressourcenverteilung weiter. Langfristig verliert das Team Breite, Lernfähigkeit und Motivation.

Diagnosefragen

1.Haben wir intern "Star-Projekte", zum Beispiel einen GenAI-Piloten, die viele Ressourcen binden, während essenzielle Systemhygiene finanziell zu wenig berücksichtigt wird?

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 nicht 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 problematisches Gleichgewicht des Schreckens treiben.

Wie du vom Muster zur Reaktion kommst

Unterbrich die direkte Kopplung zwischen kurzfristigem Erfolg und zukünftiger Ressourcenzuteilung. Wenn Innovation, Feature-Lieferung, Refactoring und technische Schulden um dasselbe Budget konkurrieren, sollte die Organisation nicht ausschließlich nach kurzfristigem Output verteilen. Feste Kapazitätsanteile, geschützte Budgets oder längere Bewertungszeiträume können verhindern, dass das kurzfristig sichtbarere Thema dauerhaft bevorzugt wird.

Erste nächste Schritte

Ein überlegenes, aber langsamer anlaufendes Architektur-Framework benötigt wichtige Schonräume ("Safe to Fail"), ein klar 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