Law 7: Unused Work Is Structural Waste

The First Six Laws in Brief

Before introducing Law 7, it is worth recalling the first six laws of outcome-driven systems.

1. If It Is Not Used, It Does Not Exist. Value only materialises when customers derive measurable benefit.
2. All Additions Increase Entropy. Every new component adds complexity and maintenance cost.
3. Dependencies Tax Flow. Coordination overhead slows delivery and reduces autonomy.
4. Delayed Feedback Compounds Failure. The later reality speaks, the more expensive correction becomes.
5. Systems Optimise for What They Reward and Tolerate. Incentives shape behaviour more reliably than slogans.
6. Local Optimisation Breaks Global Performance. Improving one part in isolation often damages the whole.

Together, these laws describe the dynamics that govern delivery systems.

Law 7 focuses on one of the most costly consequences of ignoring them: investing significant effort in work that never creates meaningful value.

This law connects directly to Law 1, because work that nobody uses does not truly exist from the customer's perspective.

It also reinforces Law 2, since every unused feature increases entropy.

It extends Law 3, because dependencies are frequently created to support initiatives that ultimately deliver no benefit.

It magnifies Law 4, because weak feedback allows teams to continue investing in irrelevant work.

It reflects Law 5, because organisations often reward delivery activity rather than adoption.

And it complements Law 6, because even if teams avoid local optimisation, they may still build the wrong thing.

A perfectly coordinated organisation can waste enormous amounts of energy if its output does not translate into actual usage.

Law 7: Unused Work Is Structural Waste.
Effort that does not create measurable customer value consumes resources, increases complexity, and reduces the system's ability to deliver what matters.

In many organisations, activity masquerades as progress.

Features move through the roadmap, teams remain fully occupied, dashboards glow with reassuring indicators, and presentations celebrate another quarter of apparent delivery.

Yet a deceptively simple question often exposes a very different reality: Who is actually using this?

The answer can prove deeply uncomfortable. Sometimes nobody uses the feature at all. Sometimes a handful of internal testers interact with it briefly. Sometimes a customer enables it once and never returns. In other cases, the product never reaches production.

Months, and occasionally years, of engineering effort can vanish into work that produces no measurable benefit.

The waste extends far beyond the code itself, because every unused feature leaves behind additional complexity, operational overhead, and maintenance obligations that the organisation must continue to carry.

More troubling still, many organisations fail to recognise such effort as waste at all, treating the mere completion of work as evidence of success even when no corresponding customer value emerges.

The Factory Illusion

Traditional manufacturing made waste visible.

If a factory produced ten thousand unsold vehicles, the inventory filled warehouses, tied up capital, and quickly revealed the problem.

Software hides waste far more effectively.

Unused features occupy no physical space. They remain quietly in repositories, infrastructure, and support queues. They continue to demand maintenance, documentation, monitoring, and operational attention.

The absence of physical inventory creates the illusion that unused software costs nothing. In reality, it imposes a permanent structural burden.

Every unused component:

• Increases cognitive load
• Expands operational complexity
• Generates additional testing requirements
• Creates future compatibility constraints
• Raises maintenance costs
• Introduces new failure modes

Unused work does not remain neutral. It enlarges the surface area of the system and increases the burden that future teams must understand, maintain, and eventually simplify.

In that sense, every unnecessary feature makes the overall system objectively worse.

Code as Inventory

Lean manufacturing treats inventory as a sign of trapped capital. Software organisations rarely apply the same logic.

Every feature that does not create measurable customer benefit represents inventory disguised as progress. Its true cost includes:

• Product discovery and design discussions
• Development effort
• Reviews and testing
• Deployments and operational support
• Documentation and onboarding
• Opportunity cost of work not pursued

The most expensive software in a company often consists of features that nobody uses.

The most expensive software in any organisation often consists of features that nobody uses, nobody needs, and nobody dares to remove.

This observation explains why many cost-reduction initiatives eventually converge on the same conclusion.

One of the fastest and least controversial ways to reduce cost involves identifying oversized features, unused capabilities, and dormant initiatives that continue to consume engineering and operational attention.

Removing or decommissioning such work immediately lowers maintenance overhead, reduces cognitive load, and frees capacity for more valuable activities.

The same principle applies to team utilisation.

Organisations that attempt to keep engineering capacity permanently saturated often generate queues, context switching, and unnecessary work.

Operating closer to 80% effective capacity leaves room for discovery, learning, and rapid response while reducing the pressure to produce features that add complexity without increasing customer value.

In other words, the most effective cost-saving measures rarely begin with layoffs or across-the-board budget cuts.

They begin with the discipline to identify and stop work that should never have existed in the first place.

