Sanjay K Mohindroo — CIO, Board Technology Advisor | stayingalive.in    

Sanjay K Mohindroo

AI should multiply workforce capability, not just cut headcount. A board-level framework for automation, cognitive capital, governance, risk, and growth.

In three decades of enterprise technology, I have seen one pattern repeat: when a new technology arrives, management first tries to force it into the economics of the old operating model.

With AI, that usually becomes one question: “How many FTEs can we remove?”

That question is measurable, board-friendly, and dangerously incomplete.

The conventional wisdom says AI transformation should convert automation directly into labor savings. My view is the opposite: if your first AI KPI is headcount reduction, you may destroy the very business capability that makes the technology valuable.

AI Transformation Is Not Workforce Reduction

There is no point pretending AI will not eliminate work. It will.

Some tasks will disappear. Some roles will shrink. Some positions will ultimately become unnecessary. Boards should expect that.

But workforce reduction should be an outcome of transformation, not the definition of transformation.

Consider a team of 100 people. AI removes 30 percent of repetitive work. The traditional response is simple: reduce the team by 30.

The better question is harder: what could the same 100 people achieve with 30 percent more capacity?

Could they serve more customers, reduce risk, accelerate product launches, improve quality, enter new markets, or solve problems the organization has been postponing for years?

That released capacity is not waste. It is an asset.

If management turns every productivity gain immediately into a cost reduction, it captures only one form of value, and often the least strategic one.

The Hidden Asset on the Balance Sheet

Experienced employees carry something most automation business cases fail to price: institutional knowledge.

They know which customer exception matters, which report is unreliable, which supplier requires escalation, which control cannot be bypassed, and why a process that looks inefficient was designed that way in the first place.

AI can process the documented procedure. It does not automatically inherit the undocumented judgment around it.

This matters because a company can save salary costs while simultaneously weakening its operating system.

I call that cognitive capital: the accumulated domain knowledge, judgment, exception-handling ability, historical context, and decision experience that allows an organization to function when the standard process breaks.

Boards track financial capital, physical capital, technology assets and intellectual property. They should start asking whether AI transformation is increasing or decreasing cognitive capital.

The real risk is cognitive debt.

Technical debt appears when shortcuts create future engineering cost. Cognitive debt appears when an organization outsources too much thinking to machines and no longer retains enough human capability to challenge, explain, or recover the process.

You see it when teams cannot operate without AI, experts disappear, exception handling deteriorates, or nobody can reconstruct why a decision was made.

That is not efficiency. It is dependency.

The Four-Layer AI Operating Model

A mature AI strategy needs four systems working together.

First, AI automation: what can machines execute reliably?

Second, human capability: what must people continue to understand and be able to do?

Third, workforce transformation: how do today’s roles evolve into AI-enabled roles?

Fourth, AI governance: what is AI allowed to do, with what data, under what conditions, and with what degree of autonomy?

Most companies over-invest in the first layer because it produces the easiest business case.

That is precisely the mistake.

Higher automation combined with lower human capability and weaker institutional knowledge creates a more fragile enterprise, not a more advanced one.

The Board Must Govern Autonomy, Not Just Adoption

The next phase of enterprise AI is not simply copilots. It is agents that can analyze, decide and execute across workflows.

That changes the governance question.

The issue is no longer only, “Can AI do this?”

It becomes, “Should AI do this, and what happens to human capability if it does?”

Autonomy should rise with evidence, predictability, reversibility and control, not merely because the model is technically capable.

A low-risk reconciliation process may justify bounded autonomy. A regulatory interpretation, strategic pricing decision or crisis response may not.

And “human in the loop” is not a sufficient control if the human merely clicks approve repeatedly.

For important decisions, management needs to define where humans intervene, what exceptions trigger escalation, who remains accountable, and whether the organization can still operate if the AI is unavailable.

One simple test is an AI-off exercise.

Can the team still diagnose the problem, perform the critical process, handle exceptions, and explain the reasoning behind a decision?

If the answer is no, the organization may have automated faster than it has learned.

A Six-Part Board Framework for AI Capability

I would ask boards and CEOs to apply six principles to every major AI transformation.

1. Automate work, not capability

Automate repetitive, low-value work aggressively. But identify the human expertise embedded in the process before it disappears.

The right question is not whether AI can perform the task. It is whether the organization can afford to lose the capability associated with it.

2. Upskill before you replace

Give experienced employees AI tools before concluding that their role is redundant.

The people who know the process are often the best people to teach the organization how to redesign it. They know the exceptions, dependencies, and workarounds that formal documentation misses.

3. Redeploy capacity before reducing capacity

Every successful automation creates an AI dividend.

If a process once consumed one million hours and AI reduces that to 600,000, management has created 400,000 hours of capacity.

Some of that capacity may eventually become cost reduction. But first ask whether it can generate revenue, improve customer experience, accelerate innovation, strengthen controls, or open new markets.

4. Preserve human judgment

Not every decision deserves the same degree of automation.

Routine, reversible work can move toward autonomy faster. High-impact decisions need stronger human judgment, escalation, and accountability.

The objective is not to keep humans clicking approval buttons. It is to keep human judgment where it creates economic and risk value.

5. Increase autonomy with evidence

AI agents should earn greater authority through demonstrated reliability.

Track success rates, escalation rates, intervention rates, policy violations, reversals, and business outcomes.

Build what I would call an agent flight recorder: an auditable history of what the agent was asked to do, what data and tools it used, what actions it took, where humans intervened, and what outcome resulted.

Autonomy without evidence is not innovation. It is unmanaged operational risk.

6. Measure capability, not just cost

If executives are rewarded mainly for FTE reduction, AI will become a headcount program.

The scorecard must be broader: hours saved, cycle-time improvement, quality, exception rates, revenue enabled, new capacity, critical-skill retention, institutional knowledge captured, internal mobility and AI-off resilience.

The objective is not maximum automation.

It is maximum business value per unit of human capability.

The Counter-Argument: What If Cost Reduction Is the Goal?

There are situations where headcount reduction is economically rational.

If work is repetitive, low-risk, well-documented, easily reversible, and carries little strategic knowledge, aggressive automation may be exactly the right decision.

The mistake is not reducing cost.

The mistake is treating all work as if it has the same capability value.

Boards should distinguish between low-value labor that can be removed and high-value expertise that should be amplified.

That distinction is where strategy begins.

The CEO Question Has to Change

The old question is easy:

“How many people can AI replace?”

The better question is more demanding:

“If AI gave us 30 percent more organizational capacity without increasing the workforce, what could we accomplish that we cannot accomplish today?”

That question changes the investment case.

It connects AI to growth, customer acquisition, product expansion, resilience, quality and competitive advantage.

It also changes accountability. Management can no longer declare victory because a cost line fell. It has to show that the enterprise became more capable.

The strongest AI operating model is therefore not:

Automate → Eliminate

It is:

Automate → Augment → Upskill → Redeploy → Transform → Grow

That sequence does not reject efficiency. It captures efficiency without automatically sacrificing capability.

AI will remove work. It should.

But if the people who understand the business become the first casualties of automation, the company may discover too late that it automated away the knowledge required to run the business well.

The board-level measure of AI success should not be, “How many people did we replace?”

It should be, “How much more capable did the organization become?”

Where do you draw the line between legitimate automation-driven cost reduction and dangerous loss of human capability?

Subscribe to TechnologyTrends, or share your view in the comments.

Sanjay K Mohindroo

One question reveals whether leaders truly agree on outcomes, value, and accountability before a transformation consumes more capital and credibility.

The One Question That Exposes Misalignment in 60 Seconds

Give a leadership team 60 seconds and one sheet of paper.

Ask each person the same question separately, and you may learn more about the state of a major transformation than you will from a 60-page steering committee deck.

The question is:

“Twelve months from now, what single business outcome will prove this initiative was worth the capital, how will we measure it, and who is accountable for delivering it?”

Over three decades around enterprise technology, I have learned that the most dangerous form of misalignment is rarely open disagreement.

Open disagreement is visible. It can be debated.

The expensive kind is false alignment. Everyone approves the same programme, uses the same vocabulary, attends the same steering committee, and leaves the room believing they agreed on something they actually defined very differently.

That is why this question matters.

It turns alignment from an impression into something you can test.

Most leadership teams confuse consensus with alignment

The conventional wisdom is that large transformation programmes need stakeholder buy-in.

They do.

But buy-in is not alignment.

A board can unanimously approve a technology investment while individual executives expect entirely different returns from it.

The CEO may believe the programme is about improving customer experience.

The CFO may believe it is about reducing operating cost.

The CIO may believe it is about replacing an ageing technology estate.

The business unit leader may expect faster growth.

