Success to the Successful

Description

The archetype "Success to the Successful", known in sociology as the Matthew effect, illustrates the failure of fair competition inside closed environments such as a company. Two parties, such as tools, teams, or projects, compete for a limited pool of resources. Party A gets slightly more success early on through luck or a tiny starting advantage. Management reads the metrics naively: Project A is performing better than B, so we should invest more budget in A. A grows massively, while Project B is starved by the withdrawal of resources even though B might actually have been the technologically or architecturally superior option.

Feedback Loops

The engine consists of two competing reinforcing loops coupled in the shape of an inverted figure eight, effectively a zero-sum game.

Upper loop, the winner: Team A ships a feature slightly faster. It receives the success bonus of more budget and more freedom in allocating resources. More budget improves developer experience, which lets Team A ship even faster.

Lower loop, the loser: Because both loops draw from the same fixed source, Team A's gain is Team B's loss. Team B gets less budget, its developer experience becomes miserable, output drops, and management cuts its budget even further in the next review. The decline becomes almost impossible to stop.

Architecture Example

Inside a large company, two cloud migration frameworks compete: old-school lift and shift versus cloud-native serverless. The lift-and-shift model wins the first small proof of concept because it is basically a copy operation. Enterprise architects celebrate and allocate large cloud budgets, training, and onboarding to lift and shift. The cloud-native team receives no credits for serverless experiments, cannot finish more demanding proofs of concept, and therefore appears slow and useless to management. Three years later the company runs five hundred inefficient legacy VMs in AWS while the more modern architecture path is effectively dead. The apparently successful project has pushed the organization into an architectural dead end.

Organizational Example

Consider the star developer versus the rest of the team. One developer ships highly visible but extremely dirty code and becomes the hero. Management rates that person as a top performer and gives them all the exciting R&D work. The other developers are pushed into bug-fixing and maintenance hell, because management denies them any chance at visible growth work. As they drown in support tasks, the star only shines brighter, because they are exempt from the mess their code created. Over time the company loses its other talented developers, who were unfairly assigned to the losing track.

Diagnostic Questions

1.Do we have internal star projects, such as a GenAI pilot, that are allowed to absorb every resource while essential system hygiene work is left to dry up financially?

2.Are we evaluating competing architecture approaches by their structural value, or simply by which one management historically watered with more money at the beginning?

3.Are we unintentionally breeding rockstar programmers by shielding them from bug fixing and support tickets, turning them into the winners of a dysfunctional culture?

Diagram

How to Recognize the Pattern in Daily Work

The key cybernetic rule for architects in this pattern is simple: never confuse structural success with system-coupled starting advantage. When managers launch internal competitions and say "let the best ideas win," an unmanaged system usually rewards not the best ideas but the ones with the fastest feedback rhythm. Real design work means decoupling strategic goals from competitive survival-of-the-fittest dynamics whenever promising options require a longer incubation delay.

What Distinguishes the Pattern from Similar Dynamics

*Success to the Successful* is fundamentally a zero-sum pattern. What one side gains, the other side loses in real resources. That makes it very different from *Escalation*, where both actors keep investing in their own buildup and drift toward a dangerous balance of terror.

How to Move from Pattern to Response

Break the connection. If you have two competing architectural duties, for example innovation and features versus refactoring and technical debt, never place a shared budget in front of them and say "deliver, then you get more." Decouple the entities, for example through a fixed twenty percent technical debt quota in every sprint, to break the zero-sum competition. Whoever decouples the rules breaks the loop that would otherwise crown the easier short-term topic forever.

First Next Steps

A superior architecture framework that starts more slowly needs protected space, a guaranteed baseline budget, and a longer evaluation delay before it is judged against an established but short-lived framework.

How to Recognize the Pattern with Confidence

Do we critically examine in retrospectives whether the so-called high-performing teams in release-train metrics truly excel because of craftsmanship, or whether they are still surfing on a wave of historical budget and resource preference from 2021?

Sources

The Systems Thinker: Success to the Successful

Daniel Kim - Systems Archetypes at a Glance

Wikipedia: Matthew Effect