AI training for executives who set the strategy

Leadership teams get stuck on three questions: which investments are worth making, who is accountable when one ships, and how to tell a real vendor claim from a rehearsed one.

These sessions close those questions. One works when a decision that had sat open for two quarters comes out of the room made, written down, and owned by someone.

What your team leaves with

The decisions you convened the session to make, with where the team landed on each and the reasoning recorded, so the call survives the next leadership change. The frameworks we applied during the session, in written form. The disagreements that did not resolve, stated plainly along with what evidence would settle them. And next actions with names attached.

The written record matters more than it sounds. Most leadership teams have made the same AI decision twice, because the first time nobody wrote down why, and eighteen months later a new CTO reopened it from scratch. A four-page memo of decisions and reasoning is the cheapest insurance you can buy against relitigating your own strategy.

How this compares to executive education

Most searches for executive AI training land on a university programme, so it is worth being precise about what is different. These are separate products for separate problems, and for some teams the university is the right call.

	This	Executive education (MIT Sloan, Harvard, Wharton, Berkeley)	Online course (Coursera, IBM, AWS)
Who is in the room	Your leadership team, alone	A cohort of strangers from unrelated industries	You, at your desk
Case material	Your own open decisions	Published cases about other companies	Generic scenarios
Length	Two hours to multi-day	Two days to several weeks	Self-paced, 4 to 20 hours
Who teaches	Me, for the whole session	A rotating faculty panel	Recorded video
Output	Decisions made and recorded	A certificate and notes	A certificate
What it costs you	A day of your leadership team’s time	Per-seat fees plus travel, times the team	Little, and it shows
Best when	A specific call is blocking you	You want a credential and a peer network	One person needs grounding

The honest summary: a university programme makes individuals better informed, and your open decisions stay open, because nobody else in that cohort shares your P&L. This makes the decisions. If you need both, do the university programme first and bring me in when the team has the vocabulary but still cannot agree.

The one thing the universities have that I do not is the brand on the certificate. If the goal is a line on a CV or a signal to your board that you spent money on the problem, that is a legitimate goal and they serve it better.

Topics

I build sessions from these. Most combine two or three, and a two-hour session realistically covers one.

AI adoption. Why adoption stalls after a successful pilot, how to find the places where the old process is quietly still running in parallel, and what makes people distrust a new system enough to keep the old one alive. The pattern is consistent: the pilot succeeds because the team running it wanted it to, and the rollout fails because nobody gave the next hundred people a reason to change what they do on a Tuesday.

Opportunity identification. How to find the places in your business where AI changes the economics rather than the optics, and how to tell those apart from the ones that demo well. We work through your own operations rather than a generic use-case catalogue. Teams usually arrive with somewhere between fifteen and forty candidate ideas and leave with four that survive a value question and a feasibility question asked in sequence.

AI-first thinking. What a process looks like when you design it around what these systems do well instead of retrofitting one built for people. This is the session that tends to change what a team asks for afterwards. A claims process redesigned this way looks nothing like the same process with a model bolted onto step four.

Investment prioritization. How to size an AI proposal against the same bar as any other capital allocation: what the effect is, on which tracked line, by when, and what has to be true for it to hold. Includes the questions that expose a proposal with no defensible number behind it. Most AI business cases fail the third question, because the benefit lands on a line nobody currently reports.

Vendor evaluation. What to ask, what a good answer sounds like, and which claims to discount. Usually run against pitches your team is actively receiving, which is more useful than a checklist and considerably more uncomfortable for the vendor. We cover accuracy claims and how they were measured, what happens to your data, what the switching cost looks like in month eighteen, and which parts of the demo were real.

Governance and decision rights. Who approves a model going to customers, who is accountable when it misbehaves, what gets logged, and how an incident escalates. This one reliably produces the longest argument, which is usually a sign it was overdue. Teams that need a full day on this want a board-level governance session rather than this one, and I scope that separately.

Agents and autonomy. What an agent actually is once you strip out the marketing, the levels of autonomy, and which level is appropriate for which process in your business. The useful output is a rule your team can apply without me: which decisions a system may take alone, which need a human to confirm, and which it may never touch.

Change management for leaders. What happens to roles when a function’s work materially changes, and how to decide and communicate that before a rollout rather than during it. Includes the question most teams avoid until it is asked in an all-hands, which is whether headcount is affected and what you are willing to promise.

