Your team hit its velocity target last sprint. 42 points, right on track. The chart looks healthy, the standup is smooth, and you feel good going into the weekly sync.
Then you look closer.
Two engineers closed 36 of those 42 points. The other three closed 6 combined — one because they were ramping up on a new codebase, one because they spent the week reviewing PRs and unblocking others, and one because a critical dependency had been stalled for eight days and nobody flagged it.
The number was fine. The team was not.
This is the problem with team velocity: it is a summary, not a signal. It tells you what happened in aggregate, not what happened to the people doing the work. And in engineering management, the aggregate almost never tells you what you actually need to know.
The math that hides the story
When you track velocity at the team level, you are averaging across people with very different situations. A sprint where one engineer closes 30 points and four others close 2 each looks identical to a sprint where all five engineers close 8 points each. The number is 38 in both cases. The health of the team is completely different.
The first scenario is unsustainable. The high-performing engineer will burn out, leave, or start coasting. The four others might be blocked, overwhelmed, or quietly disengaged — and you have no way to tell from the team number alone.
The second scenario is a healthy, distributed team. Everyone is contributing, the load is balanced, and you have real capacity to rely on.
Team velocity cannot distinguish between these two situations. That distinction requires looking at the individual level — which most teams never do, because it takes time to pull manually from Linear and feels uncomfortably close to surveillance.
Why individual velocity feels risky — and why it isn't
The concern engineering managers most often raise about tracking per-engineer velocity is that it turns into a scoreboard. Engineers compete for points, game the estimation system, or feel watched.
That concern is valid if you use the data the wrong way. If you bring per-engineer velocity into performance reviews and rank people against each other, you will create exactly those problems.
But used correctly, individual velocity is not a score — it is a leading indicator. It tells you where to look, not what to conclude.
An engineer whose velocity drops for two consecutive sprints is showing you a signal before they say anything. Maybe they picked up a ticket that is much larger than estimated. Maybe they are stuck on an external dependency. Maybe something is wrong personally and they are struggling to stay focused. The velocity drop does not tell you which one — but it tells you to have a conversation before it becomes a retro item.
That is the difference between managing with data and managing by surprise.
What team velocity should and shouldn't tell you
Team velocity is still worth tracking. It tells you whether your team's overall output is trending up, flat, or down over time. It helps you make sprint commitments that are grounded in reality. It surfaces whether a team is consistently over-committing or sandbagging.
What it should not be expected to do is tell you who is struggling, whether the sprint load is fairly distributed, or whether one person is quietly carrying everyone else through the quarter. Those questions require individual data.
The engineers who carry teams are often the worst at asking for help. They absorb the extra work, close the extra tickets, and never complain — until they leave. By the time you notice the problem in team velocity, it is already a retention problem.
How to use per-engineer velocity without the downsides
The framing matters more than the data. When you look at individual velocity trends, do it with curiosity rather than judgment. A conversation that starts with "your velocity dropped last sprint — what's going on?" is very different from "your numbers are down."
The goal is to catch problems early enough to do something about them. A two-sprint velocity dip is a conversation. A six-sprint velocity dip that you never noticed is an engineer who has mentally left the team.
Track the trend, not the number. A consistent 8 points per sprint is not better or worse than a consistent 20. What matters is whether the trend is changing — and whether the change has an explanation you understand.
If you run your team on Linear, SprintIQ surfaces per-engineer velocity automatically, sprint over sprint, without any manual export. You can see the trend before it becomes a problem — which is the only time it actually helps.