
Leadership exists to own what has no natural owner
On this page
Earlier in my career, I thought good delegation meant getting out of the team’s way. Hire exceptional people, give them context, trust them, remove obstacles and let them solve problems.
I still believe all of that. But I also learnt something the hard way.
A few times, I delegated important business systems to outstanding architects and product managers. They made sensible decisions, solved real problems and delivered exactly what had been asked of them. Yet months later, I realised something had quietly disappeared.
The thread.
The connection between all of those good local decisions and the broader architecture I had imagined for the company.
Nobody had done anything wrong. Quite the opposite. Everyone had optimised their own part of the world. The problem was that nobody owned the seams between them.
That experience fundamentally changed how I think about leadership. Today, I do not believe leaders should own every task.
I believe they should own the interfaces.
Teams optimise locally. Leaders optimise globally.
I have seen the same pattern repeat throughout my career.
One team builds the right inventory allocation service. Another chooses the best replenishment process for retail. Another solves beautifully for wholesale. Each decision is rational, and each team is acting in the best interests of the business it can see.
Collectively, however, those decisions can slowly pull the organisation in different directions.
I watched exactly the same thing happen with engineering platforms. Every team selected the programming language, framework and tooling that best solved its own problem, and every decision made perfect sense in isolation.
A few years later, engineers could not move easily between teams, knowledge had fragmented and operating the platform had become unnecessarily expensive.
Nobody had optimised for the whole system.
Leadership exists precisely because local optimisation is not the same as global optimisation.

What I actually delegate
People sometimes assume that staying close to architecture means micromanaging. For me, it is almost the opposite. I do not own the tasks. I am accountable for the interfaces.
The inside of a component belongs to the team. The coherence of the boundaries between components is what I hold myself accountable for: the canonical business ontology, the architectural seams and the contracts between systems.
Not because I define all of them myself, but because these are precisely the problems no single team is designed to hold.
Every team has an owner for the inside of its component. The seams have no natural owner at all.
Left alone, they do not get solved badly. They simply do not get solved.
So I do not tell teams how to implement a capability. But I make sure, with the precision the problem deserves, that someone has decided where that capability should live, how it connects to everything around it and whether it should exist at all.
Those decisions compound.
When the interfaces remain coherent, teams can move incredibly quickly inside them. When the interfaces drift, even brilliant teams slowly create fragmentation.
AI changes the cost of getting this wrong
This is where AI enters the picture.
Not because leaders suddenly need to become technologists, but because AI dramatically increases how quickly teams can optimise locally.
I now see people building in an afternoon what previously required a quarter. That is extraordinary. But it also means local decisions compound faster.
A workflow gets rebuilt. A new agent appears. A business process changes. Each one individually makes sense, but without someone protecting the interfaces, the organisation can fragment faster than ever before.
I wrote recently about the threshold individuals cross when AI becomes a system of execution rather than an assistant. This is the organisational half of that problem.
The more people cross that threshold, the more the coherence of the whole depends on someone owning the seams.
Ironically, the better your builders become, the more important leadership becomes.
Not to slow them down, but to connect what they are creating into something coherent.
Understanding cannot be delegated
An executive might reasonably think they do not need to understand AI because their technology team does.
I think that is true technically.
It is completely false organisationally.
Technology can be delegated. Understanding cannot.
Teams always work inside the constraints leadership leaves in place. They improve existing processes, automate existing workflows and optimise existing structures.
Very rarely can they remove the assumptions underneath them. Not because they cannot see those assumptions, but because they rarely have the authority to unmake them.
Only leadership has both the authority and the organisational context to ask questions such as:
Why does this approval exist?
Why do we plan monthly instead of continuously?
Why are these two teams handing work to one another at all?
Why are we buying software for a process we could fundamentally redesign?
Those are not technology questions. They are leadership questions.
The meeting I think every leader should have
If I were starting again tomorrow, I would begin with one exercise.
Take your own domain. Not the whole company. Your domain.
Sit down with two people: your best operator and your most curious builder. Then spend two hours answering four questions.
Which decisions here could be made continuously rather than monthly?
Which workflows could be orchestrated from end to end instead of passed between teams?
Which coordination layers exist only because information used to move slowly?
Which activities were previously too expensive or too complex to consider, but no longer are?

Notice something: none of those questions is about AI. They are all about your business.
The builder cannot answer them alone because they do not carry the full operational and commercial context. The operator cannot answer them alone because they do not yet know everything that has become possible.
Leadership exists to bring those two worlds together.
The output is not a strategy deck.
It is a list of assumptions that have quietly become optional.
What happens without this
The pattern is remarkably consistent.
Technology teams continue building inside existing workflows because nobody has challenged them. Business leaders delegate AI to specialists and assume the problem is covered. Eventually, the organisation becomes impatient with the pace of progress and brings in consultants to define the future.
More tools arrive. More pilots happen. More software gets layered onto existing work.
The organisation becomes more automated.
It does not necessarily become more capable.
Automation makes the existing system cheaper. Capability allows you to build a fundamentally different one.
Only one of those creates lasting competitive advantage.
The leaders who shaped me
I have been fortunate to work with leaders who reinforced this lesson.
Watching Dara Khosrowshahi at Expedia, one thing always stood out to me. He did not go deep because he wanted to control the execution. He went deep because he wanted to understand the system well enough to ask better questions.
The leaders I have most admired share that quality: a willingness to question assumptions everyone else has accepted as fixed.
They go back to first principles.
That curiosity gives them the confidence to challenge orthodoxy rather than inherit it.
I think it is becoming one of the defining leadership capabilities of this decade.
Where I think this ends
The more I reflect on leadership, the less I believe it is about having the right answers.
It is about protecting the coherence of the system. Teams build components. Leaders build the system those components belong to.
That requires curiosity. It requires enough courage to question inherited assumptions. And it requires going deep enough into the problem to understand which interfaces must never be allowed to drift.
AI has not changed any of that. It has simply raised the price of leaders who will not go deep.