What happens when people switch teams or leave?

Swarmia tracks the historical team memberships of contributors over time. Contributions made for one team will stay correctly attributed, even if their author later switches teams or leaves.

In any organization, people switching teams or leaving the company is a common occurrence. Swarmia is designed to handle these changes automatically to ensure your engineering metrics remain accurate and reflect the reality of who did the work, and when.

How it works: Automatic backdating with a smart heuristic

To keep your data accurate, Swarmia uses a smart heuristic to manage historical team memberships. Here’s how it works in different scenarios:

Joining the company

When a new person joins your organization and is added to a team in Swarmia, their membership is backdated. This ensures that any work they possibly did before being formally added to the team in Swarmia is correctly attributed to them and their new team.

New person joining the organization and team without any existing contributions

A person joining a team later is correctly attributed all work they did previously

Switching teams

When a person moves from one team to another, Swarmia detects this change. The new team membership is backdated to the point when they left the previous team. This correctly attributes work done during the transition period to the new team, preventing data gaps.

We consider 10-day window detecting team switches, up to 7 days gap and up to 3 days overlap.

Persons membership ended in Team A and joined Team B within 7 days is considered a valid team switch. The gap between is not attributed to either of the team.

Membership in Team A ended under 3 days, the work done during the overlap is attributed to both teams.

The gap between team switch was too long (over 7 days), Team B does also get attributed for the historical work. Team A only gets attributed the work until the membership ended.

Joining additional team

If a person is added to a new team without leaving another (e.g., joining a "Staff Engineers" team), the new membership is simply backdated. Their historical and present work will be attributed to both teams.

Person joined Staff Engineers team without leaving Team A gets their work attributed to both teams

Leaving the company

When a person leaves the organization and is removed from their teams (e.g., by being removed from the GitHub organization), their team memberships in Swarmia are correctly ended. Their historical contributions remain attributed to the teams they were part of when the work was done.

Persons contributions remain attributed to the team(s) they were part of

Team hierarchies

This tracking applies to memberships of contributors, but does not extend to team hierarchies. That is, if you move a team to another parent team, the past contributions of that team will move with it.

Example: Your team A belongs to a parent team Analytics, but is later moved to the parent team DevOps:

After the change, if you look at (for instance) the cycle time metrics of the DevOps team, you'll see the historical contributions of team A as part of it, even though A was part of Analytics at the time the contributions were made.

This is by design: we consider teams a fundamental unit of the organization, and thus consider their past contributions as being forever theirs. But during reorgs, teams might get shuffled around to different groupings. We consider the metrics of those groups to be the metrics of the teams they're presently composed of. Any alternative to this would leave you with team selectors full of teams that no longer exist.

Deleting teams

If a team is deleted from Swarmia, it also disappears from any metric views where it was shown. By extension, this means their past contributions disappear from any parent teams the team belonged to.

Example: Your team A belongs to the parent team Analytics, but A is disbanded and deleted from Swarmia. Its members are assigned to other teams.

After the change, if you look at (for instance) the cycle time metrics of the Analytics team, the historical contributions of members of A are no longer included (unless the same contributors also belonged to another child team of Analytics which was not deleted).

This is intentional: including those past contributions would cause inconsistencies between the summary metrics of Analytics, and its constituent child teams. For instance, you might see the team Analytics having merged 2000 pull requests over the past 6 months, but when you drill in to see the metrics of its child teams, there are none.

Correct offboarding

The recommended practice is to remove the person from your GitHub organization. This will automatically end their team memberships in Swarmia while preserving their historical data. You should not delete the author's profile from Swarmia, as this will permanently remove their data.

Exceptions

During a transitional period, some views do not yet take historical team memberships into account, such as the investment balance and focus summary.