The Budgeting Dissonance

[🇩🇪 - Die Budgetierungs-Dissonanz]

📧 The Drafts Folder: Why the Best Handovers Stay Unsent

Markus is an engineering manager at the Neustadt site. It is Thursday evening, 17 December 2026, 18:47. He has finished the thirty-six-page handover document for project P-2026-0418. Six engineers spent eighteen months teaching the settlement layer to handle multi-tenancy. The project closes on 31 December. The six engineers return to their line departments on 4 January. Two backend developers go to the platform team. An SRE goes to the on-call pool. A database specialist joins the central DB group. A solution architect returns to the architecture board.

None of the six will operate the system going forward. The system has been live for three weeks. It runs on nine virtual machines. It has had two hotfixes. On 12 January 2027, the first full settlement cycle on real data runs against it.

Markus types the handover email. Distribution list: IT Operations Neustadt. Attachment: the PDF. Body: six names, line assignment from January, the most important operational risks for the first six weeks, and the emergency escalation phone numbers. He reads it twice. He knows the receiving line has no capacity to absorb it. He knows the two backend engineers hit a new platform backlog on 4 January. He knows the email will be read in operations, acknowledged, and filed in a folder.

He saves it as a draft. Closes Outlook. Goes home.

On Friday morning, the email remains in Drafts. Lehmann’s weekly-report template requires a status check on whether the project closed on time and on budget. Markus marks both green.

The unsent email is a symptom. The underlying budget structure actively prices honesty out of the conversation.

🧮 The 1:4 Ratio: The Reality Missing From Total Cost of Ownership

Management loves the concept of Total Cost of Ownership (TCO). Total Cost of Ownership promises the honest price tag of a system across its lifecycle. The standard corporate calculation hides most of it.

The empirical literature on software maintenance, summarised by Robert Glass on the back of Boehm’s cost studies and Lehman’s evolution laws, places maintenance and operation between forty and eighty percent of total lifecycle cost. For long-lived enterprise systems the upper end is the realistic anchor: a 1:4 split between build and operate.

The system Markus’s team took eighteen months to build will demand several times that effort over the next seven to ten years. Edge cases get learnt the hard way. Escalation paths get walked the first time at three in the morning. Database major versions get migrated. Dead features get pruned. Regulators change the rules and the settlement logic requires a rewrite.

That operational cost has no project budget. The project budget ended on 31 December. The six heads who built the system are redirected to other initiatives whose budgets remain open. The four-times-build cost is a physical reality. It lacks a line item because line items belong to projects, and the project is closed.

The CFO’s spreadsheet shows the system as paid for. The operations director’s spreadsheet shows the workload arriving in January as normal line activity within the tolerance band. Both spreadsheets contain accurate numbers. They do not talk to each other. That gap is the dissonance.

🏛️ The IAS 38 Constraint: How Accounting Drives Architecture

European accounting standards drive this dynamic, independent of management’s foresight.

Under the International Financial Reporting Standards (IFRS), the mandatory accounting framework for European corporations, specifically standard IAS 38, building a new software feature can be capitalised as an intangible asset once the six development-phase criteria of paragraph 57 are met: technical feasibility, intention to complete the asset, ability to use or sell it, how it will generate probable future economic benefits, availability of adequate resources to finish it, and reliable measurement of attributable expenditure. Where the criteria are met, this classification shields the balance sheet. The money spent building the software bypasses this year’s profit reduction. It is capitalised, placed on the balance sheet (CapEx), and amortised slowly over several years. This keeps the company’s short-term earnings (EBIT) looking healthy.

Running and maintaining that same software is classified as operating expense (OpEx). It hits the profit and loss statement immediately, burning this year’s margin.

A CFO targeting a quarterly EBIT goal carries a structural incentive to label as much spend as possible as project work, and as little as possible as operational work. The organisational consequence is predictable. Projects receive generous budgets with start and end dates. Lines receive punishing full-cost-recovery targets. Disbanding a team the moment the project closes pushes the non-capitalisable operating spend into another cost centre, where it dissolves into normal line work. That budget operation wears the costume of frugality.

The accounting structure dictates the subsequent behaviour. Mel Conway noted in 1968 that organisations produce systems mirroring their own communication structures. When an organisation separates the project from the line as two distinct communication regimes, the systems built mirror that separation. They possess a build phase and an operate phase, with a handover modelled as a technical interface between two socially separated groups. No single entity holds responsibility for the system over its lifetime, because no single communication boundary spans its lifetime.