The risk function may primarily want stronger controls.

Everyone can support the programme.

Everyone can also be pulling it in a different direction.

That distinction matters because large initiatives rarely fail from a complete absence of intelligent people, project plans or governance meetings.

They often fail because important decisions are made against different definitions of success.

When budgets tighten, which capability survives?

When implementation creates disruption, which benefit justifies continuing?

When two business units compete for priority, which objective wins?

When the programme is six months late, what gets protected and what gets cut?

If the leadership team has never agreed on the primary business outcome, those questions get answered tactically.

That is when transformation becomes a collection of compromises rather than an instrument of strategy.

The 60-second business alignment test

The test is deliberately simple.

Before reviewing roadmaps, architecture, vendors, or programme status, ask the leaders responsible for the initiative:

Twelve months from now, what single business outcome will prove this initiative was worth the capital, how will we measure it, and who is accountable for delivering it?

Ideally, ask them individually before discussing the answers as a group.

You are looking for four things.

1. Outcome: Are we solving the same business problem?

The first test is whether people describe the same result.

Not the technology.

Not the project.

Not the activity.

The result.

“Implementing a new platform” is not an outcome.

“Completing the cloud migration” is not an outcome.

“Deploying AI across customer service” is not an outcome.

Those describe work being performed.

A business outcome sounds different:

• Reduce customer onboarding time from ten days to two.
• Increase revenue per sales employee by 15 percent.
• Reduce inventory locked in the supply chain by 20 percent.
• Cut the cost of servicing a customer transaction by 25 percent.
• Reduce the financial exposure created by a critical operational risk.

The distinction looks obvious on paper.

It becomes surprisingly difficult in a boardroom.

If one executive describes the outcome as growth, another as cost reduction, and another as technology modernisation, the initiative is not yet aligned. It may simply have accumulated several rationales to secure approval.

That is an uncomfortable conclusion.

It is also far cheaper to discover before the capital is spent.

2. Measure: Would we recognise success if we saw it?

The second test is measurement.

I have seen many initiatives with extensive programme dashboards and surprisingly weak measures of business value.

Green milestones do not necessarily mean a successful investment.

A programme can be on budget, complete every technical milestone and still fail commercially.

Boards should therefore distinguish between delivery metrics and outcome metrics.

Delivery metrics tell you whether the programme is progressing.

Outcome metrics tell you whether the company is becoming better because of it.

Both matter, but only one answers the investment question.

Consider a company funding a major digital customer programme.

A delivery dashboard might report:

• percentage of functionality completed,
• number of users migrated,
• system availability,
• implementation milestones achieved.

Useful information.

But none of those numbers tells the board whether customers are buying more, staying longer, receiving faster service or costing less to serve.

The board should be able to identify one primary business measure that determines whether the investment created value.

If success cannot be measured, almost any result can later be presented as success.

That is not governance.

It is retrospective storytelling.

3. Time: When exactly should value become visible?

Transformation language often becomes vague around time.

We talk about strategic value, future capability, long-term competitiveness, and foundations for growth.

Some investments genuinely require patience.

But “long term” can also become a convenient hiding place for weak accountability.

A board allocating capital should know when evidence of value is expected to appear.

Not necessarily the full return.

Evidence.

If the programme is expected to take three years, what should be materially different after twelve months?

If nothing measurable is expected for thirty-six months, the board should understand why.

Time creates discipline because it converts ambition into a commitment.

Without a time horizon, programmes can remain strategically important almost indefinitely.

4. Accountability: Which executive owns the outcome?

This is where the question becomes uncomfortable.

Ask who owns programme delivery, and the answer is usually easy.

There is a programme director.

There may be a CIO, transformation office, implementation partner, and steering committee.

Ask who owns the business outcome, and the answer is often less clear.

That is a problem.

Technology can enable a reduction in working capital.

It cannot own working capital.

Technology can enable sales productivity.

It cannot own revenue.

Technology can provide customer data.

It cannot own customer retention.

If a transformation promises a business result, a business executive must ultimately own that result.

This does not reduce the CIO’s accountability. It makes accountability more accurate.

The CIO remains accountable for technology capability, reliability, security, execution and the integrity of the investment.

But if a programme claims it will increase revenue, improve margins or change customer behaviour, the executive responsible for that business outcome must be visibly committed to delivering it.

A steering committee is not an accountable owner.

Neither is “the organisation”.

When everyone owns the outcome, nobody truly does.

What misalignment sounds like in the boardroom

Imagine asking six executives the 60-second question before approving the next phase of a major programme.

You receive these answers:

CEO: “It should materially improve customer retention.”

CFO: “It needs to take at least 10 percent out of our cost base.”

CIO: “We need to retire our legacy environment and reduce operational risk.”

COO: “It should simplify processes across the organisation.”

Business leader: “We need faster product launches.”

Programme sponsor: “We need to deliver the transformation roadmap.”

None of these objectives is irrational.

That is precisely the problem.

They are all plausible enough to coexist without anyone noticing that the company has not made a choice.

A major programme can support several benefits, but it still needs a dominant economic or strategic logic.

Why?

Because eventually those benefits will compete.

A decision that optimises customer experience may increase operating cost.

A decision that accelerates implementation may delay legacy retirement.

A decision that standardises processes may reduce flexibility for a high-growth business unit.

Without an agreed hierarchy of outcomes, every trade-off becomes political.

The programme does not lack governance.

It lacks a governing objective.

A simple board framework: O-M-T-A

I use a very simple way of thinking about the answer.

Call it O-M-T-A:

Outcome. Measure. Time. Accountability.

Before committing significant capital, the board should be able to complete one sentence:

We are investing in this initiative to achieve [OUTCOME], evidenced by [MEASURE], by [TIME], with [EXECUTIVE] accountable for delivering the business result.

If that sentence cannot be completed without twenty minutes of debate, the organisation is not ready to debate technology choices.

That debate comes later.

First agree on what the money is supposed to accomplish.

The board should test five things

Once the sentence is written, ask:

1.   Is there one primary outcome?

Secondary benefits are fine, but the organisation should know which result wins when trade-offs appear.

2.   Is the measure economic or strategically meaningful?

Avoid confusing implementation progress with enterprise value.

3.   Is the time horizon explicit?

Define when evidence of value should become visible.

4.   Does one executive own the result?

Committees can govern. Individuals remain accountable.

5.   Would the same answer survive outside the meeting?

Ask leaders independently. Alignment produced only after group negotiation may be compliance, not conviction.

That fifth test is particularly useful.

Senior leadership teams are very good at creating consensus in meetings.

The stronger test is whether they remain aligned when they are no longer sitting around the same table.

Misalignment is a capital allocation problem

It is tempting to classify this as a communications issue.

I think that seriously understates the risk.

Misalignment is a capital allocation problem.

If a company commits $50 million to a transformation and its executives disagree about what the investment is fundamentally intended to achieve, the organisation has effectively approved multiple competing investment theses under one budget.

That affects far more than project execution.

It changes vendor choices.

It changes sequencing.

It changes organisational design.

It changes which capabilities receive funding.

It changes which compromises are acceptable.

And, eventually, it changes how success or failure is reported to the board.

The cost of misalignment therefore does not appear as a single line item.

It appears as rework, delayed benefits, scope expansion, political escalation, underused capabilities and investments that technically finish but never produce the return originally expected.

“But large transformations have multiple objectives”

This is the most reasonable objection to the one-question test.

Of course they do.

A major ERP transformation, for example, may improve control, lower cost, standardise processes, reduce technology risk and create better management information.

The answer is not to pretend those secondary outcomes do not exist.

The answer is to establish hierarchy.

Every serious strategic investment needs a primary reason for existing.

If the company had only 60 percent of the available capital, which benefit would it protect?

If the programme had to sacrifice one objective to secure another, which one wins?

If the board had to judge the investment five years later using only one measure, what would it choose?

Those questions expose priority.

And priority is what makes strategy executable.

A strategy that treats every objective as equally important has avoided the hardest part of strategy: choosing.

Use the question before the programme is in trouble

Most organisations perform alignment exercises after warning signs appear.

Budgets increase.

Timelines move.

Benefits become uncertain.

Business sponsors disengage.

Then everyone asks whether the programme is aligned with strategy.

That is too late.

The 60-second question belongs much earlier.

Use it when approving the business case.

Use it before selecting major partners.

Use it at the start of each major investment phase.

Use it when leadership changes.

Use it when a programme requests substantial additional funding.

Most importantly, use it before discussing the technology itself.

Boards do not need to become technology committees.

They need to become much harder to satisfy on the connection between technology and enterprise value.

The real test of alignment

A perfectly aligned leadership team does not need identical language.

It needs a common economic logic.

