Compare Engineering Team Performance
Leadership is asking how your teams compare — frontend vs. backend, platform vs. product, old guard vs. the new squad. You need honest numbers, not a gut feeling.
The Problem
Most git analytics tools report per-developer or per-repository, not per-team. That leaves you doing one of two unpleasant things:
- Exporting per-developer data to a spreadsheet and manually grouping by team — fragile, time-consuming, and out of date within a week
- Reporting individual velocities that read as rankings and create political problems
You need team-level aggregation that's a first-class feature of the tool — configured once, available in every view, and honest about the noise.
The Workflow
First: Prepare Your Repository
Before measuring team performance, make sure developer identities are merged, suspicious commits are handled, and exclusion patterns are configured. Dirty data produces misleading team comparisons.
1 Define Your Teams
Open the Settings tab in Git Insight and find the Teams section. Create a team for each group you want to compare — e.g. "Frontend", "Backend", "Platform", "DevOps".
For each team, add the git identities (name + email pairs) of its members. The list is populated from your project's git history.
2 Handle Merged Developers Carefully
If you've already used Merge Developers to combine multiple accounts per person, you still need to add every raw identity to the team. Team filtering matches by raw name + email from commits, not by the merged display identity.
Tip: developers with multiple laptops typically have 2–3 raw identities — check all of them are in the right team.
3 Compare Velocity by Team
Open Developer Statistics and set a meaningful date range — at least one quarter, ideally six months to smooth out vacations and milestone cycles.
Click the Teams button in the toolbar and select one team. On the Facts tab, record:
- Lines changed per workday — team-level velocity
- Average per developer per workday — individual output averaged across team members; this is the right number for comparing teams of different sizes
Switch to the next team, re-select in the popup, and compare. The cache makes switches instant.
4 Investigate Outliers
If one team looks drastically slower, don't stop at the number. Check the Changes tab for that team — what files are they touching? A team modifying critical infrastructure with small, careful commits can easily show less velocity than a team writing CRUD UIs, even though the work is harder.
10 lines in the build system are worth more than 100 lines on a form. Velocity is a signal, not a verdict.
5 Commit Team Configuration
Team definitions live in .idea/gitInsight.xml. Commit this file so the whole engineering org sees the same team structure — and next quarter's comparison uses the same definitions as this one.
6 Prepare the Report
For each team, report two numbers rather than one:
- Team-wide lines changed (total output signal)
- Average per developer per workday (individual productivity signal, normalized by team size)
Pair each with a qualitative note from the Changes tab — what kind of work the team did. Leadership decisions based on two numbers plus context are much stronger than a single velocity score.
Common Pitfalls and How to Avoid Them
- Comparing teams of different sizes directly — always use per-developer averages, not totals
- Ignoring code category — test code, migrations, and config dominate raw counts; use categories to separate product code
- Short time windows — one sprint's numbers are pure noise; 3 months minimum, 6 months preferred
- Ranking teams publicly — internal analysis is fine, public leaderboards damage trust and incentivize the wrong behavior
Start Comparing Team Performance Today
Install the free trial, set up your teams in Settings, and get honest team-level metrics in minutes.
Install Free Trial