CIOs speak in sprints; CFOs speak in quarters. That language barrier is the number one reason R&D budgets get slashed.
For the past decade, the relationship between engineering and finance has been defined by a convenient truce. As long as interest rates were near zero and growth was the primary directive, the CFO was willing to treat R&D as a black box. The mandate was simple: hire the best engineers, adopt the fastest methodologies and capture the market. In that environment, agile was the perfect operating system. It prioritized speed, adaptability and continuous delivery.
But the economic weather has changed. The “growth at all costs” era has been replaced by the “efficiency economy,” and the truce is over.
In boardroom after boardroom, I am seeing a new friction emerge. Engineering teams are delivering more code than ever, celebrating record velocity and successfully completing complex agile transformations. Yet finance sees something entirely different. They see rising operating expenses, stagnant capital assets and a cloud bill that scales faster than revenue. From the CFO’s perspective, the agile transformation looks less like an innovation engine and more like a black hole where capital goes in but less clarity comes out.
The problem is not that agile is broken. The problem is that agile and finance speak two fundamentally different languages. And right now, the lack of translation is costing CIOs their credibility.
Tribal dialects: Story points vs. asset value
The core of this conflict lies in how these two functions define value.
Modern engineering teams live in a world of epics, stories and velocity points. Success is measured by the burn-down chart, which tracks the rate at which work is completed. This is a purely operational metric. It tells you how fast you are moving, but it says nothing about the economic destination.
The product debt audit
While agile dashboards track velocity (activity), this dashboard tracks capitalization (value). In this forensic audit of a “high-performing” team, 75% of capacity is consumed by non-accretive maintenance work. The CFO sees this not as an R&D investment, but as a depreciating asset with a 25% ROI.
Finance lives in a world of capitalization, amortization and impairment. To a CFO, software development is not just work. It is an investment activity intended to create a long-term asset. When a company spends $10 million on engineering salaries, the CFO needs to know how much of that spend built a new asset that can be capitalized and depreciated over time, and how much was simply maintenance that must be expensed immediately.
I recall a pivotal meeting with a CFO at a large enterprise SaaS company. I was presenting our roadmap, filled with “refactoring” and “technical debt paydown.” He stopped me and said, “Richard, I don’t care about your code quality. I care about my EPS. If you tell me this work is maintenance, I have to expense it today, which hurts our earnings. If you tell me it’s enhancing the asset, I can depreciate it over five years. Help me help you.”
It was a lightbulb moment. He wasn’t trying to stifle innovation. He was trying to manage the company’s valuation. We weren’t speaking the same language.
Without a translation layer, agile’s continuous nature looks like chaos to an auditor. In a modern environment where a team might ship bug fixes, new features and refactored code in a single afternoon, the financials get lost in the noise.
The capitalization matrix
To solve this translation failure, I stopped trying to teach finance about agile and started teaching engineering about capitalization. I worked with a team of engineering managers to create what we called the “capitalization matrix.”
This was a simple 2×2 grid that we reviewed during every sprint planning session. The vertical axis was “functionality” (new vs. existing) and the horizontal axis was “architecture” (new vs. existing).
If a ticket involved new functionality on new architecture, it was clearly CapEx. If it was existing functionality on existing architecture (bug fixes), it was clearly OpEx. The friction always happened in the gray zones: refactoring code to enable future scale.
Engineers view refactoring as a critical investment. Finance views it as maintenance. To bridge this, we instituted a “narrative tag” in Jira. If an engineer tagged a refactoring task as CapEx, they had to write a one-sentence “asset defense” explaining exactly how this work extended the useful life of the software or enabled specific new revenue capabilities.
This forced the engineers to think in economic terms. They couldn’t just say “cleaning up code.” They had to say “restructuring the database to support the enterprise tier launch.”
The impact was profound. Our capitalization rate stabilized, the CFO stopped auditing our sprints and the engineering team felt empowered because they understood how their technical decisions impacted the company’s P&L. We turned a compliance chore into a strategic alignment tool.
The death of the “trust me” economy
For years, technical leaders have operated on a “trust me” model. The narrative was that software development is an art form, inherently unpredictable and resistant to the rigid constraints of standard accounting.
Today, that cultural shield has evaporated. As the Financial Accounting Standards Board (FASB) has updated guidance to explicitly recognize iterative development, “it’s too complicated to track” is no longer an acceptable excuse.
I see this play out in steering committee meetings constantly. The CIO presents a roadmap filled with exciting technical initiatives. The CFO listens, nods and then asks a single question: “How does this depreciate?”
It sounds like a bureaucratic question, but it is actually a strategic one. If the work cannot be capitalized, it hits the P&L immediately and lowers earnings per share. If it can be capitalized, it spreads the cost over five years and protects profitability.
The most successful CIOs I advise have stopped fighting this reality. Instead, they have educated their teams on the why. They explain to their engineering managers that capitalization is not an accounting trick. It is the mechanism that allows the company to hire more engineers. By shielding the P&L from immediate expense, legitimate capitalization creates the fiscal space for headcount growth.
The governance solution: Defining the asset
Gartner research highlights that high-performing organizations solve this not by forcing engineers to become accountants, but by establishing clear capitalization triggers within their development process.
This begins with a concept I call technical materiality. Not every line of code is an asset. Minor enhancements, UI tweaks and routine dependency updates are the cost of doing business. Substantive functionality that extends the useful life of the platform or creates new revenue potential is an asset.
Defining these thresholds protects the team. When engineering leaders can articulate that they are below the capitalization threshold on this sprint because they are paying down debt to accelerate Q4 velocity, they change the conversation. It shifts from “Why are you slow?” to “We are choosing to invest in stability.”
Furthermore, metrics must evolve beyond velocity. Leading organizations now track the maintenance-to-innovation ratio. When engineering time tracking reveals that the vast majority of effort is skewed heavily toward keeping the lights on, the organization has effectively entered a state of technical bankruptcy. Conversely, if a team claims they are spending 100% of their time on innovation with zero maintenance, that is an immediate red flag for audit risk.
McKinsey research on developer velocity emphasizes that top-tier companies actively manage this balance, using clear data to ensure that innovation capacity isn’t slowly eroded by unplanned maintenance work.
Conclusion: The CFO as a partner
The goal of this translation is not just compliance. It is alignment. When a CIO can walk into a board meeting and explain their roadmap not in terms of features shipped but in terms of assets created and capital deployed, the dynamic changes. The CFO stops hating the agile transformation because they finally understand it. They can see the direct link between the messy, iterative work of the sprint and the clean, long-term value on the balance sheet. In the efficiency economy, financial fluency is the ultimate soft skill for technical leadership.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?
Join the Foundry Expert Contributor Network!
The Foundry Expert Contributor Network is a free platform for IT experts to share their stories and insights in a way that truly resonates with their peers and their industry – after all, who better to tell the truth of what’s happening in IT than those living it?
The Expert Contributor Network is a collection of blogs written by you and other leading IT practitioners about the technology, business opportunities and challenges you face every day. Work with our award-winning editors to craft your own posts, published to the pages of CIO, Computerworld, CSO, InfoWorld and Network World. You can find recent examples here.
What you’ll do
We’re looking for 1,200-1,500-word articles on a variety of topics, and our editors can support you in building your post. We are interested in topics including artificial intelligence, cloud computing, data management, enterprise applications, emerging technology and more. In fact, here’s a look at our core topics:
We’re interested in a first-person perspective of your lived experience in the trenches as an IT and business decision-maker, your in-depth knowledge about the everyday challenges of senior IT- and business leaders, the considerations and calculations that go into making tough decisions.
What we’ll do
For our part, we’ll do anything to enable you on all organizational matters, so you as a contributor can focus on writing content relevant to peers and our community of technology decision makers.
Provide an experienced editor to optimize your article for our audience, and to ensure alignment with our style guide and brand standards.
Publish the article on the most relevant brand website.
Promote it across our social channels, tagging both you and your organization for maximum visibility and re-sharing.
We’ll also reach out to you regularly to participate voluntarily in a crowd-sourced article, where we will present the thoughts, ideas, reactions and opinions of a variety of C-level IT and business decision-makers in one story. And, as the network grows, we’ll produce a monthly email newsletter featuring content from the Expert Contributor Network.
What are the next steps?
Simply register your interest in the form below, and we’ll be in touch.
An additional good next step would be to develop a pitch for an article with all the above in mind. You could choose any of the areas we mention above, but we’re also very open to hearing what stories you want to tell. The pitches don’t need to be much more than a working title/topic, and a few brief sentences synopsizing the article’s focus.
With that, we can approve as-is, or work with you to develop the story a bit more to ensure it will best resonate with an audience. We ask all contributors to sign and return a simple Writer Agreement. It’s a standard end-user agreement that is as much for your protection as it is for ours.