Ask five leaders why the organisation is spending the money.

If one talks about growth, another about efficiency, another about risk, another about modernisation and another about completing the programme, do not congratulate yourself on having a broad transformation agenda.

You have probably discovered five different investment theses.

Resolve that before approving the next tranche of capital.

The best governance question is often not the most sophisticated one.

Sometimes it is simply the question nobody has forced the room to answer precisely.

Twelve months from now, what single business outcome will prove this initiative was worth the capital, how will we measure it, and who is accountable for delivering it?

Ask it separately.

Give people 60 seconds.

Then compare the answers.

You may discover that the transformation problem you thought you had is actually an alignment problem.

And discovering that early can save far more than another round of programme optimisation ever will.

What is the one question you use to determine whether a leadership team is genuinely aligned, rather than simply in agreement?

Subscribe to TechnologyTrends, or add your perspective in the comments, especially if your experience leads you to a different conclusion.

Sanjay K Mohindroo

Why Clear Roles Still Cause Confusion

RACI charts clarify roles, but not authority. Learn the five tests boards and CEOs should use to turn responsibility into real accountability.

I have sat in steering meetings where every workstream had a neat RACI chart, every box had a name in it, and nobody could answer the most important question: who can actually make the decision?

The project was not suffering from unclear roles. It was suffering from something more dangerous: the illusion of accountability.

That distinction matters.

For years, conventional management wisdom has told us that when a programme becomes messy, clarify the roles. Define who is Responsible, Accountable, Consulted and Informed. Put it on a page. Socialise it. Get everyone to agree.

I have used RACI matrices. They are useful.

But I have also seen organisations spend weeks perfecting them while the underlying decisions remain just as slow, political and ambiguous as before.

My view is simple: RACI is a responsibility map. It is not an accountability system.

And treating it as one is where the trap begins.

Why RACI Looks Better Than It Works

RACI solves a genuine problem.

Large organisations naturally create overlapping responsibilities. Technology programmes make this worse because business units, finance, operations, technology, risk, procurement and external partners may all have legitimate interests in the same outcome.

A RACI matrix brings order to that complexity.

The problem is that most major initiatives do not fail because people cannot identify who is supposed to perform an activity.

They stall because nobody has made clear:

Who owns the business result?

Who gets the final say when two executives disagree?

Who can commit money or people?

How quickly must a deadlock be escalated?

What happens when a commitment is repeatedly missed?

None of those questions is reliably answered by placing an “A” in a spreadsheet.

That is the RACI trap.

The chart creates the appearance of organisational clarity while the operating reality remains unresolved.

An “A” Does Not Automatically Create Accountability

This is where I challenge the conventional wisdom most directly.

Organisations often assume that assigning one person as Accountable means accountability now exists.

It does not.

Imagine the executive accountable for a transformation milestone cannot approve additional expenditure, cannot reassign key staff, cannot resolve a dispute between two business units, and cannot overrule a functional leader whose cooperation is essential.

On paper, that executive is accountable.

In practice, the organisation has made that person responsible for an outcome without giving them the authority required to produce it.

That is not governance. It is organisational theatre.

The opposite problem is equally common.

Several senior stakeholders are labelled Consulted, but culturally each believes consultation gives them an informal veto. Every significant decision therefore needs another meeting, another round of alignment and another layer of reassurance.

The RACI looks disciplined.

The decision process is anything but.

Confusion Usually Appears at the Boundaries

Inside a well-run function, roles are often reasonably clear.

The problems emerge between functions.

Consider a global company replacing a fragmented set of business systems with a common enterprise platform.

Technology may own delivery.

Operations may own process adoption.

Finance may control the investment case.

Procurement may own the supplier relationship.

Risk may define mandatory controls.

Regional leaders may own local business performance.

A conventional RACI can assign each activity neatly.

Then the difficult question arrives.

The global design improves standardisation and lowers long-term cost, but one large market argues that it will disrupt revenue during the transition. The regional leader wants an exception. The transformation leader wants standardisation. Finance wants the savings case protected.

Who decides?

That is not a task-allocation question.

It is a business trade-off involving capital, execution risk, local revenue and long-term operating leverage.

A RACI matrix may tell us who must be consulted.

It rarely tells us whose judgement prevails.

That is precisely where senior management attention is required.

The Cost of False Clarity

Poor accountability is not an administrative inconvenience.

It is expensive.

Decisions get deferred.

Suppliers wait while internal stakeholders debate.

Teams build workarounds because approvals take too long.

Contingency budgets increase.

Senior executives spend time resolving issues that should never have reached them.

Milestones slip, but everyone can demonstrate that they fulfilled their assigned part of the RACI.

This is one reason troubled programmes can produce remarkably clean governance packs.

Every activity has an owner.

Every meeting has minutes.

Every risk has a colour.

Yet the business outcome continues to deteriorate.

Boards should be wary when governance reporting demonstrates activity more clearly than accountability.

The relevant question is not, “Have responsibilities been documented?”

It is, “Can this organisation make and execute the difficult decisions at the speed this initiative requires?”

Five Tests of Real Accountability

For material transformations, strategic investments and cross-functional programmes, I would put every critical outcome through five tests.

If any one of them fails, the RACI is not enough.

1. Is there one owner for the business outcome?

Responsibility for activities can be distributed.

Accountability for an outcome cannot.

If a programme is expected to reduce cost, improve customer experience, shorten cycle time or generate revenue, one executive must ultimately own that result.

Not the presentation.

Not the implementation activity.

The result.

This distinction sounds obvious, but it changes the conversation.

Instead of asking who owns the data migration, training programme or system deployment, senior leadership asks who owns the business benefit the investment was approved to deliver.

Boards fund outcomes, not workstreams.

Governance should reflect that.

2. Does that owner have genuine decision rights?

An accountable executive who cannot decide is not accountable.

For every critical outcome, specify the decisions the owner can make without seeking further consensus.

Can the programme leader reject a local exception?

Can the business sponsor reprioritise resources?

Can the executive responsible for the investment alter scope within agreed financial limits?

Can a functional leader stop deployment because a risk threshold has been breached?

The purpose is not to centralise every decision.

It is to remove ambiguity before a difficult decision arrives.

A surprising amount of organisational friction comes from executives discovering their real authority only when they try to exercise it.

By then, the delay has already begun.

3. Does the owner control, or have guaranteed access to, the required resources?

Accountability without resources is wishful thinking.

Many transformation leaders are given ambitious objectives while critical staff remains controlled by functional departments whose incentives point elsewhere.

The programme becomes a negotiation for people's spare capacity.

Then leadership is surprised when delivery slows.

For strategic initiatives, resource commitments should be explicit.

If an executive is accountable for the outcome, either the required resources should sit within that executive's control or there should be an enforceable organisational commitment to provide them.

Capital allocation matters here as well.

If every minor adjustment requires escalation through multiple financial approvals, the organisation has effectively separated accountability from the ability to act.

4. Is there an escalation clock?

Most governance frameworks describe where an issue should be escalated.

Far fewer specify when.

That omission creates enormous delay.

A disagreement can circulate between teams for days or weeks because everyone believes another meeting might solve it.

I prefer explicit escalation clocks for material issues.

If two functions cannot resolve a decision within an agreed period, it moves automatically to the named executive forum.

No embarrassment.

No politics.

No accusation that someone “escalated too quickly.”

The mechanism is already agreed.

This matters particularly in large transformations where dozens of small unresolved dependencies can quietly become one large schedule problem.

Good governance does not eliminate disagreements.

It prevents disagreements from becoming paralysis.

5. Is there a consequence when commitments are not met?

This is the uncomfortable test.

Many organisations are willing to assign accountability but reluctant to attach consequences to it.

If a critical business unit repeatedly fails to provide promised resources, what happens?

If an executive sponsor repeatedly postpones decisions, is the resulting schedule impact simply absorbed by the programme?

If benefits are not delivered after implementation, does ownership remain with the business, or does responsibility somehow migrate back to the technology team?

Without consequences, accountability becomes descriptive rather than operational.

Consequences do not need to mean punishment.

They may mean transparent benefit ownership, budget adjustments, formal risk acceptance, escalation to the executive committee, or changes to the investment case.

The principle is what matters.

A commitment without a consequence is usually only a preference.

The Board Should Ask Different Questions

Boards and CEOs do not need to review a 70-line RACI matrix.

They need to test whether the operating model beneath it is capable of delivering the promised outcome.

For a major initiative, I would ask five questions:

1.   Who owns the business result?

2.   Which important decisions can that person make directly?

3.   Do they control the resources needed to deliver?

4.   How long can a cross-functional disagreement remain unresolved?

5.   What happens when a critical commitment is missed?

