Empty storefronts, full kiosks: when too many people can veto a deploy, your paved road goes empty and the work routes around you. It looks like a chaos problem. It is the opposite, and another approval step is a larger dose of the disease.
Walk down a commercial street in Moscow in the mid-1990s and you would have seen something that looked like a mistake. The real storefronts, the ones with walls and doors and actual floor space, sat empty and dark. On the sidewalk directly in front of them, flimsy metal kiosks overflowed with goods and shoppers. Same street, same foot traffic, same customers holding the same rubles. The good space was vacant. The bad space was booming. Demand was obviously there, because the kiosks proved it. So why would anyone sell soda out of a booth on the pavement when there was a perfectly good shop sitting empty right behind them?
The economist Michael Heller had the answer, and in 1998 he turned it into a theory that has been quietly useful ever since. He published it in the Harvard Law Review under a title that tells you he knew he had found something structural: “The Tragedy of the Anticommons.” The shops were empty, he argued, because post-Soviet privatization had scattered the rights to each one across a crowd of owners. One party held the right to sell. Another controlled the lease. A local authority controlled the permit to use the space. Someone else had a claim on the revenue. Each of them could say no, and none of them alone could say yes and make it stick. A merchant who wanted the shop had to assemble agreement from every one of them, and any single holdout could kill the deal. A merchant who wanted to run a kiosk had to assemble almost nothing. So the good resource sat idle and the inferior one carried all the trade, not because anyone chose that outcome but because the structure of ownership made the good outcome too expensive to arrange.
Heller's name for this was the anticommons, and he defined it with a lawyer's precision: a situation in which multiple owners each hold a right to exclude others from a scarce resource, and no one holds an effective privilege of use. When too many people can say no, the thing goes underused. It is the exact mirror image of the failure everyone already knows. In the tragedy of the commons, a shared resource has no effective owner, so everyone overuses it and it collapses from overuse: the overfished sea, the trampled pasture. In the tragedy of the anticommons, a resource has too many owners with veto power, so no one can use it and it dies from neglect: the empty shop. One is death by crowd. The other is death by committee. And here is the part that matters for anyone who runs a software platform. From the inside, the two failures can feel identical, and the fixes are opposites.
We have written on this blog about the commons version of the problem, the governance of a genuinely shared resource where the danger is overuse and the cure is a good set of rules. This is the other one. It is the failure almost nobody diagnoses correctly, because from where you sit it looks exactly like the commons failure it is not. Picture the platform team. Throughput is low. The sanctioned way to ship, the paved road you spent two quarters building, sees hardly any traffic. Releases are slow and rare. Someone in leadership looks at this and reaches the natural conclusion: things are out of control, we lack governance, we need process, we need an approval step, we need a board. That instinct is correct medicine for a commons problem and poison for an anticommons one. If your paved road is empty because too many people already hold a veto over it, adding another approver is not treatment. It is a larger dose of the disease.
This is usually the point where an essay asks you to take its word. This particular claim, it turns out, has been measured, repeatedly and at scale, by the DORA research program, the same body of work that gave the industry the four delivery metrics everyone now benchmarks against. DORA looked at what happens when organizations route changes through a formal external approval, a change advisory board or a senior manager sitting outside the team that wrote the code. The finding is blunt. External approval was negatively correlated with the things you want more of: lead time, deployment frequency, and how quickly you recover when something breaks. Heavier approval, slower delivery, slower recovery. That much you might have guessed. The part you could not have guessed is the punchline. DORA found no evidence that a more formal, external review process was associated with lower change fail rates. None. The board that exists to make releases safer did not, in the data, make them safer.
Sit with that, because it is Heller's tragedy translated into an engineering metric. The change advisory board is a party that can say no to the resource without ever using it. It holds a right to exclude and no privilege of use, which is the precise definition of an anticommons owner. And the “no correlation with change fail rate” line is the whole theory proven in a single clause. The organization paid the full cost of the exclusion, the slower delivery and the queued work and the standing meetings, and bought no safety with it. That is underuse with nothing to show for it. The empty shop, rendered as a deployment pipeline.
It gets worse, and the mechanism DORA proposes is worth stating carefully, because they offer it as a likely explanation rather than a measured chain of cause and effect. When shipping requires clearing a heavyweight approval, teams respond the way anyone responds to a toll. They batch. They bundle more change into each release so they have to pay the toll less often. Bigger batches, shipped less frequently, mean a larger blast radius every time something goes out, which plausibly raises the very failure rate the board was convened to reduce. The approval process built to make releases safe quietly restructures your release process into a riskier shape. The veto does not merely slow the work. It changes what the work looks like, and not for the better.
Now the honest part, the one that keeps this from being a tidy story you should distrust on sight. The most famous prediction the anticommons theory ever made did not come true. In the same year Heller published his Moscow paper, he and Rebecca Eisenberg argued in Science that biomedical research was heading for disaster: so many overlapping patents on genes and research tools that no one would be able to assemble the rights to actually invent anything. A patent thicket, an anticommons in the lab. It was a compelling forecast. And in 2003, a team of researchers, Walsh, Arora, and Cohen, went and checked it against reality. They conducted seventy in-depth interviews with lawyers, scientists, and managers across pharma, biotech, and universities, and they asked, in effect, has this actually stopped you? Of the fifty-five respondents who spoke to the question, fifty-four could not point to a single project that had been stopped by the difficulty of getting agreement from multiple patent owners. In the domain where the anticommons was most confidently predicted, it essentially did not bite.
The theory is contested for exactly this reason. The legal scholar David Teece went so far as to call the tragedy of the anticommons a fallacy. So let me state the claim I am actually making, which is narrower than the hype. I am not telling you the anticommons is real and lurking behind every org chart. I am telling you that underuse caused by too many vetoes is a distinct failure mode with its own opposite cure, and that it is systematically mistaken for its noisier twin. And the reason the biotech anticommons did not bite turns out to be the most useful thing in the whole story. It did not bite because people routed around it. They licensed, they invented around the patents, they moved work offshore, and, quietly, they ignored patents they judged unlikely to be enforced. The blockage was real. The researchers simply refused to be blocked by it, through channels that never showed up in any official record.
In platform engineering, routing around the veto has a name. We call it shadow IT. And this is where the diagnosis inverts on you. An anticommons that is not visibly blocking anything is not therefore healthy. It may simply be getting bypassed, and the bypass is the symptom you should be reading. Nobody files a ticket that says “the change board stopped us from shipping.” They just find the other way. They ship through the exception process, or the manual hotfix path, or the one service that never got onboarded to the pipeline, or a script on somebody's laptop. Which lands us back on the sidewalk in Moscow, and shows us what that street was really telling us. The shops were not empty because demand had vanished. And the crowded kiosks out front were never evidence that the system worked. They were evidence that it did not, and that everyone had quietly agreed to route around it.
So here are two tests you can run, both sharper than “do we need more governance or less.” The first comes straight from Heller's definition. Count the parties who can say no to a deploy but do not themselves use the deploy path. Exclusion rights without a privilege of use. That is your anticommons population, and the external approval board is its purest specimen. Not everyone who touches an approval belongs on the list, which matters, because the answer here is emphatically not to abolish review. A peer reviewer reading your diff is inside the stream of work, a user of the very path they are approving. DORA's own recommendation, once you remove the external board, is to keep the review and move it into the team, as peer review during development. The distinction that does the work is exclusion-with-use versus exclusion-without-use. Keep the reviewers who ship. Count the ones who only gate.
The second test: go look for the kiosk. If your sanctioned throughput is low but the work is somehow still getting done, the veto is not preventing the work. It is relocating it somewhere you cannot see and cannot govern, which is worse than either shipping cleanly or being honestly blocked. And a caveat, because this is not an argument against all control. Some vetoes are legitimate and should stay exactly where they are. A regulatory sign-off with legal force behind it, a security review on a genuinely sensitive path, these hold a right to exclude for reasons worth the cost, and no diagnostic should talk you out of them. The point is not that no one should ever be able to say no. The point is that every additional person who can say no, and who never has to live with the resource they are gating, moves you a step further down the road from the crowded pasture toward the empty shop. And most teams, convinced they suffer from too little order, never even stop to count.
One last piece of honesty, since the DORA findings are correlational and a good skeptic should insist on it. It is possible that struggling organizations adopt approval boards in response to their troubles rather than being harmed by them. Cause and effect are genuinely hard to untangle here, and the strong version of the claim would be overreach. But you do not need the causal arrow settled to run the two tests, because they do not ask what caused what. They ask something simpler. How many people can say no to this. How many of them ever actually use it. And where is the work really going. If the sanctioned path is empty and there is a dirt track worn into the grass beside it, you do not have a chaos problem that another rule will fix. You have the opposite problem, the one that has been hiding in plain sight since a row of dark storefronts in Moscow sat staring across the pavement at the crowds buying from booths pitched in front of them.
Count the parties who can say no to a deploy but never use the deploy path. That is your anticommons population.
The same trap waits for agent pipelines: a gate that only excludes, bolted on outside the stream of work, slows delivery and buys no measured safety, and the work quietly routes to a path you cannot govern. The fix is not to abolish review but to keep the reviewers who ship and move verification into the flow. The Agent Trust Stack is verification built that way: provenance and checks that travel with the work rather than a board convened beside it, so an agent's output is gated by something that uses the path it approves. Keep the reviewers who ship; count the ones who only gate.
Read the Theory of Agent Trust
Install the whole stack: pip install agent-trust-stack · npm install agent-trust-stack