Free
Illusions in the Boardroom
The board-level diagnosis
Illusions of Work
The operator manual
How Busy Work Sustains Itself
A CFO kills a platform investment because it doesn't show ROI in year one. The cost is a visible line item. The benefits are diffuse and don't appear in any P&L. The incidents arrive months later, attributed to the wrong cause.
A European insurer invested a seven-figure sum in a shared integration layer for its claims process: a common event infrastructure that would let the claims, policy, and payments teams exchange information independently, replacing a fragile web of direct connections between services that caused regular incidents.
The platform team built a working prototype. The consuming teams were willing to migrate. The projected incident reduction was substantial. The technical case was sound.
The CFO killed the investment in the annual budget review. “Does not show ROI in year one.”
Within the instruments available to him, the CFO’s decision was rational.
The cost of the platform was visible: a line item in the technology budget, charged against the current fiscal year. The benefit was diffuse: fewer incidents, faster change, reduced coordination overhead. None of these benefits appeared in any business unit’s P&L. The incidents were attributed to “engineering quality” in the quarterly review. The coordination overhead was distributed across departments. The slower change velocity was invisible because nobody measured the time between a business decision and its implementation in the system.
Finance’s tools cannot see the connection, because the connection runs through system architecture, and finance has no instrument for observing system architecture. Finance prices departments. Value gets created at process boundaries. Nobody mapped the relationship between the two, so the CFO’s spreadsheet is structurally blind to the thing that determines whether his decisions work.
Over the following year and a half, the direct connections between systems that the platform would have replaced caused a series of major incidents. Two affected customers directly, triggering regulatory scrutiny. A commercial fleet operator waited more than a week for a claim that should have settled in two days. His broker emailed the CEO. The CEO asked the COO. The COO asked the CTO. The CTO traced the failure to the integration point that the cancelled platform would have replaced.
The CTO did not mention the cancelled platform, because the failure had already been attributed to a “data synchronisation issue” in the incident log. The incident log follows the incident, not the decision that made the incident inevitable. The broker filed a complaint with the industry ombudsman. The compliance function requested a root cause report. The report described the technical failure accurately. The report did not mention the investment decision that caused it.
The CFO never saw the ombudsman’s letter. The complaint was handled two levels below him, in a function with no reporting line to the person who made the decision that caused it.
The total cost of those incidents, including incident response, remediation, customer compensation, and regulatory reporting, exceeded the original platform investment. These costs were attributed to “engineering quality” in the quarterly review. Nobody connected them to the cancelled investment.
A year later, the budget included a smaller follow-on allocation for “integration resilience,” insufficient to do the work properly. The platform team had been disbanded. Its lead engineer had left the company.
The vignette illustrates a pattern that repeats with remarkable consistency across software-dependent corporates, a pattern worth naming: the deferred investment trace. The benefit of a rejected structural investment accrues to budgets the CFO does not control, while the cost of rejection distributes across departments that cannot trace it to the original decision. The cost is real, measurable, and attributable, but only in retrospect, and only by someone willing to trace the chain from the budget decision to the incidents it made inevitable.
Engineers see value being created through changes in system behaviour, yet failures emerge from architectural constraints, unclear ownership, and underfunded infrastructure. They know that the outcomes visible today were determined months earlier by decisions whose consequences are only now arriving. Hindsight is the only language that matters, and hindsight has no vocabulary for “the decision the CFO made last year caused the incident we resolved last Tuesday.”
The competitive pressure is market-driven. The regulatory pressure is not, and for organisations in financial services, insurance, and banking, the regulatory pressure may arrive first.
Operational resilience frameworks in the EU under DORA and in the UK under the FCA’s operational resilience regime ask not whether the firm has documentation but whether it can demonstrate end-to-end understanding of its critical business processes: who owns each process, how quickly the process can be changed when a regulatory requirement shifts, and whether the firm can trace a change through the process to the running system.
Consider the insurer from the vignette. A regulator asks: “How long would it take to implement a cooling-off-period change across your claims process?” The honest answer is months, because the process spans multiple teams, the change requires coordination across several services, and the regulatory requirement touches shared data models. The CTO cannot say this, because the answer reveals that the organisation does not own the process it operates. The CTO says “integration testing and risk validation,” which is accurate enough to be unchallengeable and vague enough to be unexamined.
What those months look like from the inside: weeks to identify which services are affected, because no map exists that traces the regulation through the system. Weeks waiting for impact assessments, change advisory boards, integration testing, regression testing. The regulatory deadline passes. The insurer requests an extension, citing “technical complexity.” The actual code change, when it is finally deployed, takes a developer half a day.
At the competitor, the claims unit owns the process. The change takes days, because the unit contains everything needed to implement it: the process definition, the code, the data, and the people who understand both.
The regulatory exposure is structural, and it compounds alongside the competitive exposure. The reconciliation report that the competitor produces weekly is exactly the evidence the regulator is looking for. The narrative that the busy-work organisation produces quarterly is exactly the evidence the regulator has learned to distrust.
See also: All articles · Illusions in the Boardroom · Illusions of Work