A CTO walks into a board meeting to present a technology strategy. What they actually present is a list of platform upgrades, tool migrations, and infrastructure projects. The slides are well-designed. The timelines are ambitious but defensible. The board nods. The budget gets approved. Twelve months later, the business is asking why nothing has changed. Customer outcomes have not improved. Delivery is still slow. The technology function is still the bottleneck everyone politely avoids naming.
The answer is straightforward, and it is the same answer in almost every organisation that finds itself in this position: the leadership team made tactical and operational decisions and called them strategic. This is one of the most common — and most expensive — mistakes in technology leadership. It is also one of the least discussed, because the people making these decisions genuinely believe they are thinking strategically. They are not. They are thinking about how without first resolving why.
What makes a decision strategic?
Strategic decisions define direction. They answer a specific set of questions: What business outcomes are we trying to create? What capabilities do we need to deliver those outcomes? How should the operating model be structured to make those capabilities reliable and repeatable?
Strategic decisions share a critical characteristic: they are irreversible, or expensive to reverse. They shape everything downstream. They constrain the decisions that follow. Examples include which markets to serve, whether to build or buy a core platform, how to structure the technology function, and what the relationship between technology and the business should look like.
The defining test is this: a strategic decision constrains all subsequent decisions. If you get the strategic decision right, the tactical and operational decisions that follow become easier — often obvious. If you get the strategic decision wrong, no amount of tactical excellence will compensate. You will execute brilliantly against the wrong objective. The organisation will be busy, productive, and fundamentally misdirected.
The tactical trap
Tactical decisions are about approach and method. They answer: How will we deliver this? What tools, frameworks, and methods will we use? They sit between strategy and operations — translating direction into action.
The problem is that most technology organisations operate almost entirely at the tactical level. They choose platforms. They select vendors. They adopt frameworks — SAFe, the Spotify model, DevOps maturity models. They restructure teams into squads, tribes, and chapters. All of these are tactical decisions. Every one of them answers the question how rather than why.
None of these decisions answer the strategic question: Are we building the right thing for the right reason? A new platform is only valuable if it serves a strategic outcome. A team restructure is only useful if the operating model it creates actually makes sense for the work being done. Otherwise, you are rearranging the furniture in a building with the wrong floor plan. The rooms look different. The building still does not work.
Tactical excellence in the absence of strategic clarity is the most expensive form of waste in technology organisations. It looks like progress. It feels like progress. It is not progress.
Operational decisions dressed as strategy
Operational decisions keep the lights on. They answer: How do we execute today's work efficiently? This includes patching, monitoring, incident response, capacity management, and sprint planning. These decisions are necessary. They are not strategic.
The danger emerges when operational urgency absorbs strategic attention. When every leadership meeting is consumed by delivery status updates, incident reviews, and capacity debates, there is no space left for strategic thinking. The organisation becomes entirely reactive. It spends money solving today's problems without ever asking whether those problems should exist at all.
A technology leadership team that spends its time debating which incidents to prioritise, which squads need more capacity, and which releases are at risk is a team that has been captured by operational gravity. These conversations need to happen — but not at the strategic level. When they do, the organisation loses its ability to step back and ask the questions that actually determine whether the investment is sound.
This is where regret spend lives.
The anatomy of regret spend
Regret spend is technology investment that fails not because the execution was poor, but because the decision was made at the wrong level. The work was competently delivered. The outcome was never going to materialise, because the decision that initiated it was tactical or operational, not strategic.
The pattern is remarkably consistent across organisations:
- Cloud migration without strategic rationale. The organisation migrates to a new cloud platform because the engineering team advocated for it, without asking whether the current architecture serves the business model. Cost: millions. Outcome: the same problems, on a new platform, with a more complex operational footprint.
- Framework adoption as a substitute for diagnosis. The organisation implements SAFe across the technology function because delivery was slow, without diagnosing why delivery was slow. The structural bottlenecks remain. The framework becomes additional overhead layered on top of existing dysfunction. Delivery gets slower.
- Headcount as a proxy for capability. The organisation hires fifty more engineers to increase velocity, without asking why the existing two hundred engineers are not delivering outcomes. The problem was the operating model — unclear accountability, misaligned teams, excessive coordination overhead — not the headcount. The new hires inherit the same structural constraints.
- Platform investment without decision architecture. The organisation builds a data platform because "everyone needs data," without a strategic view of which business decisions the data is meant to support. The platform gets built. The data engineering team is proud of it. Nobody uses it meaningfully, because nobody defined the decisions it was supposed to enable.
Every one of these is a tactical or operational decision made in the absence of strategic clarity. The money is spent. The outcomes do not materialise. And the leadership team is left explaining to the board why the investment did not deliver — usually by proposing another round of tactical decisions.
How to tell the difference
The distinction is not academic. It is the difference between investment that compounds and investment that evaporates. A practical framework:
A decision is strategic if:
- It defines or changes direction for the organisation
- It is difficult or expensive to reverse once made
- It constrains downstream decisions — tactical and operational choices flow from it
- It connects technology investment directly to business outcomes
A decision is tactical if:
- It determines approach, method, or tooling
- It can be changed without restructuring the organisation
- It serves a strategic objective — or should, if one existed
A decision is operational if:
- It manages day-to-day execution and delivery
- It maintains current capability rather than building new capability
- It should be delegated to delivery teams, not escalated to leadership
The test is simple and unforgiving: if your technology leadership team spends more than seventy per cent of its time on tactical and operational decisions, strategic thinking is not happening. And if strategic thinking is not happening, every major investment is a gamble — an expensive bet made without the clarity that would make it an informed decision.
What this means for CIOs
The CIO's primary job is to ensure strategic decisions are made first — before money is committed, before teams are restructured, before platforms are selected. This is not a luxury reserved for organisations with time and space. It is the prerequisite for every other decision being sound.
This requires three things:
- An operating model that separates strategic governance from delivery governance. Strategic decisions need a different cadence, different participants, and different information than delivery decisions. When they share the same forum, operational urgency wins every time.
- Decision rights that are clear and enforced. Who makes strategic decisions? Who makes tactical decisions? Who makes operational decisions? In most organisations, these boundaries are blurred. The result is strategic decisions made by default — by the person who happens to be in the room, or the team that moves fastest.
- A portfolio structure that connects investment to business outcomes, not just delivery milestones. If the portfolio is measured by whether projects are delivered on time and on budget, it is measuring operational performance. Strategic value — whether the investment created the intended business outcome — is invisible.
Most CIOs inherited an operating model that was never designed with this separation in mind. The governance forums blend strategic and operational concerns. The portfolio measures activity rather than outcomes. The decision rights are informal and inconsistent. Fixing that — creating the structural conditions for strategic decisions to be made clearly and early — is itself a strategic decision. It is usually the first one that matters.
The bottom line
The difference between a technology organisation that delivers business value and one that accumulates regret spend is not talent, budget, or tooling. It is the level at which decisions are made. Organisations that make strategic decisions first — and then allow tactical and operational decisions to flow from that clarity — invest with purpose. Organisations that skip strategy and jump to tactics spend money on motion that masquerades as progress.
Strategic clarity reduces regret spend. Everything else is noise. If you are unsure whether your current technology investments are strategic or tactical — that uncertainty is itself the answer.