If the answers are vague, the governance is vague, regardless of how polished the responsibility matrix appears.

These questions are particularly important for technology investments because they often cross organisational boundaries more aggressively than traditional capital programmes.

A factory expansion has a physical location.

A digital transformation may touch sales, finance, supply chain, HR, risk, customer service and every geography simultaneously.

The interfaces become the programme.

That makes decision architecture as important as technical architecture.

Should Organisations Stop Using RACI?

No.

That would be solving the wrong problem.

RACI remains useful for clarifying participation, particularly where multiple functions interact.

The mistake is expecting it to do something it was never designed to do.

A RACI should tell teams how responsibilities are distributed.

It should sit underneath a stronger layer of governance that defines business outcomes, authority, resources, escalation, and consequences.

Think of RACI as a map.

A good map tells you where everyone is positioned.

It does not decide who has the steering wheel.

Why This Matters More as Organisations Become More Matrixed

Modern organisations increasingly rely on matrix structures, shared services, product teams, external partners and cross-functional transformations.

That means authority is becoming more distributed while business outcomes remain interconnected.

The natural response has been to produce more governance.

More committees.

More role definitions.

More matrices.

More approval stages.

But adding governance artefacts does not necessarily increase accountability.

Sometimes it does the opposite.

When too many people participate in every decision, individual accountability becomes weaker.

When every stakeholder must be comfortable before action is taken, speed becomes optional.

When the executive with the “A” lacks control over money, people or trade-offs, the letter becomes ceremonial.

In competitive markets, that is not merely inefficient.

It is a strategic disadvantage.

The organisations that move fastest are not necessarily those with fewer controls.

They are often the organisations that are clearer about where authority sits and when it moves.

The Real Test of Governance

The quality of governance is not revealed when everyone agrees.

It is revealed when two legitimate priorities conflict.

Revenue versus standardisation.

Speed versus control.

Local flexibility versus global scale.

Short-term cost versus long-term capability.

That is when the organisation discovers whether its accountability model is real.

If the answer is another alignment meeting, another steering committee discussion and another revision of the RACI, the problem is probably not unclear roles.

The problem is unclear authority.

Three decades around enterprise programmes have reinforced one lesson for me: organisations rarely suffer from a shortage of intelligent people who understand their responsibilities.

They suffer when intelligent people are placed inside systems that make decisive action difficult.

A RACI matrix can clarify who is in the room.

Leadership must still decide who is allowed to decide.

Where have you seen RACI create genuine clarity, and where has it simply documented confusion more neatly?

Subscribe to TechnologyTrends, or add your perspective in the comments.

Sanjay K Mohindroo

Alignment meetings rarely solve misalignment. Learn the four decisions leaders must make to turn executive discussion into real business commitment.

Alignment Meetings Do Not Create Alignment

I have sat through two-hour alignment meetings where every executive left saying, “We are aligned.”

Three weeks later, the same programme had three priorities, two definitions of success, and no one willing to make the trade-off that mattered.

That is not unusual.

Across large transformation programmes, I have seen organisations spend enormous amounts of executive time trying to create alignment through meetings. More steering committees are formed. More workshops are scheduled. More stakeholders are invited. More slides are produced.

Yet the underlying disagreement remains.

The conventional wisdom is that alignment comes from communication. Get the right people into a room, give everyone visibility, discuss the issues openly, and eventually the organisation will converge.

I disagree.

Alignment is not a communication problem. It is a decision problem.

Meetings can expose misalignment. They can clarify information. They can improve understanding.

But alignment only exists when leaders agree on the outcome, accept the trade-offs, know who has the right to decide, and understand what happens next.

Without those conditions, the meeting has merely created the appearance of alignment.

The Most Dangerous Meeting Ends With Everyone Agreeing

The obvious sign of a bad meeting is conflict.

The more dangerous sign is unanimous agreement followed by inconsistent action.

Consider a familiar transformation scenario.

A large enterprise decides that improving customer experience is a strategic priority. The business wants faster product launches. Operations wants stability. Finance wants tighter investment discipline. Technology wants to reduce legacy complexity.

None of these positions is irrational.

The executives meet. Everyone agrees that customer experience matters. Everyone supports transformation. Everyone agrees that speed, resilience, cost control, and modernisation are important.

The meeting ends positively.

Then the real decisions begin.

Should the company delay a launch to retire a fragile legacy dependency?

Should it accept higher near-term operating cost to improve resilience?

Should a business unit abandon a customised process so the enterprise can standardise?

Should a promising initiative lose funding because another programme has greater enterprise value?

That is where alignment is tested.

Agreement on objectives is easy when the objectives are abstract. Alignment becomes visible only when two desirable outcomes compete for the same capital, capacity, or executive attention.

If nobody has agreed which objective wins under pressure, the organisation was never aligned.

It merely agreed with a collection of aspirations.

More Alignment Meetings Often Make the Problem Worse

When executives sense disagreement, the natural response is often to schedule another meeting.

This can become a sophisticated form of avoidance.

The same issue is discussed again with slightly different slides. More analysis is requested. Another stakeholder is brought in. Someone proposes a workshop. The decision is deferred until the next steering committee.

Activity increases while accountability decreases.

There is a reason for this.

A meeting allows an organisation to distribute discomfort. A decision concentrates it.

Choosing one priority means another priority loses. Funding one programme may mean stopping another. Giving one executive decision authority means somebody else has less control. Standardising across the enterprise means some business units lose local flexibility.

Those are real organisational costs.

So leaders can unconsciously substitute discussion for decision.

I call the result alignment theatre: visible collaboration without explicit commitment.

It feels constructive because everyone is participating. But the underlying economics have not changed, the conflicting incentives remain, and nobody has accepted the consequences of the supposed agreement.

Business and IT Alignment Is Really About Trade-Offs

This is particularly visible between technology and the business.

For years, organisations have talked about “business and IT alignment” as if the challenge were primarily one of mutual understanding.

Certainly, understanding matters.

But most senior executives already understand far more about each other’s priorities than we sometimes admit.

The CEO knows that technology cannot modernise an estate instantly.

The CIO knows that a commercial leader cannot simply tell customers to wait while architecture improves.

The CFO understands that resilience costs money.

The business understands, at least conceptually, that accumulated complexity creates risk.

The problem usually appears when those truths collide.

A business unit wants a capability in three months. Technology says delivering it properly requires six. Finance will fund only one of two competing programmes. Operations refuses a change during a critical trading period.

Another alignment session does not resolve that conflict.

A decision does.

Which outcome matters most?

Which risk is the enterprise prepared to accept?

Who owns that call?

What stops as a consequence?

Those questions create alignment because they turn strategic language into operational commitment.

The Four Tests of Real Alignment

Over time, I have found it useful to test alignment against four questions.

If a leadership team cannot answer all four clearly, I would hesitate to call it aligned.

1. Outcome: What are we optimising for?

Most organisations have too many priorities because they confuse important things with priorities.

Everything can be important.

Everything cannot come first.

A transformation programme might be expected to reduce cost, improve resilience, accelerate growth, simplify the technology estate, improve customer experience, and strengthen compliance.

But when those outcomes conflict, which one takes precedence?

Boards should demand more precision.

Instead of saying, “This programme will improve efficiency and customer experience,” ask what measurable business outcome has first claim on capital and management attention.

Perhaps the primary objective is reducing customer onboarding time from ten days to two.

Perhaps it is reducing the cost-to-serve by 15 percent.

Perhaps it is eliminating a concentration risk before a regulatory deadline.

Once the outcome is explicit, hundreds of downstream decisions become easier.

Without it, every function optimises for its own interpretation of success.

2. Trade-offs: What are we willing to give up?

This is the question most alignment discussions avoid.

Strategy is not a list of things an organisation wants.

Strategy is a set of choices about what it will prioritise and what it will not.

If speed is genuinely the priority, the organisation may need to accept additional cost.

If standardisation is the priority, some local flexibility will disappear.

If resilience is non-negotiable, certain launches may move more slowly.

If capital efficiency is the priority, some attractive innovations will not be funded.

The boardroom test is simple:

Can leaders articulate what they are willing to sacrifice in order to achieve the stated priority?

If not, the priority is probably still an aspiration.

A useful discipline is to write the trade-off beside the objective.

“Accelerate market launch, accepting up to X additional transition cost.”

“Reduce operating complexity, accepting reduced local customisation.”

“Improve resilience, even if selected delivery milestones move.”

That language is less comfortable than a strategy slide.

It is also far more useful.

3. Decision rights: Who makes the call when priorities collide?

Many organisations are clear about governance until somebody has to say no.

Then authority becomes surprisingly ambiguous.

