We commoditised intelligence. Not judgement.

Everyone has the box now

Let me start with the unfashionable truth, the one most people in this industry would rather not say out loud. Technology is the easiest part of all this, and it gets easier every single year.

The infrastructure that once demanded a room full of specialists and a thick deep-dive diagram now arrives as something close to an appliance. The large training and inference systems, the dense racks, even the small desktop-class machines that put real compute under a desk, all of it is turning into a product you buy rather than a feat you assemble. You can order the box. Soon you will barely think about what is inside it, in the same way you do not think about the turbines behind a wall socket.

For a long time the prestigious work was exactly that internal plumbing. Drawing how the chips talk to one another, wiring the network, designing the backup network and the failover paths. That work was hard, and being good at it set you apart. I am going to say something that will annoy some of my old peers: that work is becoming a cliché. It has been commoditised, and the need for it is shrinking. The interesting question is no longer how the processors speak to each other. It is what you make the whole machine do for a business, and whether a single human being can actually pick it up and use it.

Architecture, in other words, has evolved to a higher level, and I believe it had to. So if the machine is not the hard part, what is? It is the same thing it has always been, and it is the thread that runs through everything I have done.

Where it started

I have loved building things since 1986, the year I first sat in front of a Commodore 64. That feeling never went away. It is the reason I am still here.

I taught myself everything, built my own machines, took them apart and put them back together to understand why they worked. Then I spent a whole career turning technology into something real for the organisations I worked with. The love of building is the easy thing to talk about, because it is the part that looks like fun. But here is the quiet surprise of my working life: building is not the rarest thing I do, and it is not the thing people have most needed from me.

The rarest thing I do

The rarest thing I do is not building. It is getting large, careful organisations to actually adopt something new. I was doing it long before anyone said the word AI.

Back in 2013 I built one of the sector's first automation-native operations. I led a team of thirteen and took the most critical processes fully native, removing fourteen thousand hours of manual work a month. People feared it would replace them. It did not. It changed how they worked, and getting an organisation through that change is the hard part. It always has been. The result became a success story I was flown abroad several times to present, but the part I am proudest of was never the automation. It was the people who walked through the fear and came out the other side.

Because here is what fear does. Nobody stands up in a meeting and says "I am afraid this makes me unnecessary." Instead they rationalise. Fear loves a disguise. It arrives wearing reasonable, technical, even correct-sounding sentences, and that is the trap. If you argue with those sentences using numbers, you lose every time, because the thing you are really arguing with is not the sentence. It is the feeling underneath it.

None of these sentences is exactly a lie, and none of them is the real reason. The real reason is almost always the same: a human being afraid of losing a habit, an advantage, or a sense of safety. Miss that, and your best solution walks straight into a wall.

The most valuable lesson of my career is this. The technical part of a transformation is perhaps twenty percent. The other eighty percent is making people feel like the authors of a change rather than its victims. You cannot impose something on people, but you can make them part of it. That difference is the difference between a project that lives and one that quietly dies.

Adoption is never the goal

Here is the idea most technology people resist, and the one I would fight for: adoption is never the goal. Neither is the technology itself.

The goal is to change how the business operates so it reaches the outcomes it is actually after. The technology is only ever the means. When a board signs off a transformation, they are not buying processors or models, however the invoice reads. They are buying a different operating model, and through it a set of outcomes: a faster time to market, more revenue and a healthier gross profit, real efficiency, a lighter footprint, a safer posture.

Those outcomes are not the project. They are the by-products of changing how the business runs. This is the distinction that separates a transformation that pays for itself from an expensive pile of capability that changes nothing. Confuse the means with the end, and you will buy the most advanced tools in your industry and still operate exactly as you did before.

This is why my real place is between the technology and the people. Most people, the C-suite very much included, cannot yet see what to build with AI or how to make it real at scale. My work is to stand in that gap and get everyone moving in the same direction, from the most senior executive down to the engineer who has to live with the result.

Leadership and governance, not cleverness

Most of what derails an AI transformation has nothing to do with the technology. It derails on three things, people, direction and governance, and those are the same three things that have decided every transformation I have ever seen, long before anyone bolted the word AI onto the front of it.

I learned that in rooms where the stakes were high. As a chief architect on two of the largest Tier-1 private bank transformations at IBM, my job was never to be the cleverest person present. It was to run the governance, chair the board, hold the architecture to a single standard, and keep senior and junior people building the same thing in the same direction. The clever ideas were always the cheap part. The expensive part was alignment.

