What Actually Changes for a Manager

The most useful correction a manager can make early is to stop reasoning about which jobs AI affects and start reasoning about which tasks.

Almost no role is a single activity. A recruiter writes job descriptions, screens applications, schedules interviews, briefs hiring managers, negotiates offers and maintains relationships. AI reaches some of those substantially and others barely.

What follows from that is not obvious. When AI absorbs a portion of a role's tasks, the role does not shrink proportionally. It reweights. The remaining tasks become a larger share of the job, and they are usually the harder ones: judgement, relationships, exceptions, and the cases where the answer is contested.

So the practical effect on a team is often an increase in the difficulty density of the work rather than a reduction in its volume. A team that was spending forty percent of its time on routine drafting and sixty on judgement now spends most of its time on judgement, which is more tiring, harder to review, and harder to do consistently for a full day.

Managers who plan for a capacity gain and get a difficulty increase are surprised by the result. Planning at task level rather than headcount level is what makes the change legible in advance.

The most important empirical finding for a manager is not about how much AI helps. It is that the people using it are poor judges of whether it helped.

In a randomised controlled trial published in July 2025, METR measured experienced open-source developers working on real tasks in codebases they knew well. Developers using AI tools took nineteen percent longer to complete the tasks. Asked afterwards, the same developers estimated on average that AI had made them twenty percent faster.

The direction of the result matters less than the gap. A roughly forty-point divergence between measured and perceived effect, in people assessing their own recent work, is a serious problem for any management practice that relies on asking.

Two cautions before generalising. The study looked at experienced developers on familiar codebases, which is the case where AI assistance helps least, and results differ for unfamiliar work and less experienced staff. And tooling moves; the same research group has since reported improvement on the same population. The productivity evidence in detail is covered in the existing lesson on coding agents.

The management consequence survives both caveats. Enthusiasm is not evidence. A team that reports AI is transforming our work has told you about their experience of using it, which is genuinely worth knowing and is not a measurement of output.

AI does not remove work from a team so much as move it, and knowing where it lands lets a manager staff for it.

Production shifts toward review. Drafting a document, writing a first-pass function, summarising a call: these get faster. What replaces the saved time is checking, and checking is a different cognitive activity that people are worse at and enjoy less.

Review concentrates upward. When a junior produces three times the output, the senior reviewing it becomes the constraint. The bottleneck moves to the most experienced person on the team, who was already the scarcest resource, and their week fills with verification rather than the work only they can do.

Errors change shape. A person who does not understand something produces work that looks uncertain. A person using AI on something they do not understand produces work that looks polished. The signal a reviewer used to rely on, that confusion is visible in the output, is degraded.

And the tail gets longer. The routine cases become fast and the exceptions remain exactly as slow, so the proportion of the team's time spent on hard cases rises even as total throughput improves.

The managerial move that follows: measure and protect senior review capacity explicitly, because it is the resource that silently absorbs the change.

The dynamic that catches most teams, drawn as a flow.

AI raises the output rate of the people producing work. That output still has to be checked, and checking has not become faster in proportion. So the queue forms in front of whoever reviews.

Three things happen next, and only one of them is good.

The reviewer becomes the constraint and throughput plateaus below what the production gain promised. Uncomfortable, and honest.

Or review quality degrades under volume: the reviewer skims, and the polished-but-wrong output passes. This looks like success on every metric until something surfaces downstream.

Or the organisation invests in review capacity, distributes review, or reduces what needs reviewing by narrowing where AI is used.

The second outcome is the default, because it requires no decision and produces no visible signal.

The management question with the longest consequences concerns how people become good at things.

Expertise is built by doing work slightly beyond current ability, getting it wrong, and being corrected. Traditionally the junior tasks in a profession were exactly that: the first draft, the routine analysis, the simple case. They produced modest value and considerable learning.

Those are the tasks AI absorbs most completely. Which creates a genuine tension: delegating them to a tool is efficient today and removes the mechanism by which the next generation of seniors was produced.

The tension is real and it does not have a clean solution, so it is worth stating rather than resolving glibly. Two partial responses are available to a manager.

Move juniors up the stack deliberately rather than by default. If the routine drafting is automated, the junior's development work becomes reviewing AI output critically, which requires teaching them what good looks like directly rather than letting them discover it by producing bad versions.

And preserve deliberate practice explicitly. Some work should be done without assistance because doing it builds capability, even where the assisted version would be faster. That is a cost accepted for a reason, and it needs naming as such, or it looks like inefficiency and gets optimised away by someone measuring throughput.

Several management heuristics quietly stop working, and each has a replacement.

Output volume indicates effort. It no longer does, in either direction. Someone producing a great deal may have automated well or may be shipping unreviewed material. Replace with: assess the quality of the judgement, not the quantity of the artefact.

A polished document indicates a competent author. Presentation and understanding have decoupled. Replace with: ask about the reasoning rather than reading the output. Someone who understands their work can explain a choice they made; someone who accepted a generated answer often cannot.

Estimates reflect experience. Time estimates now include a tool whose contribution the estimator systematically misjudges, per the METR result. Replace with: measure elapsed time against estimates and recalibrate empirically rather than reasoning about it.

Struggle is visible. It used to be that someone stuck produced little. Now they can produce a lot while learning nothing and understanding less. Replace with: ask what was hard this week, and treat nothing was hard as a prompt to look closer rather than as good news.

And finally, that the person who did the work knows how it was done. With chained AI assistance this is genuinely uncertain, which matters most when something has to be debugged, defended or explained to a customer.

One principle should be stated early and repeated, because it is the foundation everything else rests on.

The person who submits work is accountable for it, regardless of how it was produced. A tool is not a colleague and cannot hold responsibility. The AI wrote it is not a defence, and a team where it functions as one has a problem that will surface at the worst moment.

That sounds obvious and it erodes in practice through a specific mechanism. When a tool produces something plausible, the psychological experience of accepting it differs from the experience of writing it. Ownership feels weaker, and weaker ownership produces less checking, which produces exactly the errors that make ownership matter.

Three things a manager can do about it.

Say it explicitly, once, clearly, rather than assuming it is understood. The norm is new enough that it is not.

Attribute work to people rather than to tools in every direction, including praise. A team that hears the model did well learns that the model is the agent.

And when something goes wrong, run the review on the person's judgement, not the tool's output. The useful question is what checking did you do, and what would have caught this, which is a question about process and is answerable.

This principle is also what makes the delegation decisions in the next lesson tractable.

Before changing how a team works, establish what is actually happening, because most managers are working from an impression.

Four things worth finding out, none of which requires a project.

What tools are in use, including the unapproved ones. An amnesty produces a more accurate answer than a policy reminder, and the gap between the sanctioned list and reality is usually instructive.

Where the time actually goes now. Not a formal study; a couple of weeks of rough task-level tracking is enough to see which tasks are candidates and which are not.

What has already gone wrong. Ask directly and without consequence. Teams generally have examples of AI-caused errors that were caught and never reported, and those examples are the most useful material available for setting norms.

And where review is currently queuing. If work is already waiting on one person, adding production capacity upstream makes it worse rather than better, and that is worth knowing before rather than after.

The reason to gather this first is the METR finding. If self-report is unreliable at the individual level, it is unreliable at the team level too, and a manager acting on the team's enthusiasm is acting on the least reliable available signal. Modest direct observation beats confident second-hand impression.