I once sat through a quarterly review where engineering looked, on paper, excellent.
Cycle time was down. PRs were moving. The team had closed more tickets than the previous quarter, with no massaging of numbers. The dashboard looked better than it had in a year.
Then the product lead asked what had changed for customers.
The answer was embarrassingly thin. A few fixes. A few features in partial rollout. A dashboard cleanup nobody outside the company would ever notice. The team had been moving faster, and I had let myself feel good about it, because the alternative was admitting that a lot of energy had turned into little progress.
I have been suspicious of speed ever since.
Speed is seductive because it is visible. Managers get something to point at. Executives get a line for the update. Teams get the relief of feeling that the system is working.
Sometimes the system is working. More often, it is only moving.
The number was true
The annoying thing about bad productivity measures is that they are often accurate.
The team did merge more pull requests, move tickets faster, shrink the review queue, and tune the deployment pipeline. I am not interested in pretending those things do not matter.
They matter. They do not settle the question.
If the checkout flow gets slower, if support volume goes up, if the codebase becomes harder to change, if engineers spend the next two months cleaning up decisions nobody remembers making, then the speed was only one part of the story. Maybe the trade was deliberate. Maybe it was still worth it. But you cannot call that productivity just because the middle of the process got faster.
This is why I still respect the SPACE framework , even though frameworks usually make me itchy. It refuses to collapse developer productivity into one number. It puts activity next to performance, satisfaction, collaboration, and flow. That is the part people skip. They take the easiest column to instrument and let it stand in for the whole thing.
Activity is comforting because it looks like evidence. It only proves that activity happened.
The local optimum problem
Most speed improvements are local.
Code generation gets faster. Reviews get faster. Builds get faster. Deployments get faster. Each improvement can help. I have spent a lot of time pushing on exactly those things.
Local speed has a habit of dumping work somewhere else.
A team shortens implementation time and finds review has become the bottleneck. It shortens review time and finds QA cannot keep up. It automates QA and discovers nobody knows whether the feature solved the original problem. Each layer celebrates its own improvement while the work waits somewhere else.
The first time I learned this properly was not from a book. It was from watching a team keep everyone busy and still miss every meaningful date. Each person had a plausible explanation. Design was waiting for product. Backend was waiting for architecture. Frontend was waiting for API shape. QA was waiting for anything stable enough to test. Nobody was idle. Nothing was flowing.
That is what most managers get wrong about productivity. They look for idle people. They should look for idle work.
The work is what matters. Find where it waits and who has to touch it next. Find the missing decision, the reopened ticket, the blocked handoff, the gap between “done enough” and “actually useful.”
Those checks are less pleasant than “how fast are we moving?”
They are also harder to game.
AI made the old mistake cheaper
AI has made this conversation more urgent. I do not think it changed the underlying mistake.
We already confused output with progress. AI just made output cheaper.
If your organization believes productivity means “more implementation in less time,” then AI looks like an easy win. I use these tools and would not go back. They are useful for scaffolding, exploration, test drafts, annoying transformations, and all the small bits of work that used to consume attention without deserving much of it.
I do not trust any productivity claim that stops at generation speed.
Google’s 2025 DORA report has the tension I care about. AI adoption is widespread. Most respondents say it improves their productivity. DORA also says the benefit depends heavily on workflow clarity, internal platforms, fast feedback, and team alignment, while reporting a negative relationship with delivery stability.
That sounds right to me.
AI helps more when the surrounding system is already good. When the surrounding system is sloppy, it creates more material for the sloppy system to process.
I do not read METR’s early-2025 study as “AI makes developers slower.” That would be too easy, and probably wrong as the tools improve. I take a narrower lesson from it. Experienced developers working in familiar, mature repositories lost time to prompting, waiting, reviewing, and cleaning up generated work. METR later changed its experiment design because measuring task-level productivity had itself become messy.
That revision feels like progress. The work is messy.
If an AI tool saves three hours of typing and creates five hours of review, debugging, and second-guessing, the typing number is still true. It is also irrelevant by itself.
Where the time went
When a team tells me they are fast but frustrated, I look at the edges of the work. The visible part (code written, PRs reviewed, deployments through CI) is rarely the whole problem. The expensive time is quieter.
It lives in the two days before implementation when nobody has forced the product question. It lives in the Slack thread where three senior people nearly agree and still leave the decision unresolved. After release, it shows up when support learns the new behavior before the team does. Months later, it shows up in the rewrite that happens because the original work was correct against the ticket and wrong against the user.
I have made this mistake as a manager. More than once.
I pushed a team to make the visible part faster because the visible part was where I felt I had control. The real delay was upstream, in decision quality. We were feeding unclear work into a better machine and then acting surprised when the machine produced clearer versions of the wrong thing.
This is why DORA’s own software delivery metrics pair throughput with instability. Deployment frequency and change lead time are useful only when read alongside failure, rework, and recovery. Speed without that counterweight flatters you. It should not.
The dashboard I want to see
I do not want fewer metrics. I want less self-deception.
The DevEx research is useful here because it talks about feedback loops, cognitive load, and flow state. Those words sound soft until you watch a team lose a week to a test suite nobody trusts or a service boundary nobody understands. Then they stop sounding soft.
A good dashboard should make the real delays harder to hide.
Show me how long work sits after it is “done” but before anyone can use it. Show me how much rework came from unclear intent. Tell me which active projects have no named decision-maker, how often a shipped feature gets changed after evidence arrives, and which handoffs keep stopping the same kind of work.
None of those numbers is perfect. Some are barely numbers.
That is fine. The point is to start a better conversation.
After a project lands, I like asking what got easier.
If nothing got easier, be careful.
The work may still have been necessary. Compliance work often looks like that. Some migrations are mostly defensive. Some reliability work prevents pain instead of creating delight. Fine. Say that plainly. Be honest about the kind of value you produced.
But if every project ships and nothing gets easier for users, operators, support, future engineers, or future decisions, you are not looking at productivity. You are looking at organizational digestion.
The team is consuming work and producing artifacts.
That is not the same as progress.
What I would change as a leader
I would start smaller than most productivity programs start.
I would stop asking teams to explain why they are not faster until I had a better answer for why the current work matters. This alone would improve many organizations. Half the pressure to move faster is discomfort with unclear priorities wearing a delivery costume.
I would make active work painfully visible. Not a beautiful portfolio dashboard. A plain list that a director can read and feel slightly embarrassed by. Too many teams carry work because nobody wants the social cost of stopping it.
I would ask for a real outcome review after delivery. No ceremony, no slide deck. The people who sponsored, built, supported, and operated the thing, looking at what actually happened. Did it help? What did it break? Did users care? What would you stop doing if you believed the evidence?
I would treat deletion as delivery. Removing a confusing feature, killing a stale project, simplifying a workflow, deleting code nobody understands. These are productivity moves. They rarely look like speed because the artifact gets smaller.
I would watch senior engineers for signs that speed is being bought with their attention. This is one of the more common hidden costs now. A team appears faster because the strongest engineers are silently absorbing more review, more cleanup, more architectural correction, more “quick question” interrupts. The dashboard says throughput improved. The senior engineer’s calendar says otherwise.
You can run a team that way for a while. The cost eventually shows up in attrition, brittle architecture, or a senior engineer who suddenly has no patience left.
What to say out loud
There is a sentence I wish more leaders would say in public:
“We are moving faster. I do not know yet whether we are more productive.”
That sentence creates the right kind of discomfort.
It respects the work that happened while keeping the standard honest. The team is not being insulted. The leader is refusing to confuse motion with value.
Most engineering teams are not full of people avoiding work. They are full of people spending too much effort on work that entered the system too casually, waited in the wrong places, or never got checked against reality after it shipped.
Telling that team to go faster is lazy management.
The harder job is making more of the effort count. Clearer intent before work starts. Smaller batches. Faster feedback. Less work in progress. Better tests. A little more willingness to stop work that no longer deserves the team’s attention.
None of this is new. That is part of why it is annoying.
Productivity is not speed. It is what remains after the movement has been tested against something real.