The Shirky Principle Explained
☕ Welcome to The Coder Cafe! Today, we explore a pattern I’ve run into more than once: teams created to solve a problem often end up preserving it. That’s the Shirky Principle, and I’ll illustrate it through two stories from my own experience. Get cozy, grab a coffee, and let’s begin!
Today’s Sponsor: Open models are ready. Most coding harnesses aren’t.
On DeepSWE, ten coding harnesses ran the same open model on 113 real GitHub issues. Results ranged from 3 solved to 62. CodeAF solved the most and paid the least per solved issue: 3.4× less than Claude Code, 4.8× less than OpenCode, 26.6× less than DeepSeek’s own harness. CodeAF is an open-source coding harness built for open models, and it works with closed models too.
Introducing The Shirky Principle
The Shirky Principle is an observation from Clay Shirky, which Kevin Kelly later named after him:
Institutions will try to preserve the problem to which they are the solution.
Shirky was mostly thinking about large institutions, but I think it applies just as well inside companies.
When I first read it, two stories from previous companies came to mind right away. Both were about internal teams whose job was to make hard things easy.
Story 1: The Platform Team That Was Supposed To Be Invisible
At a previous company, there was a platform team. Their mission was to provide a self-serve platform and shared frameworks so engineers could ship without worrying about infrastructure. In practice, it worked the other way around.
Every non-trivial action went through them: provisioning a resource, adapting the shared framework to a specific use case, getting a new environment, tweaking a CI/CD pipeline. I remember one slightly unusual infra request taking 4 weeks, which delayed the launch of a new feature.
Interestingly, the team wasn’t lazy or incompetent. They worked hard, shipped features, and felt they were delivering value, and to some extent, they were. But for every other team, they were a bottleneck with no way around it.
What bothered me most was that the more indispensable they became, the more resources they got. Nothing rewarded them for making themselves less necessary, which is pretty much what Shirky describes.
Story 2: The A/B Testing Team Nobody Could Work Around
The second story happened at a different company, where a dedicated team owned A/B testing. They built a custom experimentation platform, shipped a client library to integrate with it, analyzed and visualized results, and consulted with product teams. That sounds like a reasonable mandate.
Using the platform from the outside, though, was painful. The library was opaque and the data model convoluted. Defining an experiment, shipping it, and interpreting the results took several non-obvious steps, and the docs didn’t help much. Most of the knowledge lived in the team members’ heads. Even my first interaction with them required a meeting with three of their engineers and a PO.
So every product team that wanted to run an experiment had to pull in someone from the A/B testing team. Since each request took real effort, the team kept asking for more people to keep up. And because the platform never got simpler, demand never went down. Nobody had time to fix it; they were too busy handling requests.
By internal metrics, the team looked great: high utilization, a dependency for the whole company, and an easy case for more headcount every planning cycle. From the outside, it was the thing slowing down every experiment.
Why This Happens
In both cases, a team created to reduce friction for everyone else was measured by how much others depended on it. And people depend on a platform more when it’s hard to use without help. So over time, the incentives pulled the team toward keeping the friction it was supposed to remove.
I don’t think anyone did this on purpose. Nobody was thinking, “Let me keep this complicated so people still need me.” But a few things push in that direction:
Good docs, clean APIs, and simple self-serve flows take serious engineering work, and that work competes with new features, which are more visible and better rewarded.
Headcount and budget are often tied to ticket volume, support load, or number of users. Reducing those numbers looks bad at review time.
Knowledge ends up concentrated in a few people. Writing it down can feel like giving away leverage, whereas answering questions in 1:1s and ad-hoc meetings makes you hard to replace.
Leadership sees a team that’s always busy and in demand, and reads that as high performance. Few people ask whether all that demand is a sign that something is broken.
Put all of this together, and you get the Shirky principle in action. The team becomes the solution and the quiet guardian of the problem.
How to Spot It
Here are a few signals I’d watch for:
Headcount grows faster than adoption. If the team doubles but the number of teams shipping without them stays flat, something’s wrong.
The documented path is “just ping us.” If the answer always involves a person, it isn’t self-serve.
Onboarding takes days or weeks. Getting a new service live should take hours.
Support load is treated as a success metric. If a team is proud of handling lots of tickets, it’s worth asking why there are so many.
The team resists deprecating old paths, since every legacy flow and special case is another reason people need them.
One of these alone doesn’t prove much, but if you see several, it’s probably worth a closer look.
What to Do About It
The fix is to change what these teams are rewarded for. Instead of measuring how many people use a platform team, measure how many teams got what they needed without having to ask. That rewards simplicity and deprecation, and makes opacity and gatekeeping costly.
Some concrete ways to do it:
Measure how long it takes a new team to reach its first goal without help, and make it a top-level goal.
Track the ratio of self-serve actions to supported actions, and push it toward self-serve over time.
Reward the work of deprecating complex legacy paths instead of treating it as a chore.
Every quarter, ask product teams: “What did you have to ask the platform team for that you wish you could have done yourself?” Then fix those things.
None of this is complicated, but someone has to notice the problem first. And that’s hard when the team in question looks like one of the best-performing in the company.
AI is getting better every day. Are you? At The Coder Cafe, we serve fundamental concepts to make you an engineer that AI won’t replace. Written by a Google SWE, trusted by thousands of engineers worldwide.
Summary
The Shirky Principle: institutions will try to preserve the problem to which they are the solution.
It applies inside companies, especially to internal teams whose value is to make hard things easy.
The pattern is emergent, not malicious. Incentives reward visible demand, high ticket volume, and concentrated knowledge, not docs or self-serve flows.
Look for a gap: the team looks successful internally, but using them from the outside is painful.
Reward teams for how many others succeed without them, not for how many depend on them.
Resources
More From the Beyond the Code Category
Sources
Last Sip
❤️ Writing takes me hours. Caring takes seconds. Liking, commenting, or sharing this post helps more than you think.
☕ The Coder Cafe is free for everyone. If the content helps you, you can drop something in the tip jar by buying a coffee or upgrading to a paid subscription (same content, served with extra love).
📩 Want to reach 9,000+ engineers? Sponsor The Coder Cafe.
© 2026 Teiva Harsanyi
548 Market Street PMB 72296, San Francisco, CA 94104