You cannot lead from the surface

Some of the people who have taught me the most about AI this year work for me. They did not wait for a programme or a strategy. They were experimenting with agents, connecting tools, building things and finding new ways of working simply because they were curious enough to keep going.

In a few cases they were far enough ahead that I had to make sure I caught up. I think that has been one of the more useful (and slightly uncomfortable) leadership experiences I have had in years.

I have always tried to stay close to technology, but the pace of this is different. The operating principles themselves keep changing. There are mornings when I listen to a podcast and feel as though a decade has passed overnight. And I have spent most of my career around software, data and machine learning. For leaders without that background, I can imagine the pace feels even more overwhelming.

It has made one thing clear to me.

You can delegate execution. You cannot delegate discovering what has become possible.

The gap in my own argument

I wrote recently that leadership exists to own what has no natural owner, above all the seams between teams, systems and decisions. I still believe that, but my own team exposed a gap in the argument.

You cannot own a seam you cannot see.

AI is moving those seams because the assumptions underneath our organisations are moving. A process that required five people may have been designed around the difficulty of moving information between systems. A handoff between two teams may exist because neither side previously had enough context to make the whole decision. A capability we would naturally have bought from a vendor may now be reasonable to build ourselves. An approval may exist because something used to be expensive or difficult to verify.

When those constraints change, the sensible shape of the organisation changes with them. The problem is that the organisation does not redraw itself automatically. Someone has to notice that the old boundary no longer makes sense.

A briefing is not the same as understanding

Leaders have always relied on abstraction. Good organisations depend on it. I do not need to understand every implementation detail of every system, and I depend on excellent people to go deep, make good decisions and bring back the things that matter.

But I have become much more conscious of the limits of that model with AI. A briefing can transfer information. It is much harder for it to transfer intuition.

Someone can tell you that agents are getting better at writing software. That is different from spending a few hours directing one yourself and realising that the boundary between specifying something and producing it has moved. Someone can tell you that research can be automated. That is different from building a system that sends the same question to several models, asks them to research independently, verifies what they find and produces something useful at the end.

The information may sound similar, but the mental model you leave with is not.

Leadership decisions are rarely made from individual facts. They are made from an accumulated understanding of what is possible, what is difficult, what is risky and what is changing. If that understanding is stale, good information alone does not necessarily rescue the decision.

I build things myself

This is one reason I have found myself building much more over the last year.

I say “coding”, although even that word is beginning to feel slightly inaccurate. I use tools like OpenCode, APIs, MCPs and agents to produce software. I spend much less time writing individual lines of code and much more time describing what I want, connecting components, reviewing what comes back and working out where the boundaries need to be.

The code itself is often the least interesting part. The learning is in understanding what can now be specified rather than manually produced, what can be delegated, where an agent needs more context, where it needs a boundary and where human judgement still matters.

Recently I wanted a better way to research questions where the answer is scattered across many sources and where I care about whether the result can actually be trusted. So I built a small research platform. You give it a question, Claude, Gemini and Grok research it in parallel, other steps challenge and verify what they find, and the system brings the work together into a five or six page brief.

The tool itself is useful. But the more valuable part was building it and then putting it in front of people. I sent the output to colleagues and asked simple questions: Is this useful? What is missing? What would make you trust it?

One colleague asked whether it could surface the competitor products consumers actually compare us against, rather than the ones we assume they do. Another wrote back: “When I used Gemini so far, folks struggle to trust the data. How is this tool different?” and then asked whether teams could eventually run these questions themselves instead of routing everything through insight specialists.

Trust and self service were not on my list when I built it. Both are now driving what goes onto my roadmap.

Every answer changed the system a little, and every iteration changed my own understanding of what could reasonably be built. I learnt more from that loop than I would have from another ten demonstrations.

It changes the decisions I make

Build versus buy.

For much of my career, the economics often favoured buying, and for commodity technology they still do. But I think differently now about capabilities that sit close to our proprietary data, our judgement and the things that make the company distinctive.

If a system captures important knowledge about our business, I want us to think very carefully before putting another layer between ourselves and that knowledge. The economics of building have changed at exactly the same time as the strategic value of owning your own context has increased.

AI makes that context more valuable because the more useful context you own, the more capable the systems built on top of it can become. Over time, the combination of proprietary data, accumulated judgement and the ability to act on both becomes part of the advantage.

That has moved my own build versus buy boundary.

A briefing could have told me that AI makes software development faster. Building things myself changed my sense of how much faster, where it matters, what still remains difficult and which capabilities I want us to own.

I also do not want to sit in a leadership position expecting productivity from others that I have never tried to achieve myself. The point is not the technology. The point is recalibration.

Curiosity cannot be performed

There is an easier version of all of this. Attend the demo. Visit the pilot. Ask a thoughtful question. Read the strategy deck.

All of that is fine. It is just not the same as going deep yourself.

Going deep also changes how you evaluate what you are sold. This year I have watched more than one polished enterprise AI product arrive with confident roadmaps and monthly promises, and realised within a short session that the capability underneath was still thin. Not because anyone briefed me, but because I had built enough myself to feel the difference between a capability and a slide about one.

People who are working with these systems day to day can usually tell fairly quickly when someone has gone deep. The questions are different, and not necessarily more technical. Usually they are more fundamental.

Why are we doing this step at all? Why does this boundary exist? Why are we buying this? Why can this not happen continuously? What assumption makes this impossible?

Those questions come more naturally once you have repeatedly watched assumptions you thought were fixed turn out not to be fixed at all.

That is why I think curiosity matters so much. Not curiosity as a leadership value written on a slide, but curiosity as behaviour. The willingness to go and find out for yourself.

Leaders do not need to become engineers

None of this means every leader needs to become a software engineer. That misses the point completely.

What matters is having enough contact with the change to form your own judgement about it.

Take something from your own work. A recurring analysis. A report. A decision you repeatedly make. A problem somebody tells you is difficult. Try to build something around it and see where the technology surprises you, where it disappoints you, what still requires judgement and which constraints you assumed were permanent but turn out not to be.

I will give you mine. For twenty years I assumed the nitty gritty of infrastructure work, migrations, rewiring deployments, the unglamorous plumbing, was irreducibly manual. This year I watched a fleet of agents run exactly that work across our own estate, end to end, with engineers holding the gates rather than the shovels.

A constraint I had treated as permanent for my entire career turned out not to be permanent at all. It was just an assumption nobody had been able to test until now.

Then do something slightly harder next time.

For me, that is what crossing the threshold looks like. And I think leaders have to keep crossing it.

The threshold keeps moving

I wrote first about the individuals who cross a threshold with AI, where it stops being an assistant and becomes a system of execution. Then I wrote about what happens organisationally when those people accelerate, and why leadership has to own the seams between the things they build.

I think this is the third part of the same problem.

The leader has to keep moving too. Not as quickly as the best engineer and not as deeply as the specialist, but deeply enough to understand when the operating principles have changed.

Because the threshold does not stay where it was. Being comfortable with chatbots was useful, then it was agents, and now it is systems of agents, tools and loops that can take on whole pieces of work. There will be another shift after that, and another after that.

I do not think the gap between leaders who keep crossing and leaders who mostly consume briefings will be obvious immediately. Both will attend the same meetings, use similar language, approve similar investments and, for a while, may even make similar decisions.

The difference is that one is continuously updating their understanding of what is possible. The other is slowly making decisions using yesterday’s assumptions.

You can delegate execution. You cannot delegate discovering what has become possible.

If your mental model changes more slowly than the systems your organisation is building, you may still be accountable for the seams.

You just may no longer be able to see where they are.