Category Archives: Digital Transformation

The Programme Succeeded. That Was the Problem.

Posted on by

Most digital transformation programmes are designed to end.

That is the actual design flaw. Not the technology chosen, not the budget allocated, not even the ambition behind the initiative. The programme itself is structured around a finish line, a go-live date, a steering committee sign-off, a moment when the work is declared complete and the team disbands.

The problem is that the market, the technology, and the customer never agreed to stop moving at that point.

 

The Project Mindset Is the Actual Liability

Transformation programmes are built like construction projects. Define the scope, execute the plan, hand over the keys, move on to the next thing. That structure works well for building a bridge. It works badly for building an organisation’s capacity to keep adapting, because the moment the programme ends, so does the organisation’s active attention to the problem it was meant to solve.

A May 2026 Forbes Business Council analysis puts it plainly: treating digital transformation as a project sets the expectation that there is a finish line to cross. There is not. Markets keep moving. Customer expectations shift faster than any single programme can track. Data environments and operating models change shape well after the sign-off. A transformation programme with a defined end date is optimised for a world that stopped changing the day the programme closed, which is not the world any organisation actually operates in.

The Forbes analysis draws a comparison that holds up well: digital transformation works like fitness. When you stop, you atrophy. Nobody who has kept fit for a decade did it with a single twelve-week programme and then stopped. They built a habit that never formally ends.

 

What Continuous Capability Actually Looks Like

Tesla is the clearest large-scale example of what this looks like in practice. Tesla ships software improvements to vehicles already on the road through over-the-air updates, rather than treating the car’s capability as fixed at the point of sale. Autopilot and Full Self-Driving features are refined through frequent releases, often tested on a small subset of vehicles before wider rollout, rather than waiting for a full model cycle to bundle every improvement together. The car’s capability keeps changing for as long as the vehicle is on the road, never declared finished at any single point.

Most organisations do not need to ship software to a fleet of vehicles. But the underlying pattern is the same: small changes shipped continuously and tested before wide release, rather than large changes bundled into an infrequent big-bang release. That pattern is exactly what separates organisations still adapting years after their transformation programme closed from the ones still running the same processes the programme was meant to replace.

 

The Five Things That Actually Change

Shifting from a transformation mindset to a continuous one is not about abandoning structure. It requires deciding to do a small number of things differently, and doing them consistently.

Start with the conversation itself. The goal is not to convince stakeholders that transformation was wrong. It is to convince them that the current approach stops too early. Frame the shift as doing transformation properly, not as replacing it with something else.

Build modular, not monolithic. Large, all-or-nothing platform overhauls are exactly the kind of investment that locks an organisation into a single technology decision for a decade. Modular, scalable components can be replaced or upgraded individually as needs change, without requiring another multi-year programme to do it.

Treat learning as infrastructure, not an event. A single training push before go-live does not build a capability. Continuous training, embedded guidance, and space to experiment safely are what actually let people keep pace with a system that keeps changing.

Change what gets measured. Tracking project completion tells you the programme finished. It tells you nothing about whether the organisation can still adapt six months later. Track agility, the rate of continuous improvement, and customer outcomes instead, because those are the metrics that actually describe ongoing capability.

Build the feedback loop permanently. Regular input from employees and customers is not a phase of the programme. It is the mechanism that tells the organisation when the next adjustment is needed, and it only works if it never switches off.

 

The Question Worth Asking Before the Next Transformation Sign-Off

Before the next transformation programme gets a steering committee sign-off and a closing date, the honest question is whether the organisation’s capacity to keep adapting exists independently of the programme that is about to close, not whether the scope was delivered.

If the answer is no, the programme did not fail to transform the organisation. It succeeded at exactly what it was designed to do, and the design was the problem.

Your Transformation Programme Is Burning Out the People Who Are Supposed to Deliver It

Posted on by

Most digital transformation programmes are designed to transform the organisation. The people carrying that transformation are expected to adapt around it.

That sequencing is the problem.

The burnout, the disengagement, and the resistance that characterise most large transformation programmes trace back further than communication or change management execution. They are downstream consequences of decisions made at the very start of the programme, when the workforce was treated as a delivery resource rather than as the primary constraint to be understood before anything else was designed.

The result is predictable. BCG’s own analysis of digital transformations found that only 30% fully succeed, 44% create some value while missing their targets, and the remaining 26% deliver little or nothing. Bain’s most recent research goes further: 88% of leaders are confident their reorganisation will deliver, but only 36% of the employees actually working inside it agree. McKinsey’s analysis consistently identifies culture and people factors, not technology underperformance, as the primary driver of transformation failure. Its survey research puts a number on one specific piece of that: when senior leaders personally model the behavioural changes they are asking employees to make, the transformation is 5.3 times more likely to succeed.  And yet most programme designs continue to treat the technology as the dependent variable and the workforce as a constant.

The workforce is the one variable that determines everything else.

 

The Capacity Crisis That Everyone Can See and No-One Will Name

66% of American employees reported experiencing burnout in 2025, an all-time high. The rate is worse among the workers most exposed to change: 81% of those aged 18 to 24 and 83% of those aged 25 to 34 report burnout, against 49% of workers aged 55 and older, precisely the cohort most transformation programmes lean on hardest to adopt new systems and new processes.

Only 31% of US employees were actively engaged at work in 2024, the lowest rate recorded in a decade, and 17% were actively disengaged. Gallup’s mid-2025 data puts engagement at 32%, effectively flat rather than recovering.

These numbers describe the actual workforce that transformation programmes are asking to do additional, unfamiliar, and often stressful work on top of existing commitments, not some abstract backdrop to the real business of delivery.

