From Individual Gains to Team Capability

A six-person finance team closes the books every month, and it takes nine working days.

Four analysts reconcile different sets of accounts, which means checking that what the ledger says matches the bank statements and the detailed records underneath. Call them R, P, F and I. A senior accountant books the adjusting entries and consolidates. A controller reviews everything and signs off. R has the biggest accounts and needs three days; the other three need two each.

Then R starts using an AI assistant to match lines and draft explanations for the differences. R's reconciliation drops from three days to one. (The team and its numbers are invented to make the mechanism visible. The mechanism isn't.)

The simple arithmetic says seven days: take two days out of a nine-day job. The close finished on day nine. Exactly as before.

Nothing about R's gain was imaginary. R really did save two days. They just had nowhere to go, and that's the subject of this piece:

A gain that lives in one person's prompts, habits and private context stays that person's. It becomes the team's only when the interfaces of the work change: what passes between people, in what form, checked how.

Training and tools change people. Redesign changes interfaces. A team needs both, and they work in different places.

Where the two days went

Scroll sideways to see the whole figure

Follow R's two days and watch them disappear at three places where R's work meets somebody else's.

The stage waits for its slowest member. The four reconciliations run in parallel, and the next stage can't start until all four are done. With R at one day, the slowest member is now P, F or I, at two. R saved two days at the step; the stage saved one. Project planners call the longest chain of dependent steps the critical path, because it alone sets the finish date. R used to be on it. Now three people whose work didn't change are on it, and R finishes early with nothing to hand on.

The faster step makes work for other people. R's assistant matched more thoroughly than the manual method and turned up 58 unmatched items where the old pass listed 40. Some of those are real findings the old method missed, which is a genuine quality gain. But the 18 extra items go to account owners, who work them between their own tasks, and the exception follow-up stretches by half a day. Cheap production at one step becomes volume at the next, and the person who measured the threefold speedup never sees where the items land.

The output arrives in a form nobody else can check. R's reconciliation pack is laid out the way R finds useful, with the assistant's explanations beside the matched lines and the tie-out summarized in prose. The other three packs follow the team's old template. The controller can't tell from R's pack how the matches were made or which ones were the assistant's guesses. So the controller samples the underlying data and asks R to walk through it. Half a day goes to repeating a check R had already done, by reading the assistant's matches one by one. That check gave R real confidence and gave nobody else anything to rely on.

Scroll sideways to see the whole figure

Two days saved, minus one at the stage, minus half at exceptions, minus half at review. Zero.

R's gain was real. The team's interfaces had no place to put it.

Every one of those interfaces (when the next stage starts, how exceptions are routed, what a pack must contain) was designed for a team in which R was the slow one. Nobody did anything wrong. The team simply wasn't built to receive the gain.

The risks the day count doesn't show

Three more problems don't show up in this month's nine days, and they may decide next month's.

The method lives in R's chat history. R's matching rules, the prompt that works, the corrections R made to the assistant over the first few runs: all of it sits in R's conversations and R's head. If R is out next month, the stage goes back to three days, because nobody else can reproduce the method. If the model underneath the assistant changes and results shift, nobody has a written record of what "right" looked like to compare against.

The use is invisible. R may not mention the assistant at all, for ordinary reasons: a faster close might bring more accounts, and the policy may be unclear. This is common. In Microsoft and LinkedIn's 2024 survey, 78 percent of people using AI at work brought their own tools, and about half of them were reluctant to admit using it for their most important tasks. A team can't build on a practice it can't see. That hidden use, often called shadow AI, is also useful information, because what people reach for when nobody has provided anything is a map of where the demand is.

Every pair of people pays a translation cost. A team of six has 15 pairs of people who might pass work to each other. When every person's practice is private, every pair that exchanges work also exchanges a translation problem: a different layout, a different level of detail, a different idea of what "finished" means. With one shared format, there's one thing to learn, however many people use it.

What the evidence actually supports

Two findings are worth knowing, because together they describe the gap exactly.

The first says the individual gain is real and large. In a randomized experiment at Procter & Gamble with 776 professionals working on real product problems, individuals with an AI assistant did about as well as two-person teams without one. The more telling result for this argument: putting a second person beside someone already using AI added nothing the experiment could detect. The individual got stronger. The ordinary way of combining people didn't add to it. (It was a one-day task, so it couldn't test the handoffs and rework where the close leaked.)

The second shows what it looks like when the gain does reach everyone. In a study of 5,172 customer-support agents at one company, an AI assistant raised resolutions per hour by about 15 percent on average and about 36 percent for the least-skilled fifth. The researchers found suggestive evidence that the tool carried the practices of the best agents to everyone else. That worked because the capability lived in the tool every agent used, inside the workflow.

That's the difference. Same kind of technology. In one place the gain stayed with the person. In the other, it was built into the shared system.

"Just give everyone the tool and training"

This is the strongest objection, and it gets more right than it's usually given credit for.

With no adoption, there's nothing to share. Tools and training raise the floor, and the private experiments of many people are the raw material for anything the team later standardizes. And where work is pooled, meaning people do separate tasks whose results simply add up, the team's gain really is the sum of individual gains and no redesign is needed. Six translators each working on their own documents fit that description.

The objection fails where work is sequential, where one person's output is the next person's input, as in the close. Train all four analysts without a shared method and the controller now has four private methods and four pack formats to check, and the account owners receive four streams of longer exception lists. Everyone gets faster at their step. The close doesn't.

