- agents
- AI
- ambiguity
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- compliance
- corporate life
- data
- decisions
- delivery
- devops
- disagreement
- end user tools
- ethics
- failure
- fear
- fundamentals
- government
- halloween
- history
- humans
- hype
- identity
- inclusion
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- privacy
- process
- procurement
- products
- programming
- quantum
- reliability
- resilience
- risk
- science fiction
- security
- shadow IT
- space
- strategy
- talent
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Eight steps to enterprise AI leadership
True AI expertise is rare. AI leadership expertise, the ability to lead organisations which have embedded AI into their operating models, is even rarer. And enterprise AI leadership, the ability to lead the adoption and use of AI within established businesses, is so rare as to be virtually non-existent.
This rarity seems to persist, despite the number of press releases, articles and social media posts which claim that ‘AI is transforming industries’. My perception is that most leaders in most industries would admit that they find AI as baffling as it is exciting, as frightening as it is promising, and that they wish that it would slow down for long enough for them to catch up.
<x> is too important to delegate to your Chief <x> Officer
I started my career in the late 1980s, when the term ‘Chief Technology Officer’ was just starting to be used in companies. (It wasn’t used in the government department where I was working: that still referred to IT as ‘Automated Data Processing’. This was a place where we still had to write out our documentation by hand and send it to the typing pool to be processed,)
Since that time, I have seen the creation of many Chief <x> Officer job titles in the field of enterprise computing: alongside the Chief Information Officer and Chief Technology Officer, we have had the Chief Digital Officer, the Chief Information Security Officer, the Chief Architect and the Chief Data Officer. The latter has undergone mutation in recent years, showing up as the Chief Data and Analytics Officer (CDAO) or, now, the Chief Data and Artificial Intelligence Officer (CDAIO - a title which I can’t help singing to the tune of Old MacDonald Had a Farm - C-D-A-I-O).
The hand shapes the tool; the tool shapes the hand
Humans make tools: it is one of our defining characteristics. But our tools shape us, just as we shape our tools. If, like me, you don’t usually do a physically demanding job, try using a hammer for a few hours, and experience the blisters that it raises. Try using it for a few more days, and feel your calluses and other changes in your body.
Researchers now believe that our hands have been shaped by our history of tool use. Early human species (always remember that Homo sapiens is not the only, or the first, species of human) had weak wrists and clumsy digits compared to modern humans. The development of stone tools, and their impact on prospects of survival, meant that, from approximately 1.7 million years ago, the structure and strength of our hands evolved to get better at using tools. Our tools wrote themselves back into our DNA.
Look! I made a machine do a thing!
When I am doing hobbyist computer stuff, I often have moments which can be summarised as, Look! I made a machine do a thing! These moments bemuse family and friends, who are summoned to witness the thing that I have made the machine do, only to see a splurge of text at the command line, or an underwhelming web page. (But look at it - it works!)
The feeling of successfully making a machine do a thing is such an important phenomenon in computing that I think we should give it a name: perhaps LIMAMDAT, or LIMDAT for brevity and ease of pronunciation. The history of computing has been full of LIMDAT moments, from the first decrypts and trajectory calculations in the 1940s, through rocket launches and Moon landings, to the birth and development of the Internet.
Why have FO when there’s no MO?
If you are a business leader in 2026 trying to deal with AI, you are surrounded by fear on all sides. Analysts, investors, vendors and the media are all telling you that if you don't invest in AI, you should fear being left behind. At the same time, lawyers, risk professionals, privacy advocates and employee representatives are telling you you should fear AI harming your staff, your customers and your company's reputation.
Fear is rarely helpful in an enterprise setting. I once knew a large corporation which was desperate to move to cloud because they feared that their aging data centres could fail at any moment. But, after spending many millions to get their cloud environments ready, they wouldn't move their data because they feared security breaches. Fear drove double cost and double complexity.
Uncertainty: the final frontier
When our schedules and streaming services are full of Star Trek content (at the last count, thirteen series and fourteen films), it seems hard to remember that the series was once a lonely, experimental long shot: the first regular science fiction TV series with recurring characters and themes, squarely aimed at adults.
Prompted by watching the (excellent) series Strange New Worlds, I tracked down a print copy of the book The Making of Star Trek, published in 1968, between the second and third season of the original series, when it was on the brink of cancellation. If you can put aside some of the 1960s-era attitudes (despite the generally progressive tone of Star Trek, there are some paragraphs that wouldn’t make it into a 2026 edition), it’s a fascinating overview of television production at the time, and of the challenges of getting studios and networks to try something new (and expensive).
Can we see the future from here?
After the Second World War, it was clear that the telecommunications infrastructure of many countries needed an upgrade. The digital computer had been invented, and was emerging from the lab into the economy. In the USA, the giant early warning and control system, SAGE (Semi-Automated Ground Environment) was being built to cope with the threat of nuclear war, and needed systems and sensors to be connected across the country. The old copper cables of the telephone and telegraph systems were not up to the job.
Fortunately, experts, researchers and engineers had a solution: they would use light to transmit information rather than pushing electrons through copper. However, they did not start with the flexible, glass optical fibres that we are familiar with today: they believed that glass could not be manufactured with sufficient transparency to carry light over long distances and that, even if it could, the photons would escape at the bends.
Lessons from forty years of Excel: if you give people tools, expect them to be used
One of the anniversaries I missed last year was that of Microsoft Excel, which turned forty in August.
I think that anybody who has worked in enterprise technology over any part of those four decades will have mixed feelings about Excel. On one hand, they will be grateful for a flexible tool which almost everybody has access to, most people know how to use, and which can be used for modelling and forecasting without the need to run big projects or write complex programmes. On the other hand, they will remember the times when a major upgrade was delayed because of a set of fragile, convoluted macros, when a business critical operation depended on a spreadsheet which only one person understood, or when they were asked to ‘just’ take the logic embedded in a spreadsheet and make it into a system that worked for the whole company.
A few phrases to help resist AI illusions
‘It can’t hurt you: it’s not real!’
You might hear those words from the hero of a horror, science fiction or fantasy film. They could be walking through a dream world, subject to a hallucinogenic drug, or under the spell of a sorcerer. They know that the things that they are seeing are not real, and that all they have to do is to try to ignore what they think they can see and hear. Telling themselves that what they are experiencing is not real is a guard against fear, against stepping off the path, or, worst of all, the temptation to talk back to the illusions.
Dealing with current forms of AI can feel like this. Not just because AI is surrounded by hype, marketing, inflated expectations and a big dose of FOMO. And not just because AI can be used to produce fake videos, fake images and fake words.
A suggested New Year’s resolution: be more curious
When I was growing up, my Dad and my uncles were always working on cars and motorbikes. This was partly through need: they didn’t have much money and they had to travel for work, studies and family life, so fixing a car using spare parts, ingenuity and improvisation was an essential skill. They also enjoyed it: it was as much of a hobby as a necessity.
It was not a practice I ever acquired the skill or the appetite for. I was much more interested in reading books than getting my hands covered in grease and oil. I enjoyed spending time with my Dad and Uncles as they struggled to fit strange shaped pieces of metal into strange shaped spaces, and as they scoured scrap yards to find an old car with the right part. But I never really understood what they were doing.
This Christmas, give yourself the gift of knowing that your work isn’t boring
‘Sorry, this is the boring bit.’
When I hear those words, my heart sinks almost as much as it used to when I heard someone declare that they were not technical. In the field of enterprise technology, they normally mean that the speaker is about to attempt an explanation of technical detail to an audience which includes non-technical people.
Perhaps they are going to explain to a product manager why the system built for a hundred users can’t scale to a million without extra infrastructure. Or why it’s not a good idea to put a system which holds customer’s personal details into production without security testing. Or why, while it might be tempting to make the chat interface available to every user, someone has to pay for all those tokens.
Reflections on a vertical learning curve
Today is my last working day as CTO for the UK Government.
Three years ago, I had just learnt that I might be offered this job. I was completely uncertain about whether I should say yes or not. Fortunately, my wife, as ever, gave me good advice – to talk to some experts and mentors, who knew me and the kind of work I did, and to get their perspectives.
Those conversations yielded two insights. First (from people who were naturally analytical), when we plotted pros and cons, the pros sounded like reasons to do the job, and the cons sounded like work to be done – and therefore more reasons to do the job. Second (from people who thought in terms of purpose), I discovered a strong sense of public duty: for an example, an Australian friend told me that if his country asked him to do an equivalent job, he would accept with pride.