The note says the file won’t open. The draft says the file is broken.
Picture a colleague using AI to turn rough internal problem notes into useful support requests. They stop at that sentence. The person who wrote the note guessed that the file was broken. Nobody has established the cause.
Your colleague keeps the reported problem and takes the certainty out of the explanation.
Small move. Useful move. And if you’re responsible for helping the team work better with AI, that’s a moment worth asking about.
“How did you know to stop there?”
The answer might tell you more about a method worth teaching than a tour of the newest buttons.
Who would you ask to teach this job?
When someone asks you to organize AI help for the team, it’s easy to think of the person who follows every tool update. They know the features. They can get everyone started.
That knowledge has a place. But look at the job in front of your team.
In our hypothetical, the job is writing an internal request that helps someone understand a problem. The team already has a standard: describe what happened, include the attempts you know about, keep an untested cause separate, and say what help you need.
Who can show you how they use AI to produce that kind of request?
Maybe it’s the person who knows all the tools. Maybe it’s a quieter colleague who has found an approach that serves this one job. You find out by looking at the work and asking about the choices.
Here’s the thing. You keep looking for someone to teach the tool while the person who can explain what makes the work useful has never been asked to teach their method.
Ethan Mollick connects job knowledge with useful AI discoveries in Making AI Work: Leadership, Lab, and Crowd. Our question is how to learn from a promising discovery inside a small team.
Years in the job don’t settle that question. Neither does confidence. A colleague earns your attention by showing something useful and helping you see how they got there.
The lesson is in what your colleague notices.
Ask them to show the important choice
Go back to the rough note.
“The shared planning file won’t open. I think it’s broken.”
Your colleague uses AI to organize the request, then compares the draft with what the person actually reported. When “I think” disappears, they notice that a guess has become a statement of fact.
They could show a simpler opening: “I can’t open the shared planning file. Could you help me work out what’s stopping it?”
That still needs whatever relevant details the person can supply. What happened when they tried? What have they already attempted? If the rough note doesn’t say, the colleague asks. They don’t fill the empty space with a made-up attempt or a confident cause.
In The Professional Recipe, Examples show what you meant by useful work. Here, the example gives your colleague something concrete to teach from. They can point to the words that changed the meaning and explain the correction.
“We know they couldn’t open it. We don’t know that the file is broken.”
Yeah. That’s the lesson inside the demonstration.
Ask what they look for before accepting a draft. Ask when they go back for more information. Let them show a place where their method needs help, too.
You’re looking for choices someone else could learn to make. The prompt may be part of the method. So may the source note, the checks afterward, and the questions the colleague asks before finishing.
One polished request doesn’t show all of that by itself. A willing colleague who can take you through it gives you a promising place to start.
Let the next input change the answer
Now bring in a peer who already handles this kind of internal request. Give them a different suitable practice note.
This time, the person says the file opens, but they can’t make a change.
That’s enough of a difference to matter. If the peer copies the demonstration’s “I can’t open the file,” the request no longer describes what this person reported.
They need to use the method on the new facts. What happened? What attempts are actually known? What is only a guess? What help is being requested?
There is no need to diagnose the software. The task is to write a useful account of the problem under the standard the team already uses.
This is where you learn something about the teaching.
Did the colleague make the important choice visible enough for the peer to apply it? Or did the demonstration leave the peer with a sentence to imitate?
Knowing the explanation is one thing. Actually. The next useful piece of evidence is the request the peer produces.
Look at that request against the existing standard. The peer can explain their choices while you read, but the work needs to hold the distinction too. A clear spoken explanation doesn’t fix a written request that says the wrong thing happened.
Help is part of what you need to see
The peer may ask a question during the attempt. Good. You want to know what the demonstration left unclear.
Perhaps they ask whether they should include the suspected cause at all. The originator can explain how they handle that under the existing standard. Then the peer continues.
That is useful teaching. Keep the clarification with the method so the next person can find it.
What you need to notice is the moment teaching turns into taking over. If the original colleague quietly rewrites the whole request, you have another example of their work. You haven’t yet seen the peer use the method.
Right? The finished request can look equally good either way. What happened around it changes what you can conclude.
Don’t turn this into a test of whether the peer can struggle silently. Let them ask for help. Just be honest about the help still needed when you decide what to share.
And give the person teaching a bounded job. Ask whether they’re willing, make time for the demonstration, and agree who will handle later corrections. Finding a useful teacher shouldn’t quietly give that person a second job answering everybody’s AI questions.
A promising method can have three next steps
Suppose the peer produces a request that fits the new note and meets the existing standard. That gives you a reason to keep trying the method in ordinary work and see whether it remains useful.
Suppose one part needs clarification. You now have something specific to improve in the teaching. Add that explanation and let the peer try it again.
Or suppose the method doesn’t help with this kind of request. Leave it aside for that job. The originator may have a useful approach in a different situation, or their own judgment may be doing more of the work than the demonstration made visible.
None of those outcomes is established by our example. They’re the possibilities you need to leave open when you try this with your team.
Here’s the thing. You can recognize a colleague’s contribution without declaring their method the company standard after one attempt.
You can also decide there isn’t a suitable method to share yet. The title is an invitation to look inside the business, not a guarantee that your ideal teacher is already waiting there.
Does that make sense? The aim is to find useful teaching, not to crown an AI champion.
Your Monday Move
Pick one routine internal job and ask a willing colleague to show a potentially useful AI method for it. Start with work you can already recognize as usable under the team’s normal standard.
Have them show the input, the result, and one or two choices that made a difference. Use material the people and tools involved are already allowed to see. A non-sensitive practice example can do the job.
Then let a peer who does comparable work attempt a different suitable input. Keep the help visible. Look at the resulting work, not just whether everyone liked the demonstration.
Choose one next step: continue trying it, clarify the method, or leave it aside for this job. Note that decision where the team already keeps useful methods, with credit to the person who contributed it.
You don’t need to plan a whole training program to begin. You need to find one colleague whose choices are worth learning from, then see whether the lesson helps someone else do the work.
The lesson is in what your colleague notices.
Inspired by Ethan Mollick’s Making AI Work: Leadership, Lab, and Crowd. Operator application by Reu.
~ source material · Inspired by Ethan Mollick's Making AI Work: Leadership, Lab, and Crowd. Operator application by Reu.
