AI for Managers: Lead Teams Using AI Without Losing Control

Speed, comparison and the finished deliverable were the three signals managers judged performance by, and AI weakened all three at once.

Speed no longer separates effort from tooling. Comparison breaks when one person uses AI heavily and another does not. And the deliverable, the thing you actually see, is the artefact AI improves most. This lecture works through what each signal used to tell you and what it now tells you, using examples from ordinary knowledge work. You will look at what evidence still says something real about how a person works, and why evaluating AI-assisted output fairly means looking at process rather than polish. This is not about distrusting your team. It is about noticing that the instruments you rely on for performance management have quietly lost accuracy, so you stop depending on readings they can no longer give.

AI errors are dangerous precisely because they do not look like errors, which is why ordinary review misses them.

A hallucinated statistic, a fabricated citation, or a confidently wrong summary arrives in fluent, well-structured prose that passes the scan most reviewers give it. Review evolved to catch sloppiness, and this output is not sloppy. This lecture looks at where these errors typically enter, what happens when nobody verifies a number before it moves onward, and why an accountability gap opens as soon as nobody can say who checked what. It covers quality control and reviewing AI work as a management responsibility rather than a personal habit, including what to do when you cannot verify everything your team produces yourself. The aim is not fear, but knowing which risks normal review will not catch so you can put something deliberate in their place.

A practical method for replacing assumptions with visibility: the AI Baseline Assessment, run across usage, impact, capability and risk.

The four areas are usage, meaning which AI tools are used and for what; impact, where AI helps and where it does not; capability, how skilled each person actually is; and risk, where exposure sits. You will learn the question sequence that gets honest answers rather than defensive ones, and why an assessment framed as curiosity surfaces shadow AI that one framed as compliance never will. It then covers how to gather the information through a written check-in, one-to-one follow-ups, a team-level pattern discussion, and optionally working alongside someone. You finish with a written Team AI Baseline, the first of the five documents this course produces, and an evidence-based view of where AI capability and AI risk sit across the team. The goal is actionable visibility rather than perfect measurement: a picture good enough to manage from, not an audit report.

Seeing how AI is used is not the same as deciding how it should be used.

Once an AI usage audit is done, most managers find wide variation: different tools, different judgement about what is safe to paste into a chatbot, different levels of disclosure. This lecture explains why that variation is not a problem to tolerate but the raw material for a team agreement about how AI should be used, and why leaving it alone means the most cautious person and the most permissive person are both setting the team's AI policy by default. You will look at what an AI usage audit can and cannot tell you, what a shared way of working needs to cover, and the order it gets built in: first the agreements that apply everywhere, then the recurring AI workflows those agreements have to survive contact with.

Leaving AI use to individual discretion feels respectful, but it leaves decisions unmade that belong to the team as a whole.

Individual choices about AI now shape the value the team captures, the capability each person builds or quietly stops building, fairness between people working at different speeds with different tools, and the AI risk the team carries. This lecture teaches you to separate decisions that genuinely belong to the individual from decisions a manager owns, and why that line is about accountability rather than control. It also covers how to explain the change to a team without it sounding like a crackdown, including the actual words to use when someone hears new guardrails as distrust. The result is a clear rationale for why ground rules are needed, which is what makes collaborative standard-building possible rather than resented.

The first layer of a team AI policy is five agreements the team writes together, covering tools, data, review, disclosure, and direction and support.

Tools means which AI tools are approved and for what. Data means what may and may not go into them. Review means what checking is required before AI-assisted work moves on. Disclosure means when AI involvement should be stated. Direction and support means what the team is trying to achieve with AI and what help is available. This lecture gives you a practical way to facilitate that conversation: how to separate fixed organisational constraints from genuine team input, how to run the discussion so people contribute honestly, and how to keep the final decision where your accountability sits rather than defaulting to consensus. The output is a short, explicit set of acceptable use rules everyone helped write, which is what makes them likely to be followed rather than filed and forgotten.

Agreements stay abstract until they meet real work, so the second layer holds each recurring AI workflow against the five agreements.

This lecture covers how to choose which AI workflows matter, how to describe one plainly enough that the team recognises it, and how to test it against the agreements on tools, data handling, review and disclosure. The discipline is to change a process only where it genuinely fails to meet an agreement, so what you write down describes how the work is really done rather than an ideal nobody follows. You will see how a workflow description makes expectations concrete: not review AI work carefully, but a named point in a named process where a named check happens. Together with the five agreements, these descriptions complete the Team Working Standard, the second of the five documents the course produces.

A team AI policy only matters when it changes behaviour, and most standards fail at activation rather than in the writing.

This lecture covers activation: how to introduce the standard so it reads as support rather than surveillance, where to keep it so people can actually find it, and how to reference it in the moments where work happens, including one-to-ones, task handoffs and work reviews. You will learn how to handle the first few times it is not followed, which sets the tone for everything after, and how to put it on a review schedule so it stays current as tools and workload change rather than becoming a document nobody has opened since the meeting. The aim is to turn an agreement into working management infrastructure, so that months later it still describes how the team actually behaves and AI adoption rests on something written down rather than on memory.

AI risk becomes real at the moment nobody owns verification, which is usually earlier and quieter than managers expect.

This lecture follows a single unnoticed mistake through the work. A number that was never verified goes into a draft. The draft is summarised. The summary is quoted in a meeting. By the time anyone acts on it, the original source is three steps back and nobody remembers whether it was ever checked. You will see why the danger is not that AI errors happen but that no verification point exists, how AI-assisted work becomes the basis for decisions without anyone consciously deciding to trust it, and why assuming someone would have caught it is not a control. The purpose is to locate exactly where in your team's work an unchecked output turns into a business consequence, so you can place a verification checkpoint at that point rather than trying to check everything.

