Webinar: What CEOs Must Do Next About AI

On 9 July 2026, I gave a webinar about the AI decisions that only a chief executive can make. It is the first technology shift I have seen where the CEO’s own fluency sets the ceiling for the whole company, and that makes for an uncomfortable briefing: you can delegate the rollout, but you cannot delegate understanding it. The single decision that matters most this summer is how much to lean into the uncertainty and potential gains, and how much to hold back to wait for clarity.

First: you cannot delegate understanding

Everything else follows from learning AI yourself. A chief executive can, and should, delegate the implementation of AI. You cannot delegate understanding it, which means you have to be using the tools yourself.

I have spent thirty years in technology, as a founder, as a CTO of startups and scaleups, and now full time helping companies through this transition, and I have never seen a shift like it. Normally a CEO can stay one level up, trust the specialists, and read the summary. Not this time. When you use the tools yourself you understand their real potential, their real limitations, and how they touch your specific business, and that is what lets you make nuanced calls instead of nodding along to a vendor deck. It is also what lets you trust the people in your business who are using AI to make good decisions of their own.

It is hard to be credible on any of this from the outside. Ask your CTO or CIO to set you up properly, and ask for training so that you are using it safely. The bonus is that you get more productive too: one CEO I know has wired up a briefing assistant so that before every meeting he knows exactly who he is about to talk to and why. The rest of this piece is the handful of decisions that get easier once you are in the tools yourself.

Beyond this fundamental point, here are six decisions and trade offs you will need to make.

Time, or just tools?

This is the decision that matters most, and it is the one every other decision leans on. Will your people get real time to learn, or will you hand them a licence and hope?

Giving people time is not free. It means saying goodbye to some of your targets for a quarter or two, because a team learning to work in a genuinely new way cannot also hit the number they would have hit doing everything the old way. Saying yes to AI means saying no to something else, and it is an investment that starts with your exec team, not with a memo to everyone below them.

I have said the “people need time and space” line so many times that it has started to sound trite, and I have run a lot of workshops built entirely around it. But the honest version is that you do not have to: you can wait. We just need to be clear on what waiting actually costs.

If you buy AI tools, know that you are buying into something nowhere near finished. The most powerful AI tools today are the ones that let people build their own AI tools. This means the next couple of years will bring a huge proliferation of custom code inside ordinary businesses, much of it built once and shared across teams as reusable skills. (I think we are heading for a renaissance of forward-deployed engineers, people who sit next to the work and build the specific thing it needs, but we are not there yet.)

Buying licences against today’s immature tools is buying a moving target. If you wait instead, your best people get itchy feet as AI takes on a life of its own outside work, and you have to help them learn the future or watch them leave to find it. And you end up buying AI capability later, once someone else has worked out how to package it, which is less effort but leaves you permanently a step behind. If you are in an industry where being a step behind on AI genuinely does not matter¹, then wait by all means. If you are in software, or consulting, or anything where the work itself is the product, that is a dangerous place to be.

Spread your vendor bets

One frontier provider is the shortest path to uniform productivity gains. It is one invoice, efficient to procure, and everything lines up. But it is one dimensional, the tooling is still early, and it could get expensive fast once vendors know you cannot easily leave! I would diversify, deliberately, and I would not let myself become beholden to whichever cloud workspace provider I happen to already pay.

Put a person or a small team on the free and open models so that you always know what is now possible outside your main vendor. The first reason is hedging: the market is overheated and concentrated in a handful of very large companies, and one big AI vendor failing, or simply falling behind, should not be able to take your operations down with it. The second is that the mainstream bundles are genuinely not good enough yet. Copilot is weak, Gemini inside Google Workspace is not there, and while Anthropic is reliably the best of the frontier, its availability has been patchy lately. None of that is stable, which is exactly why you want the optionality. I went deeper on this in I don’t want an AI god and on why open models are closer than they look.

Productivity, or product?

Where does AI actually belong in your company? AI for productivity is using these tools to clear your own team’s work faster. AI in product is packaging AI into something your customers use. They need different hires, different skills, and different appetites for risk, and the common mistake is treating them as one programme because they happen to share a buzzword. Decide which one you are actually doing, or be honest that you are doing both and resource them separately.

Drive it into the light

Is your governance helping people use AI well, or is it mostly teaching them to hide it? Ban it, and you do not stop people using AI, you just push them onto personal ChatGPT accounts on their phones, where your data leaks out and you have no visibility at all. That is shadow AI, and a ban is what manufactures it. The enabling posture is the opposite: buy people good tools, make the safe path the easy path, and block the genuinely risky tools rather than the whole category. Most of the scare stories about model danger are overblown and good governance is quite possible now. The real risks are about data and judgement, and those you manage by bringing usage into the open, not by driving it underground.

AI takes the jobs we hate

The popular line, that “AI will not take your job but someone using AI will”, is only half right. The better version is that AI will not take your job, but it will take the bits of your job you never liked. Work gets reshuffled and consolidated, the same number of people get more done, and eventually, once the tools mature and we have built enough of our own, people will not even need to learn AI for it to handle those parts. We are a long way from that.

Most people assume AI is coming for engineering first. It is actually the hardest part of the company to sort out, because software delivery is a very complex subsystem and engineers hold deeply ingrained, and now disrupted, ideas about how it should be done. The simpler early wins are everywhere else in the business, in finance, operations, marketing and support. This should not be an engineering-only programme. Roll it out to everyone now, or you build a two-speed company where one function races ahead and the rest quietly falls behind. I made the fuller version of this argument in how not to screw up your AI rollout and in unblock your team.

The hire you will need

Finally, who do you hire to run all this? Should you hire a Chief AI Officer?

There is no universal answer. It depends on your size, on how much coordination the rollout needs, and on the shape of your organisation. For most mid-sized to large companies the answer is yes, someone whose main job is driving AI matters in the short term. But make it an interim role for a year, give it a clear mandate, and review it. Do not imagine that hiring someone lets you stop thinking about AI yourself. If you are small, you are the Chief AI Officer - have at it.

AI will make engineering teams leaner over time, doing more with the same headcount, and some of those engineers will move into forward-deployed work, building custom agents not just for other engineers but for everyone else in the business. That is the same platform-team pattern I covered in how to structure your teams for AI, arriving from a slightly different direction.

So those are the six decisions only you can make: time or just tools, one big bet or many, productivity or product, gate or enable, how the work gets reshaped, and who to hire. If you take one thing away, let it be the first one.

Key takeaway to remember

We have got to upskill our people, not just give them tools. That is the sentence to carry into your next exec meeting. Every other decision here, the vendor spread, the governance posture, the hire, gets easier once you have decided your people deserve real time to learn and you have protected that time against the targets that would otherwise eat it. AI adoption is not a procurement exercise, it is a people investment, and the chief executive is the only person who can authorise it.

One thing to do this week

Spend an hour in the tools yourself, on a real piece of your own work, not a demo. Pick something you actually have to do this week, a board paper, a difficult email, prep for an awkward conversation, and do it with AI alongside you. You are trying to feel, first hand, exactly where it helps and where it falls short, because that feeling is the thing you cannot delegate and cannot get from a vendor deck. If you want a repeatable way to hand the recurring parts of your week over, that is what I mean by slicing your job into skills.