Most of Your Work Shouldn't Exist

A platform team I worked with a few years ago had 14 people and six weeks of work already waiting. They were drowning. The ask was straightforward: two more developers, one more QA, a dedicated DevOps engineer. The math seemed obvious. More demand than capacity. Hire to close the gap.

Before the headcount request went through, I asked if we could look at their intake. We pulled three months of tickets and sorted them by type.

62% of their incoming work was not new work. It was rework. Clarifications on tickets that had been "resolved" but hadn't actually fixed the problem. Escalations from teams that couldn't use the platform because the documentation didn't match the behavior. Bugs reintroduced by patches to previous bugs. Support requests generated by a confusing self-service portal that had been shipped fast to meet a quarterly goal.

The team was not understaffed. It was processing its own failures.

The thing nobody measures

The phenomenon has a name. John Seddon called it failure demand: demand caused by a failure to do something or do something right for the customer.

A customer calls to open a bank account: that's value demand. The customer calls back because the account was opened incorrectly: that's failure demand. Both calls take time, consume resources, and show up in the metrics as "work handled." Only one created value. The other is pure waste, generated by the organization itself.

Across service organizations, failure demand runs at 40-60% of total demand. In local government contact centers and care services, it reaches 80%. Police forces: over 75%. Not outliers. The norm.

In software, nobody calls it failure demand, but you'd recognize it. A bug report means someone shipped something broken. A support ticket about confusing UX means someone designed for a deadline, not a user. A reopened ticket means someone marked it "done" when it wasn't. A feature request that's really a workaround means someone never understood the actual need. Each of these generates work. None of it is new value. All of it was avoidable.

Pull up your team's intake. Categorize each item honestly: is this someone wanting something new, or is this someone coming back because something upstream failed? The number will be higher than anyone in the room estimated. Managers typically guess 10-15% before measurement, then discover 40-60% or more.

Why hiring makes it worse

The instinct when demand exceeds capacity is to add capacity. More people, more teams, more budget. The logic feels obvious: if we have 100 units of work and 80 units of capacity, we need 20 more units of capacity.

But if 60 of those 100 units are failure demand, you don't have a capacity problem. You have a system that generates the demand it then struggles to process. Hiring more people to handle failure demand is increasing the system's capacity to fail.

Efficiency programs have the same problem. Process optimization, automation, better tooling: all useful, but applied to failure demand, they optimize the processing of waste. You get faster at doing work that shouldn't exist.

And the cycle reinforces itself. Targets, standardized procedures, and functional silos constrain how workers can respond. Constrained workers can't resolve the full need, so customers come back. The returning customers consume capacity, which makes everything feel overloaded. Managers respond to overload with more targets, more standardization, more cost-cutting, which further constrains workers. Failure demand increases. The organization runs harder every year, invests in "efficiency," and performance still declines. The treadmill is of its own creation.

Why nobody sees it

Failure demand is invisible because the metrics can't tell the difference. A call center manager sees "10,000 calls handled this week." They don't see "6,000 of those calls were customers calling back because we failed them." Cases processed, tickets closed, stories delivered: every unit of failure demand registers as work accomplished. And when work is fragmented across departments, nobody connects the dots. I've seen organizations where a single customer need touched four teams, generated eight tickets, and produced eight "resolved" statuses. The dashboard showed eight wins. The customer had one unresolved problem.

But the real engine of invisibility is targets. When call handlers are measured on average handling time, they close calls quickly rather than resolving them. Quick closure creates the conditions for the customer to call back. The target designed to increase efficiency generates the demand that overwhelms capacity. When developers are measured on velocity, they push stories to "done" before they're genuinely done. The reopened ticket next Sprint is a new unit of failure demand, and a new unit of velocity when it's closed again.

The part nobody wants to audit

What makes failure demand uncomfortable: it is not caused by bad people. It is caused by how the work is designed. The targets, procedures, handoffs, and org structures that management put in place are what generate the demand. Workers behave rationally given their conditions. When conditions prevent them from resolving a need the first time, they don't. The customer comes back. More work appears.

Yes, some failure demand is unavoidable. Complex organizations produce errors. But most organizations have never measured the ratio, so they have no idea how much is avoidable and how much isn't. They're treating the whole pile as "the work" when a large fraction of it is self-inflicted.

Portsmouth City Council found out what the ratio looked like. Their housing repairs service was slow, expensive, and constantly behind. When Seddon's team studied the demand, 74% was failure demand. Tenants calling back because repairs weren't done. Repeat visits because the wrong parts were brought. Follow-up complaints because nobody had shown up within the 28-day target. The work was organized around functional handoffs: one team took the call, another scheduled the visit, another dispatched the repair crew, another ordered parts. Each handoff was a chance to lose information, and each lost piece of information generated another call, another visit, another complaint.

They redesigned around the tenant's actual need: get the repair done, right, on the first visit. Gave repair workers the authority to schedule their own time. Let them carry common parts. Removed the functional handoffs. Average completion dropped from 40 days to 11. First-visit resolution hit 90%. Failure demand fell from 74% to under 10%. And here's the part that should keep every hiring manager awake: overall demand dropped by more than 30%. Not because fewer things broke. Because the organization stopped generating the callbacks, the re-visits, and the complaints that had been most of the work all along. They didn't need more capacity. They had been drowning in work they'd created themselves.

Police forces in the Midlands found the same thing: over 75% failure demand. After redesign, they doubled urgent response capacity without adding a single officer.

Before you hire

There is a reason that platform team had six weeks of work waiting. It wasn't that they were slow. It wasn't that they were understaffed. It was that more than half of the work arriving at their door was generated by their own organization: previous shortcuts, poor documentation, a self-service portal designed for a quarterly metric rather than a user need, and a handoff structure that fragmented ownership so thoroughly that no single person could resolve a request end-to-end.

When we addressed the top three sources of failure demand (the portal UX, the documentation gap, and the fractured handoff between two sub-teams), their effective backlog dropped by 40% in eight weeks. No new hires. No new tools. They stopped generating the work they were drowning in.

The exercise is simple and the results are uncomfortable. Take your team's last two weeks of incoming work. For each item, ask: is this someone wanting something new, or is this someone coming back because something upstream failed?

Count the ratio.

That number is your organization's self-inflicted tax on its own capacity. Most teams never count it, because counting it means admitting the system you designed is generating the demand you're struggling to meet. Hiring is easier. Hiring means the problem is out there: not enough people. Auditing means the problem is in here: the way we set this up. Nobody's career was ever threatened by a headcount request. Plenty have been threatened by asking why the work exists in the first place.