How Span attributes metrics to teams

Last updated: October 27, 2026

Span attributes engineering activity to the person who did the work, then rolls it up using current team membership, so team metrics, including historical ones, reflect the people on the team today. Deployments and incidents are the exception: Span attributes them to teams and services, never to individuals.

Why it matters

When someone changes teams, their full history moves with them. That keeps a trend line comparable against the roster you're responsible for today, but it also means past team numbers shift after a reorg. Knowing the rule explains most "why did last quarter change?" questions.

There are two options for team attribution, and both have trade-offs: metrics can follow the person (what Span does) or follow the team (a roster snapshot at each point in time). Span chose person-based attribution for four reasons:

It answers the question managers ask. "How is my team doing?" almost always means the people you have today.
No work gets orphaned. Every contribution reconciles 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. With historical attribution, a retired team would still own metrics nobody can act on, and a team formed from a merge would have no history.
It stays correct when your org chart gets corrected. Membership data is often backfilled or fixed after the fact. If history were frozen to past snapshots, a data-entry mistake would be permanent.

If Span pinned metrics to membership as of each date instead, trends would still move on roster changes, just invisibly; you'd review history driven partly by people who have left; reorgs would break team history at every split or merge and scatter each engineer's history; and the same PR could land in different teams depending on the date window.

How it works

Person-level activity. PRs, commits, reviews, issues, and AI-assisted coding sessions are recorded against the individual who produced them. When you view a team metric, Span joins that activity to the team's current roster. Parent teams include their child teams' members. This applies to PR cycle time, throughput, coding metrics, review metrics, and AI adoption metrics.

Deployments. Deployments have no individual owner. Span attributes each deployment to a team in one of two ways:

By service (default): the deployment goes to the team that owns its service.
By PR author: when Span links deployments to the PRs they shipped, the deployment goes to the current teams of the authors of those PRs. Span turns this on for your organization on request.

A deployment Span can't attribute, for example one with no service owner, or no linked PRs in PR-author mode, counts at the organization level. It appears in organization totals but not when you filter to a team.

Incidents. Incidents also attribute to teams, not people. Span links each incident to its team directly and counts it at the organization level when no team is set.

Surveys. DevEx and Pulse survey results group 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 it stays with the roster at launch. Activity metrics are cumulative work, which is why they behave differently.

Working with this in recurring reviews

Check whether a membership change happened. Retroactive shifts come from a change to team membership, not from someone being inactive. Someone on parental leave, sabbatical, or extended time off doesn't move their history unless they're removed from the team in Span. To keep a team's trend 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 better through roster changes. Team totals always shift when team size shifts.
Annotate roster changes. When someone joins or leaves, note the date next to the trend. Most unexplained step changes in a team metric turn out to be roster changes.
Use the person view for people who moved. A person's page carries their full history in one place.

Things to know

Worked example: Priya spent Q1 on Team A and moved to Team B in April. On a Team B trend chart for January to June, Priya's January-to-March work appears under Team B. Team A's Q1 numbers no longer include her. If Priya merged 30 PRs in Q1 and Team A merged 120 in total, Team A's Q1 total now reads 90.
After a reorg, historical team metrics shift to match the new assignments. Period-over-period comparisons for a team are strictly comparable only if the roster didn't change in between.
Deployments never show per person: deployment frequency and other deployment and incident metrics can't be broken down by person. In PR-author mode, a deployment that shipped PRs from two teams counts for both teams.
Individual metrics aren't affected by team changes, because the data is attributed to the person in the first place.
Deleted teams: members' activity follows them to whatever teams they belong to now. Nothing is lost at the individual level.
No as-of-date view: you can't view a team's metrics using its roster from a past date. Historical membership is used only for surveys. If as-of-date reporting matters for your workflow, tell your Span account team about your use case.

How to use the DORA API to send deployment activity to Span

Deployments Per Week

How to read Span's "/ week" metrics

Span DX Surveys: Complete Guide

Need help?

Contact your Span account team or reach out to support@span.app.