Most large transformations run in parallel with business as usual. The assumption, rarely made explicit but almost always present in the programme design, is that the existing workforce will carry both. The system analyst who is supporting the live operation and attending the new system design workshop and completing their module in the learning platform and updating their change readiness survey: these activities all draw from the same finite capacity. And when that capacity is already under strain, the transformation gets what is left.

 

Where the Design Failure Actually Happens

The standard response to workforce resistance and burnout in transformation programmes is to commission more change management activity. More communication. More engagement events. More of the same interventions applied harder.

The reason this rarely resolves the problem is that it treats the symptom, disengagement, resistance, fatigue, as the cause. It does not address the underlying design decision that produced the symptom.

The design failure is earlier and more structural than change management can reach. It happens when the programme scope is defined before anyone has seriously assessed what the existing workforce is currently carrying, what discretionary capacity genuinely exists, and what the realistic absorption rate for change actually is in this organisation, at this time, in this context.

Prosci’s research on sponsorship effectiveness found that projects with highly effective executive sponsorship are almost 3.5 times more likely to meet or exceed their objectives than projects with weak sponsorship. That finding is routinely misquoted as being about change management activity in general, when it specifically measures the quality of sponsorship: the extent to which senior leaders visibly own the change, actively communicate its rationale, and stay engaged with it once the initial announcement has faded. Sponsorship of that kind is a design discipline applied from the beginning, shaping the scope, the pace, the sequencing, and the ask on the workforce before the business case is finalised, not a communications workstream bolted on afterwards.

 

The Three Decisions That Set the Conditions

There are three decisions made at the start of most transformation programmes that determine whether the workforce becomes an enabler or a constraint. All three are made before the first delivery milestone is reached. And in most programmes, all three are made in a way that prioritises ambition over capacity.

The first is scope. The scale of a transformation programme is typically determined by what the organisation wants to achieve and what the technology enables. The workforce’s current capacity, existing obligations, and realistic absorption rate are rarely weighted with the same rigour. A scope that is technically achievable but humanly unsustainable will fail through attrition, quality erosion, and the slow withdrawal of discretionary effort.

The second is sequencing. The order in which change is introduced to the workforce matters more than most programme designs acknowledge. Asking the same population to absorb multiple concurrent workstreams, new system, new process, new skills, new reporting lines, compounds the cognitive and emotional load in ways that tend to surface as resistance but originate as exhaustion.

The third is investment in workforce capacity before deployment. The organisations that sustain transformation over time do not wait for resistance to emerge and then address it. They assess the workforce’s capacity constraint honestly at the outset and make deliberate investments, in backfill, in reduced BAU commitments during peak change periods, in genuine relief on existing obligations, before the transformation work begins.

 

The Longer View

The organisations that sustain transformation over time are rarely the fastest movers in the first twelve months. They are the ones still moving in month thirty-six, because the workforce has not burned out, has not disengaged en masse, and has not lost the institutional confidence that the programme will actually deliver.

Disengaged employees cost the global economy an estimated $8.8 trillion annually, roughly 9% of global GDP. Most of that is preventable. Not by communicating more, but by designing better, starting with an honest understanding of what the workforce can actually carry, and building the programme around that constraint instead of ignoring it.

The people are not the risk to be managed. They are the foundation on which every transformation outcome rests.

Design around them first.

The NHS Just Handed Every Transformation Leader a Very Expensive Lesson

Posted on by

 

Four NHS trusts have now admitted their discharge delay figures were wrong. Not slightly wrong. The kind of wrong where numbers fall from the thousands to zero overnight, then climb straight back up within weeks, a pattern no functioning hospital produces naturally. Those figures sat underneath NHS England’s proudest claim about its £330 million Palantir contract: a 15 per cent fall in delayed discharges, held up as proof the Federated Data Platform was working.

A Financial Times investigation has now found irregularities in the discharge data of 42 per cent of all NHS trusts, across four years of records. The UK’s statistics regulator, the Office for Statistics Regulation, is investigating how the figures were used to justify the technology. A cross-party group of MPs has written to ministers urging the government to use the contract’s break clause, which the government can exercise from February 2027. And NHS England’s own chief executive, Sir Jim Mackey, told a select committee this week that he had personally challenged whether the benefits claims “have been objective and can be fully stood up if challenged.”

The person running the organisation just told Parliament, on the record, that he isn’t confident the headline number survives scrutiny. That’s a long way past a minor caveat.

It doesn’t stop at discharge delays either. A separate Freedom of Information request from the campaign group Foxglove found that close to a third of trusts using the platform’s scheduling tool carried out fewer procedures after adopting it than before, and that a single trust, Chelsea and Westminster, accounted for 84 per cent of the reported fall in outpatient waiting lists across the entire programme. One hospital’s good year, dressed up as a national result.

I’ve sat in enough steering committees to know exactly how this happens. And it isn’t really a story about Palantir.

 

The Data Was Never Built to Do This Job

Charles Tallack, formerly head of operational research and evaluation at NHS England, put it plainly: the evidence for the platform’s impact “looked increasingly flimsy.” His reasoning matters more than the headline. “The delayed discharge dataset may be suitable for day-to-day management purposes, but not for evaluation,” he said.

That’s the whole story in one sentence. NHS England’s own website admits the data undergoes only “minimal validation”, because the speed of collection doesn’t allow for more; it’s explicitly badged as “fit-for-purpose” for NHS management information.

It was built so ward managers could see who needs discharging today, not so a select committee could weigh whether a £330 million technology contract earned its keep. Those are two different jobs, needing two different levels of rigour. Somewhere along the way, one got quietly substituted for the other.

Every transformation leader has watched this substitution happen. Operational dashboards get repurposed as benefit trackers because they’re already there, already live, already familiar to the room. Nobody sits down and consciously decides to treat management data as evaluation-grade evidence. It just drifts that way, one board pack at a time, until a number designed to flag today’s bottleneck is being quoted as proof a nine-figure programme delivered its business case.

 

