Dimension 4 of 6
Education & Enablement
Version 0.1. This framework is actively being refined based on real conversations and use. If you have feedback, please send it to hilary@hilarymason.me.
Part of the AI Adoption Readiness framework.
4 min read
What this is really about
Most organizations treat AI training like software training. They focus on the generic how-to: how to write a prompt, how to use the tool, how to access the feature. That information is usually already in the documentation. It's not where people actually get stuck.
The harder, more important question is "how do we use this here?" That's the gap most training programs don't close. People walk away knowing how the tool works in isolation, but not how it fits into the systems, workflows, and decisions that make up their actual job. So they either don't use it, or they use it in ways that quietly create new problems.
Real enablement is about helping people understand both the foundations and the specific use cases tied to their role. It's about answering: where does this tool fit into the system we already have? What should I be saving where? Whose data am I touching, and what does that affect downstream? When does my judgment need to override what the tool is telling me?
If your enablement doesn't answer those questions, it's not really enablement. It's product documentation in a slideshow.
What weak strategic clarity actually looks like
It rarely looks like "nobody got trained." Usually it looks like one of these:
- Training focused on how the tool works in general, with no connection to how the org actually uses it.
- People are using AI in their workflows but saving outputs to personal drives, breaking the data hygiene the org is trying to build.
- A team built a new dashboard because the existing source of truth wasn't being updated, but the new dashboard pulls from the same un-updated source. The visualization is better. The underlying data is still wrong.
- Different teams interpret the same AI output differently because nobody aligned on what it should mean for their specific function.
- Power users emerge organically and become the de facto support team, which is unsustainable and leaves gaps.
If any of these are familiar, your score here is lower than it looks.
Where to actually start
Separate foundational training from role-specific enablement.
Everyone needs a baseline (what the tool is, how to use it well, what its limitations are). Don't skip this, but don't stop here either. The real work begins once people have the foundation.
Map enablement to actual workflows, not job titles.
A finance lead, a customer success rep, and a designer might all need to use the same AI tool, but they're using it on different data, for different decisions, with different downstream consequences. Build role-specific enablement around what they actually do, not what they're called.
Tie enablement to the system, not the tool.
If your org has agreed that documentation lives in a specific drive folder, or that certain workflows pull from a specific source of truth, that context needs to be inside the training. Otherwise people use AI tools in ways that break the system you're trying to build.
Identify the moments of judgment.
For each role and use case, where do people need to override or question what AI is producing? Make those moments explicit in the training so they don't get lost.
Signals you're getting somewhere
- People can explain not just how to use the tool, but how it fits into their team's workflows and the org's broader system.
- The same use case is being handled consistently across teams that should be aligned.
- Power users are formalized, not just tolerated. There are clear paths for asking questions and surfacing edge cases.
- People are saving outputs to shared, structured spaces by default, not to their personal drives.
- When someone notices the AI is producing something wrong or off, they know what to do about it.
What I'd watch out for
- Confusing access with enablement. Giving everyone a license doesn't mean they know how to use it well. Access without enablement creates risk faster than it creates value.
- Training that ends at the tool's edge. Generic "how to write a great prompt" sessions help, but they don't address the most important question: how this fits into our work.
- The shiny new dashboard problem. A team builds a beautiful new AI-augmented dashboard because the existing one wasn't being maintained. Now you have two unmaintained dashboards instead of one, and the underlying data hygiene problem is still there. The interface improved. The system didn't.
How this connects to the rest
Education & Enablement depends on Operating Model Fit, because you can only enable people on workflows that have actually been mapped and documented. And it deeply depends on Data & Infrastructure Readiness, because enablement on top of bad data just teaches people to trust outputs they shouldn't.
It also connects upstream to Change Capacity. If people don't have the time, space, or psychological safety to learn, even good enablement won't land. The training will exist. The behavior change won't.