A programme has a sponsor, a steering committee, a transformation office, business owners, technology leaders, finance representatives, and risk functions.

Yet when a difficult choice emerges, nobody is sure who can decide.

Consensus becomes the default decision mechanism.

That sounds collaborative. At enterprise scale, it can become expensive.

Consensus works when interests naturally align. Governance exists for the moments when they do not.

Every material transformation should therefore establish explicit decision rights.

Who decides whether scope changes?

Who can move funding between initiatives?

Who can accept a technology or operational risk?

Who can stop a programme whose original business case no longer holds?

Who breaks a deadlock between enterprise and business-unit priorities?

If five executives believe they possess veto rights, the organisation does not have governance. It has a queue.

4. Consequences: What changes because we agreed?

This is the most practical test.

After the meeting, what is different?

Has capital moved?

Has a programme stopped?

Has a milestone changed?

Has one priority been elevated above another?

Has an executive accepted ownership of a risk?

Has a team been told what it should no longer do?

If nothing changes, there is a reasonable chance that no meaningful alignment occurred.

Real alignment leaves evidence.

You should be able to see it in investment decisions, performance measures, resource allocation, portfolio sequencing, incentives, and executive behaviour.

The minutes of the meeting matter less than the decisions visible in the organisation afterwards.

The Hidden Cost of Alignment Debt

There is another consequence that boards should pay attention to: alignment debt.

Like technical debt, alignment debt accumulates when difficult choices are repeatedly deferred.

A programme begins with several unresolved assumptions. Nobody settles them because delivery needs to start.

Business units interpret priorities differently. Exceptions are approved. Temporary compromises become permanent. Dependencies multiply.

Eventually the organisation pays for those unresolved decisions through delay, duplicated investment, executive escalation, rework, and weakened accountability.

What initially looked like a people problem often becomes a capital problem.

I have seen transformation teams blamed for slow execution when the underlying issue sat much higher in the organisation. They had been asked to execute against priorities that senior leaders had never truly reconciled.

No project management methodology fixes that.

Teams cannot execute clarity that leadership has not created.

Surely Meetings Still Matter?

Of course they do.

The answer is not fewer conversations for the sake of fewer conversations.

Good alignment meetings have an important role. They surface facts, expose assumptions, identify disagreements, and create the conditions for a decision.

The mistake is treating the meeting itself as the outcome.

A useful alignment meeting should therefore be designed around decisions rather than updates.

Before the meeting, leaders should know:

1.   What decision must be made?

2.   What competing outcomes are involved?

3.   What evidence is required?

4.   Who owns the final decision?

5.   What actions will change depending on the answer?

That produces a very different conversation from an agenda consisting of 12 workstream updates followed by “discussion.”

The distinction matters.

Information can be shared asynchronously.

Executive time should be spent resolving choices that cannot be delegated.

Alignment Does Not Mean Consensus

There is one final misconception worth challenging.

An aligned leadership team does not necessarily agree.

This matters because some organisations pursue harmony when they should pursue clarity.

A CIO may believe a decision creates unacceptable technical risk. A commercial leader may believe delay creates unacceptable market risk. The CFO may challenge both assumptions.

That disagreement is healthy.

Alignment exists when the debate has occurred, the decision mechanism is legitimate, the choice has been made, and leaders commit to executing it even if their preferred option did not win.

That is very different from consensus.

In fact, organisations that require visible consensus on every important decision often make decisions too slowly or dilute them until nobody strongly objects.

The result may feel collaborative.

Competitors are unlikely to care.

What Boards and CEOs Should Ask Instead

The next time a major programme comes to the board or executive committee claiming that “stakeholders are aligned,” I would ask four questions:

What outcome are we optimising for?

What have we explicitly agreed to trade off?

Who has the authority to resolve the next conflict?

What changed in capital, priorities, ownership, or behaviour because of this alignment?

If the answers are vague, another meeting will not solve the problem.

The leadership team has a decision to make.

That distinction becomes more important as organisations undertake larger digital, AI, operating-model, and technology transformations. These programmes cut across functions precisely because the underlying business choices cut across functions.

Technology rarely creates the hardest trade-offs.

It exposes them.

The organisations that move fastest are not necessarily those with the most workshops, steering committees, or collaboration tools.

They are the ones that can turn disagreement into decisions without turning every decision into an organisational crisis.

That is what real alignment looks like.

In your organisation, how often does “we are aligned” actually mean “we have made the difficult trade-offs”?

If this resonates, subscribe to TechnologyTrends or share your experience in the comments.

Sanjay K Mohindroo

Technology value is not the CIO's job alone. A practical framework for making business leaders accountable for technology outcomes and ROI.

Making the Business Own Technology Outcomes

After nearly three decades in enterprise technology, I have seen the same sentence end too many difficult meetings:

“IT needs to fix this.”

Sometimes the problem was a delayed platform. Sometimes adoption was poor. Sometimes the investment had delivered the system everyone asked for, but not the business result everyone had promised.

The conventional wisdom is that when a technology programme succeeds or fails, the CIO should be accountable.

I disagree.

The CIO should be accountable for technology delivery, resilience, architecture, security and technology economics. But if the intended outcome is higher revenue, lower operating cost, faster fulfilment, improved customer retention or reduced business risk, then the business must own that outcome.

Otherwise, we create one of the most expensive governance failures in modern enterprises: business leaders approve technology investments, IT delivers them, and nobody outside IT is truly accountable for extracting the value.

That model has to change.

Technology Accountability Is Not the Same as Business Accountability

Most large technology programmes begin with a business case.

The language is rarely technical.

Increase conversion. Reduce processing time. Improve forecast accuracy. Lower inventory. Accelerate product launches. Reduce regulatory exposure. Improve customer retention.

Yet something strange often happens after the investment is approved.

The business objective remains in the presentation, while operational accountability migrates toward IT.

The programme gets a technology steering committee. Progress becomes milestones, integrations, releases and budgets. The CIO is asked why adoption is slow, why productivity has not improved or why the return on investment has not appeared.

But a CIO cannot force a sales organisation to change its selling process.

A technology team cannot redesign decision rights inside a supply chain.

A platform cannot eliminate redundant approval steps if the business insists on preserving them.

And no software can produce a return on investment if management treats implementation as the end of the transformation.

This is where many boards confuse technology accountability with business accountability.

They are not the same thing.

The Conventional Wisdom Is Wrong: The CIO Cannot Own the Entire Outcome

There is a comfortable management assumption that technology transformation belongs to the CIO because technology is involved.

That logic would sound absurd in almost any other area of business.

We do not tell the CFO to own revenue because pricing sits in the financial model.

We do not tell HR to own sales performance because salespeople require recruitment and incentives.

We do not tell the general counsel to own market expansion because contracts are required.

Technology should be treated the same way.

When the objective is a business outcome, the accountable executive must come from the part of the organisation that can change the process, behaviour, incentives, and operating model required to achieve it.

The CIO remains a critical co-owner.

But co-ownership is different from becoming the organisational shock absorber for every missed transformation target.

#DigitalTransformation

Why Technology Value Disappears After Approval

The business case for a major technology investment usually receives more scrutiny before approval than after implementation.

That is backwards.

Before approval, executives debate benefits, payback periods, risks, and strategic necessity.

Once capital is committed, attention shifts toward delivery.

The question changes from:

“What business result are we buying?”

to:

“Are we on schedule?”

Schedule matters. Cost matters. Technical quality matters.

But none of those prove that the investment created value.

A programme can be on time, within budget and technically sound, while still being a poor business investment.

That is the distinction boards need to enforce.

Technology delivery is an output.

Business value is an outcome.

The two are connected, but they are not interchangeable.

Shared Accountability Does Not Mean Nobody Is Accountable

There is another danger here.

Whenever organisations hear “shared accountability,” responsibility can become blurred across committees, functions and steering groups.

That is not what I am proposing.

Shared accountability should not mean collective ambiguity.

It should mean two clearly named executives accepting responsibility for different sides of the same investment.

One executive owns the technology capability.

One executive owns the business result.

The relationship should be explicit enough that the board knows who must answer which question.

That distinction becomes especially important when results disappoint.

If the platform is unstable, the technology leader should answer for it.

If the platform works but the business has not changed the process, incentives or behaviours required to capture value, the business leader should answer for that.

If both have failed, both should be accountable.

That is far healthier than asking the CIO to explain every number on the benefits case.

The Shared Outcome Accountability Framework

For any material technology investment, I would encourage boards and CEOs to insist on five things before approving capital.

1. Name a Business Outcome Owner

Every significant technology programme should have one senior business executive whose name sits beside the promised business result.

Not a committee.

Not “the business.”

A person.