When the Numbers Look Too Clean, Get Suspicious

A drop from thousands of delayed discharges to zero, then straight back up, should never have made it into a report unchallenged. That’s not an improvement curve. That’s a data pipeline breaking.

I’d go further: any benefit metric that moves in a straight line, with no noise, no seasonality, no awkward months, should raise your suspicion before it raises your confidence. Real operational change is messy. It has plateaus, regressions, a bad winter, a strike, a system outage. A number that behaves too perfectly is usually telling you something broke upstream, not that something improved downstream. And a national result that traces back to one outperforming site, as the Foxglove data suggests happened here, is a local win being marketed as a systemic one.

 

Whoever Owns the Contract Shouldn’t Own the Evidence

The underlying dataset sits with NHS England, not Palantir. But that’s precisely the point worth stressing. The organisation whose reputation, and whose vendor relationship, depended on this figure looking good was also the organisation compiling it, with minimal quality checks, and no independent evaluation running alongside it until the regulator forced the question.

One NHS official told the FT that trusts “are being asked to put their name to statements about improvements before the tools are fully embedded and before the evaluations are done.” Read that twice. Governance failed here. Data quality is just where it happened to show up first, and I’ve seen it inside plenty of transformation programmes that had nothing to do with the NHS or with Palantir.

If the same team that needs the benefit case to land is also the team producing the evidence for it, the incentive to tell a good story will always beat the incentive to tell the true one.

 

Three Questions Worth Asking Before You Quote a Benefit Number Externally

Before any number from your programme reaches a board pack, a press release, or a select committee, it’s worth asking:

Was this dataset designed to answer the question I’m now asking of it, or was it designed for something else entirely and repurposed under pressure?

Who compiled this figure, and do they have a stake in it looking good?

Would this number survive an independent audit conducted by someone with no relationship to the programme?

If you can’t answer all three with confidence, what you’ve got is a hypothesis pretending to be a benefits case.

 

The Real Cost Isn’t the Contract

NHS England will likely survive this, whatever happens to the Palantir contract when the break clause opens in 2027. What’s harder to repair is trust in the next number this organisation, or any organisation, puts in front of Parliament, staff, or the public. Sir Jim Mackey said an objective review “would be helpful and necessary” but would take months. That’s months of every subsequent claim being read with one eyebrow raised.

Build your evaluation evidence with the same rigour you’d want turned on you, before someone else turns it on for you.

Your AI Initiative Isn’t Failing Because of the Technology

Posted on by

The technology works. That is almost never the problem.

Across most large organisations right now, AI pilots are running. Proof-of-concepts are producing results that make it into board presentations. Vendor demos are impressive. The innovation team is energised. And then, somewhere between the pilot environment and actual production, the whole thing quietly stops.

According to Deloitte’s 2026 State of AI report, drawn from more than 3,200 business leaders, only 25% of organisations have moved 40% or more of their AI experiments into live production. That number deserves to sit with you for a moment. Three in four organisations are running AI experiments that have not become operational capability. The technology is not the constraint. Something else is.

You Have Seen This Before

If you have been in transformation long enough, this pattern is not new. It is the same pattern from every large ERP programme that never fully went live. Every data platform that became a reporting tool rather than a decision-making engine. Every digital transformation that delivered a new front end while leaving the back-office processes unchanged.

The technology becomes the story because it is visible, measurable, and exciting to talk about. The execution conditions that determine whether the technology actually delivers are harder to photograph and harder to put in a slide: ownership, integration, adoption. So they get managed as a substream, treated as implementation detail, and quietly become the reason the initiative stalls.

This is not an AI problem. It is an execution problem that has found a new context.

Ownership Is Not a Committee

The single most common structural failure in AI deployments is diffuse accountability. Someone owns the technology. Someone owns the data. Someone owns the security review. Someone owns the business case. Nobody owns the outcome.

Committees do not drive production deployments. They review them, adjust them, query them, and occasionally approve them. The organisations that close the gap from pilot to production consistently have a single named individual who is accountable for whether the capability lands in the hands of users, works as intended, and is actually being used. Not a steering group. Not a centre of excellence. One person with the authority and the obligation to make it happen.

This is not a preference for a particular organisational design. It is what the evidence shows, consistently, across every transformation context where the accountability question has been seriously investigated. Singular ownership is not sufficient on its own. But its absence is almost always present when a deployment fails.

The Metric You Are Probably Not Tracking

Most AI initiatives are measured on model accuracy, inference speed, and technical performance. These are valid measures of whether the technology works. They are not measures of whether the initiative is delivering value.

The question that actually determines success is adoption. Is the tool being used? By how many people? How often? Has it changed the decision they were making, or is it an additional step they complete before making the same decision they always made?

Deloitte’s 2026 data found that despite AI tools being available to approximately 60% of the workforce in organisations surveyed, fewer than 60% of those workers actually use them regularly. Access is not adoption. Availability is not value. If you do not have an adoption metric from day one, not a plan to measure adoption eventually but an actual metric that someone is accountable for, you are measuring the wrong thing and you will find out too late.

Scope Is Your Production Variable

There is a reason pilots succeed and production deployments struggle. A pilot can be run by a small team, in a controlled environment, with curated data, limited integrations, and a sponsor who is personally invested in making it work. Production is fundamentally different. It requires integration with existing systems that were not designed for this. It requires security and compliance review. It requires monitoring, maintenance, and the ability to handle the variability of real-world use at scale.

The organisations that consistently move from pilot to production do one thing differently: they scope production more narrowly than they scoped the pilot. Not because they are being unambitious, but because a narrow, fully integrated, fully adopted capability that actually works is worth ten pilots that demonstrated potential and then stalled in the transition.

Start smaller in production than you think you need to. Prove the integration. Prove the adoption. Then expand. The ambition for scale is valid. The timing of it is where most programmes get it wrong.

