Every CTO or technology director has lived this scene: you spend weeks structuring a transformative project, gather the team, map the risks, choose the right architecture — and then walk into the boardroom to present. Ten minutes later, the CFO crosses their arms and asks: "But what is the return on this for the business?" And the project dies right there, not for lack of technical merit, but for lack of translation.
This is the central problem I see repeatedly in the companies I work with — from high-growth fintechs to large financial institutions like BTG, B3 and Bradesco. The technology is often excellent. The ability to communicate its value to those who make capital allocation decisions, almost always, is not.
In this article, I will share the framework I use to help CEOs, CTOs and founders measure, structure and present technology ROI in a way that the board understands, trusts and approves.
Why most technology cases fail at the board level
Before talking about formulas, we need to understand the diagnosis. Most technology investment cases fail at the board level for three structural reasons:
- Focus on technical solution, not on business problem. Presenting that you will migrate to Kubernetes or adopt a microservices architecture means nothing to a CEO. What they need to hear is what it solves, what it enables and how much it costs not to do it.
- Metrics disconnected from financial language. 99.9% availability, latency below 200ms, reduction of technical debt — these are valid indicators, but invisible to a CFO. They think in terms of EBITDA, cost per transaction, operating margin and regulatory risk.
- Absence of the cost of inaction. Most business cases show the cost of the investment. Very few clearly show the cost of not investing. This is often the turning point in the conversation with the board.
Correcting these three points already puts you ahead of 80% of technology budget requests that reach boards today.
The four-layer framework for calculating technology ROI
ROI, in its simplest form, is (Investment Gain − Investment Cost) ÷ Investment Cost. The challenge in technology is that gains are rarely direct and linear. That is why I work with four layers of value that, combined, build a robust business case.
Layer 1 — Reduction of operational costs. This is the easiest to quantify and should always be present. It includes reduction of legacy infrastructure, elimination of redundant licenses, automation of manual processes and decrease in production incidents. In a cloud migration I coordinated for a client in the financial sector, we mapped R$ 4.2 million in annual savings just from consolidating data centers and eliminating hardware maintenance contracts. That number alone already paid for the project within 18 months.
Layer 2 — Revenue gain or go-to-market acceleration. How much time does technology save in launching new products? What is the value of getting a feature live three months before a competitor? A well-built engineering platform can reduce the deploy cycle from weeks to hours. If each week of delay represents R$ 500 thousand in uncaptured revenue, the calculation becomes clear.
Layer 3 — Risk mitigation and compliance cost. This layer is underestimated, but it is often the most persuasive for boards of regulated companies. A legacy system that processes data without adequate controls exposes the company to fines, sanctions and reputational damage that can be measured. In the financial sector, a single notification from the Central Bank can cost not only the direct fine, but months of auditing, rework and customer loss.
Layer 4 — Strategic enablement. This is the hardest to quantify, but the most powerful narratively. The question is: what does this investment make possible that is not possible today? A unified database can enable generative AI models that transform the customer experience. A scalable architecture can enable an international expansion that is currently blocked by technical limitations. Here the ROI is potential, but should be presented with conservative and realistic scenarios.
Translating technical metrics into board language
One of the exercises I do with technical teams before a board presentation is what I call the "translation test": for every technical metric you want to present, you need to be able to answer in one sentence what it means for the business.
Here is how it works in practice:
- "We increased availability from 99.5% to 99.95%" becomes "We reduced annual downtime from 43 hours to 4 hours, preventing approximately R$ 8 million in blocked transactions and support costs."
- "We reduced deploy time from 3 weeks to 2 days" becomes "Our ability to respond to market demands increased 10x, which allowed us to launch 4 new products this quarter compared to 1 in the same period last year."
- "We migrated to serverless architecture" becomes "We eliminated R$ 1.8 million in fixed infrastructure costs and now pay only for what we use, with the elasticity to scale 20x during peaks without additional investment."
This exercise seems simple, but it is transformative. It forces the technical team to connect every architecture decision to a measurable business outcome — and that connection is exactly what the board needs to see.
How to structure the board presentation
The narrative structure matters as much as the numbers. After 20 years working at companies like IBM and AWS, and having supported hundreds of technology investment decisions, I have learned that the board makes decisions based on trust and clarity, not on volume of slides.
An effective technology ROI presentation should have the following five-block structure:
- The business problem today — Not the technical problem. The problem the CEO feels every morning. Response time to market. Growing operational costs. Regulatory risk. Loss of customers to more agile competitors.
- The cost of inaction — What happens if we do nothing? Projections for 12, 24 and 36 months. Include risk scenarios. This block is often the most impactful because it removes the investment from the category of "expense" and places it in the category of "protection."
- The proposed solution and its assumptions — Here you explain what will be done, in accessible language, without excessive technical details. What matters is conveying that you have a clear, executable plan with mapped risks.
- The ROI model — Present the four layers of value with conservative, moderate and optimistic numbers. Show the payback period. Make clear which assumptions underpin each number.
- Governance and tracking milestones — The board needs to know how it will track the return. Define clear KPIs, review dates and success criteria. This conveys maturity and control.
The role of generative AI in ROI measurement
Over the past two years, a growing portion of the investments I help structure involves generative AI. And here there is a specific challenge: the benefits are real, but often diffuse and difficult to isolate causally.
What I have seen work is starting with highly specific and measurable use cases. Instead of proposing "implement generative AI across the company," propose "reduce contract analysis time from 4 hours to 20 minutes, freeing up 60% of the legal team's capacity for higher-value activities." This level of specificity allows you to measure before and after with precision.
In a recent project with a company in the benefits sector, we mapped that AI automation of a single customer service flow generated savings of R$ 2.3 million per year in operating costs, while also increasing the channel's NPS by 18 points. These numbers, presented on the basis of a 90-day pilot, made the approval of the full investment practically automatic.
The lesson is: pilot before scaling, measure rigorously and present the expansion case with real data. Boards have far more confidence in evidence-based projections than in theoretical estimates.
Common mistakes that destroy credibility in the presentation
After having sat on both sides of the table — as a technology executive and as an advisor — I see some recurring mistakes that undermine even the best projects:
- Excessively optimistic projections without explicit assumptions. If you project 300% ROI in 12 months, the CFO will question every number. Be conservative and transparent about your assumptions. Credibility is worth more than impressive numbers.
- Ignoring hidden costs. Data migration, team training, transition period, legacy integrations — these costs are typically underestimated by 30 to 50%. Include them. The board will find out anyway, and it is better they hear it from you than from the audit.
- Presenting the project as a technical black box. The less the board understands what is being built, the more they distrust it. Simplifying is not underestimating the board's intelligence — it is respecting their time and context.
- Not having an owner for ROI post-approval. The investment was approved. Now what? Define who owns the return numbers and how they will be reported in results meetings.
Technology as the language of strategy, not of cost
The most profound shift a technology leader can make is to stop requesting budgets and start proposing strategic investments. The difference is not semantic — it is one of positioning.
When you come to the board with a budget request, you are in the position of someone who needs to justify an expense. When you come with an investment proposal, you are in the position of someone presenting a lever for growth or business protection. The same project, framed differently, has completely different outcomes.
The technology leaders I most admire — and have the privilege of working with — are those who have learned to think the way the board thinks: in terms of value, risk, time and competitive advantage. They did not abandon technical rigor. They added a second language: the strategic language of business.
If you have not yet mastered this second language, the time to start is now. The board is waiting.