archetypes

Tragedy of the Commons

Locally reasonable use of a shared resource can overload the whole system when access rules, cost transparency, and responsibility are missing.

technologyorganization·4 min read

Why it matters

An archetype helps you recognize recurring dynamics behind local symptoms.

Next step

Next, move into a diagnostic method to test the suspected structure against observations.

~4 min read

Description

The "Tragedy of the Commons" describes a situation in which several actors use a shared resource without sufficiently regulating consumption, cost, and responsibility. For each individual team it can seem reasonable in the short term to use more of the resource: more builds, more logs, more data, more platform capacity. When all teams act this way, the shared resource becomes overloaded. The problem does not necessarily arise from bad intent, but from locally rational decisions inside an insufficiently designed governance structure.

Feedback Loops

Each actor has a local reinforcing loop: more use of the shared resource enables more local outcomes. The costs of that use are not directly visible to the causing team, but accumulate in the shared system. There, with delay, a balancing loop emerges: performance declines, maintenance increases, incidents become more likely, or governance has to intervene after the fact. In the end, even teams whose individual behavior was understandable are affected by the degraded shared resource.

Architecture Example

A central Elasticsearch cluster is provided without quotas, retention rules, or cost allocation. Team A stores large JSON payloads because that is convenient for its own analysis. Team B stores extensive debug logs because no direct cost is visible. Over time, storage needs, index size, and query costs increase. The cluster becomes slower or fails, even though each team acted understandably from its own local perspective. The missing limit on the shared resource becomes a system-wide risk.

Organizational Example

An unprotected frontend monolith can show the same structure. Many feature teams extend the same codebase, while responsibilities, review rules, and technical boundaries remain unclear. Each team integrates its logic where it is fastest in the short term. Over time, build times, coupling, and regressions increase. The shared codebase loses maintainability because local delivery goals have more influence than responsibility for the shared technical foundation.

Diagnostic Questions

1.Do we have critical shared services in our cloud architecture, such as Kafka, Redis, or API gateways, where consumption is complete anarchy and fair-use expectations are undocumented?

2.Where do we tolerate a management narrative of "just get to the goal fast" while completely neglecting to tell teams who will pay for cleaning up the traces they leave in shared systems?

3.Which essential platform technology is close to total collapse because fifty teams are doing their own thing on top of it without contributing any real capacity back to the owning team?

Diagram

How to Recognize the Pattern in Daily Work

The pattern becomes visible when a resource belongs to "everyone", but nobody is explicitly responsible for consumption, care, and further development. Appeals to reason are rarely enough because teams operate under local goals, deadlines, and incentives. Clear usage rules, transparent costs, technical guardrails, and visible ownership for the shared resource are more effective.

What Distinguishes the Pattern from Similar Dynamics

Compared with Limits to Growth, the limit does not arise only from one actor's own growth. It arises from the sum of many local usage decisions. The central issue is the missing connection between use, cost, and responsibility in a shared system.

How to Move from Pattern to Response

Connect use, visibility, and responsibility. Shared resources benefit from clear tenant boundaries, rate limits, quotas, API keys, retention rules, and FinOps transparency. If Team A uses a large share of Kafka, storage, or build capacity, that consumption should be visible and considered in planning. This protects the shared resource both technically and organizationally.

First Next Steps

Make shared resources visible. Teams that provide shared services should define usage data, limits, responsibilities, and escalation paths from the beginning. Architecture needs deliberate friction here: not as bureaucracy, but as feedback about real system costs.