The Metrics That Lie

Many companies reward production rather than adoption.

Teams receive recognition for:

• Story points completed
• Velocity increases
• Roadmap commitments met
• Number of releases
• Lines of code delivered

On internal dashboards, these indicators often appear reassuringly green.

Yet beneath the surface, customers may derive little or no value.

Mik Kersten popularised this phenomenon through the image of the watermelon effect: green on the outside, red on the inside.

The organisation appears healthy when viewed through delivery metrics, while the underlying business reality tells a very different story.

Nokia's decline offers a powerful example. Engineering teams worked intensely, programmes advanced, and milestones accumulated, but the visible productivity masked a growing disconnect between effort and market impact.

None of these metrics, however, demonstrate value creation.

A feature can satisfy every internal measure and still generate zero meaningful benefit.

This distinction lies at the heart of outcome-driven systems.

Output measures what the organisation produced, while outcome measures what changed in reality for customers and for the business.

Only outcomes provide reliable evidence that the system created genuine value.

Real Examples of Structural Waste

Most experienced engineers can recall painful examples.

An e-commerce company spends three quarters building an endless aisle feature that customers barely touch.

A verification platform invests two years in an orchestration framework that still does not expose a single fully usable customer feature.

From an accounting perspective, these initiatives appear as investments. From a systems perspective, they represent accumulated entropy.They also violate one of the most fundamental principles of system dynamics.

Any viable organisation depends on maintaining a healthy balance between inflows and outflows. Revenue, customer adoption, and retained value replenish the system. Salaries, infrastructure, and operating expenses continuously drain it.

Unused work breaks this balance by allowing resources to flow out through sustained engineering effort while little or no corresponding value returns to replenish the system. The resulting dynamic resembles a reservoir with open discharge valves and no meaningful inflow to restore what has been consumed.

For a period, strong reserves may conceal the problem. Cash balances remain positive, dashboards look healthy, and teams continue to operate.

Eventually, however, the underlying stock declines.

This dynamic helps explain why companies such as Nokia could appear productive and financially solid while their strategic position deteriorated. The organisation consumed scarce energy without creating proportional value, slowly eroding the very reserves required for long-term survival.

Why Unused Work Happens

Unused work rarely results from poor intentions.

It emerges when organisations gradually lose direct contact with reality and begin operating inside a self-reinforcing comfort zone.

As long as teams remain busy, dashboards stay green, and no one challenges the underlying assumptions, the organisation can sustain the comforting belief that progress continues.

The longer this pattern persists, the harder it becomes to question it. People adapt to the appearance of success, internal narratives solidify, and challenging the status quo starts to feel more threatening than maintaining it.

Common causes include:

• Product decisions disconnected from actual customer behaviour
• Executive ego overriding empirical evidence
• Incentives favouring delivery over adoption
• Lack of instrumentation and usage metrics
• Fear of cancelling visible initiatives
• Weak feedback loops from production

Over time, the organisation rewards the act of building more consistently than the act of solving meaningful customer problems.

This dynamic creates a self-entertained fantasy in which activity substitutes for impact and internal validation replaces external reality.

When that shift occurs, software development turns into theatre: highly visible, energetically performed, and largely disconnected from tangible results.

The Nokia Lesson

During its decline, Nokia continued to mobilise vast engineering resources.

Teams worked hard, programmes advanced, and milestones accumulated. From the inside, the organisation looked productive, disciplined, and financially solid.

That visible activity, however, could not compensate for strategic drift and internal fragmentation. Enormous quantities of software and hardware left the organisation, while progressively less value returned through customer adoption, market relevance, and financial performance.

In systems terms, the stock of organisational strength began to erode because outflows consistently exceeded inflows. Engineering effort, operating costs, and managerial attention continued to drain the system, while the replenishing forces of market success and customer pull weakened quarter after quarter.

Mik Kersten has used Nokia as a compelling illustration of the watermelon effect: indicators appeared green on the outside, while the underlying business reality had already turned red.

The lesson extends far beyond one company. Large organisations can generate extraordinary volumes of output and still consume their own reserves if that output fails to produce meaningful value.

Productivity and effectiveness follow very different laws, and systems that ignore this distinction eventually pay the price.

If It Is Not Used, It Does Not Exist

Law 7 connects directly to the first principle of outcome-driven systems:

If it is not used, it does not exist.

Code may compile successfully, deployments may complete, and programmes may even receive internal recognition.

Until real customers derive measurable benefit, the work remains unrealised potential rather than accomplished value.

From a systems perspective, it should therefore count as unfinished, regardless of how much effort has already been invested.

Financial Consequences