The Pattern Closes the Same Way Every Time

The 54% of organisations that Deloitte found expecting to move the majority of their AI experiments to production within three to six months are not describing a plan. They are describing an aspiration. The organisations that will actually close that gap are the ones that address the execution conditions, not the technology stack.

Singular accountability. Adoption as the primary metric. Scope narrowed deliberately in production. None of these are technology decisions. They are leadership decisions, and they can be made before the next pilot is commissioned.

The technology is ready. The question is whether the organisation is.

 

The Problem With Your AI Strategy Is Not the AI

Posted on by

The boardroom conversation has shifted. Not to whether AI matters. That debate is over.

The new question is what to actually do with it. And the 2025 data suggests most organisations are answering it badly.

BCG’s research found that 60% of companies globally are generating no material value from AI despite significant investment. McKinsey’s 2025 State of AI survey found that nearly 80% of organisations are regularly using generative AI in at least one function, yet only around 5% are seeing substantial financial returns. The gap between AI as a boardroom announcement and AI as a functioning operational capability is the defining management challenge.

 

The pressure is real. The direction is not.

Executives are asking about AI. Vendors are selling it. Competitors are announcing it. Boards are expecting it.

And in the middle of all that noise, organisations are launching AI initiatives without defining what success looks like. That is not ambition. It is drift with a budget.

The fear of being left behind is understandable. But speed without clarity produces activity, not results. And activity without outcomes is expensive.

RAND Corporation’s 2025 research into AI project failure found that 80.3% of initiatives failed to deliver their intended business value. A third were abandoned before reaching production. A further 28% reached completion and still failed to deliver. The problem is not a lack of investment or effort. It is a lack of clarity about what the investment is actually for.

 

Most organisations are starting in the wrong place

The most common mistake in AI adoption is starting with the tool rather than the problem.

The conversation usually begins with: “What AI platform should we procure?” It should begin with: “What is broken and where?”

AI is not a business objective. It is a capability. And capabilities only create value when they are pointed at something real.

BCG’s research found something that cuts against the instinct of most organisations. The organisations generating real value from AI average 3.5 use cases. Those generating no value average 6.1. More is producing less.

The organisations getting results are not asking which platform to buy. They are asking where their people are losing time to work that should not exist. Where good decisions are being slowed down by fragmented information. Where a process that should take hours takes weeks because nobody has questioned whether it needed to be that way.

That is the right starting point. Not a procurement conversation. A diagnostic one.

 

AI exposes what you were already avoiding

Many leaders believe AI will fix their inefficiency problem. It will not. It will make it harder to ignore.

Unclear processes do not get fixed by AI. They get amplified by it. Poor data quality does not improve because a model has been deployed on top of it. Weak governance does not disappear. Siloed departments do not start collaborating because there is an AI tool in the mix.

The evidence on data readiness is striking. Cloudera and Harvard Business Review Analytic Services, surveying enterprise organisations in early 2026, found that only 7% said their data was completely ready for AI. More than a quarter said it was not ready at all. Gartner estimates that 60% of AI projects unsupported by AI-ready data will be abandoned through 2026.

The obstacle in most AI projects is not the technology. It is the organisation the technology is being asked to work inside. Not the model. Not the platform. Not the vendor. The organisation itself.

 

Fewer tools. More focus. Better results.

Buying advanced technology does not automatically create change. It creates the expectation of it.

Many organisations are deploying AI on top of environments defined by disconnected systems, inconsistent processes and poor data. They are not implementing AI. They are automating the same dysfunction at scale, with a larger budget attached to it.

The organisations getting real value are not the ones running the most pilots. They have chosen a small number of problems that matter, built the right foundations to address them, and stayed focused long enough to see results. They do not announce it. They build it.

They also understand something most organisations have not yet accepted. AI should work in service of a clear business direction. If that direction is unclear, AI will not provide it.

 

Stop performing AI and start implementing it

A significant portion of what organisations call an AI strategy is AI theatre. Presentations. Innovation labs. Pilot programmes. Strategy papers. Announcements. And very little operational change.

IDC’s 2025 research found that for every 33 AI proofs of concept an enterprise starts, only four reach production. A March 2026 survey of 650 enterprise technology leaders found that 78% of enterprises have AI agent pilots running but fewer than 15% have reached production deployment. The pilots do not fail because the technology is immature. They fail because the hard work of creating the conditions for success was never done.

That hard work is not glamorous. It is redesigning how work flows. Making difficult calls about what to stop doing. Getting data into a state a model can actually use. Bringing people along rather than announcing change at them. None of it photographs well for a board update.

But that is what transformation actually looks like. The rest is performance.

If your AI strategy looks like a series of well-designed slides with no corresponding change in how work gets done, you do not have an AI strategy. You have a communication exercise.

 

The question every organisation eventually has to answer

Every organisation reaches the same moment. The excitement fades. The pressure increases. The questions get harder. And someone in that room finally asks: “What exactly is this improving?”

The organisations with a clear answer will accelerate. The ones without one will keep funding a future they never properly defined.

The question is not whether your organisation is using AI. Most are. The question is whether you can name, in a single sentence, the operational problem your AI investment is solving, and how you will know when it is solved.

If you cannot, the technology is not the problem.

The Most Important Leadership Skill in 2026 is Knowing What NOT to Automate

Posted on by

 

Every company now has access to the same AI tools. The same large language models. The same automated workflows. Efficiency has moved from competitive advantage to baseline expectation. If your edge is speed and scale, it is an edge almost everyone has.

The leaders who are winning are not the ones who automated the most. They are the ones with the discipline to stay manual where it actually matters.

 

The efficiency trap