AI transformations then fail in their own particular ways, and the failures rhyme. The executives often cannot yet see what to build, so the work starts with translation rather than technology. Everyone wants the dazzling demo, and almost nobody plans the unglamorous path from demo to dependable production, which is exactly where most AI projects quietly die. And without a single standard, ten teams build ten incompatible things until the effort collapses under its own inconsistency. The way through is never a cleverer model. It is to lead from the outcomes, govern for one direction, and make the people the authors of the change rather than its subjects.

The cleverest person in the room rarely ships anything, because cleverness on its own does not move an organisation. What ships is a team that knows where it is going and trusts the route. A leader's real job is not to manage the technology. It is to manage the relationship a roomful of people has with change.

Winning a partner is easy. Keeping them is the work.

The work that actually carries AI into the world is rarely one company acting alone. It is an ecosystem: the OEM whose technology sits at the centre, the integrator who designs the end-to-end solution, the delivery partners who build it, and the customer who has to live with the result. An ecosystem does not pull together on its own. Someone has to keep it pointed in one direction.

I have spent years inside that kind of work, driving the joint solutioning and building the frameworks that let a partner adopt and productise AI without starting from a blank page each time, including sovereign-AI programmes. But the part worth writing down is not what I did. It is what the ecosystem taught me.

It is simple to say and hard to live. You make a partner's practice genuinely stronger, with the technology at the centre of it, and then they sell it because it works, not because you asked. Landing a partner is the easy part. Keeping what they ship reliable in production is the hard part, and it is the part that quietly decides whether they stay.

One bad deployment costs more trust than many good demos can ever earn.

You did not have to wait long for the reminder. This week, the AI features inside Notion, one of the most popular workspace tools in the world, started failing because the high-end Claude models behind them, from Anthropic, briefly degraded. Notion's team did the right thing in the moment. They pulled those models out of the picker and rerouted requests to alternatives, so users saw a quiet model switch instead of an outage, and within about half a day the models were back. The headline made it look like a provider had let a customer down. The real story was calmer and far more useful.

The product survived because someone had built it to survive, on a routing layer that did not lean on any single model staying perfect. I build my own platform on Claude, and I say this with no contradiction at all: even the model I rely on will have an off day, and the job is to design for that, not to pretend it away. In an AI transformation the durable thing is never the model. It is the architecture and the relationships you wrap around it, the part that decides what happens when, not if, something upstream wobbles.

That is what it means to mobilise an ecosystem. Not a louder sales motion, but making every partner in the chain a little stronger and a little safer, so reliability compounds instead of leaking away at the weakest link. The glamour is always in the demo. The value is in the boring, dependable production that comes after it, and almost nobody wants to own that part. That is the part I care about most.

It begins with the right use case

Every AI transformation lives or dies on one unglamorous decision that comes before a single thing gets built: choosing the right use cases. And you cannot choose them from the technology alone.

A use case has to hold up from two sides at once. From the business side: does it move a real outcome, is it worth doing, and does someone actually own the result. From the technology side: is it genuinely feasible, reliable and safe enough to put into production, not just to demo. Most failures pick a use case that dazzles on one axis and collapses on the other, a business dream the technology cannot deliver dependably, or a clever technical trick no business actually needs. The whole skill is sitting on both sides of that line at the same time, which is the seat I have spent a career learning to hold.

That is the lens I brought to my own build. Over the past year I built a full agentic platform on Claude, end to end. Not a demo, but a working system that takes a raw opportunity, or even a loose set of discussions, and turns it into a costed, architected proposal. In an integrator that matters more than it sounds, because the same solution, architecture and pricing get rebuilt from scratch on every single deal. I lost whole nights to it, not because I had to, but because it stopped feeling like work. I was pouring twenty years of hard-won judgement into it and turning that judgement into something other people can pick up and use, because the complexity should sit with me, not with them. It is the most alive I have felt in my career.

I did not build it to prove I can code. The rare part was never the code. The rare part is being able to sit on the customer and the partner side of the table, feel how they actually want to operate, and make that real. I can usually see what they need before they have the words for it. I would rather build the future than wait for it, and I would rather show than describe. Hand me a real problem and I will show you how I would solve it, not tell you about it over coffee.

Put it in a box

Which brings me back to where I began. If the capability is the easy part, then the real work is making it usable, and selling the outcome rather than the science project.

