The team that lives off the problem

The Shirky principle says that institutions will try to preserve the problem to which they are the solution. The line is Clay Shirky’s. Kevin Kelly gave it its name in 2010, and it usually gets explained with unions, newspapers and government agencies. It works the same way inside a software company, and it costs more there, because many of the problems could actually be solved, and there are boards, teams and tools whose budget depends on them staying unsolved. Nobody has to act in bad faith for this to happen, which is why it’s so hard to see from the inside.

Nobody sets out to preserve a problem

You’ve had a ticket open with the platform team for a week, and the change advisory board doesn’t meet until Thursday. Nobody on either wants to slow you down. But their budget, their headcount and their box on the org chart are there because you’re waiting, and nobody gets paid to ask what would become of them if you stopped. That’s what the principle describes. Kelly, when he named it, put it better: a company or an industry can become so dedicated to the problem it solves that, without meaning to, it keeps the problem alive.

Upton Sinclair had already said it of individuals in 1934: “It is difficult to get a man to understand something, when his salary depends upon his not understanding it.”

The industry that lives off the tax return

The clearest case in software is Intuit, the company behind TurboTax. In Denmark, Sweden and Spain, the tax agency already knows what you earned, because your employer and your bank report it, so it sends you a pre-filled return and you confirm it or fix it; Spain has done that since 2004. The US tax agency, the IRS, has the same data, and filing there still means hours of work and, for many people, paying for software. In 2013, ProPublica reported that Intuit had spent about $11.5 million on federal lobbying over five years, more than Apple or Amazon, and that its annual report to the SEC counted free government tax preparation among the risks to its business.

The deal that kept the IRS out of the way from 2003 on was that the industry would offer a free version to most taxpayers and, in exchange, the IRS wouldn’t build its own. In 2019, ProPublica found that TurboTax was hiding that free version from search engines. When the IRS finally built Direct File, its own program, it lasted two filing seasons. In October 2025, the Treasury announced that the IRS was suspending it: fewer than 0.5% of about 146 million returns had come through it, at a cost of at least $138 each. The same report recommended strengthening the industry’s program. Intuit is defending its business, which is what its shareholders ask of it.

The board that manages the risk

Inside a company, the principle doesn’t need lobbyists. A budget will do. The best-measured example is the change advisory board, ITIL’s CAB, which reviews every significant change before it reaches production. It’s created to reduce risk, and it exists as long as deploying is risky. According to DORA’s Accelerate State of DevOps report for 2019, organizations that required approval from a board or a senior manager outside the team were 2.6 times more likely to be low performers, and nothing suggested their changes failed less often. Low performers took one to six months to get a change into production; the best took under a day. Organizations, the report says, respond to problems with their releases by adding process and approvals, and “analysis suggests this approach will make things worse.” A board that managed to make deploys safe would run out of changes to approve, and I don’t know of one that was disbanded for it.

A platform team can end up in the same place. This week, Teiva Harsanyi wrote in The Coder Cafe about one that was set up as a self-serve platform for the other teams and became a bottleneck for every one of them: every environment and CI change went through it, and one unusual infrastructure request took four weeks and delayed a launch. They weren’t lazy or incompetent. “Nothing rewarded them for making themselves less necessary,” and “the more indispensable they became, the more resources they got.” If your company measures an internal team by the tickets it handles, it’s paying that team to keep the tickets coming.

The ones who made their problem go away

Google put a cap on its SREs’ operations work. The SRE book, from 2016, explains it in the chapter on toil, the manual, repetitive work of keeping a service running. The stated goal is to keep toil under 50% of each engineer’s time, because it “tends to expand if left unchecked and can quickly fill 100% of everyone’s time.” When a team goes over the cap, the excess goes back to the product teams, and the book makes clear that 50% is an upper bound: left to its own devices, an SRE team should end up with very little operational load.

Team Topologies, the 2019 book by Matthew Skelton and Manuel Pais, asks the same of the internal platform: the thinnest viable platform, as small as it can be while still speeding up and simplifying the work of the teams that build on it. Skelton says it could be a wiki page listing which of the cloud provider’s services you use and how, and that if that’s enough, you build nothing more.

Sometimes the problem gets removed from outside. In 2015, a one-year TLS certificate for a single domain cost an average of $178 at the five largest certificate authorities, according to the 2019 paper in which Let’s Encrypt’s team described its work. Getting one installed was manual and error-prone. The certificate authorities lived off that chore. Let’s Encrypt, run by a nonprofit founded by Mozilla and the EFF, among others, made it free and automatic, and by the end of 2025 it served 762 million websites; in much of the world, over 95% of page loads are now encrypted, up from 39% when it started.

Where it doesn’t hold

The principle is a tendency, and it’s a mistake to see it everywhere. Some problems don’t go away: someone has to be on call and someone has to review security, and that team isn’t living off the problem; it’s paid to keep it from blowing up. Nor is it an excuse to disband teams. If all that awaits whoever makes their problem disappear is a layoff, they’ll hide it, and who could blame them; Google got around that by giving its SREs engineering work when the operational load drops. The question that does work is what would happen to each team if its problem disappeared tomorrow. If the answer is that it would have nothing left to do, and nobody has thought about what it would do next, that team has reasons to keep the problem around, even if it never means to.

That question applies to whoever sells the solution too, and that includes me. kubelatch lives off a problem, access to Kubernetes clusters: who gets in, with what permissions and until when. The principle predicts that Picaporte Labs benefits from access staying messy and permissions lasting forever. All I can point to is how it’s built: a permission carries an end date, 30 days unless you pick another; cluster-admin and any other privileged access get 8 hours at most, and the rest can still be set to “Never.” That doesn’t make me immune, and a vendor saying they’re different is exactly what the principle expects to hear. If Kubernetes solved this out of the box, kubelatch would have less reason to exist, and I’d be fine with that.

Where to start

Pick an internal team, a board or a tool at your company and look at how it’s measured. If it counts tickets handled, changes approved or requests processed, try counting the opposite for a quarter: how many requests are no longer needed, how many changes ship without going through anyone, how much manual work has disappeared. Put a cap on operational work, as Google does, and decide beforehand what that team will do with the time it frees up, because without that the cap won’t hold.

Picaporte Labs is one person, in Spain. If your company has a team that lives off its problem, or one that has managed to make it go away, write to me and tell me how you measure it.