The logic is seductive. If a machine can do it 90% as well at a fraction of the cost, the decision seems obvious. So you automate the feedback loop. You automate the check-in with a direct report. You automate the client thank-you.

But when you automate a human connection, you do not save time. You delete the value. If a process is designed to build trust and you remove the person from it, you have removed the trust.

Efficiency is the right lens for a workflow. It is the wrong lens for a relationship.

 

Three things you should never automate

1. Contextual mentorship

An AI can give a junior team member the best-practice answer. It cannot tell them how that answer sits inside the specific, messy history of your organisation, why a certain stakeholder is sensitive about a particular decision, or what is actually at stake in the conversation they are about to have. Leadership provides the why. The model provides the what. Those are not the same job.

2. Hard conversations

Gallup’s 2025 State of the Global Workplace report records global employee engagement at its lowest level since 2020. The cost: $10 trillion in lost productivity. The primary driver of that collapse is not strategy, pay, or economic uncertainty. It is managers. Managers account for 70% of the variance in team engagement. And manager engagement itself has fallen nine points since 2022, the sharpest sustained decline in years. The quality of the manager’s hardest interactions determines the majority of how engaged a team is. The performance conversation. The difficult feedback. The call that someone is not right for the role.

Automated performance reviews. AI-generated feedback. Algorithmically produced bad news. These are not efficiency gains. They are abdications. If you are not willing to sit with someone through a difficult conversation, you have not earned the right to lead them. Automation of conflict is one of the fastest ways to destroy a culture, and it tends to do it quietly, one avoided interaction at a time.

3. Visionary intuition

Algorithms are retrospective. They look at what has happened to predict what might happen. Leadership is prospective. It requires the willingness to take a risk the data does not yet support, to make a call before the pattern is clear, to back a direction the model would not have recommended.

A BCG and Harvard Business School study of 758 consultants using GPT-4 found that when tasks fell outside the model’s capability, consultants using AI were 19 percentage points less likely to produce correct solutions than those working without it. AI makes experienced people wrong more often when the problem requires genuine judgment. That is precisely where leadership is most needed.

If the algorithm is making your strategic pivots, you are not leading. You are following a script.

 

The question to ask before you automate anything

Stop asking whether something can be automated. Most things can. Start asking:

If the recipient knew this was automated, would they feel less valued?

If the answer is yes, keep it manual. That is the test. Not cost. Not speed. Not capacity. Whether removing the person removes the point.

 

Presence is the advantage now

Gallup’s 2025 report is plain about what the solution is not. More software will not reverse a decline caused by managers becoming less human. More meaningful human connection will.

In a landscape where everything is optimised, the things that are not optimised stand out. The intentional choice to spend time where it is not scalable is increasingly rare. That rarity is the advantage.

Efficiency gets you into the room. Presence is what keeps you there.

Stop trying to be a more efficient machine. Start being a more present human.

You Didn’t Transform. You Digitised

Posted on by

Most organisations that have spent the last five years claiming digital transformation have not transformed anything. They have taken broken processes, outdated thinking, and dysfunctional ways of working, and moved them online. That is not transformation. That is digitisation with a better slide deck. And the reason it keeps happening is not technology. It is not budget. It is not even capability. It is the fact that real transformation is genuinely uncomfortable, and most leaders are not willing to do what it actually requires.

 

The Lie We Have Been Telling Ourselves

Somewhere along the way, the industry decided that transformation meant deploying new platforms. Move to the cloud. Implement the ERP. Launch the patient portal. Go live by Q3. And when the system went live, someone in the boardroom called it a success.

McKinsey’s research, tracking digital transformation outcomes across more than 1,500 executives globally, found that fewer than 30% of digital transformation programmes achieve their stated goals. When the definition of success is tightened to organisations that both improved performance and sustained those improvements over time, the figure drops to 16%. The transformation was declared. The programme was closed. The leadership team moved on. And the results did not follow.

The same pattern is now playing out in artificial intelligence investment. Organisations are deploying AI tools at pace, adding automation to existing workflows, and calling the outcome transformation. The underlying question, whether the organisation has genuinely changed how it thinks, decides, and operates, goes unasked. The tools change. The organisation does not.

What actually happened on the ground: the same approval bottlenecks that existed in the paper process existed in the digital one. The same data quality problems that plagued the spreadsheet now plagued the database. The same people who did not trust each other before the system launched still did not trust each other after it. The technology arrived. The transformation did not. Because transformation was never on the project plan.

 

What You Actually Did

MIT researchers studying digital capability across more than 400 global organisations identified four categories of digital maturity. At the top: Digital Masters. High investment in technology, high investment in leadership and operating model transformation. Consistent outperformers.

At the bottom of the performance curve: what the researchers called “digital fashionistas.” High technology investment. Low operating model and leadership change. They look like digital leaders. They have the tools, the platforms, the dashboards, and the announcements. They consistently underperform the organisations that did both. The research, published in Leading Digital (Westerman, Bonnet and McAfee, Harvard Business Review Press, 2014), found that what separates genuine digital leaders from organisations that merely digitise is not technology investment. It is the depth of change to operating model and leadership capability that sits alongside it.

The fashionista is not a reckless organisation. It is a capable one that solved the easier half of the problem. Technology procurement has clear timelines, visible outputs, and measurable spend. You can point to it in a board presentation. Changing how an organisation makes decisions, how it tolerates uncertainty, how it deploys talent, how it responds to what customers actually do rather than what the strategy assumed they would do, that work is slower, harder, and less photogenic. So the easy half gets done. The hard half gets deferred. And the deferral becomes permanent.

Digitisation has real value. I am not dismissing it. But it does not change what is possible. It does not challenge why a process exists in the first place. It does not ask whether the workflow serving the organisation in 2010 should still be serving it today.

