The brief is clear enough. Get AI into the business. The founder said so at the last all-hands, included it in the board pack, and handed the work to you. Three months in, a colleague asks the obvious question. Does the founder actually use any of this? You know the answer. They haven’t once.
What is the “demands but won’t model” pattern?
The pattern has a specific shape. A founder publicly backs AI adoption, includes it in the strategy deck, delegates ownership to you, and then personally engages with the technology not at all. The gap between visible sponsorship and actual practice is exactly what the organisation notices. When a founder mandates without modelling, they send a signal louder than any communications plan can correct.
This happens for understandable reasons. Non-technical founders frequently file AI under IT or digital, terrain where a senior operator or head of digital feels more legitimate. There is also a self-concept dimension. A founder who built their reputation on domain expertise is unlikely to want to be seen as a novice relative to their own reports, particularly in front of investors or a board that is already watching closely. Delegating the change work is a tidy solution to all of that.
The difficulty is that full founder withdrawal removes the strongest adoption lever available. Spencer Stuart has published an explicit playbook arguing that CEOs need to become hands-on power users rather than vocal sponsors. The framing is precise: visible sponsorship without personal practice is a different position from genuine leadership on AI, and organisations are good at reading which one they are looking at.
Why does a hands-off founder cost your adoption programme?
There is a measurable gap between nominal and active sponsorship. Change management research consistently shows that technology implementations stall for leadership and cultural reasons more often than for technical ones. A founder who stays at a distance from tools they have mandated removes the most powerful adoption signal the organisation has, the visible, sustained demonstration from the top that this is genuinely how we work now.
One set of vendor data, directional and worth treating with appropriate caution, found organisations with active C-suite involvement reaching approximately 50% Copilot activation within 90 days, compared to 28% on similar deployments without that engagement. The gap is consistent with the broader change management literature, which has long identified sustained executive involvement as one of the strongest adoption predictors across technology rollouts of every kind.
BCG’s 2025 analysis of AI adoption found around half of companies remain stuck in emerging or stagnating stages, unable to scale past proof-of-concept. High performers embed AI in strategic planning as well as operations, and the more consistent differentiator is whether leadership is genuinely in the work.
The founder’s hands-off position actively pulls against the programme you are trying to run. Understanding why it happens does not change what it costs.
Where does this show up in your day-to-day work?
The demands-but-won’t-model gap surfaces in three predictable places in the delegate’s day-to-day work. In progress reviews, the founder asks for updates but has no experiential frame for what you describe. In team conversations, colleagues who ask whether the founder uses AI get an answer that either misleads or undermines the programme. In prioritisation discussions, the founder’s view on which tools to fund next is pure abstraction without any direct contact with the work.
The progress review problem plays out in a specific way. You present what has been built, what has been learned, what the next decision is. The founder either approves or declines, but from a position of distance. Without any lived reference point, their requests for course corrections can arrive with no practical context behind them, and the conversation is harder to anchor.
Cultural signal from the top matters as much as any communications plan. When employees at any level observe that the founder avoids tools they have publicly endorsed, the permission they take from that is real. Adoption programmes depend on the whole organisation believing the change is permanent, and a founder who does not practise what they have endorsed gives an unambiguous answer on that question.
The prioritisation problem is subtler and more persistent. When the time comes to decide which projects to fund or which teams to resource differently, a founder without personal experience of the tools is drawing on secondhand information. Their instincts may be good, but they are not grounded in the work, and that makes your case harder to land when the options are genuinely close.
When should you raise this with the founder?
Many delegates wait too long to address the founder’s non-engagement with AI. The instinct is to protect the founder’s face by not naming it directly, and the result is an adoption programme without a visible sponsor. The Spencer Stuart approach positions the ask around the founder’s own productivity rather than the programme’s metrics. Start with one task, keep it low-risk, and let the experience do the work.
Spencer Stuart’s playbook proposes a 90-day sequence for CEOs to become genuine AI power users, starting with a personal sandbox in the first four weeks. The suggestion is one daily task the founder already does, automated or enhanced with AI. Preparing for a board call. Reviewing a proposal. Drafting a brief. Nothing visible to the organisation at first. The goal is to give the founder a real frame of reference before any expectation of public engagement.
The ask that lands well is different from the one that triggers defensiveness. Telling the founder they should use AI to support the programme is a demand on their time for the benefit of your agenda. Telling them there is something that could take an hour off their board prep is a genuine offer with a clear personal return. Spencer Stuart is explicit on this point: the framing is about the founder’s own productivity, not additional sponsorship activity on behalf of the programme.
One practical note on timing. The right moment to raise this is before you have a problem, not after it. A founder who has personal experience with the tools, even at a basic level, has a reference point when things stall or when a pilot does not land as expected. A founder who has never opened the tool has no frame for that conversation when the hard questions arrive.
What else connects to this pattern?
Two patterns sit alongside the demands-but-won’t-model dynamic and are worth understanding as you work through it. The first is verbal delegation with ongoing interference, where the founder nominally hands off ownership of the AI programme but keeps stepping into key decisions. The second is the founder-dependency paradox, where AI built to mirror the founder’s instincts can deepen rather than reduce the business’s reliance on them.
The verbal-delegation pattern is particularly common in founder-led businesses where the programme is new and the founder’s grip on strategic decisions is still strong. You may have been given explicit ownership of the AI work, but if the founder publicly comments on AI decisions, overrides vendor choices, or restates programme priorities in ways that contradict your brief, the organisation takes the more recent signal. Defining where the founder engages and where they do not is a conversation that is far easier to have early than to unpick later.
The founder-dependency paradox matters most if exit planning is part of the picture. Owner dependency is one of the largest discounts to exit multiples according to M&A advisors, and one of the implicit goals of any AI programme is to reduce the business’s reliance on the founder personally. AI built too closely to the founder’s decision-making style can deepen that reliance rather than address it. The more effective path is to use the AI programme as a vehicle for codifying founder process, making it transferable rather than personalised.
The demands-but-won’t-model pattern is the most common and least addressed failure in delegated AI mandates. Understanding why it happens, where it shows up, and what it costs gives you a clearer picture of the problem you are actually working with. The tactics for drawing the founder in are within reach. They require a different framing than most delegates instinctively reach for, and that framing is available.