If the investment promises to reduce cost-to-serve, improve customer conversion or shorten the order-to-cash cycle, someone with authority over that operating outcome must own it.

The test is simple:

If the technology works exactly as designed but the expected business benefit does not appear, who is called into the CEO's office?

If the answer is automatically “the CIO,” the governance model is incomplete.

2. Name a Technology Outcome Owner

The CIO, CTO, or relevant technology executive should own the technology conditions necessary to produce the business result.

That includes delivery quality, scalability, security, resilience, interoperability, and total technology economics.

This is not diluted accountability.

It is sharper accountability.

The technology leader is no longer expected to own matters outside their control, while becoming far more clearly responsible for the technology commitments that are within it.

3. Translate the Business Case into Operating Metrics

Many transformation programmes fail because their benefits remain trapped in the original investment paper.

A promise such as “improve productivity” is too vague.

What changes?

Processing time from what to what?

Conversion from what baseline?

Inventory by how much?

How many manual interventions should disappear?

How much working capital should be released?

By when?

If management cannot answer those questions, the programme does not yet have a measurable outcome.

One metric I like boards to ask for is a simple value bridge:

Baseline performance → technology-enabled change → business behaviour change → financial outcome

This forces executives to explain how the investment actually creates value.

It also exposes assumptions hidden inside large return-on-investment numbers.

4. Make Business Change Part of the Investment

This is where many business cases become unrealistic.

The capital request funds the platform but understates the cost of changing the organisation around it.

Training is budgeted.

Transformation is not.

There is a difference.

Real business change may require redesigning processes, removing controls, changing incentives, consolidating roles, rewriting policies or abandoning practices that senior leaders themselves created.

Those decisions cannot be delegated to the technology function.

Boards should therefore ask a harder question before approving transformation capital:

What must the business stop, start or change for this investment to generate the promised return?

If there is no uncomfortable answer, the transformation may not be transformative enough.

5. Review Value After Go-Live, Not Just Delivery

For many programmes, governance intensity peaks before implementation and falls immediately afterwards.

It should continue until the promised outcome is either achieved, revised with evidence, or formally written off.

A board does not stop reviewing an acquisition the moment the transaction closes.

Technology investments deserve similar discipline.

At 90 days, six months and twelve months after implementation, management should be able to answer:

What value has been realised?

What has not?

Which assumptions were wrong?

Which business changes have not happened?

What additional capital is required?

Should we continue, change direction, or stop?

This turns technology governance into capital governance.

That is where it belongs.

A Useful Boardroom Distinction: Adoption Is Not Value

Another mistake is using adoption as proof of success.

Adoption can be encouraging, but it is an intermediate measure.

A thousand employees logging into a new platform does not demonstrate value.

The important question is what changed because they used it.

Did decisions become faster?

Did error rates fall?

Did customers behave differently?

Did the organisation require fewer manual interventions?

Did revenue improve?

Did risk decrease?

I have seen organisations celebrate usage statistics while the original economics of the investment quietly disappeared from discussion.

That is dangerous.

Management should track adoption because poor adoption can prevent value.

But adoption itself is not the destination.

#CIO

What Happens When the Business Really Owns the Outcome

The quality of decision-making changes.

Business executives begin asking different questions before approving technology expenditure because they know their own performance will ultimately be measured against the result.

Requirements become more disciplined.

“Nice to have” functionality receives more scrutiny.

Process redesign happens earlier.

Adoption stops being somebody else's problem.

And benefits are less likely to become theoretical numbers added to a presentation simply to pass an investment threshold.

There is another benefit.

The relationship between the CIO and business leadership becomes healthier.

Instead of IT acting as supplier and the business acting as customer, both sides become investors in a common result.

That is a far more mature operating model.

The Counter-Argument: The Business Does Not Understand Technology

I often hear a version of this objection:

“The business cannot own something it does not understand.”

I think that confuses understanding the technology with owning the outcome.

A CEO does not need to understand every engineering detail of a factory to hold the operations leader accountable for manufacturing performance.

A board does not need to understand every quantitative model used by treasury to hold the CFO accountable for financial risk.

Business leaders do not need deep technical expertise to own the result a technology investment is supposed to produce.

They need to understand what they are buying, what assumptions underpin the value case, and what their organisation must change to realise it.

If they cannot do that, the answer is not to transfer accountability to IT.

The answer is to improve the quality of executive decision-making.

Technology Governance Should Follow the Money

At board level, technology is increasingly one of the largest pools of discretionary and strategic investment.

That means technology governance cannot remain a specialist conversation.

It is a capital allocation conversation.

For every major programme, directors should know:

What business outcome are we purchasing?

Who owns that outcome?

What assumptions connect the investment to financial value?

Which business changes are required?

What happens if the value does not materialise?

These are not CIO questions.

They are management questions.

And once boards begin asking them consistently, something useful happens: technology stops being viewed as an expensive department that periodically requests capital.

It becomes what it should have been all along, an instrument for changing business performance.

The Real Accountability Test

There is one question I would put to any executive team approving a major technology programme:

If this system works perfectly and the business case still fails, who owns the failure?

If the answer is unclear, the programme is not ready for approval.

If the answer is “IT,” despite the promised benefits sitting in sales, operations, finance or customer experience, the accountability model is wrong.

The best technology organisations I have seen do not ask the business to “support” transformation.

They make the business own the transformation with them.

That is the shift boards should demand.

Not more steering committees.

Not another alignment workshop.

Clear ownership of business outcomes, paired with clear ownership of technology performance.

Because when everybody benefits from technology but only the CIO is accountable for the result, accountability is not shared.

It is outsourced.

How does your organisation handle this today? When a technology investment delivers the system but misses the business result, who actually owns the outcome?

If this resonates, subscribe to TechnologyTrends or add your perspective in the comments.

Sanjay K Mohindroo

Build a joint business and technology operating rhythm that improves capital allocation, accountability, risk decisions, and measurable business value.

Building a Joint Business and Technology Operating Rhythm

I have sat in executive reviews where technology had a full roadmap, the business had a full strategy, and both sides believed they were aligned.

Then one question exposed the problem: which business outcomes are we jointly accountable for in the next 90 days?

The answers were rarely the same.

That is the uncomfortable truth behind much of what is called “business-IT alignment.” The conventional wisdom says alignment comes from better communication, more business relationship managers, shared workshops, or giving technology leaders a seat at the table.

Those things help. They do not solve the problem.

Alignment is not primarily a communication problem. It is an operating rhythm problem.

If business and technology leaders plan separately, review performance separately, allocate capital separately, and escalate risks through separate management processes, they will behave like separate organisations, no matter how many alignment workshops they attend.

The answer is not another governance committee.

The answer is a joint business and technology operating rhythm built around decisions, outcomes, capital, risk, and accountability.

Why Business and Technology Alignment Still Fails

For years, organisations have treated technology alignment as if the objective were to make IT understand the business better.

That framing is now outdated.

Technology is embedded in pricing, distribution, customer acquisition, supply chains, service delivery, regulatory compliance, productivity, resilience, and increasingly the economics of the business model itself.

The question is no longer whether technology supports strategy.

The question is whether business and technology leaders are running the same strategy through the same management system.

Consider a familiar pattern.

The CEO and business leaders agree on growth priorities during the annual planning process. Technology then converts those priorities into programmes, systems, platforms, integrations, data initiatives, security investments, and infrastructure work.

Three months later, the business is asking why a commercial priority has not moved faster.

Technology replies that dependencies, capacity constraints, architecture decisions, regulatory requirements, and other commitments made the original timeline unrealistic.

Both sides may be factually correct.

The operating model is still broken.

The business made commitments without seeing the full technology consequences. Technology made delivery decisions without continuously revisiting whether the original business assumptions still justified the investment.

What should have been one management conversation became two reporting systems.

Stop Treating Technology Governance as a Technology Process

This is where conventional governance often makes matters worse.

Many companies have steering committees, architecture boards, investment committees, project reviews, transformation offices, quarterly business reviews, risk committees, and technology portfolio reviews.

The organisation is not short of meetings.

It is short of shared decisions.

A technology steering committee that discusses milestones, resource utilisation, application status, defects, or programme traffic lights may be useful operationally. It is not a substitute for executive governance.

At board and CEO level, the questions are different:

• Are we still investing in the right business outcomes?
• Has the economic case changed?
• Is execution increasing or reducing enterprise risk?
• What should receive more capital?
• What should stop?
• Where is accountability unclear?
• What decision is management avoiding?

That changes the role of the technology leader.

The CIO should not enter the room merely to explain technology performance. The CIO should participate in the allocation of enterprise resources against business priorities.

Equally, business leaders cannot outsource the consequences of digital execution to IT.

If a new commercial model depends on technology, then its technology constraints are business constraints.

