The CFO asked me why we needed to spend €2M on a foundational piece of the platform nobody would see. I explained the architecture. She nodded politely and asked again. I had given her the right answer in the wrong language.
I’ve thought about that meeting a lot. Not because I was wrong about the architecture, I wasn’t. But because I walked in with a compelling engineering case and she walked out with an action item to “provide more business justification.” The frustration was mutual. And entirely my fault, now that I have thought about it.
The asset that never depreciates (on paper)
Every other capital asset the company owns gets depreciation treatment. The office building loses value on the books every year. The manufacturing equipment gets written down. The company vehicles have a schedule. These are standard practice, legally required, and intuitively understood by every CFO or accounting everywhere.
Your technology platform, the systems, integrations, and underlying infrastructure the entire business runs on, is also an asset. It generates value over time. It has a productive lifespan. It degrades with use and age. And unlike every other capital asset on the books, nobody is recording that depreciation anywhere. The deterioration is invisible in the accounts, quarter after quarter, until the moment it catastrophically isn’t.
- This is the conversation I didn’t have with that CFO. When I asked for €2M to invest in the platform, she heard something like: “I want to spend money to fix something that isn’t broken, for reasons I can’t fully explain or quantify.” That is a reasonable interpretation of what I said.
- What was actually happening: I was asking her to book the deferred maintenance on an asset that had been depreciating off the balance sheet for three years. The €2M wasn’t a new cost. It was accumulated depreciation, finally made visible, finally demanding to be paid.
The question she should have been asked, the question I should have asked ,isn’t “why do we need to spend €2M?” It’s “how much have we already spent on workarounds, incidents, and delayed delivery because we didn’t spend it earlier?” That number is almost always larger. It just never appears in a single line on a slide.
The interest rate that is never reported
Technical debt behaves like a loan you took out without reading the terms. I’ve written a lot about it in the past. The interest rate is variable and starts low. A few workarounds, some documentation that doesn’t exist, a handful of dependencies nobody fully understands. You pay a small premium every sprint, a little extra time, a few more bugs to trace. Manageable.
But the rate compounds. Every quarter you defer the platform investment, the interest increases. New features take longer because the platform can’t support them cleanly. Incidents take longer to resolve because nobody fully understands the system anymore. Good engineers leave because they don’t want to maintain it. (Ask me how I know) Eventually you hit the point where the quarterly interest payment exceeds the original principal. You are now spending more on the loan than the loan was ever worth.
What I should have shown that CFO was the interest rate. Not in architecture terms but in operational ones. Hours per sprint spent managing complexity instead of building. Average incident resolution time, trending up. Features requested in Q1 that shipped in Q4, or didn’t ship at all. Senior engineers carrying institutional knowledge of a system that’s never been documented. That is the interest payment. It’s real money. It just hides in the normal operating costs instead of appearing as a capital line item.
Why we don’t say this
Here is the part I find harder to admit. Most technology leaders know this framing. They’ve thought about it. They’ve drafted versions of it in their heads. They don’t say it.
The reason is not ignorance. It’s career safety or job security!
Naming the interest rate forces the question: who let it compound? If the platform has been quietly accumulating debt for three years, and you are now telling the board it will cost €2M to service it, someone in the room is going to wonder why that number wasn’t raised at €500K. If that someone is you, if you are the CTO who inherited this platform and understood its condition, then surfacing the full picture means surfacing a problem that predates your tenure and now lands on your watch.
So we smooth it. We put the risk in the risk register in language calibrated to generate minimum concern. We describe architectural problems as things we’re “monitoring.” We present roadmaps as certainties when we know they’re probability distributions. We frame deferred maintenance as optional investment rather than compounding liability. All of this is rational self-preservation. None of it serves the board.
The result is a CFO who approves decisions without the information she’d need to challenge them, and then expresses surprise when something goes wrong that the technology team saw coming for two years.
What to say instead
I’m still exploring this topic, becuase the CFO in that meeting wasn’t wrong to push back. She was doing her job with the information she had. The failure was mine for not giving her a financial framing within an architecture briefing.
Two things, translated into her language:
The cost of not doing this. Not technical debt is accumulating. That means nothing from a governance chair. Instead: here is what we are spending every quarter because the platform can’t do what we need it to do. Delivery drag, features that take three weeks instead of one because the architecture requires four teams to coordinate. Add to that the incident overhead. Average resolution time up 40% year on year. Headcount carried to manage complexity that a healthy platform would handle automatically. Add it up. That is the quarterly interest payment. Multiply by four. That is the annual cost of deferral. Compare it to the investment. If the investment is smaller, you have a business case. Most of the time it is.
The framing shift. Platform investment is not spending. It is asset maintenance that has been deferred until it became a capital project. The choice is not invest or save €2M. The choice is invest €2M now or spend significantly more in eighteen months under worse conditions, after something breaks. That is a risk-adjusted decision, and it belongs on the board’s agenda alongside cybersecurity and regulatory exposure, not in a separate technology bucket that competes with features.
Honestly?
I want to be careful here, because the natural ending for this kind of article is: speak the right language, and the CFO will approve the investment. Sometimes that’s true. More often not.
Speaking the right language changes what the conversation is about, not necessarily the outcome. There is a difference between “no, we don’t understand the value” and “no, we have higher priorities this quarter.” The first is a communication failure. The second is a governance decision. You can work with the second. You can push back on it, you can negotiate, you can ask the board to formally own the risk of deferral. None of that is possible when the conversation has never left the architecture review.
The CFO who understands the interest rate and still says “not this year” is doing her job with full information. That is a better outcome than the CFO who says yes because she didn’t know what she was approving.
What I should have walked into that meeting with was a one-page case: quarterly cost of deferral, three-year compound, two scenarios for the risk profile. Not slides. Not diagrams. A number she could defend to an auditor and a risk she could put on the register.
She might still have said no. But at least we’d both have known why.
Listening to while writing: Fugazi, In on the Kill Taker. Because some arguments need to be made loudly before anyone listens.
Leave a Reply