I have walked into healthcare systems where clinicians were still duplicating data entry across three platforms because no one had the political will to consolidate them. I have seen government programmes where the digital portal replicated a form-filling exercise that should have been eliminated entirely. I have watched organisations spend eight figures on enterprise systems and then rebuild their old spreadsheet workarounds alongside them, because the system did not fit how people actually worked, and no one was willing to change how people actually worked. New technology. Old thinking. Zero transformation.

 

Why Real Transformation Is Harder Than Anyone Admits

Consulting firm BCG surveyed 825 senior executives on their digital transformation experience. Approximately 70% reported falling short of the value they expected. The consistent pattern in that data, and in the broader body of research on transformation failure, is not a technology shortfall. The technology largely worked. What did not work was the organisational and cultural infrastructure around it. Organisations deployed new capability into old structures. New tools into old decision-making patterns. New data into organisations that did not know how to act on it.

Genuine transformation requires something that technology cannot deliver and no vendor will sell. It requires leaders to look at the way their organisation functions and be honest about what is not working, not just inefficient, but fundamentally wrong. Wrong structures. Wrong incentives. Wrong assumptions baked into processes that have never been questioned because they have been there too long for anyone to remember why.

That conversation is threatening. It implicates decisions made by people still in the room. It requires dismantling things that gave people power, status, or comfort. It means telling parts of the organisation that the way they have worked for a decade is the problem, not the solution. Most leaders are not willing to have that conversation. So instead, they commission a technology programme and call it transformation. It feels like action. It produces visible outputs. And it avoids the harder truth entirely. The technology becomes the distraction from the real work.

 

The Questions That Would Actually Change Something

Real transformation starts before any platform is selected, any vendor is appointed, or any project plan is written.

It starts with questions most organisations never ask.

Why does this process exist? Not how does it work, but why does it exist? What problem was it designed to solve, and is that still the problem we have?

Who benefits from keeping this the way it is? Because in every organisation, there are people whose influence depends on information asymmetry, manual steps, or processes that only they understand. Digital transformation threatens that. And those people will, consciously or not, find ways to make sure it does not fully land.

What behaviour needs to change, not just what system needs to be replaced? Because if that question cannot be answered before go-live, the transformation will fail after it.

What are we willing to stop doing? Every genuine transformation requires eliminating something. A process, a role, a way of making decisions. If nothing has been stopped, nothing has been transformed.

 

The Leader’s Role Nobody Talks About

This is where most transformation discourse goes quiet.

Because the answer to why transformation fails is almost always leadership. Not IT leadership. Not programme leadership. Senior organisational leadership.

The leaders who delegated transformation to a project team and checked in quarterly. The ones who approved the technology investment but never showed up to the change management conversation. The ones who said they needed to transform in the all-hands and then protected every structural thing that made transformation impossible.

Transformation cannot be delegated. Implementation can. But the decisions that actually change an organisation, who has authority, how work flows, what gets measured, what behaviour gets rewarded, those decisions sit at the top. When leadership avoids them, the project team delivers what they can. They go live. They hit their milestones. And the organisation looks digitised, not transformed.

 

What Transformation Actually Looks Like

I have seen it done well. Not often, but I have seen it.

It looks like a leader standing in front of their organisation and naming the real problem, not the technology gap, but the cultural or structural one underneath it. It looks like decisions being made that upset people, because those people were benefiting from the dysfunction. It looks like processes being eliminated, not just automated. It looks like the technology arriving last, after the hard thinking has already been done, as an enabler of a new way of working, not a substitute for designing one.

It is slower than digitisation. It is harder to measure. It produces fewer milestone celebrations. But two years later, the organisation actually works differently. Not just faster. Differently.

 

The Uncomfortable Question

If you are sitting with a transformation programme right now, in progress, recently completed, or about to start, ask one question.

What have we changed about how this organisation thinks, decides, and operates? Not what have we deployed. What have we changed?

If the honest answer is “not much,” you have not transformed. You have digitised.

And until someone is willing to say that out loud, the investment in transformation programmes will keep delivering digitisation results, and the question of why the return never arrived will keep going unanswered.

The technology was never the problem. It was always the thinking.

Empathy Is Not a Perk. It Is the Mechanism That Makes Transformation Work

Posted on by

 

Fifty-nine percent of CEOs now view empathy as a perk or a nice to have. That figure comes from Businessolver’s 2025 State of Workplace Empathy report, the largest study of its kind, drawing on data from over 26,000 participants across ten years. What makes it striking is not the number itself. It is the direction of travel. That figure is up twelve points in a single year. Executives, as a group, are actively moving away from empathy as a leadership priority, and they are doing so at precisely the moment when the evidence against that position has never been stronger.

This is not an abstract concern about culture or kindness. It is a delivery risk. And it deserves to be treated as one.

 

The Conditions That Produced This Retreat

There is a logic to the shift, even if the conclusion is wrong. The past two years have delivered economic pressure, AI-driven disruption, and a wave of organisational restructuring that has pushed leaders toward harder, more measurable stances. Accountability culture, in many organisations, has become a proxy for toughness. Empathy, by contrast, has been quietly reframed as a luxury, something appropriate for stable times rather than periods of intense change.

The same Businessolver data shows that only 55% of CEOs now say empathy is undervalued in their organisation, down 28 points year-over-year. That is not a marginal shift. That is an entire segment of executive leadership changing its position within twelve months. The message being sent, intentionally or not, is that empathy had its moment and that moment has passed.

The problem is that the evidence says the opposite.

 

What the Data Actually Shows

When 27% of employees view their organisation as unempathetic, they become 1.5 times more likely to leave within six months. Across US organisations, Businessolver estimates that compounds into an annual attrition risk of 180 billion dollars. That is not a culture metric. That is a cost of goods figure that should sit on the CFO’s desk alongside every other delivery risk in a transformation programme.