So the two positions combine into a sequence, and this is what I'd do. Give people the tools and the training, and encourage them to experiment in the open. Find the sequential workflow where personal gains are biggest. Then redesign that workflow's interfaces, using what the experimenters learned.

What redesign actually means

Six changes, and every one of them alters what passes between people.

Shared context. The assistant should start from the same written material for everyone: which accounts exist and who owns them, the matching rules and tolerances, the recurring exceptions and why they happen. A playbook, kept in one place and loaded into every session. Write down the reasons as well as the rules, because rules outlive the conditions that justified them. R's private matching rules become the first draft, which is exactly how a personal practice becomes a team asset (Write for the Model That Doesn't Exist Yet).

Shared checks. Every pack carries the same tie-out, so that someone who didn't produce it can see in a minute whether it holds: opening balance plus activity equals closing balance, with unreconciled items aged by how long they've been open. And the team keeps the last few closes' resolved exceptions as an evaluation set, a fixed collection of real cases with known right answers. When a prompt, a rule or the underlying model changes, the team reruns the set and sees what moved. That is what lets the controller trust a sample instead of rereading everything.

Clear roles: who specifies, who produces, who checks. Before AI, these were usually fused in one person. The analyst decided what counted as a match, made the matches and checked them. When producing becomes fast and cheap, what's left is specifying (what is wanted, and how it will be judged) and checking, and both need owners. The controller sets tolerances and materiality before the close starts. The analysts produce. A named reviewer checks exceptions and a sample. Each exception has an owner.

Fewer handoffs. Exceptions go straight from the matching tool to their owners with a proposed entry attached, without passing through R's inbox. Adjusting entries start while exceptions are still being cleared. And all four analysts use the same method, so the reconciliation stage takes one day because everyone is now as fast as R.

Templates for decisions already made. A tie-out template, a standard exception format and a tolerance table hold judgments the team has settled, so nobody remakes them under deadline pressure. The limit is variety: AI-assisted work tends to come out more alike. Standardize where checking is cheap and variety has no value. Leave alone the work whose value is that it differs.

Practice made visible. R shows the method at the close retrospective. The prompt and rules go into the playbook with a named owner and a change log. The next person to use it improves it and records the change. A few hours per practice is what separates a team with a story about R from a team with a method (When Work Starts to Compound).

Apply all six and the close changes shape. Reconciliation takes one day for everyone. Exceptions and adjustments overlap and take a day and a half instead of two. The controller reviews a standard pack by exception and by sample, in one day instead of two. The close comes in at about five and a half days.

Treat that as a target to test. It rests on assumptions you'd test one by one: that the others reach R's speed, that proposed entries save time, that a sampled review catches what the full read caught. The first close under the new design will probably run long, because the method is new and the playbook is thin.

Put the capability where the work happens

Documents and habits decay. The strongest form of team capability puts the shared pieces inside the tools people already use, so they apply to whoever happens to be doing the work. For the close, the playbook and the tie-out template sit inside the close checklist and the ledger tools. The assistant's harness, the ordinary software around the model that supplies its standing instructions, data connections and tools, loads the same playbook no matter who starts the session. In a software team the equivalent is instruction files and tests kept in the code repository and reviewed like code.

Two tests tell you whether you've got there.

The leave test. Does the capability still work if the person who built it is gone for a month? If not, it lives in a person.

The island test. Does it help one team on its own, and get better as neighboring teams join? It can fail in two opposite ways. Some designs need every department to move to the same platform before they help anyone, so they never reach a first user. Others are built for one department and held up by a champion, and fall into disuse when the champion moves on. The way between them is a thin shared layer of conventions, checks and context, wrapped around the systems each team already uses, useful to the first team alone and more useful with each team that joins. That's a design judgment; nobody has measured it. It's the one I'd bet on.

What to do

Measure the whole job. Track the lead time of the whole close, in working days, compared like with like (quarter-end with quarter-end). Track how long finished work waits at each handoff, since that's where this example leaked. The failure signature is unmistakable: hours saved going up, usage going up, faster first drafts, and a close that still ends on day nine (Measuring AI Impact Without Fooling Yourself).

Check the gain is real before redesigning around it. People can feel faster than they are. Timestamp the step. If the stage's clock time fell and the close didn't, the gain leaked, and redesign will capture it. If the stage didn't shorten, there's nothing to capture yet.

Find your R. Somebody on the team is already much faster with AI. Ask them to show the method openly, and treat it as the first draft of the team's playbook.

Redesign one sequential workflow at a time. Shared context, shared checks, clear roles, fewer handoffs, templates where variety doesn't matter, and a routine for making practice visible.

Run the absence test. Once a quarter, have someone who wasn't involved run a stage from the playbook alone, with R out. If it works, the team owns the capability. If it doesn't, R still does.

Check yourself

Why did R saving two days not shorten the close?

The next stage waited for the slowest of the four analysts, extra exceptions landed on account owners, and the controller had to recheck R's pack. The team's interfaces had no place to put the gain.

Why does the objection to just give everyone the tool and training fail in the close?

The work is sequential. Four private methods give the controller four pack formats to check, so everyone gets faster at their step and the close doesn't.

What is the leave test?

It asks whether the capability still works if the person who built it is gone for a month. If not, it lives in a person, not in the team.