🪞 The CapEx Blind Spot: What the Board Report Misses

The spreadsheet recording the closure of project P-2026-0418 on 31 December contains structural blind spots.

The two backend engineers know the settlement layer shows a rare race condition in a particular tenant configuration. They discovered it in the two weeks before go-live and worked around it with a configuration setting. That information sits in no Confluence article. Both heads start the platform backlog on 4 January. When the race condition reappears in May 2027, the operations team needs a week to reconstruct the configuration workaround. That represents the unwritten knowledge tax, paid by the next P&L, attributed to system instability.

The continuous adaptation is missing from standard asset tracking. Lehman’s laws of software evolution, formulated in 1980 and validated across decades of industrial systems, established that any productive system embedded in a real environment must change continually or progressively become less useful. Database major-version upgrades, dependency rewrites, regulatory rewrites, security-driven refactors: none of them sit in the TCO calculation. They count as normal line operation. The cost of the asset hits the balance sheet. The cost of keeping the asset alive is smeared.

The board report in February 2027 illustrates the asymmetry of cost visibility. It contains two numbers side by side. Project P-2026-0418 closed at 4 percent under budget (success, visible, attributable). The Neustadt Operations line missed its full-cost recovery in Q4 2026 by 7 percent (problem, diffuse, attributed to line management). Nobody connects the two. Mik Kersten documented across large enterprises that capitalisation practice renders the true unit cost of a software product structurally invisible. The board sees two unrelated rows.

🚧 Cognitive Load Fragmentation: The Handover That Fails by Design

Matthew Skelton and Manuel Pais formalised the operating-model consequence of Conway’s observation in Team Topologies. Their empirical move involved a multi-year study of how high-performing software organisations structure their teams. They identified a recurring pattern. Long-lived stream-aligned teams owning both build and operate are organisationally cheaper, faster, and more resilient than the sequence of a build team plus a handover plus line operation.

The mechanism they named is cognitive load fragmentation. The knowledge required to operate a system safely under load includes the unwritten edge cases, the configuration tweaks the build team applied at the last minute, and the implicit ordering between two services that nobody documented. Handovers run expensive because the knowledge requiring transfer cannot be written down fast enough to matter.

A project structure disbanding the team at go-live guarantees the handover cost gets paid by whoever inherits the system, in operations, at the worst possible moment, with no budget line backing it. A Confluence page cannot fix this structural deficit. The cheapest handover is the one you avoid by refusing to separate build from operate at inception. That is the economic reality behind Werner Vogels’ mandate: You build it, you run it.

When an organisation cannot transition to that model in one step, the intermediate move requires designing the team topology change into the project closure itself. Resolving this requires a governance change rather than a wiki update.

🔧 The Shadow-OPEX Line: Budgeting the Reality of Handover

Here is the governance lever the steering committee must embed into the Project Charter at initiation, and the exact terms Markus needs to trigger on his closure report next Monday.

To bridge the handover gap without relying on punitive measures, IT Finance must mandate a dedicated bucket, pre-allocated by the parent programme alongside the project budget, called the Shadow-OPEX line. It is sized before the first line of code is written, costed at fully-loaded internal rates, and held as a separate OpEx tranche so it survives project closure. It treats the transition not as a risk to be avoided, but as a standard phase to be financed. It funds two collaborative levers and requires two mandatory deliverables:

• The Transition Retainer (Funded). Two of the build engineers, two days a week, for the first eight weeks of operation, reporting into the receiving line manager but paid from the Shadow-OPEX line. The receiving teams those two engineers join on 4 January accept the reduced 0.6 FTE allocation for the Retainer period in writing, with their own delivery commitments adjusted accordingly and the gap funded from the same Shadow-OPEX bucket. Their job in the room is to sit with the receiving operators when something breaks, document each escalation live, and avoid fixing it alone.
• The Stabilization Warranty (Funded). A pre-approved budget block, held by the parent programme, explicitly designated to cover the receiving line’s operational friction for the first two quarters. This is not a penalty; it is the priced-in cost of early-life support. It incentivizes the line to accurately log the time they spend stabilizing the new system, rather than hiding it in their general OpEx to protect their own targets.
• The Blindspot Audit (Deliverable). A two-day pre-mortem in the final two weeks of the project, run by the disbanding team, addressed to the system receivers. It answers the question “what is going to surprise you in the first ninety days, and where in the code is it”.
• Cognitive Debt Sign-off (Deliverable). A single line on the project closure report, signed collectively by the build team in the final working week before disbanding, naming the system components whose operational knowledge sits exclusively in the heads of departing people. An honest inventory, captured while the signers are still on the project payroll.

