AI for Leaders
Decide what to build, what to buy, and what to refuse — without writing a line of code.
Most corporate AI projects fail. Not because the technology does not work — it works embarrassingly well on the wrong problems — but because someone bought a solution before anyone defined the problem, and nobody was willing to say so out loud six months later. The pattern repeats with painful regularity: a board asks for an AI strategy, a vendor demo lands, a pilot is funded, the pilot produces a screenshot, and the screenshot never becomes a workflow anyone uses on a Tuesday morning. This path is written for the person who signs that budget. It will not teach you to code, and it will not teach you the difference between a transformer and a diffusion model, because neither of those decisions is yours. It teaches the decisions that are: which problem is worth attacking, how to tell a real capability from a rehearsed demo, what a defensible ROI actually looks like once you count the cost of supervision and rework, when buying beats building and when it quietly locks you in, and how to move an organisation whose middle managers have correctly concluded that this project threatens them. You will finish able to kill a bad AI project in a meeting, with evidence — which is worth more than launching three good ones.
What you will learn
Prerequisites
- No technical background required
- Responsibility over a budget, a team or a process
- Willingness to hear that your favourite idea is a bad one
Where it leads
- AI transformation lead
- Head of department deploying AI in the field
- HR director owning upskilling and role redesign
- Executive sponsor of an AI portfolio
Phases
Phase 1 — Framing
Learn what the technology genuinely does, then find the one problem in your company where that matters.
Estimated duration · 2-3 weeksCapability, not magic: what these systems do and where they break
You need one working mental model, not a course in machine learning. These systems are extraordinary at transforming language and mediocre at being accountable for a fact. Once you internalise that split, half the vendor pitches in your inbox collapse on their own — and the surviving half becomes surprisingly easy to evaluate on the only question that matters: what happens when it is wrong, and who pays.
Topics covered
What you will build
- Take the last AI pitch you received and write a one-page rebuttal naming its three unstated assumptions
- Run the vendor demo yourself on ten of your own real inputs, including the three ugliest, and record the failure rate
- Write the "what happens when it is wrong" paragraph for one proposed use case, naming the person who absorbs the error
Finding the problem worth attacking
Companies pick AI use cases the way they pick restaurants: by what someone mentioned recently. The disciplined alternative is to inventory where your people actually lose hours, filter for tasks that are high-volume, low-stakes and text-shaped, and refuse everything else for now. The best first use case is almost always boring, internal, and invisible to your customers — which is exactly why nobody proposes it in a steering committee.
Topics covered
What you will build
- Shadow one team for a half-day and produce a ranked list of the ten tasks that eat the most hours
- Score each of those ten on volume, stakes and reversibility, and defend your top choice in writing
- Measure the current process end-to-end — hours, error rate, rework — before any tool is selected
Phase 2 — Proving
Build an ROI case that survives a hostile CFO, and decide honestly whether to buy, build or walk away.
Estimated duration · 2-3 weeksThe honest ROI
The ROI slide you have been shown counts the licence and the hours saved. It omits the supervision, the rework when the output is subtly wrong, the integration, the process redesign, and the fact that saved hours only become money if a headcount changes or that time is redeployed to something billable. An honest model is less flattering and infinitely more useful: it tells you in advance which projects were never going to pay back.
Topics covered
What you will build
- Build a one-page TCO model for your chosen use case with a line for supervision and a line for rework
- Write the kill criteria — the specific numbers at which you stop — and get them signed before the pilot begins
- Run a four-week pilot against your measured baseline and publish the result even if it is negative
Buy, build, or do nothing
Buying is fast and rents you a capability that your competitors can rent too. Building is slow, expensive, and the only route to something that is actually yours. Doing nothing is the option nobody puts on the slide and it wins more often than the industry admits. The real question is not cost — it is whether this capability is close enough to what you sell to be worth owning, and what it costs to leave.
Topics covered
What you will build
- Price the exit: document what it would cost in money and months to leave your leading vendor
- Write a two-page decision memo comparing buy, build and do-nothing with named owners and real numbers
- Interview two companies that deployed something similar and write up what they would do differently
Phase 3 — Landing it
Move the organisation, govern the risk, and build the internal capability that outlives the project.
Estimated duration · 3-4 weeksChange management when the change is threatening
Resistance to AI is usually rational. Your middle managers are not confused; they have read the situation accurately and concluded that this tool makes part of their leverage visible and replaceable. Communication does not fix that — incentives and honest answers about job security do. The teams that adopt fastest are the ones told plainly what happens to the time they free up, by someone with the authority to make it true.
Topics covered
What you will build
- Interview five sceptics and publish their objections verbatim, with your answer to each
- Write and circulate the one-page answer to "what happens to my job" — signed, not anonymous
- Redesign one role around the new workflow and get the person holding it to agree in writing
Governance, risk, and building the bench
Governance written as a fifty-page policy is decoration; nobody reads it and it stops nothing. Governance that works is short, names an owner per use case, states which decisions a machine may never make alone, and defines what gets logged so an incident can be reconstructed. In parallel you build the bench — because a company that cannot evaluate its own AI work will believe whatever its vendor says, forever.
Topics covered
What you will build
- Write a two-page AI governance note with a named owner per use case and three hard prohibitions
- Run an incident rehearsal: a wrong AI output reaches a client — reconstruct who knew what, from your logs
- Build a twelve-month upskilling plan with three tiers, named participants and a budget line
Questions
Do most corporate AI projects really fail? Why?
Yes, and the causes are boringly consistent. The project starts from a tool rather than a problem, so there is no baseline to improve against and no agreed definition of success. The pilot is measured on enthusiasm instead of outcomes, so nobody can prove it worked or failed and it drifts. Nobody costed supervision, so the promised savings evaporate into review time. And the people expected to change their daily work were told about it rather than asked, so they comply politely and revert the moment attention moves elsewhere. None of these are technology failures — every one of them is a decision made before a single line of code existed. That is precisely why this path is aimed at you rather than at your engineers.
I am not technical. Can I really lead this without learning to code?
Yes — and more than that, coding would not help you with the part that is actually failing. The decisions that sink these projects are scoping, measurement, incentives and governance, and none of them require Python. What you do need is enough of a mental model to know when an answer is evasive: why a system that is right ninety percent of the time can be worthless if you cannot tell which ten percent, why a demo on clean data proves almost nothing about your messy data, and why "the model will improve" is a promise nobody can keep on your timeline. That is a week of concepts, not a career change. This path gives you those concepts and then spends the rest of its time on the decisions that are genuinely yours.
What is the single most common mistake you see?
Starting too big and too visible. The instinct is to pick something impressive — customer-facing, strategic, worth announcing — because that is what justifies the budget in front of a board. It is exactly backwards. A first use case should be internal, high-volume, low-stakes and reversible, because your first attempt will be mediocre and you want the cost of that mediocrity to be a wasted afternoon rather than a damaged client relationship. The second most common mistake follows directly: refusing to kill the project once the numbers say to. Write your stop criteria before the pilot starts, get them signed, and honour them. A leader who has killed one AI project on evidence is trusted with the next three.
Related paths
Want to walk this path with a coach and a cohort?
Discover the 212AY Academy →