You know that shared staging environment that's been "temporarily broken" for (random period →) three weeks? The one where deployments fail randomly, tests are flaky, and nobody's quite sure who's supposed to fix it? The one where every team points to every other team when asked who owns it?
Congratulations, you've discovered the software industry's favorite pastime: turning shared resources into digital wastelands where good infrastructure (and the vast ecosystem of libs, helpers and commons ) goes to die.
Welcome to the "Tragedy of the Commons"—the archetype that explains why your shared database looks like a flea market designed by committee, and why that "company-wide" monitoring dashboard shows everything except what anyone actually needs to know.
Understanding the "Tragedy of the Commons"
The "Tragedy of the Commons" is one of the most predictable patterns in complex systems, yet we keep falling into it like it's a surprise every time. Here's how it works: You have a shared resource that benefits everyone when used responsibly. Each individual user makes rational decisions that benefit them personally—decisions that make perfect sense in isolation. But when everyone makes these same rational decisions simultaneously, the collective result is that the shared resource gets degraded or destroyed.
The irony? Everyone loses, including the people who were just trying to optimize their own outcomes. In software systems, this pattern shows up wherever we have shared infrastructure, shared code, or shared responsibilities. The resource might be a database, a deployment pipeline, a monitoring system, or even team expertise. The pattern is always the same: individual optimization leads to collective degradation, and somehow nobody saw it coming (even though we've seen it a thousand times before).
This is one of the main ways of getting from a forrest to the desert (Kent Becks article here).
The Shared Database Disaster
Let’s take this totally hypothetical scenario which never , ever happens in real life: a "shared analytics database" that multiple teams use for reporting. It starts innocently—a few teams need to run some queries, and setting up individual databases seems like overkill.
Team A needs to store user events, so they create a few tables with reasonable indexes. Team B needs to track inventory, so they add their tables—also reasonable. Team C needs real-time dashboards, so they add some automated queries that run every minute. Still fine.
Then Team D needs to store high-frequency trading data. Team E wants to run machine learning models. Team F decides to use it for session storage because "it's already there." Team G adds a nightly ETL job that locks tables for an hour.
Fast-forward six months: The database is a graveyard of abandoned tables, conflicting indexes, and mysterious queries that nobody remembers writing. Performance is terrible because every team optimized for their own use case. The schema is a Frankenstein's monster of naming conventions. And when someone suggests "maybe we should clean this up," everyone suddenly has very important meetings to attend.
Nobody set out to create a monster. Each team made perfectly rational decisions for their individual needs. But the collective result? A shared resource that serves nobody well.
The Greatest Hits of Commons Destruction
The Shared Environment Shuffle: Everyone deploys to staging → Nobody owns staging stability → Staging becomes unreliable → Everyone bypasses staging → Production becomes the new staging environment
The Shared Code Library Decay:
Everyone adds utility functions → Nobody refactors the library → Library becomes bloated and slow → Everyone vendors their own copies → Library becomes abandoned
The Shared Monitoring Tragedy:
Everyone adds their alerts to the dashboard → Dashboard becomes overwhelming → Important alerts get lost in noise → Everyone builds their own monitoring → Critical issues go unnoticed
The Shared Infrastructure Neglect:
Everyone uses the Jenkins server → Nobody upgrades or maintains it → Server becomes unreliable → Everyone sets up their own CI → Infrastructure becomes a maze of redundant systems
The Documentation Commons:
Everyone needs docs → Nobody maintains the wiki → Information becomes outdated → Everyone creates their own docs → Knowledge gets siloed and lost
The Psychology of "Not My Job"
Here's what makes this pattern so persistent: it's always rational to let someone else handle the maintenance. If you spend time cleaning up the shared database, you're essentially doing free work that benefits everyone else more than it benefits you. If you don't clean it up, maybe someone else will, and you can focus on your own deliverables.
This creates what economists call a "free rider problem"—everyone benefits from someone maintaining the commons, but nobody has a strong individual incentive to be that someone. The more people sharing the resource, the more diffused (smart word™) the responsibility becomes, and the less likely anyone is to step up.
Even when everyone recognizes the problem, it's hard to coordinate a solution. Who should take the lead? How do you split the work fairly? What if you invest effort in fixing something and then your team gets reorganized next quarter?
It is not a nice place to be in …
The Compound Effect of Neglect
What starts as minor degradation accelerates over time. Each small compromise makes the next one easier to justify. Each workaround becomes a permanent solution. Each "quick hack" becomes a load-bearing hack that nobody dares to touch.
The shared resource doesn't just get worse—it becomes actively hostile to improvement. The technical debt accumulates to the point where fixing anything requires understanding years of context that exists only in scattered Slack threads and the fading memories of people who've since moved on.
Eventually, the commons becomes so degraded that using it is more painful than building your own alternative. So teams start creating parallel systems, which fragments the organization's knowledge and creates new silos. The thing that was supposed to promote sharing ends up causing more isolation than if you'd never shared anything at all. Quite a in the gut punchline.
Architect's Alert 🚨
The tragedy isn't that shared resources get overused—it's that they get under-maintained. The solution isn't to avoid sharing (that leads to wasteful duplication and isolated silos). The solution is to structure ownership and incentives so that maintaining the commons becomes someone's explicit job, not everyone's implicit hope.
Remember: A shared resource without a dedicated owner is just a tragedy waiting to happen. Good intentions and team guidelines aren't enough to overcome structural incentive problems. If you want something to be well-maintained, make sure someone's success depends on maintaining it.
And at the end of the day, there might be a good case for going separate ways for some functionalities that only on the surface have a slight semblance.
Breaking the Tragedy Cycle
Want to prevent your shared resources from becoming digital wasteland? Stop relying on collective goodwill and start designing for individual incentives:
Make Ownership Explicit
Assign a specific team to own each shared resource
Make their success metrics depend on the health of that resource
Give them authority to make decisions about usage and access
Create Usage Contracts
Define clear expectations for how teams can use shared resources
Establish consequences for teams that degrade shared systems
Build monitoring that shows who's impacting performance
Design for Self-Service
Make it easier to use shared resources correctly than incorrectly
Automate the common maintenance tasks
Provide tools that prevent rather than detect problems
Align Incentives with Outcomes
Reward teams for improving shared systems, not just using them
Make shared resource health a part of performance reviews
Create rotation systems so everyone has skin in the game
Your Turn
Look around your current systems: What shared resources are slowly degrading because everyone assumes someone else is maintaining them? Which databases, environments, or services are stuck in the "everyone's responsibility is no one's responsibility" trap?
The tragedy of the commons isn't inevitable—it's just what happens when we design systems that rely on everyone to do something that benefits them less than it costs them. The good news? Once you recognize the pattern, you can design around it.
What shared tragedy is your team currently starring in?
Another example: Shared QA. When get rid of dedicated QA teams and adopted quality as a mindset.
I have a post scheduled in a few weeks that covers this topic.
Good stuff.