AI Didn't Make People More Productive. Yet.

A tool that speeds up one step only helps if that step was the thing holding you back. That sentence is close to a tautology, and we keep spending as though it isn’t true.

Let’s imagine a specific Tuesday.

Someone on a sales team — 40 open deals, around 60 emails a day, four or five calls a week, a CRM she updates on Friday afternoons when she remembers — gets access to a genuinely good AI assistant on Monday. By Tuesday she’s drafting emails in a third of the time. She notices. She tells two colleagues. It feels like a real change.

Now skip to the end of the quarter. Her pipeline looks like last quarter’s pipeline. Same number of live conversations, same conversion, same deals quietly going dark. She saved maybe 45 minutes a day, and if you asked her where those 45 minutes went, she’d have to guess.

Saved time doesn’t pool up somewhere, waiting to be invested in something better. It leaks. It goes into more email, into the next meeting, into the low-grade admin that expands to fill whatever space you clear. The tool did exactly what it promised and the work came out the same shape.

I think a lot of people are living inside a quieter version of that Tuesday: powerful tools, a vague sense that output hasn’t moved, and a reluctance to say so out loud because everyone else seems to be having a breakthrough.

This has happened before, and it took a generation

Factories ran on steam. One enormous engine in the basement, a system of shafts and belts running along the ceiling, and every machine placed according to how close it could get to the power. Buildings went up rather than out, because vertical was the cheapest way to stay near the driveshaft. The whole floor plan was a physical argument about where the energy came from.

Then electric motors arrived. Owners did the obvious thing: they pulled out the steam engine, dropped in one large electric motor, connected it to the same shafts and belts, and waited for the gains.

The gains barely showed up.

What eventually changed everything wasn’t the motor. It was someone realizing that if every machine could have its own small motor, power was no longer a location. You could lay out a factory by the sequence of the work instead of by proximity to a driveshaft. Single-story buildings. Machines arranged in the order things actually happened. Materials moving in a line rather than looping back to wherever the belt reached.

That took decades. Not because the technology was slow, but because the redesign required admitting that the entire existing floor plan was an artifact of a constraint that had disappeared.

In 1987, watching computers spread through offices with no matching jump in the numbers, the economist Robert Solow wrote the line everyone still quotes: you can see the computer age everywhere but in the productivity statistics. The gains came later, and they came alongside reorganized work, not alongside faster machines.

Most AI adoption right now is a new motor bolted to the old driveshaft.

The tell: you’re doing the same tasks, faster

Here’s the diagnostic I keep coming back to. Look at your list of tasks from a year ago and your list from today. If it’s the same list, executed more quickly, you bought a tool. If there are things on today’s list that were simply not possible before — not slow, not annoying, but genuinely not worth doing — you redesigned something.

The second one is where the change lives, and it’s harder to see, because a redesigned workflow doesn’t announce itself as a productivity win. It announces itself as a new habit.

My own version of this is sales. I built an agent system that runs alongside my pipeline: it drafts outreach, it chases deals that have gone quiet, it guards the integrity of what’s in the CRM. It never sends anything and never decides anything on its own — I’ll come back to why that constraint matters more than it sounds.

The change from that system I find most instructive isn’t the impressive one. It’s the boring one: deal documentation stopped being a chore performed on the deals that felt important, and became a byproduct of the work happening at all — every call, every stalled conversation, logged as it happened rather than reconstructed at 6pm from memory.

That’s not the old task done faster. I’m not going to put a ratio on it — I have a count, and it would look good in a sentence like this one, which is exactly why I’m leaving it out.

Nobody was ever going to log every deal by hand at that frequency. That’s not a speed problem — no amount of typing assistance closes that gap, because the bottleneck was never typing. It was the mental cost of stopping, context-switching, deciding what was worth recording, and writing it up in a form that would mean something to a future reader.

That’s a different behavior, not a faster one. The unit of work changed. And the downstream effect is the part that actually pays: a pipeline where the record of what happened is close to complete is a pipeline you can reason about. You can’t build anything on top of Friday-afternoon memory.

Context was the constraint, and nobody noticed

Second example, same theme.

A deal in my pipeline had gone quiet. Not a lead — a real conversation that had run for a while and then stopped. It came back, and it came back specifically because the system reconstructed the whole history of that relationship rather than the last message in the thread.

