A scene that has played out in too many board meetings I have sat in over the last year. The CIO presents a technology roadmap. It is detailed, expensive, and runs three years out. The CFO asks what the return looks like. The business heads each push for their own priorities to be funded first. Someone mentions AI. Someone else mentions technical debt. The board, depending on its composition, either pushes for more ambitious investment or worries that the company is spending faster than it is learning.
And underneath all of it sits a question that almost nobody in the room can answer with real conviction. Are we spending the right amount, on the right things, in the right way?
I have come to believe that this is the single most important strategic conversation a senior leader will have in the next decade — and the one most senior leaders are least equipped to lead. Not because they are not smart. Because the conversation has changed shape three times in five years and the language we use to describe it is still drawn from the era of mainframes.
This is the first of three essays on what I have come to think of as the returns on technology. Thirty principles, distilled to twenty-four, that I think a CEO, COO, or board member should be able to articulate in their own words. Not because frameworks matter. Because the boards I sit on are increasingly populated by people who have noticed, correctly, that the cost of getting this wrong has gone up — and that most management teams cannot defend their technology choices when pressed.
This first essay is about the mindset. Eight principles on how to think about technology spending before a single rupee is committed. The next two essays go deeper — into returns and execution, and then into strategy itself. But the mindset is the foundation, and I have watched too many sophisticated firms get every downstream decision wrong because the upstream posture was set wrong.
Tech as cost, or tech as capability
The first decision a leader makes about technology is not a budget decision. It is a posture decision. And the posture is almost always invisible — buried in the language of monthly review meetings, in the way the CIO is treated in the executive committee, in whether the technology line in the P&L is described as a cost or as an investment.
There are two postures, and I think they explain almost everything else.
The first treats technology as a cost. A necessary expense, like rent or utilities, to be minimised where possible. Companies in this posture run their CIO function as a service organisation. They benchmark IT spend as a percentage of revenue and feel pleased when it is below the industry median. They treat outages as performance failures rather than as signals about underinvestment. The CIO, in this world, is a procurement officer with a technical title.
The second posture treats technology as a capability — something that, like brand or distribution or talent, compounds when invested in well and decays when neglected. Companies in this posture do not ask whether their tech spend is high or low. They ask whether it is producing more or less capability per rupee than their competitors.
The difference is not semantic. It changes who owns technology decisions, how they are evaluated, and what stories the company tells itself about its own progress. A cost mindset asks: what can we cut? A capability mindset asks: what can we compound?
The Indian BFSI industry is full of companies trapped in the first posture. The CIO reports to the CFO. The technology budget is set as a percentage of revenue. Vendor management is treated as the senior tech function. And then — invariably, every two or three years — the CEO discovers that a competitor has done something the firm cannot match within eighteen months, and the panicked rush begins. The right amount of money is spent. The wrong posture has prevented it from compounding into anything.
The practical implication is uncomfortable but clear. If your organisation talks about the IT budget rather than our technology capability — if your CIO reports to the CFO rather than the CEO — if technology investments are evaluated like cost reductions rather than like product launches — then your posture is already determining your outcomes, regardless of how much you spend.
The fix is not a budget increase. The fix is a frame.
The seventy-twenty-ten allocation
Once a company has settled on the capability posture, the next question is allocation. Not how much, but how distributed.
The framework that matters here is the seventy-twenty-ten rule — sometimes called Run-Grow-Transform. The principle is simple. Roughly seventy percent of technology capital goes to running the business — keeping the lights on, maintaining systems, ensuring uptime, paying for licences. Roughly twenty percent goes to growing — improving existing products, enhancing customer experience, expanding capacity, reducing cost. Roughly ten percent goes to transforming — funding bets that may or may not pay off but that, if they do, change what the company is.
The exact percentages vary by industry and stage. The principle of explicit allocation across the three buckets is what separates mature investors from the rest.
Most mid-sized Indian firms, when they actually audit their spending, discover something uncomfortable. Their run-the-business spending is closer to ninety percent. Their grow spending is starved. Their transform spending is essentially zero — dressed up as a few experimental pilots that nobody has the conviction to scale. The transform budget is real. It is just so small that any project funded under it cannot achieve scale before it is killed in the next budget cycle.
I sat with the CFO of a mid-sized Indian bank last year who showed me his technology investment ledger. He was proud of it. The numbers were clean. The projects were named. The approvals were documented. I asked him a simple question — what fraction of this is genuinely transformational, in the sense that it could change the answer to "what business are we in" three years from now? He thought about it for a long time. Eventually he said, probably less than one percent. He was not embarrassed. He was just honest. And his is one of the more sophisticated banks in the country.
The senior leader's question is not whether seventy-twenty-ten is the right ratio for their business. The right ratio depends on competitive intensity, regulatory pressure, and strategic ambition. The question is whether the allocation is explicit at all. Most companies do not allocate. They spend. And the spending pattern, viewed in retrospect, reveals priorities the company never deliberately chose.
The discipline I recommend to every CEO I work with is this. Once a year, before the budget cycle starts, sit down with the CIO and CFO and force the run-grow-transform split into writing. Not as a target. As a current state assessment. Most leaders, doing this exercise honestly for the first time, are shocked by what they find.
Build, buy, partner — and now the AI question
The build-versus-buy decision is the oldest debate in enterprise technology. The classical version goes something like this. Build what differentiates you. Buy what is commodity. Partner where neither makes sense alone.
The principle is sound. It has accumulated decades of complications. Cloud changed it. SaaS changed it again. And AI is changing it for a third time, faster than any earlier wave.
The classical case for building is differentiation. The case for buying is speed and predictability. The case for partnering — increasingly common as ecosystems mature — is that some capabilities are too important to outsource entirely but too non-core to build alone.
In Indian financial services, the playbook has been mostly buy-with-heavy-customisation. The largest banks adopted Finacle, TCS BaNCS, or similar core platforms and then customised them so heavily that they ended up with effectively bespoke systems anyway — at considerably greater cost than building would have been. The regret is rarely articulated, but it is visible in the technology debt these firms now carry.
AI has introduced a new variant of the trilemma. The question is no longer just build-versus-buy software. It is whether to train your own foundation model, fine-tune an existing one, or use a general-purpose model through an API. The economics are still being discovered, but the pattern is clear. Building your own foundation model is justifiable only for a handful of firms — those with both unique data and the engineering depth to use it. For everyone else, the right answer is some combination of API-level consumption and selective fine-tuning on proprietary data.
The senior leader's mistake I see most often is treating build-versus-buy as a one-time decision. It is not. The cost of building has been falling for decades. The cost of falling behind on what you bought has been rising. The decision must be re-examined every two to three years, by category, in writing. The firms that get this right tend to have an explicit doctrine — this is what we build because it differentiates us, this is what we buy because we are not in that business, this is what we partner on because the value is shared. The firms that get this wrong default to whichever option is loudest in the room. Usually the vendor with the most aggressive sales motion.
If I had to give a single piece of advice on this principle, it would be — write the doctrine down, re-read it every year, and if you cannot defend any line of it, change that line.
The hidden two-thirds
If there is one number that almost every CFO gets wrong on technology investments, it is the total cost.
Licence fees and implementation costs — the visible numbers in the procurement contract — typically account for only about a third of what a major technology investment will actually cost over its lifetime. The rest is hidden. Integration with existing systems. Change management. Training. Process redesign. Ongoing customisation. Eventual decommissioning. Technical debt service.
The rule of thumb I have come to use is that for every rupee of licence cost, expect three to four rupees of total cost over a five-year horizon. For ERP-class implementations, the multiplier can run as high as eight or ten. The visible cost is the smallest part of the real cost. And almost every business case I have seen presented to a board only contains the visible cost.
The pattern is consistent across industries. Major banks routinely budget hundreds of crores for new systems and then spend three to four times that on the integration, training, and process redesign required to actually use them. Insurance firms commit to policy administration platforms with five-year licence costs and then discover, eighteen months in, that the integration with their distribution and claims systems will cost more than the platform itself. The CFO who approved the original budget is not corrupt or incompetent. He was given a number, and he approved that number. The number was just wrong.
The disciplined practice — used by the most sophisticated technology investors — is to require every major technology business case to include a five-year total cost of ownership projection. Not just licence and implementation. Integration, change management, ongoing operations, eventual replacement.
The exercise is uncomfortable. The numbers are larger than the sponsor wants to defend. That is precisely why it is necessary. A business case that survives a true TCO scrub is a business case worth funding. A business case that does not is one you were about to make a mistake on.
I make this a hard rule on every board I sit on. No major technology approval without a five-year TCO. No exceptions for AI projects, where the temptation to skip TCO is highest because the field moves so fast. Especially not for AI projects.
Where to spend, where not to
Geoffrey Moore's framework — articulated most clearly in Dealing with Darwin — is one of the most useful mental models a senior leader can carry into a technology budget meeting. The framework distinguishes between core activities — those that differentiate the company from its competitors and produce premium pricing — and context activities — those that the company must do well but that do not differentiate.
The trap is that companies typically spend more on context than on core. Because context is louder, more visible, and more politically defended.
Moore's prescription is to systematically pull resources out of context — through automation, outsourcing, or simplification — and reinvest them in core. The challenge is identifying which is which. Context for one company is core for another. Customer service is context for a logistics company and core for a luxury hotel. Compliance is context for a manufacturing company and core for a regulated bank. The work of senior leadership is to make the distinction explicit and then defend the resulting allocation against the constant pressure to treat everything as equally important.
In Indian general insurance, where I have spent much of my career, the misalignment is visible at almost every firm I have observed. Policy administration systems get treated as core — and so they get heavily customised, expensively maintained, and constantly enhanced. Underwriting models, by contrast, get treated as context — and so they get under-invested, run on stale data, and updated only when an external auditor flags them. This is the wrong way around. Policy administration is genuinely commodity work. Every insurer needs to do it. Nobody wins business because their policy admin system is better than the competitor's. Underwriting, by contrast, is where the entire economics of the business are made or lost. And yet the spending pattern, in firm after firm, is exactly inverted.
The practical discipline is straightforward. Once a year, force the leadership team to draw the core-context line explicitly, in writing, by activity. Then ask the CIO whether the technology spend matches that line. In ninety percent of firms, the answer is no. The spend matches whichever leader had the loudest voice in the last budget cycle. Aligning the spend to the line is not glamorous work. It is the work that produces the most value per rupee of any technology decision a CEO will make in a given year.
The highest-ROI investment is usually the unblocking one
Eli Goldratt's Theory of Constraints, developed in the 1980s for manufacturing, has quietly become one of the most useful frameworks for thinking about technology investment.
The principle is that any complex system has a single binding constraint — a bottleneck — and that improvements anywhere except the bottleneck produce no system-wide benefit. Investment in the bottleneck produces disproportionate returns. Investment elsewhere is, in a meaningful sense, wasted.
Applied to technology spending, the principle leads to an uncomfortable question that most companies do not ask honestly. What is the actual bottleneck in our value chain right now, and is our technology investment focused on it?
More often than not, the answer is no. Companies invest where the project sponsor has the loudest voice, or where the budget owner can defend the spend most easily. Not where the bottleneck actually sits.
The Indian consumer lending business has illustrated this principle better than any case study I could write. The bottleneck in consumer lending is not, as is often assumed, the credit decision itself. It is the time from customer intent to disbursement. A customer who walks into a store wanting a loan to buy a refrigerator is rarely lost because of credit quality. They are lost because the loan takes three days to process, by which time they have either bought it on a credit card or changed their mind. The firms that figured this out — Bajaj Finance is the cleanest example — invested aggressively in the technology infrastructure that compressed the cycle from days to minutes. Instant approvals at point of sale. Paperless onboarding. Pre-approved limits drawn from existing customer data. The competitors who invested similar amounts of money in better credit models lost market share for a decade. They did not have a worse model. They had a worse bottleneck-clearing stack. Which is a different — and more powerful — kind of disadvantage.
The senior leader's discipline is to force the question every budget cycle. What is our actual bottleneck? Where is the system slowest, most expensive, most fragile? And does our technology investment match that answer, or are we investing where the politics, rather than the physics, point?
Most firms cannot answer the first question without a week of work. That, by itself, is the diagnosis.
What shadow IT is actually telling you
Every CIO I know has, at some point, complained about shadow IT — the unauthorised tools, spreadsheets, scripts, and SaaS subscriptions that proliferate inside business teams without going through formal procurement. The standard CIO response is to crack down. Audit the credit cards. Block the URLs. Centralise procurement. Restore order.
This is, almost always, the wrong response.
Shadow IT is not a governance problem. It is a signal. It tells you, with high precision, exactly where the official technology stack is failing the business. When the credit ops team starts running its own Excel-based workaround for a function the core system was supposed to handle, the right question is not how do we stop this? It is what does the core system fail to do that this workaround is succeeding at?
Every shadow IT artefact I have ever investigated has revealed something useful. Sometimes it is that the formal system is too slow. Sometimes it is too rigid. Sometimes it lacks a feature that the business has been requesting for two years and has been told is "in the roadmap" without ever appearing. The workaround exists because the official answer was inadequate. Killing the workaround does not kill the inadequacy. It just hides it.
The mature response to shadow IT is to read it as feedback. Where is the tooling proliferating? What problems are people solving themselves? What does that tell us about where the official stack is weakest? And then — and this is the harder move — to either absorb the workaround into the official stack or, if it represents a genuine new capability, formalise and fund it as such.
I sat with the head of operations at a large Indian bank a few years ago who had just been asked by the CIO to crack down on shadow IT in his function. He had counted forty-two distinct shadow tools across his team. Forty-two. The CIO wanted them all gone. The head of ops, who was a sharper thinker, asked a different question. Why do we have forty-two? What does that tell me about my own technology team's responsiveness? He spent the next six months turning each of the forty-two into a structured request to the IT function. About a third were absorbed into the official stack. About a third turned out to be better than what the IT function had been planning to build. About a third revealed real gaps that the IT team had been quietly aware of and unable to prioritise. The CIO, to his credit, eventually became the head of ops's strongest ally. The shadow IT count fell from forty-two to single digits — not because of crackdown, but because the underlying inadequacies got fixed.
The senior leader's question is not how do we reduce shadow IT? It is what is our shadow IT trying to tell us about our official stack? The first question produces a control system. The second produces a learning system. Only one of them compounds.
Why foundations matter more than features
The temptation in any technology budget is to spend on features — visible new capabilities that produce a demonstrable customer-facing improvement. The thing that gets less budget, year after year, is foundations. Data platforms. Identity systems. Integration layers. The plumbing.
This is a mistake, and it is the most expensive mistake on this list.
Features compound only if the foundation supports compounding. A new digital onboarding flow that runs on a fragmented identity system is a brittle improvement that will break when the next product line is added. A personalisation engine that runs on a non-unified customer data platform produces theatrical results in a controlled demo and deeply average results in production. A new mobile app built on top of a legacy core that cannot expose APIs cleanly is a frontend without a backend — and the user experience eventually betrays it.
The firms that have built durable technology advantages have, almost without exception, prioritised foundation investments at moments where it would have been politically easier to ship features. The hard-won insight is that the visible win comes from features, but the long-run advantage comes from foundations. A leader who does not understand this will be perpetually surprised by why competitors with apparently similar capabilities seem to extract more value from them.
The Indian BFSI firms that have widened their lead over the last decade are the ones that, around five to seven years ago, made a deliberate decision to invest in foundations even at the cost of slowing visible feature delivery for a while. The firms that did not are now, predictably, struggling to layer AI capabilities on top of stacks that were never designed to support them. The AI conversation is, in many cases, just the latest exposure of foundation choices made — or not made — five years ago.
The senior leader's question on this principle is uncomfortable. When my CIO asks for foundation investment that does not produce a visible win for two years — am I able to fund it? Or do I default to the feature with the prettier demo? The honest answer, for most leaders, is the second. Which is exactly why most firms find themselves stuck on the wrong side of the compounding gap.
The mindset is the foundation
Eight principles on how to think about technology spending before the spend happens. I have given them in deliberate order — posture first, then allocation, then the build-buy-partner doctrine, then total cost, then core-vs-context, then bottleneck, then shadow IT, then foundations.
If I had to compress all eight into a single line for a busy reader, it would be this. The most important technology decisions a senior leader makes are upstream of the spending itself — in the posture they bring to it, the allocation they enforce, and the discipline with which they distinguish core from context.
Most leaders I have worked with are competent at the spending part. They can read a vendor proposal. They can challenge an implementation timeline. They can negotiate a licence fee. The thing they are less competent at — and the thing that determines whether the spending compounds — is the upstream posture work.
That is the work this essay has been about. It is also the work that does not show up on any dashboard, that no consultant can do for you, and that no AI tool is going to automate. Which is exactly why the firms that do it well will, over the next decade, widen their lead over the firms that do not.
The next essay in this series turns from posture to performance. Why most technology projects fail, why the failures are almost never the technology, and how a few firms manage to extract genuine returns from investments that look identical, on paper, to the ones that fail. That is the harder conversation, and the one I think most senior leaders are even less prepared to lead.
But the mindset is the foundation. Get that wrong, and nothing downstream saves you.