Invisible Work Is the Only Work That Lasts.
A decision that prevents a failure produces no evidence that it worked. That is a budgeting problem long before it is a fairness problem.
Your incident record is a complete list of the occasions on which prevention failed. There is no corresponding document for the occasions on which it worked.
That absence is not a gap in reporting. My argument in this piece is that it is one of the reasons technology organisations underprice the work that keeps them standing, and that the cost surfaces later in a change budget as remediation nobody planned and nobody can trace back to a decision.
The work is done at the start. The credit is handed out at the end.
Most of what decides whether a system will fail is settled early. During discovery, when someone establishes what the business rule actually is rather than what the current system happens to do. During architecture, when a boundary is placed correctly. During design, when a failure mode is anticipated and closed before any code exists.
Credit is distributed at go-live, months or years later, with different people in the room. The team that finished the last feature is present and visible. The person who removed the problem that would have made the launch impossible has moved on, and there is no artefact recording what they removed.
I have watched this play out in enough organisations to be confident it is structural rather than a failure of generosity. That distinction matters. A mechanism can be redesigned. A character flaw cannot.
There is a name for this, and it is twenty-five years old
Nelson Repenning and John Sterman, both at MIT Sloan, published a paper in California Management Review in 2001.
“Nobody Ever Gets Credit for Fixing Problems that Never Happened”
The line was not theirs. They took it from an engineer at an automotive company during fieldwork.
Their model is austere. An organisation facing a performance gap has two options. It can work harder, which raises output immediately and only while the effort continues. Or it can work smarter, raising the capability of the process so every subsequent hour produces more, with the return arriving after a delay.
Because organisations rarely hold spare capacity, pressure to work harder takes its hours from improvement. Capability erodes slowly. The gap widens. Pressure rises again. They call this the capability trap, and its defining feature is that working harder is better-before-worse, while working smarter is worse-before-better.
Why experience teaches the wrong lesson
People assume cause and effect sit close together in time and space. A defect gets attributed to the operator standing next to it rather than to a training programme whose influence is delayed and unobservable. That is the fundamental attribution error, and it explains why credit and blame both land on whoever is nearest the visible outcome.
Then it compounds. A manager applies pressure and throughput rises. They cannot see how much of that rise came from real additional effort and how much came from improvement work being quietly dropped. Repenning and Sterman work an example where a manager needs six hours per person per week, gets two from genuine effort and four from abandoned improvement, and concludes that pressure produced all six. They call this the self-confirming attribution error. The manager overstates the effect of their own approach by up to a factor of three, and receives immediate evidence that their people were not trying hard enough.
The error is not corrected by experience. It is manufactured by experience.
One consequence follows directly, and it is the least comfortable finding in the paper. Organisations dependent on firefighting reward and promote the people who rescue troubled work. Over time, senior management comes to consist of those people, who then favour others who resemble them. The trap stops being a question of resource allocation and becomes the composition of the leadership team.
None of this is an argument against firefighters. Recovering a service under pressure is genuinely difficult, and the people who can do it are good at something rare. The failure sits in the ratio and in the visibility, not in them.
Why a chemical plant is the same estate you run
The paper’s central case is Du Pont, and the finding is not the one most people expect.
In 1991 an internal benchmarking study found Du Pont was spending 10 to 30 percent more on maintenance per dollar of plant value than the best performers in its industry. Uptime ran 10 to 15 percent lower. More money, worse availability.
The problem was never the size of the budget.
The mechanism transfers exactly, so it is worth following slowly.
When critical equipment breaks in a chemical plant, it has to be fixed. That work is not optional and cannot absorb a cost reduction. So the reduction lands on planned maintenance, training, and equipment upgrades, because those are the only things that can be deferred without anyone noticing this month. Breakdowns then rise. Mechanics are reassigned from planned work to repair work. Breakdowns rise further. As uptime falls, operators become less willing to release equipment for scheduled maintenance, because they are already behind.
Now change the nouns.
Production incidents have to be resolved. That work cannot absorb a cut. So the cut lands on the design work, the discovery, the platform investment, and the upgrade nobody is asking for yet. Defects rise. Engineers move from building to supporting. Availability falls, and the appetite to take a service down for the work that would fix it properly falls with it, because the team is already behind.
Your estate is the plant. The nouns changed and the loop did not.
Du Pont’s response ran through the 1990s. At the plants that adopted it, equipment reliability improved at roughly twice the rate seen at comparable plants that did not, and direct maintenance costs fell by around a fifth while rising at the comparison sites.
A decade with nothing to show for it
There is a version of the same thing in software, described from the inside.
In April, Werner Vogels wrote about the AWS Lambda networking team, whose work over roughly a decade produced no launch, no announcement, and nothing a customer could point at. Marc Olson’s description, quoted in that piece, is of converting a propeller aircraft into a jet while it stays in the air.
When the team building Aurora DSQL later needed networking of that grade, they did not receive a document explaining how to build it. The Lambda team had packaged the whole thing as a service that DSQL installs and runs, with Lambda continuing to own it and issue new versions, so every subsequent improvement reaches DSQL without DSQL doing anything at all. Vogels reports it saved them months.
Ten years of work whose entire visible output was that another team did not lose time.
Had that same team instead spent the decade recovering from outages, every quarter would have contained something to show for it.
The decisions I argued for on the wrong grounds
Over more than two decades I have made this argument from the inside repeatedly. Looking back at it now, the pattern is not that I lost those arguments. It is that I almost never won them on the grounds that actually mattered to me.
The clearest instance was building a single credit cards capability on one platform, to be used by more than one business unit rather than each unit standing up its own.
The resistance was not architectural. It was about change cadence. A shared platform means agreeing when changes land, and a business unit that currently controls its own release schedule is being asked to surrender that control in exchange for something it cannot yet see. Their objection was rational. Mine was a promise.
That argument took years to settle, and what I had been buying only became visible when the second business unit was onboarded. By then the capability existed and the operating model was proven, so the work was onboarding rather than building. Nobody in the room at that point was thinking about a platform decision taken years earlier. They were looking at the onboarding, which is exactly where a reasonable person would look.
A second instance was building an abstraction over third party integrations. The business model depended on assembling capability from several external providers, which made provider change a permanent condition rather than an exception. The layer sat between the business capability and the providers, so one could be added, replaced or renegotiated without rewriting what sat above it. What I was buying there was a series of rewrites that never took place, and a rewrite that does not happen leaves nothing behind.
Three others follow the same shape. Domain Driven Design alongside an event driven approach, which splits an estate into areas that each own a defined part of the business and has them announce what has happened rather than reaching into each other’s data. What I wanted was the coordinated three-team release that would no longer be necessary. A genuine build and run model, where the team writing the software also operates it and is called when it breaks, set against an operating model built on separation and heavy change control. What I wanted was the defect that does not survive, because the person who wrote it now sees it fail. And choosing a cloud provider’s own managed services over tooling designed to run anywhere. What I wanted was the delivery time not spent proving that the portable option was still immature.
Not all of these took hold. The domain approach became the working model in parts of the estate and never reached others, which is its own evidence about how long this work takes and how easily it stalls.
I should be precise about what I was doing in these rooms, because there is a version of this story that sounds better than the truth. I did not conceal my reasoning. Modularity, ownership, capability, resilience. I believed all of it and all of it was real.
What I did was argue the parts that could be evidenced, and leave out the benefit I was primarily buying.
An absence cannot be put into a business case.
When each of these landed, the credit went where credit goes. To the delivery.
One concession on the last of them. The dependence argument was not wrong. Vendor concentration is a real exposure and it was raised in good faith. It was being priced at some number, while the delay on the other side of the decision was being priced at zero, because nobody had a way to write down a delay that had not occurred.
What actually changes it
Exhortation does not. Every organisation already agrees that prevention beats cure, and the agreement changes nothing, because the manager’s own evidence keeps pointing the other way.
Three mechanisms are more promising.
1. Write down the counterfactual before the outcome exists
An absence can only be credited if somebody recorded what was expected to be present. A design record that names the specific failure being closed off, in terms concrete enough to be wrong, converts prevention into something with a stated before and after.
This is the mechanism I failed to use in every decision described above. It is also the reason none of them appears in any record of achievement, including my own.
2. Ring-fence the dividend
Repenning and Sterman observe that in the programmes which held, leadership explicitly reallocated the capacity freed by improvement back into further improvement.
If prevention work frees six weeks, and those six weeks are absorbed into the next delivery target, the loop has been turned from virtuous to vicious by an act of apparently sound management.
3. Warn the board that the cost gets worse first
This is the mechanism most programmes die on, because the warning arrives after the cost does.
BP’s Lima refinery in Ohio was deep in the trap by the early 1990s, lagging other US refineries, with BP weighing sale or closure. The improvement programme started in 1994. It was not a leadership initiative. The original champions were an equipment specialist, a maintenance training supervisor, and an engineer.
Maintenance costs rose by roughly 30 percent in the first six months.
That is the point at which this work normally gets cancelled, and a board cancelling it is acting reasonably on the information in front of it. Lima’s management held, because they had already lived through that curve inside a simulation and knew it was coming.
By 1998, the average time a pump ran before failing had moved from 12 months to 58. Reported new value was around $43 million a year, against a programme cost near $320,000.
Two weeks. Five thousand dollars. Eight years.
A team at Lima eliminated butane flare-off, saving about $1.5 million a year. The work took two weeks and cost about $5,000.
They had known about the problem, and the solution, for eight years.
They had the expertise. Most of the materials were already on site. What was missing was any belief that the time existed, or that it was theirs to take.
Both cases undercut themselves
Leaving this out would make the piece an advertisement.
Du Pont’s programme produced real results and was then weakened by company-wide cost-cutting that drained the reinvestment it depended on. Winston Ledet, who led it, took early retirement.
BP announced its intention to sell Lima in 1996, then announced it could not find a buyer and would close it. Clark USA bought the refinery in 1998 for $215 million.
The work plausibly made the asset saleable. It did not make it safe.
Prevention work does not protect you from a decision taken two levels above you. It changes what that decision is choosing between.
Where the incentive cannot hold, a standard has to
There is one place where preserving work that produced no visible output has already been made non-optional.
The PRA’s supervisory statement SS1/23 on model risk management took effect in May 2024. Principle 1.2 sets out what a firm’s model inventory must contain. Alongside the models in use and the models in development, it requires the models that have been decommissioned.
A footnote gives the reason. The rationale behind a retirement may inform how future models are developed, and the retired model may later be useful as a challenger.
Read narrowly, that is a model risk provision and nothing more. My reading of it, and I am labelling this as a reading rather than a statement of the PRA’s intent, is that a supervisor has looked at work whose entire value sits in a future that has not happened, and made keeping it a condition rather than a preference.
Four questions I have started asking myself
None of these need a programme behind them.
What did I expect not to happen? For any design decision I made this year, can I state the specific failure I believed it would prevent? If I cannot state it now, I will have no way of knowing in three years whether it worked, and neither will anyone else.
Where did the freed capacity go? When prevention work gave a team time back, was that time reallocated deliberately, or absorbed into the next target? I have let it be absorbed more than once and called it pragmatism.
Whose earlier decision made this possible? When I recognise a delivery, do I trace it back past the people standing in the room? It takes about two minutes and I do not do it often enough.
What have I known how to fix for years and not funded? The Lima team held the answer to a $1.5 million problem for eight years. This is the question I find hardest, because the honest answer is usually a list rather than an item.
None of this is free. Prevention work spends delivery capacity now against a saving that lands in a later budget, often under a different leader. That is exactly why it has to be funded as a decision rather than justified as a return, because the business case cannot carry an absence and never will.
You do not notice a floor until it gives
I do not think this is only a technology problem, and I am not certain it is only an institutional one.
Good architecture is invisible. So is a culture that works, and a way of working that fits the work being done. None of them announces itself. What registers is their absence.
A team with real trust in it feels like nothing at all. People say what they think, which seems unremarkable until you spend a month somewhere nobody does. A house with sound foundations is simply a house. Nobody stands in a room admiring them. They are noticed in the one year a wall cracks, and never in the forty before it.
That is the difficulty with foundations of any kind. Their success is silence, and silence is the one signal most organisations hold no instrument for.
Every institution can name the person who saved it. Almost none can name the person who made saving it unnecessary.
If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.