A weekly AI adoption routine for managers

A manager can support AI adoption with a short, recurring review of real work. Bring one recent example to an existing team meeting, examine the result and the checking it needed, then agree what someone will do before the next attempt. Follow up on that action at the next review.

Start with a weekly slot if the work repeats often enough to produce something worth discussing. The point is to make useful learning part of the team's routine. If the task happens monthly, or nothing has changed since the last discussion, adjust the cadence.

This article gives you an agenda to try. For a broader conversation about access, skills, workload or concerns, use the guide to helping people adopt AI at work.

Prepare one example people can learn from

Ask a colleague to bring an ordinary piece of work they have recently tried with an approved AI tool. A draft that needed substantial correction can teach the team as much as a polished success. Choose something other participants recognize and might need to do themselves.

Keep preparation light. You need enough context to understand the attempt, not a slide deck or a live demonstration that must go perfectly. Ask the person to bring:

• The task and its standard. What were they trying to finish, and how would they judge an acceptable result?
• An approved example. Show the relevant input and output, or a safe summary when the original material cannot be shared with this group.
• The checking and corrections. What did they verify, change or discard before using the result?
• One question for colleagues. What remains uncertain, awkward or worth trying differently?

Check that the material is appropriate for the meeting's audience. A team learning session does not change who is allowed to see customer information or internal records. If the example cannot be shared safely, choose another one.

There is a useful research basis for reviewing a specific attempt. Tannenbaum and Cerasoli's meta-analysis of debriefs found performance benefits across 46 samples involving 2,136 participants. Its definition emphasized reflection on a particular event, active participation, multiple information sources and a developmental purpose. The studies covered varied work and simulation settings, not this AI routine. They support learning from an experience together, without establishing an ideal weekly schedule or promising a particular gain for your team.

Try this agenda in an existing meeting

Start with a 15-minute timebox and one example. The timings below are a proposed starting point you can change. Keep a longer technical investigation outside the meeting and invite only the people needed for it.

Close the follow-up with a result or a named dependency that still needs attention. The walkthrough should leave a shared understanding of what worked and what required judgment. Finish with one change worth testing, or a reason to stop the use, and agree where the learning will be kept.

At the first meeting, use the opening two minutes to agree on the purpose and choose the task. In later meetings, start by closing the previous action. Otherwise a recurring discussion can keep producing suggestions without resolving any of them.

During the walkthrough, ask to see the point where human judgment mattered:

• Did someone catch an incorrect statement?
• Did the output omit a condition the customer needed?
• Did a colleague have to reconstruct the context before they could use it?

The answer tells the team more than a prompt alone.

Include the work after generation. A fast first draft is only part of the task. The strategy guide's measurement section explains why checking and rework belong in the assessment.

Microsoft describes a related practice in its own sales organization. In a September 2026 account, Kathleen Hogan reports that the team mapped account managers' work and used weekly peer-led huddles to share practices. That is a vendor's account of its own programme, with several changes happening together. It illustrates a way to organize learning; it does not show that a weekly meeting alone caused the reported business results.

Make unfinished work welcome

A review needs an honest account of the attempt. If every example must demonstrate impressive savings, employees have little reason to bring the awkward result that took longer to fix.

You can set the tone with something you tried yourself. Explain what you checked and what you still do not know. Then ask the person presenting what they would change, before offering your own answer. You do not need to be the team's most advanced AI user to keep the discussion specific and follow through on a decision.

In a public r/EngineeringManagers discussion, one Reddit user described a weekly internal demo at a previous job. They felt that keeping it low stakes helped engineers get started. A reply described a limitation of a similar arrangement.

The two accounts point to questions worth asking in your own team:

• Is the example relevant to the people who rarely attend?
• Can they contribute a question without presenting?
• Does the meeting fit their working hours?

A recurring audience tells you whom the session is reaching, but it does not explain everyone else's needs.

Offer a way to send an example or question beforehand. Invite the person who checks the output, not only the person who generated it. Save a short, usable note for colleagues who were absent. Keep sensitive individual concerns in a private conversation rather than making someone explain them to the group.

