Tragedy of the Commons

Every request looked reasonable

A manual review team can sustainably resolve 600 cases a day without sacrificing decision quality.

Three product teams are running experiments. One adds about 120 cases a day, another adds 180 and a third adds 250. Each increase looks manageable in its own plan, and each team gets the conversion benefit if its experiment works, while nobody owns the total demand entering the queue.

When the experiments overlap, incoming work exceeds the review team's recovery rate, the queue grows and legitimate customers wait more than a day. Analysts work late, then begin making faster, weaker decisions, and some high-risk cases pass because the people meant to inspect them are exhausted.

No single team made an absurd request. The system failed because the reasonable requests were never managed as one combined demand.

This is the Tragedy of the Commons: a shared resource runs down because each person gets most of the benefit from using more, while everybody shares the cost of it running low.

The teams need to see how much review capacity exists, how quickly it recovers and what each experiment is allowed to consume.

Look beneath the queue at the resource being used up

The queue is the thing everyone sees late. Underneath it is reviewer attention at a level where people can still make accurate decisions.

A simple way to reason about any commons is:

resource tomorrow = resource today + regeneration - total withdrawals

For a fishery, renewal means fish reproducing. For a support team, it includes finishing work, resting, training and getting better tools. For a database’s limited set of connections, it means a connection becoming free after a request finishes.

It does not matter that each request looked reasonable on its own. When total use keeps exceeding renewal, quality falls long before the resource looks empty.

That changes the intervention. More reviewers will only buy time if every team still has an unlimited claim on the new capacity.

The teams could manage the shared capacity like this:

• Define sustainable throughput together with a quality threshold.
• Give teams normal usage budgets rather than an unlimited claim on the queue.
• Preserve reserve capacity for incidents and vulnerable customers.
• Expose total demand, age and error rates to every contributing team.
• Let reviewers slow or pause intake when agreed safety thresholds are crossed.
• Charge experiment plans for the review work and remediation they create.
• When an experiment adds a new block of demand, require it to fund automation, staffing or another way to restore the capacity it consumes.

Local experiments can still move quickly when every team can see the limit and knows when temporary extra use must be repaid or stopped.

Where shared capacity runs out elsewhere

Ecology and economics. A pasture, fishery or aquifer can support repeated use up to a regenerative limit. Each participant receives the immediate value of one more animal, catch or litre, while the loss from depletion is shared. Yet collapse isn't inevitable. Elinor Ostrom's research showed that user communities can successfully govern common property with workable boundaries, locally fitted rules, monitoring and credible ways to resolve violations. Her research matters here because communities have managed shared resources without leaving access completely open or handing the resource to one private owner. The 2009 Nobel Prize press release.

Software and systems. Online services rely on limited shared pools: the number of database requests they can handle at once, background jobs they can run and requests another provider will accept. Every request may be valid, but too many at once can fill the pool. Everything slows, failed requests are tried again and those retries add still more work. Teams can limit how much enters, make new work wait, share capacity fairly and reserve room for emergencies. More computing capacity can help, but it costs money and may simply move the shortage somewhere else.

Organisations and product design. Customer trust, reviewer attention, brand tolerance and support capacity are shared across product teams. One team can gain a visible metric improvement while delayed failures enter queues owned elsewhere. The harm arrives later and in another team's queue, so a normal product plan rarely counts it. Shared budgets, a clear cost for review work and authority to pause intake make each team account for what it adds.

The common pattern is that many people use the same finite capacity, each person sees their own benefit first and the damage becomes visible only after total use has crossed the limit.

Make the commons visible before it fails

Use this model when several actors share a resource, individual use is locally valuable and exclusion or ownership is weak.

Before adding capacity, write down:

1. The stock: What finite resource is actually being consumed?
2. The users: Who can withdraw from it?
3. The unit: How can use be compared without pretending every case is identical?
4. The renewal rate: How quickly does the resource recover under acceptable quality?
5. The depletion signal: What changes before collapse becomes obvious?
6. The usage rights: Who may spend how much, under which conditions?
7. The reserve: What capacity is protected for shocks or people with few alternatives?
8. The replenishment duty: Who restores what the system consumes?
9. The exception path: How can a legitimate unusual need be heard without erasing the boundary?

This gives people a visible limit, rules for using it and a way to raise a real exception. "Please be considerate" is not a capacity plan.

Shared ownership can work when the rules are real

People sometimes use this model as proof that shared ownership must fail. Shared ownership can work, but only when the users agree on boundaries, monitor use and can act when someone breaks the rules.

Central quotas can also create damage. Teams may hoard allocations, politically powerful groups may receive the best access, and a slow approval body may prevent useful experiments. In emergencies, rigid limits can protect the spreadsheet while harming the person the system exists to serve.

Not everything shared is a commons. Knowledge can become more useful as more people use it, and one more reader does not use it up. What may be scarce is the attention and maintenance needed to keep that knowledge accurate.

Use this model only when one person's use leaves less for someone else. Set the rules with the people who use and restore the resource, keep an appeal path and show when temporary extra use will be paid back.

Nearby models

Negative Externality describes a cost imposed on someone outside the decision. The Tragedy of the Commons is a more specific structure: repeated individual use depletes one shared stock. Pollution can be an externality without exhausting a jointly used capacity; overfishing is both.

Theory of Constraints asks which part is currently holding up the whole system. The review queue may be that part. The Tragedy of the Commons asks why several teams keep using the same limited review capacity without any shared rule for how much it can handle or recover.

Can total use stay below what the resource can restore, and who acts when it doesn't?