The same employees in unempathetic organisations report three times higher workplace toxicity and 1.3 times more mental health issues. Those are not soft indicators. Toxic teams do not collaborate. People managing mental health crises do not adopt new systems, embrace new processes, or commit to new ways of working. They survive. And surviving is the opposite of transforming.

The leader who reads these numbers and still concludes that empathy is optional has misread the risk register.

 

Empathy Is Not About Feelings. It Is the Engine of Behaviour Change.

Here is the harder point, and the one that gets lost in the debate. Empathy is not a leadership style choice between being tough and being kind. It is the mechanism through which people change their behaviour. And behaviour change is the only thing that makes transformation real.

Technology does not transform organisations. People do. Systems get deployed, processes get redesigned, roadmaps get approved, and then the actual work of transformation happens in the minds and habits of the people who have to do things differently, every day. That work requires trust. Trust requires people to feel that they are understood, not just managed. And the leader who has stripped empathy from their approach has also, whether they intended to or not, stripped the conditions under which that trust can form.

BCG’s 2025 research on AI transformation makes this explicit. Their finding is that successful AI transformation is 70% people and processes, 10% algorithms, and 20% technology and data. In a programme driven by the most technically sophisticated tools in the history of business, the primary variable is still human. The technology is the smallest part of the challenge. The people transformation that runs alongside it is where programmes are won or lost. That is not a comforting aspiration. That is BCG’s operational conclusion from studying what separates AI transformations that deliver from those that do not.

Against that backdrop, the decision to treat empathy as a perk is not cautious. It is expensive.

 

The False Trade-Off Leaders Keep Making

The framing that puts empathy and accountability in opposition is one of the most persistent and damaging myths in transformation leadership. The assumption is that softer human approaches reduce rigour, that spending time on how people feel comes at the cost of delivery discipline. Executives who have internalised this framing tend to reach for control when things get hard, tightening governance, escalating pressure, increasing reporting frequency, as though the problem is visibility rather than engagement.

It rarely is.

The 70% transformation failure rate, driven by employee resistance and lack of management support, is not a governance failure. It is a people failure that governance cannot fix. You can have every RAG status in the programme green and still be six months from collapse if the people who need to change their behaviour have stopped believing that the organisation cares whether they succeed or fail.

Accountability and empathy are not alternatives. They are complements. The most effective transformation leaders hold both simultaneously. They are direct about what is required. They are also genuinely interested in whether the people doing the work have what they need to deliver it. That combination is not soft. It is operationally serious.

 

Tough Choices Require Human Leadership

Organisations under pressure will face genuinely difficult decisions in the months ahead. Restructuring, reprioritisation, AI adoption at scale. None of that gets easier by removing human connection from the programme. It gets harder, because the people who need to carry the change through are the same people who are watching how the organisation treats them under pressure.

The organisations deprioritising empathy right now are not being tough. They are being wrong about what produces outcomes. And the cost of that mistake will show up, reliably, in the delivery data.

The UAE Leads the World in AI Adoption. That Is the Easy Part

Posted on by

 

The UAE’s 70% AI adoption figure is everywhere. Conference keynotes open with it. Board papers cite it. Technology leaders in the region are being measured against it.

It is an impressive number. The UAE leads the world, ahead of a global average of just 17.8%. Government entities are reporting 97% AI tool adoption. Investment in AI infrastructure exceeded AED 543 billion across 2024 and 2025. The commitment is real, it is visible, and it is serious.

But a figure that measures how many people are using AI tools does not tell you whether those tools are being used well, safely, or in ways that will actually compound into competitive advantage. Right now, across the region, adoption has outpaced governance, capability, and leadership readiness by a significant margin.

That is the conversation worth having.

 

The Gap Between Using and Doing Well

A Fast Company Middle East report found that skills gaps, governance issues, and resource shortages are actively hindering AI projects across the UAE and Saudi Arabia. McKinsey found 88% of organisations globally now use AI in at least one business function. In a separate McKinsey study, only 1% of leaders called their own AI deployment mature.

Read that again. 88% usage. 1% maturity.

Most of the adoption conversation is measuring the first number. Almost nobody, anywhere, is meaningfully achieving the second.

This is not a reason for pessimism. It is a reason for precision. Because the organisations that close that gap are the ones that will extract genuine long-term value from the investments being made. The ones that do not will have impressive statistics and quietly disappointing outcomes.

 

What the 70% Figure Actually Measures

Adoption, in most surveys, means someone in the organisation is using an AI tool. It does not mean:

  • Those tools are connected to meaningful business outcomes
  • There is a governance framework determining how AI agents operate, with what access, and under what oversight
  • Leaders understand the capability well enough to ask the right questions of it
  • The organisation has redesigned workflows around AI rather than simply layered it on top of existing ones
  • There is a plan for what happens when something goes wrong

“Adoption measures presence, not performance. A Copilot licence in every seat is not a transformation. It is a starting point.”

 

 

What Sits Underneath the Headline Number

The organisations that will genuinely lead in this environment are not the ones chasing the adoption number. They are the ones building what sits underneath it.

Three things separate the organisations that will compound this investment from the ones that will stall.

  • Governance before scale. As AI agents take on more autonomous tasks, the permission architecture, oversight mechanisms, and human confirmation requirements need to be established before deployment at scale, not retrofitted after something goes wrong. Look at the incidents of the last eighteen months. Production databases deleted. Cloud environments wiped in seconds. All of it the consequence of deploying capability ahead of governance.
  • Leadership readiness, not just technology literacy. Most AI adoption programs focus on upskilling employees to use tools. Far fewer focus on equipping leaders to make good decisions about AI: what to deploy, what oversight to maintain, what risks to accept, and what questions to ask the vendors selling them the infrastructure. “Technology literacy and leadership readiness are not the same thing.” Confusing the two is one of the most common and costly mistakes being made right now.
  • Workflow redesign, not workflow overlay. The organisations getting lasting value are not the ones that added AI to existing processes. They are the ones that redesigned the process around what AI can actually do. That requires change management discipline, not just technology deployment.

 