Think about why that matters. The old workflow’s unit of context was “the last touchpoint,” and that wasn’t laziness. It was a physical limit. A person carrying dozens of live relationships cannot hold the full arc of each one — what they were trying to solve two years ago, who else was in the room, which objection was real and which was polite. So the working memory shrinks to the most recent email, and outreach built on the most recent email reads exactly like what it is: someone who forgot.

Faster drafting would not have revived that deal. A better-written “just circling back” is still a circling back. What revived it was that the unit of context changed size — from the last message to the entire relationship. That’s a redesign. The tool made a previously impossible input cheap, and the shape of the work moved to match.

Third: reading the whole record instead of the summary is, by itself, a form of verification nobody was doing before, because nobody had a spare afternoon to audit a report that isn’t obviously broken. A number that looks approximately right gets glanced at and believed, quarter after quarter, precisely because checking it properly is tedious and usually confirms nothing was wrong.

Verification is the category of work that gets skipped most reliably, because it’s tedious and its output is usually “yes, fine.” Make that check cheap enough to run continuously and you don’t get a faster audit. You get an audit at all — which is a task that had effectively been deleted from the workflow because no one could justify the hours.

The honest part

I’m not going to give you a conversion number. Not because there isn’t one — because I can’t isolate what it would actually mean. The market moved. I got better at my job in ways unrelated to any system. Things changed around me that I didn’t control. Anyone who tells you they’ve cleanly isolated a system’s contribution to a number like that is selling something.

The messiness of that attribution is itself part of the argument.

A bolted-on tool is easy to measure. You can A/B a subject line generator, because everything else is held still. A redesigned workflow is nearly impossible to measure, because the whole thing moved — the inputs, the habits, the cadence, what counts as “a deal I’m working.” When the attribution gets murky, that’s often a signal you did the more valuable thing, not the less rigorous one.

Which is uncomfortable, because it means the projects with the cleanest ROI stories are frequently the ones that changed the least.

Why almost nobody does the redesign

Two reasons, and neither is about technology.

The first is that tools can be bought and workflows cannot. A tool is a purchase — a budget line, a vendor, a rollout email. A workflow redesign requires the sustained attention of the person who actually does the work, because they’re the only one who knows which steps exist for a good reason and which exist because of a constraint that expired years ago. That person’s attention is the scarcest resource in any company, and it’s already fully committed to this quarter.

The second is that adopting a tool is a neutral act, and redesigning a process is an admission. It says the old way was shaped around limits that no longer apply. That’s a mildly embarrassing thing to say about a process you designed, or defended, or have been executing faithfully for six years. Buying software says we’re moving forward. Redesigning says we were doing it wrong.

So the motor gets bolted to the driveshaft, and the productivity statistics stay flat, and everyone concludes the technology was overhyped.

Where to look, if you want to find yours

Not a checklist — three questions I’ve found useful, in rough order of how much they tend to pay.

What do you never do because it’s too expensive? Not the things you do slowly. The things that got quietly dropped: the follow-up cadence you know works but can’t sustain, the documentation nobody keeps, the analysis you’d run monthly if it didn’t eat a day. Every one of those is a task the old constraint deleted. Some of them are worth restoring, and restoring them looks like new behavior rather than acceleration.

Where does context die between steps? Handoffs are where information gets compressed to whatever the next person can absorb — the summary, the last message, the ticket title. Every one of those compressions was a concession to human bandwidth. Some of them no longer need to be.

What do you never verify? Whatever it is, it’s probably been wrong for a while, in a plausible-looking way, and you’d never know.

One more thing, since it’s the constraint I’d defend hardest: my system doesn’t send and doesn’t decide. That’s not caution for its own sake. Judgment is the part of the work worth protecting, and the redesign is only survivable because the mechanical layer moved while the judgment stayed exactly where it was — with me, on the hook, reading every draft before it goes anywhere. Redesigning a workflow doesn’t mean removing the person from it. It means removing the tax the person was paying to stay in it.

The word in the title is “yet.” I don’t think this is a story about disappointment. Electrification did eventually rewrite manufacturing — it just did it on the timeline of floor plans, not the timeline of motors. The gains from AI will show up on the timeline of workflow redesign, not model releases, and that timeline is set by how quickly people are willing to look at their own process and say: this shape only made sense under a limit that’s gone.

I’d genuinely like to hear from anyone who has rebuilt one of their own workflows this way — and specifically, which part broke first. In my experience it’s never the part you plan for, and that’s the part I’m still getting wrong.