The Retainer and the Warranty represent guaranteed base costs. However, to prevent a failing system from endlessly draining resources, the governance model requires an Operational Circuit Breaker.

This circuit breaker is tied to machine-generated observability data: the system’s change failure rate and mean time to restore service, measured against the DORA performance bands. If these metrics consistently breach the agreed baseline and the Stabilization Warranty is exhausted, the receiving line is formally empowered to pull the cord.

They do not escalate to assign blame, but to force a binary architectural decision from the steering committee. The governance framework leaves only two valid responses to a tripped circuit breaker: formally recall the original build engineers under an eighteen-month recall clause written into their post-project reassignment contracts (or release equivalent senior capacity from a parent-programme reserve held for exactly this case) and fund an architectural remediation phase, or deliberately decommission the new system and roll back. Attempting to force the line to quietly absorb a failing system is procedurally blocked.

Triggering this line depresses the reported project result initially, but it aligns the budget with reality. A project externalising its shadow-OPEX cost into the line has simply shipped its overrun into a different P&L, where the people who built the system can no longer help.

Ultimately, this entire governance apparatus remains a transitional crutch. The only sustainable way to completely avoid the handover tax is to eliminate the handover itself. Organizations that abandon temporary projects in favour of permanent, stream-aligned teams owning the system across its entire Product Life Cycle (PLC) do not need stabilization warranties. They own the consequences of their architecture from day one.

🩹 The Warranty Friction: Where the Governance Switch Snaps

The Stabilization Warranty and the Circuit Breaker carry specific boundary conditions. You need to know them before walking into the steering committee.

If your organisation runs strict per-project capitalisation tests under IAS 38 paragraph 57, the Stabilization Warranty fails the capitalisation criteria. Because it is explicitly earmarked for operational support, the cost lands on the P&L immediately as OpEx. The project’s reported margin drops without compensating EBIT relief. Your CFO needs to sit in the room when this is designed, not after.

The lever can also undergo gaming during the definition of the Circuit Breaker. A project sponsor holds a structural incentive to negotiate the baseline metrics so high that the breaker never legally trips. If the baseline is artificially inflated, the warranty budget drains, the system remains unstable, and the receiving line is left without the procedural right to pull the cord. The defence requires anchoring change failure rate and mean time to restore against the published DORA performance bands, rather than against an internally negotiated number.

Finally, there is the cultural friction of the Andon Cord. Even if the Circuit Breaker legitimately trips, line managers historically conditioned to “make do” and absorb bad software may hesitate to formally demand a remediation phase. The governance framework only works if senior leadership publicly supports the first line manager who pulls the cord to stop a failing system, proving the mechanism is a safety net, not a career trap.

🏁 The Bottom Line: The Bill Arrives in February

Markus has two options on Friday morning.

He can send the first email, the one currently sitting in Drafts. The receiving line will read it, file it, and complain in three weeks that the system behaves unstably. The complaint lands on Markus’s old desk, which now belongs to someone else. The two backend engineers will hear about the production incident through the grapevine and spend a Sunday afternoon helping out, off the books, because they wrote the code and they cannot bear to watch it burn.

The alternative is a different email. To Lehmann, copying the receiving line manager and the operations director. Subject: Project P-2026-0418 closure: shadow-OPEX cost not yet budgeted. Body: a short text explaining that the system is live, but the receiving line cannot operate it from 4 January at the quality the SLA requires. Eight weeks of part-time Transition Retainer from the build team is required, plus a Stabilization Warranty buffer for the first two operational quarters. Estimated cost: €150,000 — roughly €50,000 for the Retainer at fully-loaded internal rates, €100,000 for the Warranty — charged against the closing project’s parent programme. Without this allocation, the system degrades in production within the first quarter and the cost of recovery exceeds the cost of prevention by an order of magnitude.

This second email intentionally depresses the project’s closing result. It presents the steering committee with a fact they avoided asking for, and it requires Lehmann to perform an action his weekly-report template lacks a column for.

