“You can’t command people to play with something. Play has to be allowed.” — Kasimir Husain (paraphrased, Dec 2025 session)
Session context: 2025-12-05_Mastermind — Kasimir’s observation during a discussion about why well-resourced AI rollouts inside organizations often produce low sustained adoption despite significant investment.
Core Idea
The pattern is consistent across organizations that have tried to accelerate AI adoption: mandate → surface compliance → silent reversion. Leaders buy the tools, run the training, set the expectation — and 90 days later, most employees are using AI for the same narrow tasks they started with, or not at all. The investment didn’t land.
The diagnostic is not about tool quality, training quality, or employee capability. It’s about what mandate does to intrinsic motivation. When AI adoption is mandatory, it activates compliance psychology: employees learn the minimum needed to pass the check, associate the tool with obligation rather than possibility, and stop experimenting the moment the oversight pressure relaxes. Compliance is the enemy of exploration, and exploration is required for AI to become genuinely useful.
Participatory adoption works through a different mechanism: curiosity + permission + a safe place to fail. When employees are given unstructured time to explore without being evaluated on outcomes, two things happen. First, individuals who are naturally curious discover use cases that management would never have mandated — often the highest-value use cases in the organization. Second, peer-to-peer sharing of discovered use cases is dramatically more persuasive than top-down instruction. “Watch what I did with this” converts more skeptics in five minutes than a full training day.
The coaching insight for leaders: your job is not to drive adoption. It is to create the conditions in which adoption emerges. This means scheduled unstructured time, explicit permission to experiment with work processes, and visible curiosity modeling from the leader (see Insight - The Leadership AI Transparency Trap — Hiding AI Use From Your Own Team).
Practical Application
The Permission Architecture — a three-part framework for leaders rolling out AI adoption:
- Schedule play time: designate 30 minutes per week per person as unstructured AI exploration — no deliverable, no report-out, no KPI. Call it what it is. Protect it from being reclaimed for “real work.”
- Create a sharing ritual: a lightweight weekly or biweekly channel, standup slot, or async post where anyone can share one thing they tried — worked or not. The norm is curiosity, not success.
- Model from the top: the leader shares their own experiments — including failures. “I tried to use AI to prep for the board meeting. It was useful for structuring my thinking, but it hallucinated two data points and I caught them at the last minute. Here’s what I’d do differently.” This signals that the learning curve is real, visible, and not a performance review concern.
Related Insights
- Insight - AI Adoption Requires Both Top-Down Vision and Bottom-Up Permission — this insight is the operational mechanism that makes bottom-up permission real; top-down can enable it but can’t substitute for it
- Insight - The Leadership AI Transparency Trap — Hiding AI Use From Your Own Team — leaders who hide their AI use are modeling concealment, not curiosity; it prevents the participatory mechanism from activating
- Insight - The Leadership AI Transparency Trap — Hiding AI Use From Your Own Team — leaders who conceal AI use are actively modeling the opposite of participatory adoption; transparency is a precondition for the mechanism to activate
- Insight - The AI Paralysis Triad — Fear, Doubt, and Overwhelm as Compounding Blockers — play time and peer sharing are structural interventions for the overwhelm element of the triad; they reduce the activation energy required to start
Evolution Across Sessions
This establishes the baseline for the participation-first AI adoption model. Future sessions should test whether this framework holds across organizational sizes and cultures, and whether any members have implemented the permission architecture with their own clients.