The human cost hidden inside velocity

A team I worked with closed three consecutive quarters at or above their velocity target. Releases went out on schedule and every commitment on the planning board was honoured. Eight months in, the team was a different place. People had stopped talking to each other about anything that was not a ticket, and nobody paired by accident anymore. Retros stopped surfacing problems and started surfacing blame. The work was still going out, and the team was quietly going toxic. Nothing on the velocity chart had moved.

That gap, between what the velocity number shows and what is happening inside the team, is the one I want to point at. The dashboard cannot see the conversation that stopped happening at the coffee machine or in the team chat, the engineer who learned to ship a fix without asking what it was fixing, or the spec that got executed cleanly because nobody felt safe enough to push back on it. It also cannot see what is happening to the work itself: surface fixes that close tickets and re-open them three sprints later, debt piling up where root-cause investigation used to live, reviews waved through because the reviewers were slammed too.

The 2025 to 2026 conversation around delivery measurement has already conceded this gap: DORA added rework rate, and the SPACE and DevEx work argues that satisfaction and friction belong on the same page as throughput. I am not arguing with those frameworks, only pushing harder on the part they soften. Velocity is legitimate as a short-to-mid-term instrument and corrosive as a culture. You have to know which of the two your team is living in this quarter, and that is not a question the dashboard gets to answer on its own.

Use velocity as a benchmark

Velocity is a tool for asking questions about the team. When it drops, the question is why, and when it climbs, the question is how, and both answers are worth sharing across teams. The moment the number itself becomes the thing you report upward and compare across teams, it has stopped being a benchmark and started being a target, and from that point on the team will quietly reshape its work to keep the number where it needs to be. Nobody does this cynically. An engineer who knows a dip in the chart means questions from above will pad the next estimate or split the next ticket, because padding is cheap and explaining a dip is not, and every one of those small trades looks reasonable from where they sit.

Run velocity-first with an expiry date out loud

There are real moments when velocity-first is the correct call: a launch cliff, a regulatory deadline, a competitive window, a bottleneck the team itself is frustrated about. In those moments, run the sprint, and say two things out loud: when the window closes, and what you are willing to trade for the speed, whether that is code-review depth, exploration time, or the unallocated thinking hours. A bounded window the team agreed to does no lasting damage. A window that quietly becomes the normal way of working is how a factory forms, and the structural difference between the two is an expiry date that holds, which means refusing to slide it when the date arrives and the pressure has not gone anywhere.

Ask the sustainable-or-factory question, then watch what disappears

In 1:1s I ask a version of this out loud: are we building a sustainable team, or a factory that can churn work fast and treats every person as a replaceable part? It is a forcing question. People answer it less with the words they pick than with what they tell you they have stopped doing:

• Ten-minute hallway conversations that were not about a ticket.
• Asking someone how a debugging session went after it ended.
• Pairing on something for half an hour because it was interesting.

None of those show up in a ticket count, which is why they are the first things to go when the number is under pressure. When that kind of interaction has been compressed out of a team, the conversion to factory mode has already happened, whatever the dashboard says, and the signal shows up weeks before the velocity chart moves.

Hold the line against the AI-velocity fantasy

The most consistent pressure on your team this year arrives from above as a fantasy about AI, and it lands in the same shape every time: why is velocity not 10x with AI. It comes from someone who has been reading external commentary rather than writing code, it costs its asker nothing to raise, and left unanswered it is the engine that pushes a sustainable team into factory mode faster than anything else I have seen.

You can hold this line, because the technical ground truth is on your side, and holding it means surfacing the prerequisites the question skips:

• Training time.
• Pipeline work to let the tooling reach the code.
• A realistic understanding of which parts of the job compress and which do not.

A leader who has lost the ground truth cannot do this, which is why staying technical, deliberately is the upstream defence against the fantasy.

Read retros and incentive ceilings as the team's involuntary honesty channels

Two channels are hard for a team to fake for long. The first is retro language. In factory-mode retros, the same situation surfaces as fault: "the specs were not clearly given to me, this slowed me down, next time give me proper specs." In sustainable-mode retros, it surfaces as something to solve together, and the engineer taking the item is committing to fix it rather than defending themselves. The shift is small in any single retro and unmistakable across three of them in a row.

The second is incentive arithmetic. Velocity-first teams run on individual incentive (bonus, equity event, promotion, recognition), and every individual incentive has a ceiling. When the engineer hits it, or is told no, the engine for the sustained pace disappears, and they either chase a higher incentive elsewhere or stay and disengage. This is arithmetic rather than a theory of motivation: every org has a comp ceiling, and a team running indefinitely on incentive alone collides with it on a known timeline.

Read the work itself

Retros and incentives are two channels, and the third is the work itself. Factory-mode teams produce work the velocity chart cannot grade: surface fixes that re-open three sprints later, root-cause investigations that never started because they were invisible to the ticket count, reviews that signed off because the reviewer was slammed too. The team is shipping more tickets and more debt at the same time, and the dashboard cannot tell you which it is producing more of, so once a quarter, read a slice of recent PRs the way you read retros.

Name what sustainable looks like

Pointing at the absence of factory signs is easy. Naming what sustainable looks like in its own right is harder, and I triangulate it from three signatures:

• An honest happiness signal, whether that comes from a formal survey or just from how 1:1s feel.
• The attrition trend over the last few quarters.
• The tone of retros.

Any single one of them can lie for a quarter, which is why I want all three before I believe the picture.

Call the deliberate slow-down when impact is the bigger goal

The most surprising thing I have watched here is what happens when a team that is hitting every target deliberately slows down, because the bigger goal is impact. Fresh eyes show up, people notice the thing they were too busy to investigate last quarter, and unallocated time turns into ideas that velocity-first would have compressed out. The outcome over the following quarter is regularly larger than anything the previous pace produced. I will not claim a precise multiple, but the mechanism is real and I would bet on it again.

When the sprint is the right call

None of this means refuse the sprint. Velocity-first is correct when the prerequisites are met: there is a real cliff, the window has a date, and the team has named what it is trading. You get into trouble when you let the number stand in as the answer to "how is the team", because that question has a slower and less measurable answer, and the dashboard will keep offering you the fast one for as long as you let it.