Somebody on your team has figured something out.
They’re using agents in a way that looks different from what everybody else is doing. They have several pieces of work moving at once. They come back from lunch and a problem that used to take the afternoon is ready to review. They spend money on tokens without apologizing for it, because they can point to what they got back.
And the team is still behind.
That combination is going to become familiar. One person’s capacity can change much faster than the organization around them. Code arrives faster than anyone can review it. A prototype is ready before the people who need to decide what it should do have agreed. The person who could settle a question is in three meetings about other questions. Everybody has better tools, and finished work still waits.
The instinctive management response is often to make the fast person teach everybody else. Document your setup. Run a workshop. Standardize the prompts. Help us get everyone to your level.
Some of that can be useful. But it can also consume the very capacity you were excited to discover. You’ve found someone who can do unusually good work unusually quickly, and your first move is to give them another job.
I want a better answer to this: How do we increase the productivity of the team without throttling the people who are already moving?
That means taking individual gains seriously, and being hard-nosed about what counts as a team gain. One person producing ten times the work for five other people to sort through is a capacity problem. Slowing that person down until the queue feels familiar again just hides it.
There is a lot of attention on the extraordinary operator right now. The 100x developer. The 2000x developer. Lauren Tan reported about a thousand merged pull requests in July, said she was on track to double it, and reported 2,462 in August. I understand why. The interesting behavior is often happening well before anyone has a sensible vocabulary for it.
But you don’t need to accept a spectacular multiplier to take the underlying change seriously. Cursor’s Spring 2026 developer-habits report found that the 99th-percentile user merged about fifteen times as many pull requests as the median active pull-request author. That’s an observed difference in one product’s users, measured through one kind of output. It doesn’t tell us that those people created fifteen times the customer value, or that AI caused the whole difference. It does tell us there is a very wide range of behavior worth investigating.
The question for a leader is what to do with that range. Six principles help. Make agent work usable by more than one person. Separate the work that needs to survive from the environment running it. Keep humans accountable. Leave work in a state somebody can continue. Give agents a way to check reality. Remove processes whose jobs have changed.
The difficult part is deciding how much of each your team needs. If not done carefully, it can turn all six into unnecessary bureaucracy.
This briefing covers:
Where the saved time goes. A tenfold gain in implementation turns into a 1.8x gain for the business, and the arithmetic shows you which part of your pipeline actually decides when work finishes.
Which standards are worth imposing. Requiring a reproducible test and requiring everyone to use the same prompts are not the same move, and one of them makes your best people worse.
How to keep your fastest builder off the help desk. What to turn into a reusable check instead of a workshop, and how to price that maintenance so it doesn’t land on the person you were trying to free.
How to tell whether the rollout worked. The five measures worth tracking across a two-week trial, including the one that catches a gain borrowed from your strongest contributor.
The Faster Factory Kit. The guide turns all six principles into editable agreements, a worked invoice-export example, a working check runner, and a trial scorecard you can run next week.
The video covers the six principles. What follows is the part that didn’t fit in it: the tradeoffs behind each one, and how to tell which your team needs first.
