Nate: when individual 10x with agents doesn't translate into more team productivity

By Nate's Substack · September 27, 2026.

Nate opens this executive briefing by describing a situation that, he says, is becoming common inside teams: someone discovers a way of using AI agents that is very different from everyone else's. That person keeps several pieces of work running at once, comes back from lunch and finds themselves ready to review a problem that would previously have taken all afternoon, and spends money on tokens without needing to justify it because they can show the result. And even so, Nate says, the team as a whole remains behind.

The central argument is that this combination — one person's individual capacity soaring while the organization around them does not change at the same pace — is going to become increasingly common. Code arrives faster than anyone can review it, a prototype is ready before the people who are supposed to decide what it should do have agreed, and the person who could settle a question is stuck in three other meetings. Everyone has better tools, but finished work is still waiting in the queue.

Nate notes that management's instinctive response is usually to turn the fast person into a teacher for everyone else: have them document their setup, run a workshop, standardize the prompts so everyone reaches their level. He acknowledges some of that can be useful, but warns it can also consume exactly the capacity that was just discovered: you have found someone capable of doing unusually good work unusually fast, and the organization's first move is to give them another job (teaching everyone else).

Against that, he poses what he considers a better question: how to increase the team's productivity without slowing down those who are already moving fast. That means, he says, taking individual gains seriously and being very strict about what actually counts as a team gain. He offers the example that one person producing ten times more work for five others to review is really a review-capacity problem, not an achievement: slowing that person down until the queue feels familiar again only hides the problem, it does not solve it.

As evidence that the phenomenon is real, the email cites two specific references. First, Lauren Tan reported close to a thousand merged pull requests in July, said she was on track to double that figure, and ultimately reported 2,462 in August. Second, Cursor's spring 2026 developer habits report found that the 99th-percentile user merged roughly fifteen times more pull requests than the median author among those actively merging pull requests. Nate qualifies this second data point carefully: it is a difference observed within one product's users, measured through a single type of output (merged pull requests); it does not imply those people generated fifteen times more customer value, nor that AI is the cause of the entire difference. What it does indicate, he says, is that there is a very wide range of behavior worth investigating.

From there, Nate proposes six principles to help a leader decide what to do with that range of behavior: make agents' work usable by more than one person; separate the work that needs to last from the environment that runs it; keep humans ultimately accountable; leave work in a state where someone else can pick it up; give agents a way to check reality; and eliminate processes whose original purpose has already changed. He warns that the hard part is not the principles themselves but deciding how much of each a particular team needs: applied carelessly, all six can degenerate into unnecessary bureaucracy.

The email lists the topics covered in the full briefing (available at the link to the post): where the saved time actually goes, with the example that a tenfold gain in implementation can end up translating into just a 1.8x gain for the business, depending on where the real bottleneck sits in the process; which standards are worth imposing, distinguishing between requiring a reproducible test and requiring everyone to use the same prompts, and noting that this second requirement makes your best employees worse; how to keep the fastest developer from becoming an internal support service, replacing workshops with reusable checks and thinking about who pays for maintaining those checks; and how to assess whether a rollout of these practices worked, through five measures to track during a two-week trial, including one designed specifically to detect when a team's productivity gain actually comes only from its strongest contributor.

As additional material, Nate mentions the 'Faster Factory Kit', a guide that turns the six principles into editable agreements, includes a worked invoice-export example, a functional check runner and a scoring template for running the trial the following week. He clarifies that the briefing video covers all six principles, while the text of the post develops the trade-offs of each and how to know which one each team needs first.

The email closes with a promotional note aimed at members of the 'Executive Circle' plan, noting that in addition to these Sunday briefings they get access to Nate's Library MCP server, with a link to change plans.