Take whatever activity dashboard you have and sort ascending. There is a decent chance your most valuable engineer is near the top of that list.
Fewer commits. Less "active" time. Lower ticket throughput. Long stretches where the tooling says not much is happening.
Managers usually respond to this in one of two ways. Either they conclude the metric is broken and quietly stop looking at it, or they conclude the engineer has coasted since their promotion. The second conclusion is more common than it should be, and it is usually wrong.
I want to argue something slightly stronger than "metrics are imperfect." I think this specific failure is structural, it gets worse as people get more senior, and no amount of metric tuning fixes it.
What senior work actually consists of
Watch what a genuinely strong senior engineer does in a week.
They spend an hour with someone stuck on a problem, and that person ships two days earlier than they would have. Nothing appears on the senior's record. The two days show up on someone else's.
They read a design doc and ask the question that kills a six-week project which was going to fail. The value is enormous and permanently invisible, because you cannot measure a disaster that did not happen.
They delete 2,000 lines of dead code. Net negative on any additive metric.
They spend a morning on a review that catches a subtle concurrency bug. The reviewer's contribution is a comment thread. The author's contribution is a merged PR.
They say "we should not build this," and are right.
Every one of those is high-leverage. None of them generates the activity signature the tooling is counting. And the more senior someone becomes, the larger the fraction of their week those activities represent — which means the measurement error grows with the person's value. That is a bad property for a metric to have.
Why this is not a tuning problem
The instinctive fix is a better metric. Weight reviews more. Count mentorship somehow. Add a multiplier for architecture work.
It does not work, for two reasons.
The first is that the value being created lands on other people. When the senior unblocks someone, the throughput appears in that person's numbers. Any individual-attribution scheme has to decide where to put the credit, and there is no honest answer — it genuinely belongs to both, and if you count it twice your totals stop meaning anything.
The second is gaming, and this is the more serious one. Every metric that gets weighted gets optimised. Weight review comments and you get more comments, not better review. Weight mentorship and you get logged mentorship. You will have converted a real activity into a performance of that activity, and destroyed your ability to see the original.
This is not cynicism about engineers. It is what happens to any measure that becomes a target, in any profession.
The frameworks agree, and people ignore them
Both DORA and SPACE — the two frameworks with actual research behind them — explicitly warn against individual measurement. SPACE goes further and says productivity cannot be captured by any single metric at all, which is the entire reason it has five dimensions.
People adopt these frameworks and then build individual dashboards anyway, because that is what was wanted in the first place. The framework becomes decoration on a decision already made. If you are going to use DORA and SPACE, the constraint about measuring teams is not the boring part to skip. It is the finding.
What I would actually do
Stop trying to rank individuals with data, and be honest that this is a limitation rather than pretending the dashboard is nearly there.
For evaluating a senior person, three questions do more work than any tool:
What would break if they left tomorrow? Who got faster because of them this quarter? Which expensive mistake did not happen because they were in the room?
None of those are on a screen. All of them are obvious to a manager who is paying attention to the team rather than to the metrics. And if you cannot answer them about someone senior, that is worth knowing too — it might mean they have disengaged, or it might mean you have not been close enough to the work to see it.
So what is activity data for
This is where I should be clear about what we build, since we sell an analytics tool and I have just spent several hundred words arguing against a common use of one.
Activity data is good at describing systems. Whether the team has any uninterrupted time. Whether meeting load has crept up since the reorg. Whether one person is absorbing every escalation. Whether the work is distributed sanely across the group.
Those are conditions, and conditions are what a manager can actually change. Fixing a fragmented calendar helps everyone on the team; ranking the team helps nobody and makes the data worse, because the moment people know they are being scored on activity you get activity instead of work.
That is why ProdView reports at team level and shows every employee their own data. Not primarily as an ethical position, though it is one — as a measurement one. Data people trust is data that still means something in six months. The wider argument is in how to track employee productivity and focus time versus active hours.
The short version
If your best engineer looks bad on your dashboard, the dashboard is doing exactly what it was built to do. It is counting activity. They have moved past activity into judgement, and judgement does not have a unit.
Go and ask the three questions instead. They take five minutes and they are more accurate than anything I can sell you.