Output quality is only one category of AI risk, and focusing on it alone leaves the others unmanaged.

This lecture widens the view to exposures that closer proofreading will never catch: data handling, where information goes into AI tools that should not leave the organisation; disclosure, where work reaches clients without anyone deciding whether AI involvement should be stated; dependence, where a person stops developing a skill because a tool covers it; and inconsistency, where similar work is produced to different standards depending on who did it. You will look at each in terms of what it costs and what would have to be true to prevent it. The conclusion is practical rather than alarming: these are operational risks that need operational controls placed at specific points in the work, not general caution or a policy document that sits unread.

Three moments carry most of the AI risk in knowledge work: where data goes in, where AI-assisted work becomes the basis for a decision, and where work goes out to a client.

This lecture shows you how to find those moments in your own team's workflows and write a checkpoint for each one as When, What and Who: the named moment it happens, the specific two-minute check that occurs, and the named person who owns it. You will learn why checks must be embedded in normal work rather than bolted on as an extra step, since anything added on top of an already full week gets skipped first. It also covers activating the map with the team and keeping it light enough to survive contact with real deadlines. The output is your Checkpoint Map, the third of the five documents the course produces.

Resistance to AI is feedback rather than refusal, and reading it that way is what makes adoption hold.

Treated as an attitude problem, resistance hardens. This lecture reframes it as information about conditions a manager can actually change. You will look at what people are typically saying when they hold back, which is rarely that they do not want to, and more often uncertainty about what is allowed, a fear that using AI signals they are replaceable, workload that leaves no room to learn a new tool, or an early bad experience with an AI tool that nobody debriefed. It covers why pressure produces compliance rather than adoption, and why compliance quietly reverses the moment attention moves elsewhere. This is the change management side of AI adoption: it is built by removing the reasons people hesitate, not by insisting harder.

Four reinforcement levers keep an agreed way of working alive: Vision, Recognition, Asking and Modeling.

Vision means saying out loud what AI is for in this team, in the moments where work actually happens. Recognition means praising how someone worked rather than only what they produced, so the behaviour you want gets named when it appears. Asking means changing how did it go to how did you approach this, because what you ask about signals what you care about. Modeling means using AI tools visibly yourself, including showing where they did not work first time. You will see how each lever sends a different signal and why they compound when used together. Pulled deliberately inside normal management routines, they keep the team's AI policy visible, discussable and valued, so AI adoption does not quietly fade back to how things were before.

Teams do not move at one speed, so AI capability has to be developed person by person rather than through a single training session.

Treating everyone as the same starting point wastes the strong and strands the hesitant. This lecture teaches you to form an honest read on where someone actually sits, based on observed AI-assisted work rather than confidence or enthusiasm, then agree one concrete next step with them instead of a development plan nobody revisits. It covers what a good next step looks like: small enough to happen this month, specific enough that you can tell whether it happened, and chosen with the person rather than assigned to them. You then use follow-up evidence to adjust together, which is what makes this coaching, not a training course. It works whether someone is ahead of you or has barely started, and it fits inside one-to-ones you already hold, so upskilling happens continuously instead of in a one-off training event.

When one person works out something useful about AI it usually stays with them, and this lecture covers moving it to the whole team.

The four steps are Surface, noticing and drawing out what someone has figured out; Examine, checking whether it actually holds up and where its limits are; Spread, getting it to the people it would help in a form they can use; and Retain, capturing it so it survives the person moving on. You will see why the examine step matters most, since spreading an untested trick is worse than not spreading it at all. It also covers the manager's role, which is mostly creating the moments where surfacing happens rather than being the person with the answers. The result is shared best practice treated as a deliberate leadership habit rather than luck, and AI capability that grows across the team instead of sitting with one or two people.

Staying ahead does not mean chasing every new tool. It means scanning for high-value AI use cases and proving one in a bounded trial before adopting it.

You will learn how to scan by looking at where time goes, where quality is inconsistent, and where work is repetitive rather than judgement-heavy. Then how to run a bounded trial of a new AI tool with a defined scope and a defined end date, so an experiment cannot quietly become permanent by default. Then how to decide on the evidence whether to adopt it, hold it for later, or escalate it to someone with more authority. It also covers what evidence is worth collecting while a trial runs. You end up with a management routine for staying current that costs little and prevents both common failures in AI adoption: adopting on enthusiasm, and never adopting at all.

The two documents that turn the course into an executed plan: the 60-Day AI Adoption Workbook and a completed worked example.

The workbook holds every exercise from the course, sequenced across eight weeks, two for each of the four moves, so you know what to do and in what order rather than facing a blank page. You will see how it is organised, how to adapt the pacing to your team's reality, and where the output of each move feeds the next. The worked example is Leila's finished plan, showing what a Team AI Baseline, a Team Working Standard, a Checkpoint Map and a Lead AI Adoption Plan look like once they are filled in for a real team. Seeing the finished shape before you start is the fastest way to understand what good looks like and what level of detail is enough.

A short close to the course: what actually changed, what is ahead as AI keeps developing, and the one habit worth carrying forward.

What changed is not the documents you now hold but the position you are in: you can see how AI is used in your team, you have a team AI policy everyone helped write, checkpoints where AI risk enters the work, and a way to keep people developing. The lecture is honest about what is ahead, since AI will keep getting more capable and more woven into everyday work, and explains why a method built on evidence and guardrails adapts to tools that do not exist yet rather than going stale with the next model release. The habit worth carrying forward is staying curious: continuing to listen to your team, and noticing what is changing around them, which is what keeps AI adoption moving once the course is behind you.