How Span attributes metrics to teams

Summary: Span attributes engineering activity to the person who did the work, then rolls it up using current team membership. This means team-level metrics — including historical ones — always reflect the people on the team today. If someone changes teams, their full history moves with them.

How it works

Every contribution in Span (a PR, a commit, a review, a deployment, an AI-assisted coding session) is recorded against the individual who produced it. When you view a team-level metric, Span joins that activity to the team's current roster.

Example: Priya spent Q1 on Team A and moved to Team B in April. When you open a Team B trend chart covering January to June, Priya's January-to-March work appears under Team B, not Team A. Team A's Q1 numbers no longer include her.

This applies to all standard metrics: PR cycle time, throughput, DORA metrics, coding metrics, review metrics, and AI adoption metrics.

The one exception: surveys

DevEx and Pulse survey results are grouped by the team each respondent was on when the survey was sent, not their current team. A survey response is a point-in-time snapshot of how someone felt, so freezing it to the roster at launch is the only reading that makes sense. Activity metrics are cumulative work, which is why they behave differently.

Why we designed it this way

There are only two options for team attribution, and neither is free of trade-offs. Metrics can follow the person (what Span does) or follow the team (a historical roster snapshot at each point in time). We chose person-based attribution for four reasons.

It answers the question managers actually ask. "How is my team doing?" almost always means the people you have today. Person-based attribution keeps a trend line apples-to-apples against the roster you're actually responsible for.

No work gets orphaned. Every contribution reconciles back to an individual, so an engineer's own history is always complete and never split across teams.

It survives org change. Teams get renamed, split, merged and retired constantly. With historical attribution, a team that no longer exists still owns metrics that nobody can see or act on, and a team formed from a merge has no history at all.

It stays correct when your org chart gets corrected. Membership data is frequently backfilled or fixed after the fact. If history were frozen to past snapshots, a data-entry mistake would be permanent.

What historical attribution would cost

If Span pinned metrics to team membership as of each date instead:

• Trends would still move on roster changes, just invisibly. The metric would measure a different set of people at every point in time, so a dip could be caused by churn rather than by anything about how the team works.

• You'd be reviewing history you can't act on. Numbers would be driven partly by people who have since left the team.

• Reorgs would fragment both views. Team history would break at every split or merge, and each engineer's individual history would scatter across teams.

• Reconciliation would get harder. The same PR could land in two different teams depending on the date window you chose.

What this means in practice

• Trend charts for a team reflect the current members' activity over the selected period, not who was on the team at each point in time.

• After a reorg, historical team-level metrics shift to match the new team assignments.

• Period-over-period comparisons for a team are only strictly comparable if the roster didn't change in between.

Working with this in monthly reviews

If you run recurring operational reviews on team metrics, a few practices keep the numbers readable through roster changes.

Check whether a membership change actually happened. Retroactive shifts are triggered by a change to team membership, not by someone being inactive. Someone on parental leave, sabbatical, or extended PTO does not move their history unless they are removed from the team in Span. If you want a team's trend to stay stable through a leave, leave the person on the team.

Prefer per-contributor metrics over team totals. Metrics normalized per active contributor (throughput per engineer, median cycle time) hold up much better through roster changes, because they don't move when headcount does. Team totals will always shift when the team's size shifts.

Annotate roster changes in your review. When someone joins or leaves, note the date alongside the trend. Most unexplained step-changes in a team metric turn out to be roster changes rather than process changes.

Use the individual view for people who moved. If you want to understand a specific engineer's trajectory across a team change, their individual profile carries their full history in one place.

Frequently asked questions

Why did my team's numbers from six months ago change?

Almost certainly a membership change. Someone joined the team (adding their prior history), left the team (removing theirs), or was reassigned. Nothing about the underlying contribution data changed.

Can I see a team's metrics as of a past date, using the roster from that time?

Not today. Historical membership is used only for surveys. If as-of-date reporting matters for your workflow, tell your Span contact — it's an active area of feedback and it helps us to hear the specific use case.

Does this affect individual metrics?

No. Individual metrics are unaffected by team changes, since the data is attributed to the person in the first place.

What happens when a team is deleted?

Its members' activity follows them to whatever teams they belong to now. Nothing is lost at the individual level.

Questions about how this affects a specific report? Reach out to your Span contact and we can walk through your dashboard together.