The thing that matters now is productising the AI offering. You take raw capability and you package it so a customer buys a result, not a research effort they have to babysit. Call it AI in a box if you like the phrase. The infrastructure underneath is already close to an appliance. The value has moved into the offering wrapped around it, and into the single question of whether anyone can actually pick it up and use it well.

Capability on its own stays a demo forever. Someone has to help the world put it into production, responsibly and reliably, and that is the part the box can never do for you. It is also, as it happens, the part I am good at.

In a world where everyone owns the same box, the box stops being the differentiator. What is left is the judgement you wrap around it, the question you choose to ask of it, and whether there is a real human standing behind the result. Intelligence got cheap. Judgement did not.

The circle closes

I write this on Silicon Tales, a small publication I run on the side, and that is not a coincidence either. It is the same belief, pointed at the page instead of a boardroom.

I built a technology publication and rooted it in the human story behind the silicon. It is my whole career distilled to a single line: the technology was never the point, the people always were. The chips and the numbers are the shell. Underneath is always someone's fear, someone's ambition, someone's stubbornness, a decision made at three in the morning that should not have worked and did. In an age of infinite, competent, soulless output, I deliberately put the human voice first.

And here is what pulls at me now, on the other side of twenty years spent on the hard, human part. Not building one more system myself, but helping a whole ecosystem of people build the way I learned to. Building one system taught me the limit of building one system. The point was never the next thing I make. It is many people making the right things, well, so the benefit actually reaches the world.

For most of my career I tried to teach this to others. Now I practise it every day on my own desk. In a way, the circle closes.

To anyone starting out

When people starting out ask me what to do, and it is usually them who ask, what I say is plain. It fits in three lines, but each one cost me a career to learn.

Let me open the first one up. Almost nothing I used in 1986 is the same today, and almost nothing I use today will survive another few years. Fall in love with a tool and you lose yourself when it ages. Fall in love with the question and you are reborn in every era. The second one is the easiest to get wrong. Learn the technical skill, by all means, but hold it as a foundation, not as an identity. Taste and judgement are not taught on a course. They are earned slowly, through attention, through reading and seeing far more than you make. The one thing the machine still cannot do is know when to stop. Keep that decision for yourself.

Why I am here

You asked, more or less, what my reason for all of this is. I am wary of big words, so let me keep it plain and honest.

I want to tell true things well. And in an age of machines, I want to remind people that the human behind the work is still the thing that matters most. My dream is not a unicorn. My dream is to show that one person, with the right eye and a little courage, can still make something worth reading and worth using. If I can do that, even just for myself, I think that is enough.

It was never the machine. It was always the person sitting across from it.

Twenty years ago, leading my first fight to get a careful organisation to trust something it was afraid of, I could not have put any of this into words. But I think I sensed it from the very start. I still do. And I suspect I always will.

Frequently asked

If technology is the easy part, what is the hard part?

Getting people and organisations to actually change how they work. Capability sits on the cloud, ready for anyone, and the infrastructure can be ordered as a box. The difficulty is human: the fear of being replaced, the comfort of an old way, the trust it takes to move a whole team in one direction. That part has not been commoditised, and it will not be for a long time.

What is the real goal of an AI transformation?

Not adoption, and not the technology itself. The goal is to change how the business operates so it reaches the outcomes it is after. Faster time to market, more revenue and gross profit, efficiency, sustainability and security are by-products of that operating-model change, not the project itself. The technology is only ever the means.

Will AI take our jobs?

Tools change and work shifts, which is not new. What matters is knowing what to hand over and what to keep. Give the machine the repetitive, templated work. What remains, judgement, taste, asking the right question and understanding people, stays scarce for a long time. The real question is not whether it replaces you, but what it frees you to do.

What should someone starting out invest in?

Not a single tool, since tools age in a few years. Invest in the ability to ask the right question, in taste, in judgement and in reading people. Those have not been commoditised. Learn the technical skill, but treat it as a foundation, not an identity.

How do you get a large organisation to actually adopt new technology?

You start with the fear, not the technology. Until you understand what people are afraid of losing, you cannot explain what they stand to gain. Then you connect the idea to their own language and their daily problems, and you make them the authors of the change rather than its victims. Most people do not love technology. They love having their problem solved.

What does it mean to put AI in a box?

It is shorthand for productising AI: taking raw capability and packaging it so a customer buys an outcome rather than a science project. The infrastructure is already close to an appliance. The value now sits in the offering wrapped around it, and in whether anyone can pick it up and use it well.