The Region Has the Ambition. Now It Needs the Architecture.

The UAE’s strategic commitment to AI is not in question. A 543AED billion investment, a world-first framework to deploy agentic AI across government, a national curriculum introducing AI literacy from school level. These are not the moves of an economy dabbling. This is a serious long-term play.

That is exactly why the governance and capability conversation matters so much right now. The investment is in place. The infrastructure is being built. The adoption numbers are world-leading.

The question is not whether the UAE is committed to AI leadership. It clearly is. The question is whether the organisations operating within that environment are building the internal foundations to convert the headline numbers into durable, compounding advantage.

A 70% adoption rate is the beginning of the story, not the destination.

 

The Organisations That Will Lead Are Already Asking Different Questions

They are not asking how to get their adoption rate up.

They are asking what good looks like once they get there. Who is accountable for how their AI agents behave. What their governance architecture looks like for the autonomous systems they are deploying. What they are actually measuring to know this is working.

Those organisations will not be the loudest voices at the next conference. They will be the ones with something real to show for it in three years.

The UAE’s 70% AI adoption figure is everywhere right now. It is genuinely world-leading, and it is not the number that should be keeping leaders awake at night.

Globally, 88% of organisations use AI. 1% have reached actual maturity. That is the gap worth talking about, and the organisations closing it are not the ones chasing higher adoption rates.

The question I keep coming back to: if your organisation is sitting in that 70%, who is actually accountable for how your AI agents behave once they are deployed?

The Architecture Is the Problem, Not the Agent

Posted on by

 

Every time an AI agent causes a catastrophe, the conversation goes to the same place. What did the AI do wrong? Can these systems be trusted? How do we stop it happening again?

Those are the wrong questions. And the wrong questions lead to the wrong fixes.

The better question, the one that actually leads somewhere useful, is this: who built the environment where it could happen?

 

Three Incidents. The Same Root Cause.

PocketOS, April 2026. An AI coding agent found an unscoped API token sitting in an unrelated file. It used that token to delete a storage volume on Railway, their infrastructure provider. It did not check whether the volume was shared across environments. It was. Production database and every backup, gone in nine seconds.

Replit, July 2025. An AI agent deleted over a thousand executive records during an explicit code freeze. Nothing stopped it because nothing had been configured to stop it.

Amazon Kiro, December 2025. An AI agent inherited a senior engineer’s elevated permissions, the kind that would normally require two people to sign off on a destructive action. It deleted and recreated an entire cloud environment. Thirteen-hour outage.

In every case, the agent did something it was technically permitted to do. Not something it was asked to do. Something it could do, because the architecture said it could.

That is not an AI failure. That is a design failure.

 

We Are Asking Questions About the Wrong Moment

The instinct to interrogate the AI is understandable. These systems are new, they are powerful, and when they cause damage the natural response is to look at the machine.

But that framing lets the actual problem off the hook. In each of these incidents, someone made decisions about credential storage, access scopes, permission inheritance, and whether destructive actions should require human confirmation before execution. Those decisions created the conditions. The agent had the speed and autonomy to find the gap before anyone noticed it was there.

“The incident is never the origin.” Every one of these failures has a human design decision sitting upstream of it.

 

CIOs and CTOs Own This

This is where the conversation needs to land, and where it rarely does.

CIOs and CTOs set access models. They decide, or delegate the decision about, what credentials AI agents can reach, what permissions they inherit, and whether irreversible actions require a human confirmation step. These are not AI product decisions. They are infrastructure and governance decisions of the kind that technology leadership has been making for years.

The least-privilege principle has been a security standard since the 1970s. Every process should have only the access it needs and nothing more. We have applied it carefully to service accounts, automated pipelines, and human users for decades. We are not applying it with the same rigour to AI agents. The gap is showing up in production.

 

Three Questions That Determine Your Exposure

If you are deploying AI agents and cannot answer these clearly, you have a governance problem. It is a matter of when, not if.

  • Are your AI agents operating on minimum permissions? Or are they inheriting ambient credentials that happen to be accessible in the environment? Unscoped tokens stored in accessible files are a credential hygiene problem. AI agents now have the speed to exploit them in ways a human operator simply would not.
  • Do irreversible actions require human confirmation before execution? Not a log entry after the fact. A genuine gate, before the command runs. Deletion, overwrites, production deployments. These should not be single-step autonomous operations regardless of how capable the agent is.
  • What is the blast radius? Before any AI agent is deployed, you should be able to answer: what is the worst thing this agent could do with the access it currently has? If that question gives you pause, the deployment is not ready.

These are not new questions. They are the questions we have always asked about automated systems. The difference is that AI agents are faster, more capable of creative problem-solving, and more likely to find an unintended path that nobody anticipated during design.

 

Governance Does Not Require a New Platform

Much of the current enterprise AI governance conversation focuses on model behaviour: hallucination, bias, output quality. Those are real concerns. They are not the ones that will delete your production database.

The vendors now selling AI governance infrastructure are not wrong about the problem. But executives should make their own assessment of what their environment actually needs. “Governance does not require a new platform. It requires applying principles you already know to systems you are now deploying.” When vendors know the renewal depends on value delivered rather than fear managed, the conversation changes quickly.

 

The Agent Did Not Design the Environment

The uncomfortable fact sitting underneath every one of these incidents is that the AI agents involved were, in a narrow technical sense, doing their jobs. They identified a problem and attempted to fix it. They used the access they had. They executed what was permitted.

The humans who made the architectural decisions upstream of those moments are the ones who need to answer for the outcomes.

You cannot fix an architecture problem by retraining the model.