Follow through between reviews

The manager's most useful action may happen after the meeting. A colleague can improve a prompt, but they may need you to resolve a priority, find an appropriate reviewer or take an access question to its owner.

When the action needs extra practice or review, agree how that time fits alongside delivery. Name the work that changes and its approver.

Keep the follow-up small enough that you will use it. Record the task, the lesson, the next action, its owner and the point when you will review it. Link to the approved example where colleagues already look for help. Avoid creating a second reporting system just to prove that the meeting happened.

When a review changes a recurring working rule, record it in the team AI agreement so colleagues can find the expectation between meetings.

When an action depends on another team, name who will pursue the answer and when you will check back. Do not ask the employee to repeat a blocked experiment every week. The parent guide's discussion of matching support to the obstacle can help identify the decision owner.

Check whether the routine earns its time

After a few meaningful repetitions, review the meeting itself. Look for evidence you can inspect:

• Actions close. The team can say what happened to the changes it agreed.
• Examples travel. A colleague can find a useful note and apply it to a similar task, with the necessary checks.
• Problems become clearer. Repeated difficulty leads to a decision, an escalation or stopping an unsuitable use.
• Participation is useful. People can contribute questions and corrections without needing a polished success story.

Use those observations to decide whether to keep or change the routine. If the meeting mostly repeats announcements, send those in writing. If the task has not recurred, move the review. If colleagues need hands-on help, arrange that support rather than stretching a short discussion into a training session.

For your next meeting, choose one shareable attempt and tell the contributor which question you want to understand. Leave with an action you can return to. That is enough to begin testing whether this routine helps your team.

Questions about a manager's AI adoption routine

Does the review have to happen every week?

No. A weekly AI review is a starting option for teams whose work produces a useful new example that often. Choose a review point after the task has been attempted again or when someone can make a decision about an unresolved problem. A monthly task may need a monthly review, while an unchanged access dependency may need follow-up with its owner rather than another team discussion.

Keep the agenda tied to something the team can inspect: the previous action, a new output and its checks, or a decision about what changes next. The suggested 15-minute agenda is adjustable. After a few repetitions, use the routine review criteria to decide whether the meeting is earning its time.

What if the manager knows less about AI than the team?

A manager does not need to be the team's most advanced AI user to run a useful review. Ask what the colleague was trying to finish, what an acceptable result requires, and how they checked the output. Let colleagues explain tool-specific choices and involve a specialist when the question exceeds the group's knowledge. Do not treat confidence with a tool as proof that its result is correct.

The manager still needs to resolve priorities, arrange suitable support and follow through on decisions within their authority. For example, a customer-service manager can ensure someone checks a proposed delivery date against the carrier record even if a colleague knows more about writing AI instructions. Use the preparation questions to keep the discussion grounded in the work, and name the follow-up owner for anything the group cannot resolve.

What if nobody has an example to share?

Find out why before assigning a presentation. The team may have no suitable recurring task, no approved access, no time to practise or uncertainty about which material can be shared. An AI review should help resolve those conditions; it should not create pressure to manufacture a success story. An unsuccessful attempt can be useful if the team can safely inspect what happened.

If colleagues need help identifying work to try, use the AI use-case discovery worksheet. If they have a task but cannot attempt it, use the obstacle and support guide to identify the person who can help. Choose a small approved attempt together when that is appropriate, or move the review until there is something meaningful to discuss.

What should the team record?

Record the task, what the team learned, the next action, its owner and when the result will be reviewed. Link to an approved example if colleagues are allowed to see it. Include enough context for someone who missed the meeting to understand the change and the checking still required; a saved prompt on its own may not explain either.

For the furniture-delivery reply example, the note would explain that the draft promised an unconfirmed date, identify the revised instruction to test, and name the supervisor who will check the next draft against the order and carrier records. Keep private concerns and unnecessary personal information out of the shared note. Save it where colleagues already look for help, rather than creating a separate reporting system for the meeting.