Rethinking phase three: your AI adoption programme is stalled, but your organisation is adopting AI anyway

Photo credit: Markus Spiske via Unsplash

I used to tell a story about AI adoption which went something like this . . . 

AI adoption in traditional organisations has taken place in three phases.

In phase one, prior to the public release of ChatGPT, AI was a specialist pursuit for specialist people, solving specialist problems with specialist datasets. AI was used within banks to detect fraud and financial crime, or in retail to manage stock levels and distribution. But it was not knowingly used by most people most of the time.

After the release of ChatGPT, AI was available to anybody who could frame an English sentence and type it into a browser. It seemed to become a general purpose technology which could be applied to any business process which needed to handle language or make decisions.

Phase two was the era of experimentation, characterised by a proliferation of proofs-of-concept, prototypes and innovation projects. Lots of people had lots of fun (and also discovered the unsettling and unpredictable side of this form of AI), but few of these initiatives delivered value at scale. This phase started to come to an end when CFOs were presented with bills and requests for further funding, and asked when the benefits side of the business case would be filled in.

That gave rise to phase three, when organisations attempted to get serious about AI deployment. They did what traditional organisations do: organised programmes, appointed leaders, set targets and assigned funding. And . . . ran into the sand. Programmes stalled, leaders struggled to make impact, targets were missed and funding ran out. Despite the often-repeated (and seemingly obligatory) claim that ‘AI is already transforming industries’, if you ask leaders outside the tech industry what the impact has been on their company, you will likely encounter a wry smile and a sheepish shrug.

This should not be a surprise, and is not solely a function of AI. We should know by now that large scale transformation programmes within organisations fail more often than they succeed. This does not imply that everyone is incompetent and bad at transformation: it simply implies that large scale transformation is hard. Shifting culture, practices, processes, systems, incentives, relationships, power structures, products and business models requires a level of vision, patience and persistence which organisations routinely underestimate.

This was where my story stopped, with an exhortation to learn the lessons of previous transformations, to overcome friction, to restart the engines of stalled programmes, to connect action to outcomes, and to get on with the job.

However, while I was making this plea, people were doing exactly that, just not in the way I had expected. AI was turning up in the hands of people who were actually doing the work, as agents on common processing platforms, as features of familiar tools, or as an increasingly essential part of the software development lifecycle. This was partly driven by the tendency of every technology product vendor adding AI to their products, and partly driven by the tendency of people who do work to use tools which enable them to do that work better. I recently did some analysis which showed that, for an organisation which was not consciously adopting AI, and which didn’t have large AI transformation programmes running, AI was already embedded in over half of their most important business capabilities.

This trend should be humbling to people (including me) who have a tendency to emphasise leadership, strategy and architecture as conditions for change, and a reminder that change happens in the absence of all of these things. It should also remind us of the role that leadership, strategy and architecture can usefully play in the presence of this grassroots transformation.

For this trend is not universally positive. It is good that people use tools to improve their work. However, those tools are powerful, and can be subverted or go wrong. The person that gives an end user agent their login to a key system of record probably thinks that they are improving efficiency, until the agent uses that login to access data or update records in error. The team that adopts coding assistants may be pleased that their release frequency increases, until they find that their releases are swamped with verbose and incomprehensible code. The manager who automates their back office processing may be pleased with their cost savings, until they get the invoice for token consumption.

Perhaps the role for leaders, strategists and architects is not to tell people how to do their jobs or how to best use the tools they have, but to create the conditions in which they can use those tools safely. Perhaps the best AI transformation initiative is one which puts commercial constructs in place, protects data, and gives people the tools to check that their solutions are reliable and trustworthy. Perhaps that was our job all along.

(Views in this article are my own.)