A board meeting from earlier this year. A large Indian firm, name irrelevant. The CEO has just walked the directors through a slide showing the company's technology investment over the last three years. Hundreds of crores. Several major platforms delivered. A respectable number of AI pilots in production. The slide ends with what is meant to be a victory line — technology has been a strategic enabler of our growth.
A non-executive director — a retired CEO, sharp, reads everything — asks one question. What was the return on that spend, separable from the underlying business growth?
The room goes quiet. The CFO offers a cost-savings number. The CIO offers a productivity-improvement number. The business heads each claim a slice of the revenue growth as technology-enabled. The numbers, when added up, exceed the total spend by a comfortable margin. The director smiles politely. He does not believe any of it. And he is right not to.
This essay is about the most uncomfortable conversation in any boardroom — the honest one about whether the technology spend is actually working. Eight principles on returns, project failure, and what separates the firms that genuinely extract value from technology investment from the ones that simply spend.
If the first essay was about what to do before the rupee is committed, this one is about what happens after. The spending part of the work is the easy part. The returns part is where most firms quietly fail.
Why technology ROI is genuinely hard to measure
Let me start with an admission that most consultants will not make. Technology ROI is genuinely hard to measure. Not because the people doing the measurement are lazy or incompetent. Because the cause-and-effect relationships are inherently difficult to isolate.
A new core banking system goes live. Six quarters later, retail deposits are up fifteen percent. Was it the system? Or was it the new branch network, the better deposit pricing, the change in interest rate environment, the improved customer service team that was hired around the same time? The honest answer is — some combination, in proportions that no one in the firm can credibly disentangle. The system gets credit when the numbers are good and gets blame when they are bad. Neither attribution is rigorous.
The harder version of the problem is that the largest returns from technology investment are often the ones that are hardest to measure. Capability gains. Optionality. The ability to do something next year that the firm could not do this year. None of those show up in the year-one cost-benefit analysis. All of them are real. And the firms that consistently outperform on technology returns are the ones that have stopped pretending to measure what cannot be measured, and started thinking carefully about what can be assessed even if not formally measured.
This is the place where I differ from the standard CFO position. The CFO's job, properly done, is to demand rigour. Show me the numbers. But applied dogmatically to technology investment, this discipline produces a perverse outcome. The investments that get funded are the ones with measurable returns — which are usually the smallest, most incremental ones — and the investments with the largest potential returns get starved because their cases cannot be made on the CFO's terms.
The firms that have figured this out have a two-tier process. Short-cycle technology investments — automation projects, productivity tools, infrastructure modernisation — go through a standard ROI gate. Long-cycle, capability-building investments — data platforms, AI infrastructure, foundational rebuilds — go through a different gate that asks different questions. What capability does this give us? What can we do next year that we could not do this year? What competitive position does this protect or extend? The gates are different because the questions are different. Forcing both kinds of investment through the same ROI gate is one of the most reliable ways I know to systematically under-invest in the things that compound.
The senior leader's job here is not to abandon rigour. It is to recognise that there are two kinds of rigour, and the firm needs both.
Why CEOs kill good projects too early
Almost every meaningful technology investment follows a J-curve. Things get worse before they get better. Productivity dips during the transition. Costs spike during implementation. The new system, in its first six to eighteen months, often performs worse than the old one it is replacing.
This is not a sign of failure. It is the structurally expected shape of a real change.
The problem is that boards, CEOs, and CFOs almost always view the dip as a failure signal. The project sponsor gets called in. The benefits case is re-examined. The budget gets cut. The most senior champion of the project, sensing political risk, quietly stops defending it. And then the project gets killed at exactly the moment it was about to start producing the returns it was always going to produce.
I have watched this pattern play out at firm after firm. A new CRM system rolled out across a sales force takes nine months before sales productivity returns to the pre-rollout baseline. The third quarter looks terrible compared to the previous third quarter. The CEO, under pressure from analysts, asks whether the project was a mistake. The CIO, sensing the wind, agrees to "scope down." The momentum is lost. Fifteen months in, the firm is still using parts of the old system, parts of the new system, and a layer of workarounds that will outlast both. The CRM project is recorded in the corporate memory as a failure. It was not. It was a victim of the J-curve.
The discipline that works here is committing, in writing, before the project starts, to a specific J-curve tolerance. We expect productivity to decline for nine to twelve months. We will not interpret that decline as failure. We will interpret it as the cost of the transformation. We will only intervene if the dip is deeper than X or longer than Y. Putting this in writing, signed off by the CEO and the board, is what gives the project room to breathe through the difficult middle.
In the Indian context, the J-curve discipline is even more important than in Western firms — because Indian boards are typically more impatient with quarterly performance dips than their global counterparts. The pressure to "show results" can kill any project that does not deliver in the first two quarters. The firms that have built durable technology platforms in this market are the ones whose CEOs have, deliberately and sometimes unpopularly, defended the J-curve in front of their boards. The CEOs who have not — who allowed the dip to be interpreted as failure — have left a trail of half-done projects and the cumulative scepticism that comes with them.
Why most technology projects fail (and it is almost never the technology)
The McKinsey research that gets cited at every technology conference is the one that says seventy percent of digital transformation initiatives fail to meet their objectives. The number is roughly right. The interpretation is usually wrong.
The standard interpretation is that the technology was bad. The vendor over-promised. The integration was too complex. The platform did not perform.
Almost none of this is true.
In my experience — and the academic research, when read carefully, agrees — the dominant cause of technology project failure is organisational, not technological. The technology works. The organisation around it does not absorb it. The processes were not redesigned. The roles were not changed. The incentives still rewarded the old way of working. The middle management layer was uncomfortable with the new tools and quietly resisted them. The training was inadequate. The data hygiene was poor. The internal political champions left, and there was nobody to defend the project's pace.
The pattern shows up everywhere. A bank rolls out a new origination platform that, on paper, should reduce loan processing time by sixty percent. Six months in, processing time is down by eight percent. The platform is fine. The branch managers are still requiring the same paperwork they always did, because their performance reviews still depend on documentation completeness measured the old way. The customer-facing process is unchanged. The technology is being used as a faster way to do the old process — which is not what it was supposed to do.
I have seen this exact pattern in lending, in claims, in onboarding, in customer service. The technology is roughly fine. The technology absorption is not.
The leadership implication is uncomfortable. The hardest, most expensive part of any major technology project is not the technology. It is the work of redesigning processes, changing incentives, retraining people, and politically defending the change against the constant gravitational pull of the old way of working. Most firms under-invest in this work by a factor of three or four. They budget twenty percent of the project for change management. The honest number is closer to fifty.
The firms that get this right tend to have one thing in common. The technology project sponsor is a senior business leader, not the CIO. The CIO is a partner. The accountability for absorption sits with the business. When the project goes badly, the right person owns the failure — and is therefore motivated to do the unglamorous work that prevents the failure in the first place.
Where eighty percent of the value lives
Closely related to the absorption problem is what I have come to call the last-mile problem. Eighty percent of the value of any technology investment lives in the last twenty percent of the rollout. And that last twenty percent is, almost without exception, where firms run out of energy.
The pattern is familiar. The platform goes live in the first business unit. The early adopters love it. The internal case study gets written. The firm celebrates. And then the rollout stalls. The next business unit is harder. The data is messier. The processes are less standardised. The local champions are less enthusiastic. The CIO's attention has moved to the next priority. The CEO has stopped paying close attention because the project is no longer in the headlines. The third and fourth business units never quite get there. The last few branches keep using the old system. The technology is officially "rolled out." In practice, sixty percent of the firm is using it, forty percent is using something else, and the value the platform was supposed to produce never fully materialises.
I sat with a CIO last year who walked me through his firm's last five major technology projects. In every single one, the gap between the promised value and the realised value was attributable to the last-mile problem. The technology delivered. The first wave of adoption delivered. The completion never happened. He estimated the cumulative cost of incomplete rollouts across those five projects at over two hundred crores in foregone value.
The discipline that works here is unglamorous. Define the rollout as complete only when the last business unit, the last branch, the last team is fully migrated. Track adoption percentage as a board-level metric until that number reaches ninety-five percent. Resist the temptation to declare victory at sixty. The CEOs who have done this — and I know a small number who have — describe it as the most disciplined and the most boring work they have ever done. The boredom is precisely the point. It is boring because it is unrewarded externally. No analyst report celebrates the firm that completed its rollout. The market only notices the one that started one. And so the firms that complete are the ones whose CEOs are willing to do work that nobody else will reward them for.
This is, in many ways, the inverse of the J-curve principle. The J-curve is about not killing projects too early. The last-mile principle is about not abandoning them too late. Both errors come from the same root cause — insufficient leadership stamina across the full lifecycle of a major investment.
Tech debt as a balance sheet item
Every CFO understands that the company has a balance sheet. Most CFOs do not understand that the company also has a technology balance sheet — and that it is, in most firms, far more poorly managed than the financial one.
Technical debt is the accumulated cost of past technology decisions that were optimised for short-term delivery rather than long-term sustainability. It includes legacy systems that should have been retired years ago. Customisations that were faster to build than to integrate. Workarounds that became permanent. Third-party dependencies that nobody in the firm understands anymore. Documentation that was never written or has gone stale.
Technical debt accrues interest. Every year that the legacy system is not retired, the cost of retiring it goes up. Every year that the workaround stays in place, more processes get built on top of it, making it harder to remove. Every year that documentation is not maintained, more institutional knowledge walks out the door. The interest is real, even if it does not show up in any GAAP report.
The firms that manage this well treat technology debt as an explicit balance-sheet item. They estimate it. They report it. They reserve a portion of every annual technology budget — usually fifteen to twenty percent — for paying it down. The debt-paydown work is unglamorous. It produces no new features. The CEO cannot put it on a slide. But the firms that consistently allocate to it have, over a decade, dramatically lower technology cost ratios than the firms that do not.
The Indian BFSI industry is, by international standards, carrying an enormous technical debt load. Most of the large banks are still running core systems that were architected in the 1990s, on technology stacks that are now expensive to staff and slow to change. The firms have been deferring the paydown for so long that the size of the debt now exceeds what any single year's budget can absorb. Which is the worst possible position for a balance-sheet liability to be in. The interest keeps growing. The capital required to clear it keeps growing. And the firms keep finding reasons to put off the work for one more year.
The discipline I recommend is the same one I have given on every board I have sat on. Make the technology debt visible. Estimate it. Report it. Allocate to its paydown every year, without exception. The firm that does this consistently — even at the cost of slightly slower feature delivery — will, over time, end up with a far more efficient technology stack than the firm that does not. The compounding goes both ways.
Same technology, ten times different outcomes
This is the principle that, of all thirty in this series, I find the most under-discussed and the most consequential.
The same technology, deployed in two different organisations, produces wildly different outcomes — sometimes by a factor of ten — depending on the talent that uses it.
The conventional view is that technology produces value. The view I have come to hold is that technology enables value, and talent extracts it. Without the talent, the technology is dormant. With the talent, the technology compounds. The same CRM system, the same analytics platform, the same AI tooling — in two different firms, will produce two completely different orders of magnitude of value.
I have seen this most clearly in data and analytics. Two banks I worked with around the same time both bought roughly the same modern analytics stack. Same vendors. Same architecture. Roughly the same investment. One of them, three years later, was making consistently better credit decisions than its peers and reducing its loss rate by 80-100 basis points. The other was generating beautiful dashboards that nobody read. The technology was identical. The talent was not. The first firm had hired a small team of genuinely sharp data scientists, given them direct access to the business problems, and protected them from being absorbed back into a generic analytics function. The second firm had bought the platform and assumed that the value would flow from the platform. It did not. It never does.
This has profound implications for how senior leaders should think about technology spending. The investment in the platform is roughly half the investment. The other half is in the people who will use it. Most firms get this ratio badly wrong. They spend ninety percent on the platform and ten percent on the talent — and then are puzzled when the platform does not produce the returns the business case promised.
The mature posture is to think of every major technology investment as a paired investment. We are investing X in the platform and Y in the people. Both numbers must be defensible. The firms that do this consistently end up with a small number of genuinely high-value technology assets that are extracting many multiples of their cost. The firms that do not end up with a large number of underutilised platforms producing average results.
The CEO's question on this principle is uncomfortable but unavoidable. For our most important technology platforms — do we have the talent to extract their value? Or do we just have the platforms? If the honest answer is the second, the platform investment was, in important ways, premature.
When to walk away
Every major technology programme reaches a point — sometimes once, sometimes more than once — where the right answer is to stop. To walk away. To write off the investment so far and accept that the path being followed is not going to lead where the firm needs to go.
This is the hardest decision a senior leader will make in technology. Almost nobody makes it well.
The reason is sunk cost. The firm has already spent two hundred crores on the platform. Senior careers are tied to its success. Vendor contracts are signed. The board has been told, repeatedly, that the project is on track. Walking away looks like an admission of failure. Continuing looks like resilience.
But in technology, more than in almost any other domain, the right move is sometimes to walk away. The platform that was a good bet three years ago may be the wrong platform now because the underlying technology has shifted. The vendor that looked strongest at the start of the implementation may be losing relevance. The architecture that made sense in 2022 may not make sense in 2026. The cost of continuing on the wrong path is almost always greater than the cost of stopping. And yet stopping is what senior leaders find hardest to do.
The discipline that works here is the pre-commitment to a kill criterion. At the start of the project, the leadership team agrees in writing what would constitute a reason to walk away. Not what would slow the project down. What would kill it. If the platform does not pass these specific tests by this specific date, we will stop. We will accept the write-off. We will redirect the capital. Putting this in writing, before emotion is involved, is what makes it possible to actually invoke when the conditions are met.
The firms that have walked away from major technology programmes well — and I have watched a small number do it — describe the experience the same way. It was the hardest thing we did in that decade. It was also unambiguously the right thing. The capital that was redirected from the failing programme to the right one produced more value in the next two years than the failing programme would have produced if continued for five.
Walking away is not a failure. The failure is staying. The senior leader who can distinguish the two — and act on the distinction — is the leader who creates more shareholder value over a career than the one who cannot.
The new mathematics of AI returns
The last principle in this episode is the one that has caused more confused boardroom conversations than any other in the last two years. How do you measure the ROI of AI?
The honest answer is — not the way you measure other technology ROI. The mathematics is genuinely different.
Traditional technology investments produce deterministic returns. The new system processes loans 30% faster. The automation reduces headcount by X. The integration eliminates Y manual touchpoints. You can model these. You can compute a payback period. You can defend a business case.
AI investments produce probabilistic returns. The system will work better than the alternative on average, sometimes much better and sometimes worse, with a distribution that depends on the use case, the data, the prompt design, and the human review process. This is not a deterministic system. It is a stochastic one. Applying deterministic ROI logic to it produces nonsense — usually understatement of the value, occasionally overstatement, almost never accuracy.
The firms that are getting AI ROI right are the ones that have stopped trying to apply the old framework and have built a new one. The new framework asks different questions. What is the expected improvement, with a confidence interval? What is the variance of the improvement — meaning, how often does the system underperform, and what is the cost when it does? What is the capability multiplier — meaning, what becomes possible at all that was not possible before, even if hard to value?
In the underwriting work I am closest to, the AI-augmented underwriter is, on average, moderately faster and somewhat more accurate than the unaugmented one. The traditional ROI calculation captures the average and produces a modest number. What it misses is the variance — the unaugmented underwriter has a long tail of bad decisions that the augmented one substantially reduces. And it misses the capability multiplier — the augmented underwriter can take on a class of risks that the unaugmented one was simply not equipped to handle. Both of those effects, properly valued, dwarf the average productivity gain. The firms that miss them are systematically under-investing.
The CEO's discipline on this principle is to actively resist applying the old ROI framework to AI investments — not because rigour does not matter, but because the wrong rigour is worse than uneven rigour applied carefully. Insist on a probabilistic frame. Insist on variance and capability questions, not just averages. And accept that some of the most important value will only become measurable in retrospect, two to three years after the investment was made. That is not an excuse for poor analysis. It is an accurate description of how this particular kind of return actually shows up.
The honest scoreboard
Eight principles on returns, project failure, and what separates the firms that genuinely extract value from technology from the ones that simply spend.
If I had to compress all eight into a single line, it would be this. The firms that get returns from technology are not the ones with better technology. They are the ones with better organisational discipline around the technology — measurement that respects what cannot be measured, projects that survive the J-curve, change management that goes the last mile, technical debt that is paid down, talent that is paired with platforms, kill criteria that are honoured, and AI ROI thinking that has been rebuilt for a probabilistic world.
None of that is technology work. All of it is leadership work. Which is why most senior leaders find this conversation uncomfortable — and why the ones who have made peace with it produce returns that compound while everyone else's wash out.
The next and final essay in this series moves from execution to strategy. Why every classical principle of technology investment is being rewritten by AI, and what that means for the next decade of leadership. That is the harder conversation. It is also where the next decade of competitive advantage will be made.
But first, the work of returns. Get this right, and the strategy conversation becomes possible. Get it wrong, and no strategy will save you.