Sector briefing. What your industry is deploying today, drawn from current work rather than vendor case studies, including the failures where those teach more.

Formats

Two hours. A board briefing, or a focused working session on one open question. Enough for one topic and a short working block. Choose this when the team is broadly aligned and needs to close a single call.

Half a day. One topic covered properly, plus a working block against a live decision, plus time for the argument that the working block starts. This is the most common booking and the shortest format I would recommend when the team disagrees.

Full day. Two or three topics, two working blocks, and enough room to reach the second-order questions. Suits a leadership team that has been circling AI strategy for a while without landing it.

Multi-day, or a leadership offsite. Three or more topics, working blocks against several decisions, and the space to sequence what comes out of them into a plan. Usually paired with pre-reading and a follow-up session four to six weeks later to check what actually moved.

Groups run from five to about fifty. The teaching content works at any size in that range; the working blocks stop functioning above roughly twenty-five, and past that I split them by function and bring the conclusions back together.

Remote or in person, both work. In person is better whenever the working block carries the session, because the useful material is the disagreement between your executives, and people concede a point more readily on a video call than they should.

What a half day actually looks like

The shape below is the most-booked format, run for a leadership team that has a vendor decision and an adoption problem at the same time. Timings shift with the topics.

First forty-five minutes. Where these systems are reliable, where they fail, and why they fail in the particular ways they do. No architecture. The goal is that everyone in the room can tell an implausible vendor claim from a plausible one by lunchtime.

Next forty-five. The chosen topic, taught against your situation. If the topic is vendor evaluation, we are working on the pitches currently in your inbox.

Break.

Ninety minutes, working block. The team takes the actual decision. I facilitate, apply the framework, and push on the reasoning. I do not vote. This is the part of the day that justifies the rest of it, and it is the part that gets cut when a team tries to do this in two hours with six topics.

Final thirty. Write down what was decided, what was not, and who owns each next action. In the room, on a screen everyone can see, so nobody leaves with a different memory of what happened.

You get the written version within two working days.

The failure modes every session covers

The opening block is the same regardless of topic, because every later argument depends on it. Executives do not need to know how a transformer works. They need to know the specific ways these systems break, because that is what determines which guarantees you can offer a customer and which vendor claims deserve a second question.

Five failure modes account for most of what goes wrong in production.

A model states something false in the register of something true. The failure has no signal attached, which is what makes it expensive: a wrong answer arrives with the same confidence as a right one, and the reviewing human calibrates to the system being usually correct. Any process where a wrong answer is costly and hard to spot needs a check that does not rely on a person noticing.

The same input produces different outputs on different days. Teams design a process assuming stability, then discover in month three that the vendor changed a model version and the outputs shifted underneath them. This is the single most common cause of a working pilot degrading after rollout.

Performance collapses at the edges of the data the system saw. A system that handles ninety-five per cent of your cases well can be worse than useless on the remaining five if those are the ones that carry the risk, and in claims, credit and clinical work they usually are.

A system optimises the thing you measured rather than the thing you wanted. Give an agent a resolution-time target and it will close tickets. Whether it solved anything is a separate question, and you will find out from your churn numbers a quarter later.

Autonomy compounds errors. One wrong step in a five-step chain produces a wrong outcome, and the intermediate steps look reasonable in the log. This is why the autonomy question is a governance question rather than a technical one.

Once a leadership team can name those five, vendor evaluation stops being a matter of trust. The questions ask themselves.

Questions the room always asks

These come up in nearly every session, so they are worth answering before you book rather than after.

How far behind are we, actually? Almost always less than the team fears. The public narrative is set by companies whose product is AI. Most organisations in most sectors are somewhere between a pilot and a policy, and the gap between the median and the leader is smaller than the gap between the leader and the marketing.

Should we build or buy? Buy the capability, build the part that is yours. The test is whether a competitor could licence the same thing and be at parity. If yes, buying it is correct and building it is vanity.

What do we do about the data problem? Name it precisely first. “Our data is a mess” is not a finding. Which fields, in which system, are wrong often enough to break which use case, is a finding, and it is usually much narrower than the anxiety suggests.

