Failure Demand: The Hidden Tax on Engineering Productivity in the AI Era

Before measuring how much AI improves your engineering team’s productivity, understand how much of its capacity is being consumed by unplanned work.

During a recent HyperscaleCEO cohort meeting, one of our amazing portfolio CEO’s was wrestling with a question that many technology leaders are now asking: how do you measure the productivity gains from introducing AI into your engineering organisation?

They wanted to understand how much more efficient the organisation was becoming, and whether the investment in AI was translating into faster development and greater engineering output.

But as we worked through the problem, applying first-principles thinking and working backwards from the outcome he wanted to achieve, we uncovered something much more fundamental: approximately 50% of the engineering team’s time was being consumed by unplanned work, a significant proportion of which involved fixing issues with software that had already been released.

This immediately changed the nature of the conversation. Before we could properly understand the productivity gains from AI, we needed to understand why so much of the team’s capacity was being diverted from planned work in the first place.

It also brought us to a concept from systems thinking that I believe every CEO leading a software business should understand: “Failure demand”.

Understanding Failure Demand

The concept of failure demand is associated with systems thinker John Seddon, who describes it as demand created when an organisation fails to do something correctly, or fails to do something a customer needs, in the first place.

A simple call-centre example illustrates the problem. Imagine a team receiving 1,000 calls every day, of which 200 are not resolved successfully, requiring those customers to call back the following day. The team now has 1,200 calls to handle: the 1,000 new calls plus the 200 repeat calls generated by yesterday’s failures.

If this pattern continues, the organisation finds itself devoting an increasing proportion of its capacity to resolving problems that should have been dealt with correctly the first time, while simultaneously trying to keep up with the demand coming through the door each day.

The instinctive response might be to employ more people to handle the additional workload, but this simply increases the cost of operating the system without necessarily addressing the reason the extra work exists. The more valuable question is why those 200 customers weren’t helped properly in the first place, and what needs to change to prevent the same problems from recurring.

That is the essence of failure demand: work that is generated because something has not worked as it should have done, creating additional demand that consumes capacity without delivering equivalent additional value.

The same problem exists in software engineering

In software engineering, the consequences can be particularly significant because a single issue can generate work across multiple teams and disrupt delivery well beyond the time required to fix the original problem.

A defect in released software may require an engineer to abandon planned development, investigate the issue and produce a fix, while another team waits for the dependency to be resolved and a release is delayed. If the underlying cause is never addressed, the organisation may find itself dealing with the same class of problem repeatedly, each time consuming capacity that could otherwise have been devoted to building new capabilities and delivering value to customers.

Of course, not all unplanned work is failure demand, and some production incidents, urgent customer requests and unexpected technical problems are an inevitable part of running a software business. The important distinction is between the work that is genuinely necessary and unavoidable, and the work that is repeatedly generated because the organisation has failed to address the underlying causes of its problems.

The true cost of a failure lies in the additional work, delays and disruption it creates throughout the system.

Why this matters in the AI era

Returning to our CEO’s dilemma, if approximately 50% of the engineering team’s time is consumed by unplanned work, how can you accurately measure the productivity gains from AI?

Suppose AI enables engineers to complete certain coding tasks 30% faster. That would be a meaningful improvement in the efficiency of those activities, but it doesn’t automatically follow that the organisation will deliver 30% more valuable software, because the overall outcome depends on much more than the speed at which code can be produced.

The team still has to deal with unplanned work, alongside the maintenance, architectural improvements, security requirements and other activities necessary to operate a reliable software business. AI might help engineers diagnose and resolve defects more quickly, releasing capacity for planned work, but if the underlying causes of those defects remain, the organisation may simply become more efficient at treating the symptoms rather than eliminating the problem.

This is particularly important when companies are investing heavily in AI and trying to establish whether those investments are improving the economics of their business. Without a clear understanding of where engineering capacity is going, it becomes extremely difficult to distinguish the genuine productivity gains from AI from the constraints and inefficiencies that continue to limit the organisation’s overall performance.

Why adding more engineers may not solve the problem

When an engineering organisation struggles to deliver against its commitments, the instinctive response is to assume that it needs more people, more capacity and a larger budget, and there are certainly situations where additional resources are the right answer.

However, before approving another hiring plan, I think CEOs should ask themselves a more fundamental question: how much of the capacity they already have is being consumed by work that might not exist if the organisation had solved the original problems properly?

Adding more engineers may help absorb the workload, but it will not automatically eliminate recurring defects, incomplete requirements, fragile architecture or unreliable release processes. If the underlying system continues to generate unnecessary work, the business risks increasing its engineering costs without achieving a proportionate increase in the amount of valuable software it delivers.

This is one of the reasons I believe leaders need to be careful about treating every productivity challenge as a resource problem. Sometimes the constraint is the amount of unnecessary work the organisation is creating for itself.

Fix the system, not just the symptoms

The starting point is to understand where engineering capacity actually goes, how much is devoted to planned development and necessary maintenance, how much is consumed by unplanned work, and what is driving that unplanned work in the first place.

If defects repeatedly escape into production, for example, is the underlying issue insufficient testing, architectural complexity, unclear ownership or pressure to release software before it is ready? If features repeatedly have to be redesigned or rebuilt, are requirements poorly defined, are customer needs being misunderstood, or are priorities changing so frequently that teams cannot complete what they started?

The answers matter because the solution depends on the cause, and while engineering teams can improve testing, simplify architecture and strengthen their development practices, many of the factors generating unnecessary work sit outside engineering itself.

Sales commitments made before feasibility is understood, incomplete product requirements, conflicting priorities and decisions that are repeatedly revisited can all create additional work for engineers. These are organisational issues, even when their consequences eventually appear in the engineering backlog.

This is why failure demand is as much a leadership issue as an engineering issue. The CEO’s responsibility is to understand how the operating system generates work, where capacity is being consumed, and which constraints are preventing the organisation from delivering the outcomes it needs.

The real opportunity

Imagine two engineering organisations with 20 engineers, both using the same AI tools, but with very different levels of unplanned work. The first spends a substantial proportion of its capacity dealing with recurring incidents, defects and avoidable rework, while the second has systematically addressed the underlying causes and established more reliable ways of working.

Although they have the same headcount and access to the same technology, the second organisation has created the conditions in which the productivity benefits of AI are more likely to translate into faster delivery, better software and greater value for customers.

Our CEO’s session at HyperscaleCEO was an important reminder that sometimes the most important discovery is not the answer to the question you started with, but the more fundamental question you uncover along the way. You must, as I like to say “Keep peeling the onion”, layer by layer until you find the root cause of the problem.

Before asking how much more productive AI has made your engineering team, ask how much of its capacity is being consumed by unplanned work, what is generating that work, and how much of it could be prevented by addressing the underlying causes.

Don’t just use AI to accelerate the work. Fix the system that determines which work needs to be done.

For more valuable insights on how to be an excellent CEO, check out Hyperscale Academy!

Photo by Leo_Visions on Unsplash