Unused work destroys capital through three reinforcing mechanisms, each of which weakens the organisation in a different but equally damaging way.

The first mechanism involves direct consumption of resources. Salaries, cloud infrastructure, software licences, consulting fees, and management attention all flow into initiatives that fail to generate corresponding customer value. From a purely financial perspective, the organisation converts cash into assets that produce little or no return.

The second mechanism arises through carrying cost. Once a feature enters the system, it rarely remains dormant. Teams must understand it, test it, document it, monitor it, secure it, and maintain compatibility with future changes. Even when nobody uses the capability, the organisation continues paying an invisible tax simply to preserve its existence.

The third mechanism concerns opportunity cost. Engineering capacity invested in unused work cannot simultaneously address genuine customer problems, reduce technical debt, improve reliability, or accelerate strategic initiatives. The greatest cost often lies not in what was built, but in what the organisation failed to pursue while resources remained tied up elsewhere.

Every euro invested in unused work therefore disappears twice: first through the effort consumed, and again through the valuable opportunities that never materialise.

At sufficient scale, this pattern becomes a structural tax on the organisation, steadily draining the reserves required for innovation, resilience, and long-term growth.

Organisational Consequences

The consequences extend well beyond financial loss.

When engineers repeatedly see their efforts disappear into irrelevance, morale gradually erodes. Teams become cynical, stakeholders lose trust, and planning turns into ritual rather than informed decision-making.

Over time, people stop believing that delivery and impact remain meaningfully connected.

At that stage, organisations begin to drift into a form of learned helplessness in which activity continues, but confidence in purposeful progress quietly disappears.

The Discipline of Customer Pull

The antidote lies in developing a disciplined attachment to customer outcomes rather than to the artefacts we create.

Engineers naturally take pride in elegant code, robust architectures, and technically satisfying solutions. Such pride reflects craftsmanship and should not disappear. Yet professionalism requires the ability to remain emotionally detached from the work itself.

Code remains a hypothesis whose true worth only emerges when it enters production and encounters reality.

For that reason, mature engineers learn to derive satisfaction not from the mere act of building, but from the long and disciplined process of observing whether customers actually benefit.

Production should not mark the end of the journey. It should represent the beginning of the most important phase: receiving feedback from the only judge that matters.

Before building, teams should ask:

• What customer problem are we solving?
• How will we measure adoption?
• What behaviour should change?
• How quickly will we know whether it matters?
• Under what conditions will we stop?

After release, they should continue asking:

• Who is using it?
• How often?
• What measurable benefit occurred?
• Should we expand, refine, or remove it?

This mindset requires humility, because it asks us to treat our creations as experiments rather than possessions and to welcome production feedback as a source of truth rather than a threat to our ego.

When engineers become emotionally attached to customer satisfaction instead of to their own code, software development regains its proper purpose.

Without this discipline, development remains little more than speculation.

The Courage to Delete

Building software attracts prestige, whereas deleting software rarely receives the same recognition.

Yet some of the most valuable engineering work consists not in adding new capabilities, but in removing what no longer serves customers.

Deletion reduces complexity, lowers maintenance costs, sharpens focus, and returns cognitive capacity to the organisation.

It also requires intellectual honesty. Removing a feature means acknowledging that earlier assumptions proved wrong or that circumstances have changed.

Mature engineers and leaders understand that their responsibility does not end with creation. It includes the discipline to simplify the system whenever evidence shows that a component no longer contributes meaningful value.

In many cases, the highest-leverage feature is the one that disappears.

The Real Measure of Delivery

The only meaningful measure of completed work lies in realised customer value.

Lines of code, closed tickets, and polished presentations may indicate effort, but they do not demonstrate impact.

Only observable improvements in customer outcomes confirm that delivery has genuinely occurred.

Everything else remains inventory awaiting validation.

Law 7

Unused Work Is Structural Waste.
Work that does not create measurable customer value consumes resources, increases complexity, and weakens the organisation.

Final Thought

Unused work does not merely waste effort. It quietly converts organisational energy into complexity.

If leaders wish to reduce cost, increase speed, and restore strategic focus, they should begin by identifying what nobody uses.

The fastest productivity gains often come not from adding more capacity, but from eliminating work that should never have existed in the first place.

Many organisations worry obsessively about moving too slowly, yet a far greater danger lies in moving quickly in the wrong direction while producing work that nobody uses.

From a systems perspective, unused work does far more than fail to help. It consumes capital, increases complexity, and steadily weakens the organisation's capacity to respond to genuine customer needs.

The most dangerous form of waste often arrives disguised as progress, celebrated internally while silently draining the reserves on which the organisation depends.

In software, the most expensive feature often proves to be the one everyone applauded and nobody used.