In this article
This is a different problem from encouraging initial experimentation. The challenge is turning one person's useful method into something another person can use responsibly.
Treat AI adoption as transfer of a practice
Share the complete method rather than a screenshot or an impressive prompt. People need to understand the task boundary and how to recognise an unacceptable result.
Microsoft's article on the ripple effect of AI discusses how use can influence colleagues. Peak Belt's recommendation is to focus that spread on reproducible work rather than enthusiasm alone.
In a hypothetical purchasing team, an analyst uses AI to organise approved supplier notes. Colleagues want the same result, but the analyst quietly repairs product codes before every run. Sharing only the prompt hides an essential step.
Document that preparation and decide whether it belongs in the shared procedure.
Create a compact experiment handoff
Give the next user enough information to try the method and judge it. Keep the handoff small enough that they will actually read it.
Include:
- The problem and intended user.
- Approved inputs and information that must stay out.
- The instructions or template.
- A sample input and a checked sample output.
- The review checklist and a known failure.
- The person to contact when the task falls outside scope.
Use synthetic or authorised examples. A convincing demonstration does not justify sharing confidential customer or employee information.
Label the method as a pilot until the organisation's approval process says otherwise. A colleague's successful experiment is not automatically an approved team standard.
Run the second-user test
Ask a colleague to follow the written method without coaching them through every step. Observe where they hesitate, make assumptions or need missing information.
In the hypothetical purchasing example, the colleague may not know which supplier notes are approved or what counts as an unresolved issue. Those gaps belong in the documentation, not in a judgement about their ability.
After the attempt, compare the result against agreed criteria. Ask what the person checked and what they assumed the tool had checked.
If the workflow succeeds only when its creator supervises every decision, it is not yet ready to spread widely.
Adapt without losing the important controls
Different teams may need different formats, but some requirements should remain stable. Separate flexible presentation choices from essential accuracy, information and approval boundaries.
For example, a field team might prefer a short checklist while a central team needs a table. Both still need unresolved issues preserved and source facts distinguished from suggestions.
Keep a version note explaining the change and its reason. Untracked copies can drift until no one knows which instructions reflect the current practice.
Microsoft's current Copilot overview describes differences between experiences. When colleagues have different access, test the method in the environment they will actually use.
Share failures in a useful form
Describe the circumstances, the output problem and the corrective action. Avoid vague warnings such as “AI sometimes gets things wrong,” which do not teach the next user what to inspect.
A useful note might say: “When the notes contain two delivery dates, the draft may choose one. The reviewer must flag the conflict and ask the owner to resolve it.”
Invite reports of checking effort and abandoned attempts. If only positive demonstrations receive attention, the shared evidence becomes misleading.
Decide what belongs in a shared library
Include methods that have a clear purpose, approved information boundary and a checked example. Keep exploratory conversations in a separate area so colleagues do not mistake them for endorsed procedures.
For each shared method, show its owner, status and review date. A short label such as “pilot for draft internal summaries” is more useful than “best AI prompt,” which obscures where it should and should not be used.
Archive superseded versions through your organisation's normal process. If a colleague has saved a local copy, tell them what changed and why; silently replacing the central file may leave outdated instructions in everyday use.
Use feedback to improve the library rather than simply make it larger. If several people cannot reproduce a result, the method needs clarification or a narrower scope. If a method is never used, investigate whether the underlying task still matters.
The shared collection should reduce uncertainty, not become another folder employees must search to discover which advice is current. A handful of maintained workflows can be more useful than hundreds of disconnected prompts with unknown provenance.
Expand only when support is available
Before another team adopts the method, identify who maintains it and answers questions. An unsupported pilot can become a burden for the enthusiastic person who first shared it.
Schedule a review of whether the method still serves the original problem. Retire it if changes in policy, tools or work make it unsuitable.
Choose one promising experiment and prepare its compact handoff. The next milestone is a successful second-user test, not an organisation-wide announcement.
Explore PiOfAI, the AI procedure guide and leading change for the operational and human parts of adoption.
AI-assisted researched guidance from PeakBelt. Hypothetical examples are labelled in the text. See our editorial approach.