The Tragedy of the Corporate Commons

April 4, 2026 SupportTrenches Systems, Processes & Resilience 5 minutes

Why shared knowledge, documentation, and tools always decay unless someone actively defends them.

Picture the company wiki on a random Tuesday. It launched two years ago as the single source of truth - clean architecture diagrams, battle-tested runbooks, and troubleshooting flows that actually worked. Everyone cheered at the kickoff. Leadership called it "our knowledge superpower."

Fast-forward to now. The same wiki is a digital landfill. Half the pages are outdated by three major releases. The troubleshooting guide for the most common outage still references a database that was decommissioned in 2023. Search results are 90 percent noise. Your best power horse 🐎 just spent forty-five minutes reconstructing the answer from memory and Slack screenshots because the "official" doc was worse than useless.

You've seen this movie. We all have.

I watched it happen live at a mid-sized SaaS company that prided itself on being "process mature." We built a beautiful shared knowledge base right after a painful outage season. The power horses poured real effort into it - clear language, working examples, even a little dry humor in the edge-case sections so the next person wouldn't want to throw their laptop out the window.

Then the tragedy began.

Nobody owned it.

Sales reps started dumping half-finished notes from customer calls: "Check the log for error XYZ (more details later)." Product managers added shiny new feature overviews that were accurate for exactly eleven days. The sloths - those lovable beige creatures who move at the speed of bureaucracy - discovered they could copy-paste a ticket comment, hit "publish," and call it documentation. No one ever went back to fix, test, or delete the garbage. Why would they? Updating the commons cost them their own time and delivered zero personal points on the performance review.

Within eighteen months the wiki had become a collective shrug. The power horses kept it alive in their heads instead. One of them told me, deadpan, "I don't read the docs anymore. I just remember who wrote the good ones and ping them directly. Faster that way."

That's the Tragedy of the Corporate Commons in pure form.

Shared resources - wikis, runbooks, internal tools, even the Slack channels full of tribal knowledge - work great when everyone takes only what they need and leaves them better. But humans being humans, most take what they need and leave the maintenance to "someone else." The cost of decay is spread across the entire team (slow onboarding, repeated mistakes, midnight heroics), while the cost of fixing it lands squarely on the one person dumb enough to care.

So the power horses either burn out defending the commons single-handedly or quietly stop caring and start keeping their best fixes in private notes. The sloths thrive. Leadership wonders why knowledge transfer is so terrible and why the new hires keep breaking the same things.

The fix is brutally simple and annoyingly unsexy.

Someone has to own the damn thing. Not "the team." Not "we should all contribute." One accountable human who has permission - and skin in the game - to delete the cruft, reject the half-baked contributions, and enforce a minimum standard. That person becomes the quiet guardian of the commons. They don't get applause in all-hands. They get the satisfaction of watching repeat incidents drop and new engineers ramp up in weeks instead of quarters.

I've seen it work twice in my career. Both times it was the same pattern: a power horse quietly took ownership, turned on edit notifications, and started treating the wiki like their own backyard - mowing the lawn, pulling the weeds, occasionally telling a sloth, "Nice try, but this belongs in the trash folder." Morale among the real engineers went up. Turnover among the horses went down. The sloths grumbled a bit and then found easier places to graze.

Leadership takeaway, straight from the trenches: if you want elite support instead of expensive chaos, stop treating documentation and tools as optional group activities. Assign an owner, call them knowledge champions or janitors, give them real time and real authority, and measure them on whether the commons actually stays useful.

Because left undefended, every shared resource in your company will decay at exactly the speed of human laziness. The only thing that slows it down is someone willing to stand guard and say, "Not on my watch."

The power horses notice when that guard shows up. They stay longer. They ship better work. And suddenly the "knowledge superpower" stops being a punchline and starts being a competitive advantage.

It's not glamorous. It's just the difference between a team that remembers everything and one that keeps relearning the same expensive lessons. Choose wisely.

Knowledge ManagementDocumentationIncentivesCorporate CultureRetention