Who should own this? Someone with budget authority who is not the CTO by default. AI that lives entirely in engineering solves engineering problems. If the value is in claims, the owner should be whoever runs claims, with engineering supporting.

What do we tell staff about jobs? Whatever is true. A promise you cannot keep costs more than the honest version, and people can tell the difference between “no AI-driven layoffs” and “we do not currently plan any, and we will tell you before that changes.”

How do we know it is working? Pick the number before you start. If the benefit lands on a line nobody currently reports, add the report first, because a benefit you cannot see will be attributed to something else.

Is it too early? For the moonshot, usually. For the boring internal use case that saves your operations team a day a week, you are late.

What teams actually decide

Sessions vary, and these are the kinds of calls that have come out of them. Details are changed enough to keep clients unidentifiable.

A financial services team killed a document-processing build at month four and bought instead, after working out that their differentiation sat in the review workflow rather than the extraction, and that they had been building the commodity half.

A logistics operator agreed a rule for agent autonomy: systems could reschedule and reroute without a human, could not contact a customer without one, and could never issue a credit. That rule had been argued informally for three quarters and had never been written down, which meant every new project relitigated it.

A healthcare group discovered mid-session that two of its divisions had signed with competing vendors for overlapping capability, because nobody owned the decision at group level. The session’s main output was naming that owner.

A retailer decided not to proceed with anything for two quarters, and instead fixed the product data that every proposed use case depended on. That is a real outcome and a good one, and it is cheaper to reach in a room than nine months into a build.

What happens after

The written record goes to your sponsor within two working days: decisions, reasoning, open questions with the evidence that would settle them, and actions with names against them. Four to six pages, written to be read by someone who was not in the room, because in six months that will include half the people who were.

Most engagements stop there, and that is a reasonable place to stop. Where a team wants a check on whether anything moved, I run a follow-up session four to six weeks later against the action list. That interval is deliberate. Two weeks is too early to see whether a decision survived contact with the organisation, and three months is long enough for the list to have quietly died.

A session sometimes surfaces that the real constraint is not knowledge. A team that cannot agree on vendor selection because nobody has looked at the state of the data has a readiness problem rather than a training problem, and the honest next step is an AI readiness assessment instead of another session. Where the open question is what to build and in what order across the portfolio, that is AI strategy work. I will say which one applies rather than sell you a second workshop.

Sector experience

The sector briefing draws on current work rather than a research deck. The sectors I can speak to in detail are financial services and insurance, healthcare and health administration, logistics and supply chain, retail and ecommerce, telecommunications, and professional services.

For a sector outside that list I will say so and drop the briefing rather than assemble one from public sources over a weekend. The other topics do not depend on it.

Who should not book this

Everyone in the room should control budget, headcount, or policy, because the working blocks ask people to make calls. Boards, C-suites, and senior leadership teams.

Individual contributors and engineers are the wrong audience. The discussion sits at a level that wastes a builder’s afternoon. If your team wants hands-on tool training, hire someone else for it. If you need a structured programme across the whole workforce rather than the leadership layer, that is a different piece of work and I scope it separately.

Also worth saying plainly: if your leadership team has no open AI decisions, this is entertainment. Book it when something is actually blocked.

How I tailor it

I talk to your executive sponsor beforehand, for about forty-five minutes. The questions are always some version of these:

Which AI decisions are currently open, and how long have they been open? Where does the leadership team disagree, and is the disagreement about facts or about priorities? What have you already tried and abandoned, and what was the stated reason at the time? Who in the room can say no, and who thinks they can? What is the one thing that would make you regard the session as a waste of a day?

That last question is the most useful one I ask. The answer usually names the real agenda.

Those answers become the worked examples. The frameworks stay the same across engagements. The material I apply them to is yours.

The curriculum draws on the CXO resource library on this site, which I write for executives from scratch. If you want to know how a topic is treated before booking, the AI adoption and governance briefings are representative.

Where I am the wrong choice

I am one person. There is no delivery team behind me, no analyst layer, and no capacity to run the same programme across nine regional offices in a quarter. A large firm does that better and you should hire one for it.

I do not certify anyone. Nobody leaves with a badge.

And I am not neutral about outcomes. If the honest answer to your question is that you should not build the thing, the session will land there, and some teams book training expecting validation instead. Worth knowing before you spend a day on it.