AI made me faster this year. I draft faster, research faster, and I’ve built software I couldn’t have built two years ago. I’m much less sure it made any organisation I work with faster.

According to McKinsey’s August survey, I’m in good company on both counts. Eighty percent of respondents say AI has improved their personal productivity. The number is remarkably flat across the hierarchy: 80% of C-level respondents, 81% of senior managers, 81% of midlevel managers, 76% of individual contributors. Yet only 37% say AI has contributed anything to their company’s EBIT, the same as a year ago.

So if eight in ten of us are faster, where did the time go?

For the rest of us: why a faster step doesn’t make a faster process

Imagine a relay race with four runners. You give the second runner better shoes, and she knocks two seconds off her leg. The team’s time only improves if nothing else absorbs those two seconds. If the handoff to runner three is still clumsy, or runner three is waiting for the official to wave the next leg through, the team doesn’t finish any sooner. Runner two is just waiting longer at the baton.

Work in organisations is mostly relay races. A proposal gets drafted, then reviewed, then approved, then sent. A customer query gets read, routed, answered, checked. AI is extremely good at making individual legs faster: the draft, the summary, the first answer. It does nothing, on its own, to the handoffs, the queues and the sign-offs between legs. And in most processes, the handoffs are where the time goes.

This is the same pattern I described in The Dynamo Problem: new capability, old layout. Here it plays out at the level of one person’s week.

The individual gain is real

It’s worth saying clearly before the caveats: the individual gains aren’t an illusion.

McKinsey’s respondents report more than speed. About half say AI helps them develop new skills and make better decisions. And a separate, very different kind of evidence points the same way. Anthropic analysed about 400,000 sessions of its Claude Code tool from roughly 235,000 people between October 2025 and April 2026. People in software occupations reached verified success, meaning evidence like passing tests or committed code, in about 30% of coding sessions. People from other professions reached it in about 26%. Every one of the ten largest occupations in the data landed within seven points of software engineers.

The more interesting finding is what drives success: expertise in the problem, not in the tool. Novice-rated sessions reached verified success 15% of the time. Intermediate and expert sessions reached 28–33%. Experts also got much more from each instruction: about 12 actions and 3,200 words of output per prompt, against 5 actions and 600 words for novices. People made about 70% of the planning decisions and only about 20% of the execution decisions.

That’s the individual story in one line: AI multiplies what you already know. (Two honest caveats: this is one product’s users, and success was classified by a model, so it’s observational rather than causal. The authors say themselves they can’t measure whether the work was used afterwards.)

The strain is real too, and it’s not evenly shared

Here’s the part of the McKinsey survey that rarely makes the slide.

When asked about negative effects of AI on their work, 47% of midlevel managers and individual contributors reported at least one, against 31% of executives and senior managers. The pattern holds item by item. “Hurts my ability to think critically”: 20% of midlevel managers, 9% at C-level. “Increases anxiety about my career prospects”: 19% of midlevel managers and 18% of individual contributors, 6% at C-level. “Creates pressure to take on more work”: 18% of midlevel managers, the highest of any group.

The positive experience is nearly identical up and down the hierarchy. The negative experience isn’t. The people approving AI budgets mostly feel the upside. The people reviewing AI outputs, redoing AI drafts and absorbing the expectation that everything is now faster feel more of the downside.

That matters for the missing productivity. One plausible place the saved time goes is straight back into the system as more drafts, more review and more requests, landing on the middle of the organisation. The survey doesn’t measure that directly, so I’ll hold it as a question rather than a finding. But if you’re a leader wondering why individual gains don’t add up, it’s the first place I’d look.

Turning personal speed into company results

The McKinsey data is fairly direct about what separates the minority who see enterprise returns. Nearly three-quarters of its “high performers” have fundamentally redesigned workflows around AI, against about a quarter of everyone else. They’re twice as likely to have defined processes for measuring AI’s impact, and twice as likely to say senior leaders visibly own the effort.

In practical terms, from my own work:

  • Find where the saved time lands. Take one process, trace a real case through it, and see where time actually goes after the AI-assisted step. Usually it’s a queue or a review, not the work.
  • Redesign the handoff, not just the step. If AI drafts in minutes but review still takes a week, the review is now the process. Change who reviews, what gets reviewed and what can skip review.
  • Measure the relay, not the runner. “How many people use the tool” tells you about adoption. End-to-end cycle time tells you whether anything improved.
  • Ask the middle. The people with the most strain have the clearest view of where the process breaks. They’re also the least likely to be asked.

What this means

Individual productivity is the easy part, and it’s mostly already happened. It happened bottom-up, one person and one tool at a time, and it shows up in every survey.

Enterprise productivity is a design problem. It needs someone with the authority to change the process, not just the tools inside it. Until that happens, AI will keep making people faster inside organisations that stay the same speed. The cost will land on the people in the middle, who carry the extra load without being asked how the process should change.

References