A founder described his AI review process to me as “approving things I can’t really evaluate.” His delegate brought weekly updates. He listened, asked a few questions, signed off the spend. The programme moved forward. But he felt, and suspected his delegate felt, that he wasn’t really in the loop.
Sign-off authority is not the same as understanding. Many founders running a delegated AI programme are in exactly this position: sitting above the work, endorsing it, but not fluent enough in the tools to judge whether the direction is right.
That’s a position worth changing, and there’s a clear model for how to change it.
What does a founder AI power user actually look like?
Spencer Stuart’s power-user playbook for CEOs describes a 90-day agenda for moving from approval to hands-on use. The power user is not someone who micromanages the delegate or pretends to be technical. They are a founder who uses AI tools regularly in their own work, and who has, through that use, developed a working sense of where AI performs well and where it does not.
The distinction between this and traditional sponsorship matters. A sponsor endorses a programme, attends the launch, and checks in on the numbers. A power user has their own reference points for what good looks like. When the delegate says “we tested three tools and this one gave us the most reliable outputs,” the power user can ask the right follow-on questions, because they have run their own tests, even if only informally.
Spencer Stuart’s agenda does not require a technical background. The 90-day arc is built around applying AI to the CEO’s actual daily work, things like preparing board materials, reviewing strategy documents, and drafting communications. The tools are conversational and require no coding knowledge. The founder learns by doing, on their own work, before setting any expectations for anyone else’s.
Why does fluency give you something that approval never will?
Approval is a filter, not a lever. When a founder signs off an AI recommendation without hands-on experience of the tools involved, they are relying entirely on the delegate’s framing. Fluency changes that. A founder who uses AI daily in their own work has a calibrated sense of what the tools can do, what they cannot do, and where the delegate’s judgement deserves scrutiny.
There is a second effect, less obvious but probably more significant. The organisation watches what the founder does, not what the founder approves. If the people closest to a founder see that she reads AI-drafted summaries, uses AI for research, and openly rates the output, they infer that AI is part of how the business actually runs. That inference drives adoption far more reliably than a company-wide rollout announcement.
McKinsey’s 2025 State of AI research found that the firms attributing meaningful profit impact to AI were distinguished less by tool choice and more by how deeply AI was embedded in day-to-day working practices, including at the leadership level. Broad deployment with shallow leadership engagement consistently underperformed against narrower deployment with visible, active use from the top.
Where does the fluency gap show up in a delegated programme?
The gap tends to surface in three places: the weekly review, the approval of new tool spend, and the moment the delegate escalates a difficult call. In each situation, a founder without direct experience of the tools is relying on a second-hand account. The delegate learns, consciously or not, to shape that account in a way the founder will accept.
This creates a particular failure mode. The founder, sensing they do not have the reference points to challenge the delegate, defaults to broad approval. The delegate, knowing this, frames recommendations as already-decided rather than open for input. Over time, the gap between “the founder approved this” and “the founder understood this” widens, and the programme drifts in a direction the founder may not have chosen if they had been more engaged.
BCG’s analysis of AI adoption found roughly half of organisations stuck and unable to scale their AI work past initial pilots. The gap between pilot and scale is rarely a technology problem. It tends to be a leadership one: the right people were not engaged at the right level, and the programme lost momentum as a result. A founder who has no direct experience of the tools cannot give the programme what it needs at that stage.
When should you stay in the work, and when should you step back?
The answer depends on which kind of staying-in you mean. A founder who uses AI for their own work, drafting, analysis, preparing for a board meeting, is not interfering with the delegate’s programme. Those are separate tracks. The risk is a different kind of interference: the founder who approves decisions from a distance but then overrides the delegate when outcomes do not match expectations.
Using AI for your own work and running a company-wide AI programme are not the same activity. The first is a personal practice the founder controls entirely. The second belongs to the delegate, and the delegate needs clear decision rights to run it well. The power-user position is about building the first so you can be a better sponsor of the second. It is not about expanding founder involvement in operational decisions.
Spencer Stuart’s playbook frames this as earning the right to sponsor by first being a user. The founder who has been using AI tools in their own work for three months before the company-wide rollout launches has something the approval-from-a-distance founder does not: a genuine perspective on what the tools can do, and a reputation inside the business as someone who actually uses them. Those two things carry real weight when the programme hits its first difficult moment.
What else connects to the power-user position?
Three ideas sit close to this one. The decision-rights conversation, settling what the delegate owns versus what needs founder sign-off, is a prerequisite; fluency alone does not resolve an unclear mandate. The exit lens matters: M&A advisors flag founder dependency as the largest single discount on exit multiples, so an AI programme needs to reduce that dependency rather than gradually reinforce it.
The third is modelling. If the founder becomes a confident AI user before the programme is announced, the announcement lands differently. It shifts from “we’re rolling this out for the teams” to “here is what I’ve been doing and what I want us to do together.” That shift in framing carries more weight than any amount of formal sponsorship activity, because it signals that this is how the business actually operates, not just how it aspires to operate.
MIT NANDA research found that around 95% of generative AI pilots stall or show no measurable impact. The cause is consistently identified as a learning gap in how the technology is integrated into working practices, not a problem with the tools themselves. The founder who has closed that gap in their own work is far better placed to close it across the business.
If you want to work through where your AI programme actually stands and what the founder’s role in it should look like, book a conversation.