The Five-Beat Business and Technology Operating Rhythm

The strongest organisations I have seen do not achieve alignment through slogans.

They create a repeatable rhythm in which business and technology leaders make the same five types of decisions together.

I think of it as a five-beat operating rhythm.

1. Define a Small Number of Joint Business Outcomes

The first discipline is subtraction.

Most organisations have too many priorities because every initiative is allowed to describe itself as strategic.

A genuine joint operating rhythm starts with a small set of business outcomes that matter enough to compete for executive attention and capital.

Not:

Implement the new customer platform.

But:

Increase digital conversion while reducing acquisition cost.

Not:

Complete cloud migration.

But:

Reduce the cost and operational risk of running the current estate.

Not:

Build an enterprise data platform.

But:

Improve pricing, forecasting, or customer decisions using trusted data.

The distinction matters because technical delivery is not the same thing as economic success.

A platform can launch on time and still destroy value.

A programme can miss its original technical scope and still create significant value if the business outcome improves.

The shared outcome should therefore include a business measure, an accountable executive, a defined time horizon, and the assumptions supporting the investment.

I would rather see a board track six meaningful technology-enabled business outcomes than receive 60 project status indicators.

2. Make Portfolio Choices Together

The second beat is where alignment becomes real: capital allocation.

Technology portfolios often contain several layers of spending at once:

mandatory regulatory work, cyber and resilience investments, infrastructure, technical debt reduction, productivity initiatives, growth programmes, data capabilities, and innovation bets.

Each can be justified individually.

The problem is that capital is finite.

So is management attention.

A joint operating rhythm requires business and technology executives to make trade-offs in the same room.

If the organisation wants to accelerate a digital sales programme, what gets delayed?

If a regulatory deadline consumes scarce engineering capacity, which commercial assumption must change?

If maintaining a legacy environment absorbs an increasing share of technology expenditure, what is the economic case for continuing to defer simplification?

These are business decisions.

They should not emerge indirectly from IT capacity planning.

One practical discipline is to classify major technology expenditure according to the business reason the organisation is funding it:

1.   Run: maintain essential operations and service levels.

2.   Protect: reduce cyber, regulatory, operational, or continuity risk.

3.   Improve: reduce cost, increase productivity, or improve quality.

4.   Grow: create revenue, customer, market, or strategic advantage.

5.   Option: fund controlled experiments where the economic case is not yet proven.

The exact labels matter less than the conversation they force.

When leaders can see how much capital is being consumed by each category, technology stops looking like a single cost line.

It becomes a portfolio of enterprise bets.

3. Review Value and Risk Monthly, Not Just Delivery

The third beat is the monthly management review.

This is where many organisations fall back into old habits.

The meeting becomes a project status update.

Green, amber, red.

Milestones completed.

Budget consumed.

Issues escalated.

That is not enough.

Every major technology-enabled initiative should be reviewed against three dimensions:

Value: Is the expected business outcome still achievable?

Execution: Are we delivering the capabilities needed to achieve it?

Risk: Has the risk profile changed?

These three dimensions frequently move differently.

A programme may be technically green but economically red because market conditions changed.

A programme may be behind schedule but commercially more attractive because customer demand increased.

A cyber programme may create no direct revenue but materially reduce enterprise exposure.

The point of the operating rhythm is not to reward green dashboards.

It is to surface changes early enough for management to act.

4. Reallocate Capital Quarterly

Annual technology planning is one of the least questioned habits in large organisations.

It should be questioned.

You cannot credibly operate in fast-moving markets while pretending that every technology investment decision made during the annual budget cycle will remain equally sensible nine months later.

Quarterly portfolio reviews should therefore ask a harder question than, “Are we on budget?”

They should ask, “Would we approve this investment again today?”

If the answer is no, management should have the courage to reduce, redesign, pause, or stop it.

This is where the joint rhythm becomes a source of competitive advantage.

Most organisations are relatively good at approving projects.

Far fewer are good at withdrawing capital from initiatives whose assumptions have weakened.

The ability to stop is an executive capability.

Consider a business investing heavily in a new customer proposition. Six months into execution, competitive behaviour changes and the original revenue assumptions weaken.

The conventional response is often to continue because money has already been spent, teams are mobilised, and stopping would be politically uncomfortable.

A better operating rhythm treats sunk cost as sunk cost.

The next unit of capital must compete again against every other use of that capital.

That is not technology governance.

That is basic management discipline.

5. Make One Executive Accountable for Each Outcome

The final beat concerns accountability.

Joint ownership sounds collaborative, but it can easily become no ownership.

Every major outcome needs one clearly accountable business executive.

Technology leaders should share accountability for delivery choices, architecture, resilience, security, data integrity, and technology economics.

But the business outcome itself cannot belong to “IT.”

If a digital distribution programme fails to produce the expected revenue, the answer cannot simply be that the technology platform was delivered successfully.

Similarly, if business leaders continually change scope, avoid process decisions, or fail to drive adoption, the programme cannot simply be labelled an IT failure.

The operating rhythm should make those dependencies visible.

A useful test is simple.

At any executive review, management should be able to answer four questions in under five minutes:

1.   What business outcome are we trying to create?

2.   What is the current economic case?

3.   What is preventing us from achieving it?

4.   Who must make the next decision?

If the room cannot answer those questions clearly, more project detail will not fix the problem.

What the Board Should Actually See

Boards do not need a more sophisticated technology dashboard.

They need better visibility into the economics and risk of technology-enabled change.

A board-level view should therefore concentrate on a limited number of indicators.

For major initiatives:

• capital committed and capital still at risk
• business value expected and value actually realised
• major assumptions that have changed
• material delivery or dependency risk
• cyber, regulatory, operational, and resilience exposure
• decisions requiring executive or board intervention

The purpose is not to turn directors into programme managers.

It is to allow the board to discharge its responsibility for capital allocation, strategy, risk, and management accountability.

That distinction is important.

The Counter-Argument: Does This Create Too Many Meetings?

A reasonable objection is that senior executives are already overwhelmed with governance.

Why add another operating rhythm?

My answer is that organisations should not add one.

They should remove several.

A joint business and technology rhythm should replace duplicated reporting processes, not sit on top of them.

If the business has one strategy meeting, technology has another portfolio review, transformation has its own steering group, and finance reviews investment separately, the organisation is paying four times for fragmented decision-making.

Combine the decisions that belong together.

Push technical detail downward.

Escalate only the decisions that require enterprise trade-offs.

The goal is fewer meetings with better consequences.

The Real Test of Business-Technology Alignment

The strongest signal of alignment is not whether the CIO attends the executive committee.

It is not whether business leaders understand cloud, AI, cybersecurity, or architecture.

It is not whether every programme has a business sponsor.

The real test is this:

When assumptions change, can business and technology leaders change direction together?

Can they move capital?

Can they stop something?

Can they accept a technology constraint as a business constraint?

Can they increase investment when evidence improves?

Can they identify one person who owns the next decision?

That is what an operating rhythm creates.

Technology has become too economically important to manage through a separate management cycle.

The organisations that understand this will spend less time talking about “business-IT alignment” because they will no longer be running two different systems that need to be aligned.

They will simply be running the business.

In your organisation, do business and technology leaders genuinely make portfolio decisions together, or do they still meet mainly to explain decisions already made elsewhere?

Subscribe to TechnologyTrends or add your perspective in the comments. I am particularly interested in what has worked, and what has failed, in your own operating model.

Sanjay K Mohindroo

Technology value is not the CIO's job alone. A practical framework for making business leaders accountable for technology outcomes and ROI.

Making the Business Own Technology Outcomes

After nearly three decades around enterprise technology, I have seen the same sentence end too many difficult meetings:

“IT needs to fix this.”

Sometimes the problem was a delayed platform. Sometimes adoption was poor. Sometimes the investment had delivered the system everyone asked for, but not the business result everyone had promised.

The conventional wisdom is that when a technology programme succeeds or fails, the CIO should be accountable.

I disagree.

The CIO should be accountable for technology delivery, resilience, architecture, security and technology economics. But if the intended outcome is higher revenue, lower operating cost, faster fulfilment, improved customer retention or reduced business risk, then the business must own that outcome.

Otherwise, we create one of the most expensive governance failures in modern enterprises: business leaders approve technology investments, IT delivers them, and nobody outside IT is truly accountable for extracting the value.

That model has to change.

Technology Accountability Is Not the Same as Business Accountability

Most large technology programmes begin with a business case.

The language is rarely technical.

Increase conversion. Reduce processing time. Improve forecast accuracy. Lower inventory. Accelerate product launches. Reduce regulatory exposure. Improve customer retention.

Yet something strange often happens after the investment is approved.

