Systems & Organizations
Stop Applauding Solo Wins
The badge goes to whoever ships first, so nobody's name is on the work of making the two versions agree.
2026-09-161 min read
A first-ship award is cheap to run and easy to justify: it names a date, a team, and a winner. What it quietly does is convert delivery into a tournament, where the reward depends on rank rather than on output. Contestants in a tournament have no reason to hand each other information, and every reason to keep a half-built component to themselves until it can be announced. The duplicated pipeline is the visible symptom. The invisible one is that integration work - reconciling two designs that both already exist - has no ship date, no announcement, and no winner attached to it.
Picture two groups inside one company, each given the same quarterly goal and each told the first working version wins the demo slot. Both build an ingestion path. Both write their own retry logic, their own schema, their own dashboard. Neither is hiding anything; they simply never had a reason to ask. The demo slot goes to whichever finishes on a Tuesday instead of a Thursday, and the losing version does not get deleted - by then something depends on it. Weeks later an engineer nobody is watching is writing the adapter that makes the two schemas agree, and that adapter is now a permanent part of the system.
That adapter is the real bill. It was created by an incentive, it is owned by no one, and it will be described in the next planning cycle as technical debt - as though it had accumulated on its own rather than been purchased, deliberately, with a badge.
Key insights
A first-ship reward is a rank-order tournament, and tournaments reliably suppress information sharing between the people competing in them.
Duplication is the cheap half of the cost; the expensive half is the permanent integration layer written to reconcile it.
Work that has no ship date cannot win a race, so it lands on whoever has the least leverage to refuse it.
Why it matters
Duplication shows up in a retrospective as wasted weeks; the adapter written to reconcile it never shows up at all, and it is the part you keep paying for.
If integration has no owner and no ship date, adding coordination rituals will not help - the reward is still pointing the other way.
Use this tomorrow
1Open the last two quarters of shipped features and count how many have a second component in the codebase doing substantially the same job, then write that number next to the name of whoever was recognized for shipping first.
2List every adapter, translation layer, and sync job in your system and write next to each one the team that asked for it; count the ones where you cannot name a requester, because those were bought by an incentive.
Go deeper
Melvin Conway observed that the systems an organization builds end up mirroring the communication paths inside it. A first-ship race is a direct intervention on those paths: it gives two groups a reason not to talk during exactly the window when a shared design would have been cheap. The duplicate components that result are not an accident of the architecture - they are an accurate picture of the org chart the incentive created. Redrawing the diagram afterward does not change what produced it.
Edward Lazear and Sherwin Rosen modelled pay based on relative rank rather than absolute output, and the tournament literature that followed is consistent about the side effect: when contestants' work is interdependent, competing on rank reduces cooperation and can make withholding help individually rational. Delivery work is unusually interdependent, which makes it close to the worst available fit for a rank-based prize. The fix is not to remove urgency but to move the prize onto something no single group can produce alone. Rewarding the first integrated release rather than the first shipped one leaves the speed intact and takes the payoff out of hoarding.