A People Lead saving an honest handover in Drafts understands the symptom without fixing the problem. The second email functions as the cheapest form of escalation available. It belongs sent.

Lehmann will receive it on Friday afternoon. He will read it once. And then, he will predictably dodge the financial demand. He will tick the closure-on-track status green in the weekly report on Monday morning at 08:14, because the project is technically on course to close on time and on budget. The formal closure sign-off two weeks later will carry the same colour. The amber risk note Markus added to the receiving-line section, two pages further in the same report, will simply be filed under “line responsibility from January”.

The two pages do not point at each other.

But Lehmann’s immediate reaction is secondary. The second email provides an authoritative date stamp. In February 2027, when the board report shows the project under budget and the operations line over budget, somebody produces the email. The question of who pays for the asymmetry shifts from diffuse to attributable. The alternative is paying for the handover each month until the system dies.

⏱️ TL;DR: The Drafts-Folder Audit

If you are a CTO or COO with three minutes to spare and a quarterly review next week, read this:

• Operate dwarfs build. Four decades of cost studies put maintenance and operation at forty to eighty percent of total lifecycle cost. Long-lived enterprise systems sit at the top of that range: roughly 1:4 between build and operate. Your project budget ends at the 1. The 4 gets paid by somebody else.
• Accounting drives the architecture. IAS 38 capitalises build cost as an asset, protecting short-term earnings. Operate cost hits the P&L immediately. CFOs label spend as project, creating teams that disband at go-live.
• Handovers run expensive because knowledge is unwritten. Skelton and Pais, building on Conway, show long-lived stream-aligned teams are organisationally cheaper than build-then-handover. You build it, you run it.
• The intermediate lever is a Shadow-OPEX line. Featuring a Transition Retainer, Stabilization Warranty, Blindspot Audit, and Cognitive Debt Sign-off. Triggered by early-life operational support needs. It intentionally depresses the reported project result.
• The lever requires a Circuit Breaker. Strict capitalisation regimes, gamified metrics, and a culture of absorbing bad software break it. If metrics fail, the receiving line must be empowered to pull the cord.
• Send the second email. Saving an honest handover in Drafts understands the symptom but fixes nothing. Make the asymmetry attributable in writing, with a date stamp.

🧾 The Receipts: The Accounting and the Architecture

If your CFO or steering committee asks where the 1:4 ratio, the Shadow-OPEX concept, or the handover-cost argument originate, put these references on the table.

• Conway’s Law: Conway, M. E. (1968). “How Do Committees Invent?” Datamation. Systems mirror the communication structures of the organizations that build them; decision bottlenecks become architectural bottlenecks. Read the paper here
• Team Topologies: Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow (ISBN: 978-1942788812). The empirical formalisation of the stream-aligned team pattern.
• You Build It, You Run It: Vogels, W. (2006). “A Conversation with Werner Vogels.” ACM Queue. The economic argument against the build-versus-operate split from inside a hyperscaler. DOI
• Capitalisation Constraints: IFRS Foundation. IAS 38: Intangible Assets. The accounting standard creating the incentive to label spend as project rather than as operate. Read the standard here
• The Unit Cost Blind Spot: Kersten, M. (2018). Project to Product (ISBN: 978-1942788393). The empirical case that capitalisation practice makes true product unit cost structurally invisible at the board level.
• DORA: The Enterprise Value of Safety & Flow: Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps (ISBN: 978-1942788331). The statistical proof, based on DORA metrics, that high-safety cultures and short-lived branches predict elite IT performance.
• The 40–80 Percent Maintenance Share: Glass, R. L. (2003). Facts and Fallacies of Software Engineering (ISBN: 978-0321117427). Fact 41 consolidates four decades of cost studies showing that maintenance and operation typically consume between forty and eighty percent of total software lifecycle cost.
• The Original Cost-Distribution Study: Boehm, B. W. (1981). Software Engineering Economics (ISBN: 978-0138221225). The foundational empirical work establishing that maintenance dominates the software lifecycle cost profile; the COCOMO data set Glass and later authors consolidate.
• Continuous Adaptation as Structural Cost: Lehman, M. M. (1980). “Programs, Life Cycles, and Laws of Software Evolution.” Proceedings of the IEEE, 68(9), 1060–1076. DOI. The empirical laws establishing that any productive system embedded in a real environment must change continually or progressively lose its usefulness — the structural reason operating cost dwarfs build cost over a system’s lifetime.