People
Training your team to work with an AI employee
Tobiloba Odejinmi · 9 Apr 2026 · 6 min · 913 words
Direct answer
Train the team on the loop, not the model. Show them what a finished case looks like, what an escalation looks like, and what they are not allowed to wave through. The first week of live review is the curriculum. A slide deck about “working with AI” will not survive contact with a real queue.
- Teach review and escalation before you teach prompting.
- The first live week is training. Budget time for it.
- Rubber-stamping is the failure mode, not refusal to adopt.
- A short written standard beats a workshop people forget.
Skip the prompt workshop
Most “AI training” I have sat through is a tour of a chat box. People learn to ask nicer questions. Then they go back to a queue that still needs judgment. That is not training for an AI employee. That is a product demo with sandwiches.
The skill you need is closer to supervising a junior hire. What is in scope. What must come back. What “done” looks like. What you never sign without looking. If the team cannot do those four things, the model’s fluency will make them faster at being wrong.
Teach review, not cheerleading
Adoption is the wrong success metric in week one. I would rather a reviewer send ten cases back than wave twenty through because leadership asked for a usage chart. Cheerleading creates rubber stamps. Rubber stamps create silent misses.
At SmartComply the win was not that people “used AI.” Review time dropped by about half because the first pass came back in a shape we could check. The people still had to look. Training was: here is the shape, here are the fields that lie, here is when you stop and ask a person. That is a one-page standard, not a certificate.
The first week is the curriculum
Put the owner next to the reviewers for five working days. Use real tickets, real CVs, real follow-ups. Pause on the ugly ones. Write down the rule you just invented so you do not invent it again on Thursday.
This is slower than a launch email. It is also the only week you get before habits set. After that, people will either treat the system as a colleague they supervise, or as a printer they do not read. There is not much middle.
- A sample of ten cases, including two you know are messy.
- A shared note of what got sent back, and why.
- One person who can say “stop” without a meeting.
- No volume target until the send-back reasons repeat.
What “good” looks like in a queue
Good is not speed on day one. Good is a reviewer who can explain a change in one sentence. Good is an escalation that arrives with the payload still attached, not a screenshot. Good is a person who will hold a case when the system sounds confident and the facts do not.
Write three examples. One clean pass. One edit. One send-back. Pin them where the queue lives. When someone new joins, they read those three before they touch a live case. That is the whole onboarding I want. Anything longer is usually a slide that will not be opened again.
The failure mode is rubber-stamping
Teams rarely refuse the tool out loud. They accept the output because the queue is long and the prose looks finished. That is how you get a hiring screen that ranked on the wrong field, or a support note that promised a refund nobody approved.
Watch for review time collapsing to a few seconds. Watch for identical approval notes. Watch for escalations that never happen. Those are training problems. They are also design problems if the system makes “accept” one click and “send back” a form. Make the honest path the easy one.
A practice loop you can keep
Once a week, pull five cases the system marked done. Read them as if a customer will. If two are thin, the owner tightens the standard or the scope. That meeting should be short. If it becomes a debate about models, you have left the work.
BCG’s 2026 research keeps repeating that value shows up when the way people work changes. Training is that change, done on purpose. You are not asking the team to become prompt engineers. You are asking them to keep their judgment after a fluent draft arrives.
Questions people ask
Do people need to learn prompting?
A little, if they edit drafts. Most of the team needs to learn how to judge output and send work back. That skill matters more than writing a clever prompt.
How long does training take?
Plan a few hours before go-live and a full week of paired review after. If you cannot spare the week, you cannot spare the workflow. The team will invent their own habits, and those habits are usually “accept and move on.”
What if the team is afraid it will replace them?
Say what the system will take and what it will not. Then keep a person on the exceptions. Vague reassurance is how you get quiet resistance and quiet rubber-stamping at the same time.
Should we train everyone?
Train the people who will see the queue. A company-wide town hall is optional. The five people who will clear escalations are not.
What does good review look like?
They can say what they checked, what they changed, and why they sent a case back. If the only note is “looks good,” they are not reviewing. They are clearing a list.
Written by
Tobiloba Odejinmi
Head of Engineering at 10mg Health. I have run engineering at Zeeh Africa and sold Insurpass and Shopl. I still write the code. If you have one process that still runs on people copying things, we can look at it in thirty minutes.
