Linear is great at tracking what your team ships. It is not great at telling you who is shipping it.
If your team has five engineers, Linear can tell you that you closed 48 points last sprint. It won't easily tell you that two engineers closed 40 of those points, and three others closed 8 combined. That difference matters — a lot.
This is the gap between team velocity and velocity per engineer. And it's the gap most engineering managers hit when they try to use Linear for real performance visibility.
Why team velocity is not enough
Aggregate velocity is a useful number. It tells you whether your team's output is growing, stable, or declining over time. That's worth tracking.
But it hides everything underneath. A team hitting its velocity target could be running on two engineers carrying everyone else. A team whose velocity looks flat could have three engineers dramatically accelerating while two others are stuck on the same blocked ticket for two weeks.
You can't see any of that in Linear's default views.
The questions that actually matter in a weekly engineering sync are:
- Who shipped the most this sprint, and is that sustainable?
- Who shipped the least, and is it because they're blocked, ramping up, or working on something large?
- Is the same engineer always carrying the sprint?
- Is someone's velocity trending down — a sign they're struggling before they say anything?
None of these questions have good answers in Linear out of the box.
What "velocity per engineer" actually means
Velocity per engineer is simple: how many story points (or issues, if your team doesn't use points) did each engineer close in a given sprint or time period?
Tracked over time, it becomes a trend line for each person. That trend line is one of the most useful signals in engineering management.
A trend line going up usually means an engineer is growing into their role, getting faster, or taking on better-scoped work.
A trend line going down usually means something is wrong: an unclear project, too many meetings, external dependencies killing flow, or something personal. None of those show up in the issue tracker — but the velocity trend shows up first, before the engineer says anything.
How to get per-engineer velocity from Linear
Linear does not have a built-in view for this. Here is what most teams do instead.
Option 1: Manual spreadsheet
Export your issues to CSV (or use Linear's API), group by assignee, count points or issues per person per sprint. Build a chart. Update it every sprint. This takes 30 to 60 minutes per sprint if you're disciplined about it. Most teams start here and stop after three sprints.
Option 2: Linear's Insights (Pro)
Linear's Insights section shows some per-member data — issues created and issues completed. It's a starting point but lacks trend visualization, sprint-over-sprint comparison, and any sense of whether velocity is improving or declining.
Option 3: Connect a dedicated analytics layer
Tools built specifically on top of Linear's API can compute per-engineer velocity automatically, show it as a trend over multiple sprints, and surface it in a dashboard you don't have to rebuild every week.
SprintIQ does this. It connects to your Linear workspace in about 30 seconds (read-only OAuth, no data written back), pulls your issue history, and shows you:
- Velocity per team member across the last 12 weeks, in a chart you can actually read
- Week-over-week and sprint-over-sprint trends per person
- Which engineers are trending up, flat, or down
- Total team velocity broken down by contributor
It resyncs daily. You open the dashboard before your weekly sync and the numbers are already there.
How to use per-engineer velocity without it becoming surveillance
The most common concern when engineering managers start tracking individual velocity is that it will feel like surveillance to the team. That concern is valid.
Individual velocity numbers should never be used as a performance rating in isolation. An engineer who closes 10 points in a sprint while spending 40% of their time reviewing PRs and unblocking teammates is delivering more value than the raw number shows.
Used well, per-engineer velocity is a signal for the manager, not a score for the engineer.
Use it to spot someone who might be struggling before they ask for help. Use it to notice when one person is consistently carrying the load. Use it to make sure your sprint commitments reflect your team's real capacity, not the average performance of your two strongest engineers.
When you have a conversation with an engineer about their velocity, lead with curiosity, not judgment. "Your velocity dropped the last two sprints — is there something making the work harder right now?" lands very differently than "your numbers are down."
What to track alongside velocity
Per-engineer velocity is most useful in combination with two other signals.
Blocker time per engineer. How long is each person's work sitting in a blocked state? A low velocity combined with high blocker time tells a clear story: it's not a productivity issue, it's a dependency issue.
Cycle time per engineer. How long does it take each person's tickets to move from started to done? A long cycle time might mean they're taking on tickets that are too large, or that they're getting pulled off work mid-sprint.
Together, velocity, blocker time, and cycle time give you a reasonably complete picture of where each engineer actually is — without needing to micromanage or ask for daily status updates.
The bottom line
Linear tracks the work. It does not tell you who is doing it, whether they are getting faster or slower, or whether the load is distributed in a way that is sustainable.
Per-engineer velocity, tracked over time, is the metric that bridges that gap. You can build it manually from Linear's CSV export, you can piece it together from Linear Insights, or you can connect a tool that computes it for you automatically.
If your team runs on Linear and you want visibility into individual velocity without a spreadsheet, SprintIQ connects in 30 seconds and is free to start.