Years before Flank, when people first started reporting to me, I did their work for them. I didn't set out to. We had a high bar for quality, I felt responsible for whatever my team produced, and when something reached me that wasn't quite right, the quickest fix seemed to be fixing it myself.

It took me longer than I'd like to admit to see what the habit was doing. Work that was ready to move sat waiting for me to look at it, and every fix I made myself added overhead nobody needed. The more I cared about the outcome, the longer the queue at my desk became. I was in the way.

I think about that version of myself often at the moment, because I see him everywhere in how we work with AI.

What the good ones did instead

The best managers I have worked with did close to the opposite. They trusted the people they had hired, and they used their own expertise for something more valuable than redoing the work: knowing where to lean in, and where to remove themselves completely. Each of them had a short list of things they always looked at closely, and they left nearly everything else alone.

Andy Grove, who ran Intel, had a name for what I had been doing. He called it meddling, a manager using superior knowledge to take over a situation instead of letting the person in it work it through, and he counted it as negative leverage. What he wanted was monitoring. A manager who monitors knows what is going on and steps in when something goes wrong. A manager who meddles does the work again.

New managers again

With AI, most of us are back where I started. When Anthropic studied its own engineers last year, they were using Claude in about 60% of their work, yet more than half said they could fully delegate a fifth of it or less. The company's data on Claude Code shows the arc I went through as a manager, compressed into months. New users approve each action before the agent takes it. Experienced users run on full auto-approve in over 40% of their sessions and interrupt more often, stepping in when something goes wrong. That is Grove's monitoring by another name: staying close enough to step in when it counts, and leaving the rest alone.

Approving every action feels like diligence, but it is also arithmetic. If a piece of work took three hours to produce and one to check, and an agent now produces it in ten minutes, the job takes seventy minutes instead of four hours, and it will never take less than sixty however good the agent gets. The part you cannot speed up sets the ceiling. As a new manager I was that part; now the reviewer is. I think this is one of the reasons the speed people feel at their desks so rarely shows up in what their organisation produces.

Nor does checking everything buy the safety it promises. A meta-analysis in Nature Human Behaviour pooled 106 experiments comparing people, AI systems and the two working together. On average the pair did worse than the better of the two on its own. Where the people were better than the AI, adding the human helped. Where the AI was better than the people, adding the human made the result worse. Lean in where your judgement beats the machine's, and step back where it doesn't.

Where the analogy breaks

So far, managing an agent sounds a lot like managing people. The analogy breaks at one point, though, and I find that most of the real work sits exactly there.

Good managers get out of the way for two reasons. One is throughput: the manager is the slowest step in the team, and everything routed through them waits. The other is growth. People improve when they are trusted, and a mistake you let someone make is tuition. Next time they catch it themselves, and you can step a little further back.

With AI the first reason gets stronger, because the agent works in minutes and your attention becomes most of the cost. The second reason disappears. An agent does not learn from your trust. Each morning it starts from the same place, and it will repeat yesterday's mistake unless something outside the model has changed.

So the tuition has to be paid somewhere else. Every mistake an agent makes ends up in one of two places. It goes into the system around the agent, as a rule, a test, an example or a point where the agent has to stop and ask. Or it goes into the head of whoever caught it, who now checks a little more while the organisation learns nothing. You can get out of an agent's way exactly as far as that system has learned to catch what you used to catch.

Toyota's founding story has a version of this. By 1924 Sakichi Toyoda had built a loom that stopped itself when a thread broke. Until then every loom needed someone watching it; afterwards one person could look after many. Threads still broke. The loom noticed, stopped and made the problem visible, so that a person could fix the cause instead of standing guard. Stepping back from an AI system needs the same thing. And because current AI is strong at some tasks and weak at others that look almost identical, the map of where it should stop has to be written down, tested and redrawn with every new model.

What we do in our own code

We generate a lot of code with agents at Flank, and we use AI to review it. I understand why that makes people uneasy, but a human on every change has its own cost. Review becomes a bottleneck for the whole company, as I have written before. The question I find more useful now is which instrument should catch a given mistake. Anything core to the product, the parts that would hurt a customer if they broke quietly, gets a person, always. The engineer on our team who reads every line the agent writes is exactly who I want there. For a change to how a page looks, a person reading the code line by line is the wrong instrument. Mistakes there show themselves the moment someone looks at the screen, and being able to undo a change in minutes catches them better than a tired reviewer at six in the evening.

When something does slip through, the fix I push for is a change to the system, a test or a rule the agent reads, rather than a person going back to reading everything.

The same reflex in legal

I recognise my younger self most clearly in lawyers, and I mean that kindly. They are trained into exactly the reflex I had. Their name goes on the work, the bar is very high, and they feel personally responsible for every word, because professionally they are. It is one of the best things about the profession. Pointed at every contract that crosses the desk, it is also why so much work that lawyers should not be doing stays with them.

Even the American Bar Association's guidance on generative AI says the checking a lawyer owes depends on the tool and the task. For a legal team, getting out of the way means the lawyers decide the positions, the thresholds and the cases that always come to them. The agent does the work and stops where it should. When it gets something wrong, the correction goes into the playbook it runs on, rather than into a lawyer's private resolution to read the next fifty contracts more carefully. And someone owns all of it, and answers for what comes out.

That is the part we take on at Flank. We deploy agents into a legal team's own systems, keep the playbooks they run on current as corrections come in, and stand behind the work.

What I don't know yet

I don't know where the line sits for any particular team, and I am wary of anyone who claims to. It moves with each model release and with the team's own work. There is a risk on the other side too. In a field experiment with 181 recruiters, Fabrizio Dell'Acqua found that those given a better AI tool were less accurate than those given a worse one, because they put in less effort. Stepping back can turn into falling asleep, and if nobody does the core work any more, soon nobody can review it either. My best managers' answer still seems right to me: stepping back from most things is what keeps you sharp on the few that matter.

So here is the question I would put to any team, in legal or in engineering, that feels faster but cannot see it in the results. Think of the last mistake your AI made. Where did the correction go? If it went into a rule, a test or a playbook, you are building something you can step back from. If it went into your head, and you have been reading everything a little more carefully ever since, you are where I was as a new manager, doing the work for my team and wondering why nothing moved faster.