For the management team
You can only set strategy for capabilities you can imagine.
And you can only imagine capabilities you have experienced. That is why AI transformation starts in the leadership team, not in an IT project.
Organizational transformation cannot outrun the leadership team's personal understanding of what is possible. When AI is delegated to IT or an innovation team, those teams propose what they can see: efficiency gains and tool rollouts. When executives experience AI augmenting their own judgment, in their actual work, the ambition changes. They stop asking what can be automated and start asking what the company can do that was impossible before.
The bottleneck
The bottleneck has moved
Anton Osika, whose company Lovable became one of the fastest-growing software companies in history, describes the shift in one line: the bottleneck in business is moving from who can build it to who knows what to build. Execution used to be the constraint. You had the idea and needed engineers, analysts and specialists to make it real. That constraint is evaporating. People who could not code a year ago now ship working systems in a week.
What stays scarce is judgment: knowing which capability matters, which opportunity deserves the organization's focus, what to stop doing. In a company, that judgment sits with the leadership team. Which is why AI fluency is a leadership question before it is a technology question, and why a transformation that skips the management team caps out early.
The trap
The delegation trap
No. Delegating AI to IT or an innovation team is the most common reason corporate AI initiatives stall. Those teams propose what they can see from their seat: tool rollouts and efficiency gains. The questions that decide competitive position, what changes about our business model, what capability do we build, what do we stop doing, can only be answered by the people who own the P&L. The CEO does not need to become technical. The leadership team needs to become fluent.
The organization then moves at the speed of its least-experienced decision-maker. The board does not approve strategies the CEO cannot evaluate. The budget does not fund initiatives the CFO cannot imagine. So the safe bet gets approved, and the safe bet is always too small. That is how a company ends up with thirty pilots and no position.
The deeper reason delegation fails this time: AI is not one more technology in the stack. It is the technology of intelligence itself, and it is recursive, already being used to improve the systems that build it. A capability that compounds weekly does not wait for an eighteen-month evaluation cycle. The head of AI adoption at one of Sweden's largest industrial companies said it plainly: the executives have not used the technology enough themselves to see what is possible. Not opposed, not skeptical. Inexperienced. The full argument is in The Delegation Problem.
Fluency
What executive AI fluency actually means
Executive AI fluency means having used AI on your own work, your preparation, your analysis, your decisions, long enough to build an intuition for what it makes possible. Users improve their productivity 20 to 30 percent. Builders create value that did not exist before. The difference between the two is experience, not talent, and a management team can build it in weeks.
The user-builder line is concrete. A user asks AI to do a task: summarize this, draft that. A builder redesigns the work around what AI now makes possible. Users hit a ceiling, because once the existing workflow is optimized there is nothing left to speed up. Builders compound, because every system they build makes the next one easier.
Two populations are forming inside companies right now: people whose intuition for the technology deepens every week, and people practicing not-knowing. Both are becoming who they practice being, and the gap does not close by deciding to engage two years from now, because the intuition takes time to form and the technology will not wait. The longer version is in Build Builders, Not Users.
The dip
Expect the dip
A fluent leadership team also knows, in advance, that real transformation gets worse before it gets better. When factories first electrified, productivity fell for twenty years, then tripled once the floor was redesigned around the new capability. AI follows the same J-curve: redesigning work costs before it pays, and the dip is what doing it right looks like.
So treat clean first-quarter ROI as a warning sign, because it usually means the company is automating around the edges instead of building capability. The leadership job during the dip is to hold the course and measure the right things: learning speed, new capabilities, what the team can do now that it could not do last month. The metrics argument is in You're Reading the Wrong Curve.
Your builders
The question your builders are already asking
There is a second reason fluency cannot stay at the top. The people who gain the most from AI first are your best people, and many of them are already using it quietly. They do not surface the gains, because in most companies the reward for saving eight hours is eight more hours of the old job.
A leadership team rolling out AI has to answer the incentive question before the tools: who owns the productivity gains? Give builders room to create and a share of what they generate, and they become the engine of the transformation. Ignore the question and the most capable people in the building eventually notice they no longer need the building. In a market where one person with the right systems can do what used to take a team, keeping your builders is strategy, not retention policy.
The program
What a leadership-team AI program looks like
GRAIL's leadership program, See The Opportunity, runs three workshops across 3-4 weeks. How to Think sets the strategic foundation: where AI creates real value and where it is noise. Your AI Team is a hands-on half day where each executive builds a personal suite of 5-10 custom AI agents trained on their market and their work. Competitive Edge refines everything against real usage and ends in an AI opportunity roadmap. The team leaves with working tools, not slides about tools.
The design principles matter more than the agenda. The team works on its own live decisions, not case studies. It works together, so a shared reference forms for what good looks like. And it leaves owning everything that was built: the agents, the workflows, the skills. The full programme, including what comes after the first step, is on the services page.
There is a reason GRAIL can run this in weeks rather than months, and it is the same shift the program teaches. GRAIL rebuilt its own delivery around AI first: the diagnosis, the competitive analysis, the agent building all run on its own AI infrastructure, so senior thinking is the only bottleneck left. The firm is the proof of its own argument, which is also why it can deliver the triple threat, faster, cheaper and better at once, instead of asking you to pick two. The fuller version of that positioning is on how GRAIL works.
Course vs program
Why a course is not enough
A course teaches the team about AI. It rarely changes how anyone works on Monday. Fluency comes from using AI on your own live work, with your own data, your own market, your own decisions, and from doing it together so the management team builds a shared reference for what good looks like. That is a program design question, not a curriculum question: hands-on beats lecture, own work beats case studies, and the team beats the individual.
You cannot lead a transformation you have not personally experienced. A certificate does not change what you can imagine. A few weeks of using the technology on your own decisions does.
Users get 20-30% faster. Builders change what the company can do.
Three years of using AI as a search engine trains one leadership team. Three years of using it as a thinking partner trains another. Same tools, different company.
Questions leadership teams ask
Why should AI transformation start with the leadership team?
Organizational transformation cannot outrun the leadership team's personal understanding of what is possible. When AI is delegated to IT or an innovation team, those teams propose what they can see: efficiency gains and tool rollouts. When executives experience AI augmenting their own judgment, in their actual work, the ambition changes. They stop asking what can be automated and start asking what the company can do that was impossible before.
Should the CEO delegate AI to the IT department?
No. Delegating AI to IT or an innovation team is the most common reason corporate AI initiatives stall. Those teams propose what they can see from their seat: tool rollouts and efficiency gains. The questions that decide competitive position, what changes about our business model, what capability do we build, what do we stop doing, can only be answered by the people who own the P&L. The CEO does not need to become technical. The leadership team needs to become fluent.
What is executive AI fluency?
Executive AI fluency means having used AI on your own work, your preparation, your analysis, your decisions, long enough to build an intuition for what it makes possible. Users improve their productivity 20 to 30 percent. Builders create value that did not exist before. The difference between the two is experience, not talent, and a management team can build it in weeks.
What does an AI program for a leadership team include?
GRAIL's leadership program, See The Opportunity, runs three workshops across 3-4 weeks. How to Think sets the strategic foundation: where AI creates real value and where it is noise. Your AI Team is a hands-on half day where each executive builds a personal suite of 5-10 custom AI agents trained on their market and their work. Competitive Edge refines everything against real usage and ends in an AI opportunity roadmap. The team leaves with working tools, not slides about tools.
Is an executive AI course enough for a leadership team?
A course teaches the team about AI. It rarely changes how anyone works on Monday. Fluency comes from using AI on your own live work, with your own data, your own market, your own decisions, and from doing it together so the management team builds a shared reference for what good looks like. That is a program design question, not a curriculum question: hands-on beats lecture, own work beats case studies, and the team beats the individual.