You can't mandate adoption: the five-step sequence that earns trust in a new AI tool
Bottom line: Adoption of an AI tool is not an event you announce; it is a sequence of trust earned in order, and you cannot skip a rung. People move from knowing a tool exists, to understanding how it works, to verifying its output, to relying on it, to advocating for it — in that order. A mandate jumps straight to reliance and skips the three rungs of trust beneath it, which is precisely why mandated rollouts produce compliance on paper and abandonment in practice. You cannot mandate trust. You can only sequence the conditions that earn it.
The rollout email that kills the tool
The most common way to launch an internal AI tool is also the most reliable way to kill it: an all-hands email announcing that, effective Monday, everyone will use it. The logic seems sound — leadership has invested, the tool is good, usage is the goal, so mandate usage. The result is depressingly consistent. Logins spike, the dashboard turns green, leadership declares success, and within a quarter the tool is quietly abandoned by everyone whose work it was supposed to improve.
The mandate fails because it confuses the destination for the path. Reliance — people depending on the tool for real work — is the fourth rung of a ladder, and a mandate tries to legislate it into existence without building the three rungs underneath. You cannot order someone to trust a system whose workings they do not understand and whose output they have never been able to check. They will comply in the narrowest possible way — log in, generate the required artifact, ignore it — and route their real work around the tool, because trust was demanded rather than earned. The green dashboard measures the compliance, not the adoption, and the gap between the two is where the investment quietly dies.
A mandate can produce logins. It cannot produce trust — and only one of those is adoption.
Trust is earned in an order
The reason a mandate cannot shortcut to reliance is that trust in a tool, like trust in a person, accrues in a sequence. You do not depend on a colleague you have just met; you depend on one whose work you have seen, checked, and found sound over time. A new AI tool is a new colleague of uncertain competence, and the people best positioned to judge it — your most experienced staff — are rightly the most skeptical, because they can see failure modes a demo conceals. Their skepticism is not resistance to be overcome; it is judgment to be satisfied, in order.
Each step in the sequence is a precondition for the next. You cannot verify a tool you do not understand. You cannot rely on one you have not verified. You cannot advocate for one you do not rely on. Skip a step and the steps above it have nothing to stand on — which is exactly what a mandate does, and exactly why it collapses. The job of a rollout is not to demand the top of the ladder. It is to build each rung so the user can climb it themselves.
The Trust Ladder
The sequence has five rungs, and each one is the user speaking.
Exhibit 1. A mandate skips straight to reliance — rung four — and the three rungs of trust beneath it were never built.
Exposure: "I know this tool exists and what it is for." Understanding: "I see how it works and where its limits are." Verification: "I can check its output against what I already know." Reliance: "I depend on it for real work, with my judgment still engaged." Advocacy: "I bring it to my peers without being asked." The ladder is climbed from the bottom, by the user, over time — and the user's own words at each rung are the only honest measure of whether they have reached it. A login is not exposure if the person does not know what the tool is for. A mandate is not reliance if the person does not trust the output. The rungs cannot be faked from above, because they describe internal states, not observable compliance.
A mandate, mapped onto this ladder, is an instruction to stand on the fourth rung without having climbed the first three. Sometimes people will perform it — they will go through the motions of reliance — but performance is not the same as trust, and it does not survive the first time the tool is wrong and no one taught them how to catch it.
Every rung of the ladder is the user speaking. You cannot climb it on their behalf.
The design job at each rung
If trust cannot be mandated, it has to be designed — and each rung names a specific thing the user needs and a specific thing you must build to provide it.
Exhibit 2. Every rung is a design decision, not a memo. Skip the build and the user stops climbing.
For exposure, the user needs to encounter the tool in the flow of real work, so the design job is to put it where the work already happens rather than in a separate application they have to remember to visit. For understanding, they need to see how it works and where it is weak, so you show the reasoning, the sources, and the honest limits rather than presenting a confident black box. For verification, they need to check the output against their own expertise, so you make outputs inspectable and easy to confirm or refute. For reliance, they need to depend on the tool without surrendering their judgment, so you let them override it and keep them accountable and in control. And for advocacy, they need a reason to bring it to peers as their own discovery, so you surface their wins and let champions teach — because adoption spreads from a trusted peer far better than from a management directive. Every rung is a design decision, not a memo. Skip the build and the user simply stops climbing.
What this looks like on Monday
Set two rollouts of the same tool side by side in one organization. (This is an illustration, not an account of any specific engagement.)
Exhibit 3. One rollout demanded the top of the ladder; the other built it. Illustrative, not a client account.
The first rollout is mandated. It opens with an all-hands email: from Monday, everyone uses it. The experts are told to trust the tool and their doubts are overridden as resistance. Success is measured in logins and license seats, which duly climb. Six months later there is compliance on paper and the tool has been quietly abandoned by the people whose work it was meant to improve — because their doubts were never satisfied, only dismissed.
The second rollout is sequenced. It begins with a small pilot among the people most likely to benefit, who are invited to break the tool and whose doubts shape the next version rather than being argued away. Success is measured in unprompted use and voluntary advocacy. Six months later the tool is spreading by pull from peers, and its adoption outlives any mandate because no mandate was ever needed — the trust was built rung by rung.
Same tool. One rollout demanded the top of the ladder; the other built it. Only one tool is still in use by the end of the year.
Where this argument fails, and what it costs
The frame has limits worth stating.
Some tools genuinely should be mandated, and pretending otherwise is its own mistake. Where a tool is a safety or compliance requirement — where the cost of non-use falls on customers or the public, not just on the user — a mandate is appropriate, and the sequence becomes a way to make the mandate stick rather than a substitute for it. There is also a real tension with speed: sequencing trust is slower than issuing an order, and an organization under genuine time pressure may have to accept a shallower, faster adoption and rebuild trust afterward, knowing it is a trade. And not everyone climbs at the same rate — some laggards will never reach advocacy, and a rollout that waits for unanimous, organic enthusiasm will wait forever. The discipline is to sequence trust for the people whose adoption actually determines whether the tool delivers value, and to accept that the distribution will have a long tail.
That bounds the claim. Mandate what safety requires, trade sequencing for speed only with eyes open, and design for the users who matter rather than for unanimity. The point is not that mandates never have a place; it is that they cannot manufacture the trust that adoption is actually made of.
The decision
Before your next tool rollout, the move is concrete.
Stop planning the launch as an announcement and start planning it as a sequence. Map your rollout to the five rungs and ask, for each one, what you are building to help the user climb it — where they will first encounter the tool, how you will make its workings legible, how they will verify it, how they will rely on it without losing control, and how their wins will reach their peers. Begin with a pilot among the people most likely to benefit and most able to break it, and treat their skepticism as the specification for the next version. Measure unprompted use and voluntary advocacy, not logins. And resist the mandate, except where safety genuinely requires it.
You can buy a tool in an afternoon, but you cannot buy the trust that makes anyone use it. That has to be earned, in order, by the people who will depend on it. Sequence the rungs, design the climb, and let adoption spread by pull rather than push — because the alternative is a green dashboard sitting on top of a tool nobody trusts. This is the operational counterpart to the trust layer in the companion piece on judgment and the trust gate in the piece on why pilots never reach production: there, trust is named as the thing that decides the outcome; here is how you actually earn it.
Sources
- McKinsey — The State of AI (annual survey). Adoption and change-management among the leading determinants of whether AI investments capture value. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- Deloitte — State of Generative AI in the Enterprise (2024–2025). Workforce adoption, trust, and change management as recurring obstacles to scaling AI. https://www2.deloitte.com/
Bottom-line summary (one line)
Adoption is trust earned in a fixed order — exposure, understanding, verification, reliance, advocacy — so design a rollout that helps users climb each rung rather than mandating the top one, and measure unprompted use, not logins.
Suggested LinkedIn hooks (link back to the blog)
- The all-hands email announcing "from Monday, everyone uses the new AI tool" is the most reliable way to kill it. Here's why mandates produce compliance, not adoption. [link]
- You can't order someone to trust a tool whose output they've never been able to check. Trust is earned in an order — five rungs — and a mandate skips straight to the fourth. [link]
- The experts resisting your new AI tool aren't being difficult. Their skepticism is the specification for the next version. Treat it that way and adoption spreads by pull. [link]