The business objective remains in the presentation, while operational accountability migrates toward IT.

The programme gets a technology steering committee. Progress becomes milestones, integrations, releases and budgets. The CIO is asked why adoption is slow, why productivity has not improved or why the return on investment has not appeared.

But a CIO cannot force a sales organisation to change its selling process.

A technology team cannot redesign decision rights inside a supply chain.

A platform cannot eliminate redundant approval steps if the business insists on preserving them.

And no software can produce a return on investment if management treats implementation as the end of the transformation.

This is where many boards confuse technology accountability with business accountability.

They are not the same thing.

The Conventional Wisdom Is Wrong: The CIO Cannot Own the Entire Outcome

There is a comfortable management assumption that technology transformation belongs to the CIO because technology is involved.

That logic would sound absurd in almost any other area of business.

We do not tell the CFO to own revenue because pricing sits in the financial model.

We do not tell HR to own sales performance because salespeople require recruitment and incentives.

We do not tell the general counsel to own market expansion because contracts are required.

Technology should be treated the same way.

When the objective is a business outcome, the accountable executive must come from the part of the organisation that can change the process, behaviour, incentives and operating model required to achieve it.

The CIO remains a critical co-owner.

But co-ownership is different from becoming the organisational shock absorber for every missed transformation target.

#DigitalTransformation

Why Technology Value Disappears After Approval

The business case for a major technology investment usually receives more scrutiny before approval than after implementation.

That is backwards.

Before approval, executives debate benefits, payback periods, risks, and strategic necessity.

Once capital is committed, attention shifts toward delivery.

The question changes from:

“What business result are we buying?”

to:

“Are we on schedule?”

Schedule matters. Cost matters. Technical quality matters.

But none of those prove that the investment created value.

A programme can be on time, within budget and technically sound, while still being a poor business investment.

That is the distinction boards need to enforce.

Technology delivery is an output.

Business value is an outcome.

The two are connected, but they are not interchangeable.

Shared Accountability Does Not Mean Nobody Is Accountable

There is another danger here.

Whenever organisations hear “shared accountability,” responsibility can become blurred across committees, functions and steering groups.

That is not what I am proposing.

Shared accountability should not mean collective ambiguity.

It should mean two clearly named executives accepting responsibility for different sides of the same investment.

One executive owns the technology capability.

One executive owns the business result.

The relationship should be explicit enough that the board knows who must answer which question.

That distinction becomes especially important when results disappoint.

If the platform is unstable, the technology leader should answer for it.

If the platform works but the business has not changed the process, incentives or behaviours required to capture value, the business leader should answer for that.

If both have failed, both should be accountable.

That is far healthier than asking the CIO to explain every number on the benefits case.

The Shared Outcome Accountability Framework

For any material technology investment, I would encourage boards and CEOs to insist on five things before approving capital.

1. Name a Business Outcome Owner

Every significant technology programme should have one senior business executive whose name sits beside the promised business result.

Not a committee.

Not “the business.”

A person.

If the investment promises to reduce cost-to-serve, improve customer conversion or shorten the order-to-cash cycle, someone with authority over that operating outcome must own it.

The test is simple:

If the technology works exactly as designed but the expected business benefit does not appear, who is called into the CEO's office?

If the answer is automatically “the CIO,” the governance model is incomplete.

2. Name a Technology Outcome Owner

The CIO, CTO, or relevant technology executive should own the technology conditions necessary to produce the business result.

That includes delivery quality, scalability, security, resilience, interoperability, and total technology economics.

This is not diluted accountability.

It is sharper accountability.

The technology leader is no longer expected to own matters outside their control, while becoming far more clearly responsible for the technology commitments that are within it.

3. Translate the Business Case Into Operating Metrics

Many transformation programmes fail because their benefits remain trapped in the original investment paper.

A promise such as “improve productivity” is too vague.

What changes?

Processing time from what to what?

Conversion from what baseline?

Inventory by how much?

How many manual interventions should disappear?

How much working capital should be released?

By when?

If management cannot answer those questions, the programme does not yet have a measurable outcome.

One metric I like boards to ask for is a simple value bridge:

Baseline performance → technology-enabled change → business behaviour change → financial outcome

This forces executives to explain how the investment actually creates value.

It also exposes assumptions hidden inside large return-on-investment numbers.

4. Make Business Change Part of the Investment

This is where many business cases become unrealistic.

The capital request funds the platform but understates the cost of changing the organisation around it.

Training is budgeted.

Transformation is not.

There is a difference.

Real business change may require redesigning processes, removing controls, changing incentives, consolidating roles, rewriting policies or abandoning practices that senior leaders themselves created.

Those decisions cannot be delegated to the technology function.

Boards should therefore ask a harder question before approving transformation capital:

What must the business stop, start or change for this investment to generate the promised return?

If there is no uncomfortable answer, the transformation may not be transformative enough.

5. Review Value After Go-Live, Not Just Delivery

For many programmes, governance intensity peaks before implementation and falls immediately afterwards.

It should continue until the promised outcome is either achieved, revised with evidence or formally written off.

A board does not stop reviewing an acquisition the moment the transaction closes.

Technology investments deserve similar discipline.

At 90 days, six months and twelve months after implementation, management should be able to answer:

What value has been realised?

What has not?

Which assumptions were wrong?

Which business changes have not happened?

What additional capital is required?

Should we continue, change direction or stop?

This turns technology governance into capital governance.

That is where it belongs.

A Useful Boardroom Distinction: Adoption Is Not Value

Another mistake is using adoption as proof of success.

Adoption can be encouraging, but it is an intermediate measure.

A thousand employees logging into a new platform does not demonstrate value.

The important question is what changed because they used it.

Did decisions become faster?

Did error rates fall?

Did customers behave differently?

Did the organisation require fewer manual interventions?

Did revenue improve?

Did risk decrease?

I have seen organisations celebrate usage statistics while the original economics of the investment quietly disappeared from discussion.

That is dangerous.

Management should track adoption because poor adoption can prevent value.

But adoption itself is not the destination.

#CIO

What Happens When the Business Really Owns the Outcome

The quality of decision-making changes.

Business executives begin asking different questions before approving technology expenditure because they know their own performance will ultimately be measured against the result.

Requirements become more disciplined.

“Nice to have” functionality receives more scrutiny.

Process redesign happens earlier.

Adoption stops being somebody else's problem.

And benefits are less likely to become theoretical numbers added to a presentation simply to pass an investment threshold.

There is another benefit.

The relationship between the CIO and business leadership becomes healthier.

Instead of IT acting as supplier and the business acting as customer, both sides become investors in a common result.

That is a far more mature operating model.

The Counter-Argument: The Business Does Not Understand Technology

I often hear a version of this objection:

“The business cannot own something it does not understand.”

I think that confuses understanding the technology with owning the outcome.

A CEO does not need to understand every engineering detail of a factory to hold the operations leader accountable for manufacturing performance.

A board does not need to understand every quantitative model used by treasury to hold the CFO accountable for financial risk.

Business leaders do not need deep technical expertise to own the result a technology investment is supposed to produce.

They need to understand what they are buying, what assumptions underpin the value case, and what their organisation must change to realise it.

If they cannot do that, the answer is not to transfer accountability to IT.

The answer is to improve the quality of executive decision-making.

Technology Governance Should Follow the Money

At board level, technology is increasingly one of the largest pools of discretionary and strategic investment.

That means technology governance cannot remain a specialist conversation.

It is a capital allocation conversation.

For every major programme, directors should know:

What business outcome are we purchasing?

Who owns that outcome?

What assumptions connect the investment to financial value?

Which business changes are required?

What happens if the value does not materialise?

These are not CIO questions.

They are management questions.

And once boards begin asking them consistently, something useful happens: technology stops being viewed as an expensive department that periodically requests capital.

It becomes what it should have been all along, an instrument for changing business performance.

The Real Accountability Test

There is one question I would put to any executive team approving a major technology programme:

If this system works perfectly and the business case still fails, who owns the failure?

If the answer is unclear, the programme is not ready for approval.

If the answer is “IT,” despite the promised benefits sitting in sales, operations, finance or customer experience, the accountability model is wrong.

The best technology organisations I have seen do not ask the business to “support” transformation.

They make the business own the transformation with them.

That is the shift boards should demand.

Not more steering committees.

Not another alignment workshop.

Clear ownership of business outcomes, paired with clear ownership of technology performance.

Because when everybody benefits from technology, but only the CIO is accountable for the result, accountability is not shared.

It is outsourced.

How does your organisation handle this today? When a technology investment delivers the system but misses the business result, who actually owns the outcome?

If this resonates, subscribe to TechnologyTrends or add your perspective in the comments.