I have seen a recurring pattern in how organizations approach AI.
A team discovers a new model or tool. Someone demonstrates what it can do. A workshop is scheduled. Documentation is published. People are encouraged to experiment.
Then, a few weeks later, the excitement can be gone while the work is largely unchanged.
I have seen this described as an adoption problem, followed by calls for more training, better communication, or a more capable tool. Those things can help, but they do not necessarily change how the work itself happens.
One common missing layer is workflow design.
In the durable cases I have seen, people did not adopt a new system simply because it was impressive. They adopted it when it helped them complete work they already needed to do, with less friction and enough confidence to use it repeatedly.
That changes the question from:
How do we teach people to use AI?
to:
How do we redesign a recurring piece of work so that AI makes it meaningfully better?
This distinction has shaped how I think about AI-native environments. My interest is not limited to building tools. I care about the conditions that help useful tools spread: identifying real pain, creating clear ownership, making contribution easy, connecting new workflows to existing work, and measuring whether behavior actually changes.
Why training alone rarely changes the work
Training is useful when someone already has a reason to use a tool. It can reduce uncertainty, demonstrate possibilities, and help people get through a first experience.
But training has limits.
First, it often asks people to add a new activity to an already full schedule. A workshop may be interesting, but the participant still has to find time to translate the lesson into their actual work.
Second, training tends to begin with the capabilities of the tool rather than the needs of the user. The conversation becomes a tour of features: prompting, agents, retrieval, automation, or integrations. The participant leaves knowing more about the tool, but not necessarily knowing which recurring problem it should solve.
Third, training creates visibility without necessarily creating ownership. Someone may be excited during a demonstration, but who is responsible for improving the workflow after the first attempt? Who fixes it when the output is incomplete? Who decides whether it is safe and useful enough to continue?
Finally, training often rewards attention rather than durability. A successful session is measured by attendance, satisfaction, or the quality of the demo. Those measures are not useless, but they are weak signals of whether the tool has become part of daily work.
The real test comes later.
Does someone use the workflow again next week? Does it survive when the original champion is unavailable? Does it reduce a manual step? Does another person adapt it for a similar problem?
These are workflow questions, not training questions.
From push to pull
I have found it useful to distinguish between push adoption and pull adoption.
Push adoption starts with a tool or capability. The organization teaches people about it and hopes that interest turns into usage.
Pull adoption starts with a validated problem. The organization looks for recurring pain, builds a solution around that pain, and creates the conditions for the solution to become part of existing work.
The difference is not subtle.
A push approach says:
Here is a powerful new capability. Find a use for it.
A pull approach says:
Here is a recurring problem that costs time or quality. Can AI help us remove part of the burden?
The second question is narrower, but that is its strength. It gives the team a concrete outcome to evaluate.
A pull approach also changes what counts as a good idea. The most interesting idea is not necessarily the best candidate. The best candidate may be a mundane task that happens frequently, has a clear owner, and creates enough friction that people are motivated to change it.
Good opportunities often come from work such as preparing recurring reports, investigating metrics, drafting routine analyses, reviewing experiment results, or translating a specialized process into something a broader group can use.
The goal is not to make every task autonomous. It is to identify where an AI-assisted workflow can reliably remove unnecessary effort while preserving human judgment where it matters.
Start with pain discovery
Before building, I want to understand the work as it exists today.
That means talking to the people who perform it, observing where the process slows down, and asking questions that reveal behavior rather than aspiration:
- What do you repeat every week?
- Which part requires the most manual preparation?
- Where do you copy information between systems?
- What do you postpone because it is tedious?
- Where do you rely on a small number of experts?
- What would you stop doing if the result were trustworthy enough?
These conversations are more useful when they focus on concrete recent examples. People are generally poor at predicting how they will use a new tool, but they can describe the last time a recurring task caused frustration.
I also like the idea of a pre-commitment. If someone identifies a problem, would they be willing to try a first version when it exists?
This does not guarantee adoption. It does create accountability. The person is not merely expressing general interest. They are saying that the problem is important enough to revisit.
Pain discovery should produce a small set of specific, high-frequency problems. If the list contains dozens of broad opportunities, the discovery phase has probably not gone far enough.
Build the first useful workflow
The first version should be small enough to try and useful enough to matter.
That usually means starting with one recurring task, one clear user, and one visible outcome. Avoid designing a complete platform before anyone has experienced the workflow.
A first version might help someone prepare a recurring analysis, gather relevant context, identify missing inputs, or produce a structured starting point for review. It does not need to remove every manual step. It needs to make the next attempt easier and better.
There is an important difference between a prototype and a workflow.
A prototype demonstrates possibility. A workflow has an owner, inputs, outputs, expectations, and a place in the calendar.
That means the first useful version should answer practical questions:
- What triggers the workflow?
- What information does it need?
- What does it produce?
- What must a person verify?
- How long should it take?
- Where does the result go?
- What happens when the input is incomplete?
- Who improves it after observing a failure?
These details may appear less exciting than a demo, but they determine whether the system can survive contact with real work.
Make contribution possible for everyone
An AI-native environment should not assume that every contributor is comfortable with code, repositories, command-line tools, or configuration.
There should be more than one contribution path.
A technical contributor may create a reusable workflow directly. A nontechnical contributor may submit a description of a recurring task, provide examples of good and bad outputs, or document the context an assistant needs to understand.
Both forms of contribution are valuable.
A useful contribution system should make it easy to answer:
- What problem does this workflow solve?
- Who is it for?
- What inputs does it require?
- What does a successful output look like?
- What are its known limitations?
- Who owns the next improvement?
- Is it ready for reuse, still experimental, or incomplete?
Incomplete work should be allowed, as long as its maturity is clear. A half-built workflow can be valuable when it gives someone else a starting point. The danger is not incompleteness. The danger is ambiguity.
People should know whether they are using a finished workflow, a pilot, or an idea that still needs testing.
This is also where attribution matters. Contributors are more likely to share useful practices when their work remains recognizable and when the system makes it clear how an idea was adapted.
The contribution path should reduce friction without hiding responsibility.
Keep ownership close to the work
Centralization is attractive because it promises consistency. One team maintains the library, approves changes, and decides what becomes official.
That model can work for a small, stable system. It becomes difficult when workflows depend on rapidly changing local knowledge.
The people closest to a task usually understand its exceptions, terminology, and failure modes better than a distant central owner. They are also more likely to notice when a workflow stops reflecting reality.
For that reason, I prefer a model where ownership stays close to the team doing the work, while the broader system provides shared conventions, discovery, and support.
This does not mean every team builds an isolated solution. It means local owners can improve their workflows without waiting for a central group to understand every detail.
The shared layer should make it easier to find, compare, reuse, and adapt useful patterns. It should not become a bottleneck that prevents iteration.
There is a useful balance here:
- Shared standards create clarity.
- Local ownership creates responsiveness.
- Lightweight review creates trust.
- Visible attribution creates participation.
Integrate into recurring work
A workflow becomes durable when it is connected to something the team already does.
If a new AI system requires people to remember a separate destination, schedule a separate session, or maintain a separate process, it is competing with existing habits.
Integration is more powerful than novelty.
A workflow embedded in recurring planning, reporting, experiment review, or metric investigation has a natural trigger. People do not need to invent a reason to use it. The work itself creates the reason.
This also makes value easier to evaluate. Instead of asking whether people like a tool, we can ask whether a recurring process became faster, clearer, or more reliable.
The integration does not need to be perfect at the beginning. It needs to be visible and repeatable.
One practical approach is to identify the existing artifact that the workflow should improve. That might be a report, a planning document, an analysis template, or a review meeting. Then design the AI-assisted step around that artifact rather than creating a new destination.
The closer the workflow is to the existing object of work, the less behavior change is required.
Measure habits, not excitement
Usage counts alone can be misleading.
A tool can receive many trial interactions and still fail to become part of anyone’s process. A demo can generate enthusiasm without producing a single eliminated task.
I prefer to measure adoption as a progression:
- Someone agrees that the problem matters.
- They try the workflow on a real task.
- They return to it without direct support.
- Another person can use or adapt it.
- The workflow becomes part of recurring work.
- A manual step is reduced or eliminated.
Repeated behavior is stronger evidence than initial interest.
A simple habit test can ask whether several people use the workflow repeatedly over multiple weeks without requiring constant assistance. The exact threshold will depend on the context. The principle is more important than the number: adoption should demonstrate durability, not just novelty.
Quality gates are also important. Repeatedly producing an unreliable result is not success. A workflow should meet a minimum standard for usefulness, correctness, and human review.
The most meaningful outcomes may include:
- A task no longer needs to be performed manually.
- A recurring process takes less preparation time.
- A workflow is adapted by another team.
- A person with less specialized knowledge can complete the task.
- An expert spends more time on judgment and less time on assembly.
- The team can identify and correct failures more quickly.
These measures connect AI adoption to work rather than to tool activity.
Design for failure and exit
Not every workflow should survive.
Some ideas will fail because the problem was not painful enough. Others will fail because the workflow requires too much setup, depends on unavailable context, or cannot produce results people trust.
A healthy adoption system makes failure visible early.
Before scaling an experiment, define what evidence would justify continuing. Also define what would trigger a redesign, a narrower scope, or an intentional sunset.
This protects teams from a common trap: continuing to invest in a weak workflow because effort has already been spent on it.
An exit criterion can be simple:
- No repeated use after the initial trial.
- No clear improvement over the current process.
- Too much support required for each run.
- No owner willing to maintain it.
- Inputs or outputs are too inconsistent to trust.
Sunsetting a workflow is not necessarily a failure of the people who built it. It is part of learning which problems are worth solving and which designs fit the environment.
The same system that helps successful workflows spread should help unsuccessful ones stop consuming attention.
The Pain to Practice framework
I think about reusable AI adoption as a path from pain to practice:
Observed pain → Pre-commitment → Small workflow → Reusable skill → Local owner → Existing-workflow integration → Repeated use → Task eliminated
Each step answers a different question.
- Observed pain: Is this a real and recurring problem?
- Pre-commitment: Is someone willing to try a solution?
- Small workflow: Can we create value without building a large system?
- Reusable skill: Can the approach be documented and adapted?
- Local owner: Who will improve it when reality changes?
- Existing-workflow integration: Where does it belong in the current process?
- Repeated use: Does behavior continue without constant support?
- Task eliminated: Did the work become meaningfully better?
The framework should include two feedback loops.
The first runs from repeated use back to workflow refinement. Real use reveals missing context, edge cases, and opportunities for improvement.
The second runs from failure to redesign or sunset. If a workflow does not earn repeated use, the system should make it easy to learn from the attempt and move on.
The role of an AI-native advocate
This is why I distinguish between being a builder and being an advocate.
A builder creates the product, workflow, or system. An advocate helps an organization develop the conditions in which those systems can become useful and durable.
That work includes language, incentives, ownership, measurement, and culture. It means making the case for small experiments while also being disciplined about evidence. It means helping teams see that AI adoption is not a one-time launch. It is a process of changing how work gets done.
The most important question is not whether an organization has access to powerful AI.
It is whether people can turn that capability into repeatable practice.
When adoption starts with real pain, stays close to the work, gives people a clear way to contribute, and rewards durable improvement, AI becomes less like another tool to learn and more like a new layer of how the organization operates.