Measure engineering
productivity from code.
See how much your team ships, scored by impact, not lines or commit count. People and agents, same yardstick.
ETV = Engineering Throughput Value: one impact score per code change.
Trusted by engineering teams




One score for each code change.
Each code change gets one score, in Engineering Throughput Value (ETV). A 2-line fix to the payments path can outweigh 400 lines of renamed variables.
feat(metrics): add five-way work categorization (#1482)
This commit introduces a new capability that elevates tests and documentation into first-class, independent buckets, spanning the scoring engine, the schema and the reporting UI.
To support this, CategorizeFileChange now returns a five-way split, and work_mix stores the per-category totals so a report can aggregate them without re-reading the diff.
Obsolete AST-based pairing routines were removed in the same change, which is why part of it grades as maintenance rather than as a feature.
Related entities
Knowledge graph showing relationships to other commits, PRs, and issues.
- Pull request#1482Merged
Five-way work categorization
- Issue#1435Closed
Tests and docs disappear into maintenance
- Commita41c7f0Follow-up
Backfill work_mix for Q1 commits
Same score for people and agents.
A commit counts the same whoever typed it.
- 01File changeGraded from the diffA model reads it in the context of the repository.0.07 – 0.14ETV
- 02CommitSum of its file changes150 files here, most worth little on their own.2.80ETV
- 03Pull requestSum of its commitsWhat reviewers already argue about, now with a number.8.40ETV
- 04Developer, 12 monthsSum of their merged pull requestsA quiet month of hard work beats a loud month of renames.354.2ETV
- 05Team, 12 monthsSum of its developers71.0 a month, the number hiring can’t inflate.781.0ETV
Every team number traces back to a file change.
How a change is graded against your repository
Repository map
Modules, services and stores, and how they connect. Every diff is graded against this map.
Imports and call graph
Every push re-reads what depends on what.
Ownership from history
Who touched each module, and when.
Docs, PRs and issues
Linked to the module they discuss.
See what the month was made of.
Every month is split into features, maintenance, tests, docs, and fixes. A spike can be new features or the same bug fixed three times. Compare it with your team’s own pre-AI baseline.
Work split by type each month.
- 4 ETV
- 31 ETV
- 41 ETV
- 33 ETV
- 78 ETV
- 67 ETV
- 103 ETV
- 98 ETV
- 91 ETV
- 147 ETV
- 88 ETV
A monthly report, linked to commits.
What shipped and what got in the way, each claim linked to its commit.
The team delivered the foundations of the checks service and quota management, alongside a redesign of the cost insights dashboard. Volume dropped, and the month went into security hardening and architectural refactoring instead.
Shipped the checks read path and wired PR checks end to end, backend to UI 1a84b86b (Paige)
Introduced a company context agent with background research and onboarding setup f642dca5 (Paige)
Established the data model, migrations and store layer for the quota system 3487b86a (Marcus)
The reporting module needed repeated fixes to correct metric aggregation bbe7bb6f (Sam)
Security hardening took a batch of authorization fixes after a pre-release pen test d8f09e07 (Paige)
Refactoring decoupled the reconcile package from the collector service 4a30bb48 (Marcus)
Benchmark your team against itself.
Start with your own team four quarters ago. Add other companies later, for board context.
Green is above your baseline, red is below.
Your team against your team, four quarters ago
- Q2 2026 (now)You58.9 ETV
- Q2 2025Baseline24.8 ETV
Same code, same team, same review bar. When this number moves, you moved it.
Against the other teams in your org
2nd of 48% behind the Platform team- Platform team+9%64.1 ETV
- Checkout teamYou58.9 ETV
- Growth team−30%41.2 ETV
- Billing team−51%28.7 ETV
The team on a decade-old payments service loses this chart and can still be your best.
Against other companies on the same unit
Above median40% above the cohort median- Peer cohort, top quartile+21%71.4 ETV
- Checkout teamYou58.9 ETV
- Peer cohort, median−29%42.0 ETV
- 500 OSS Index−40%35.6 ETV
Good for a board meeting, bad as a goal. Their number carries their stack.
The same comparison, in public.
The same engine runs live on the top 500 open source projects. Read the direction, not the level.
Engineering productivity measurement questions.
How does engineering productivity measurement work?
Navigara grades each code change in repository context, then compares equal periods for the same team. It adds work mix, quality, and priorities, because commit count can’t tell a feature from a typo fix.
Where should we start with developer productivity measurement?
With your own history. Navigara backfills twelve months of commits, so your baseline exists before the first meeting. Note staffing or scope changes in that window before you compare periods.
Does engineering productivity measurement assess individual performance?
It measures work. Mentoring, planning, interviews, and anything outside the connected repositories never reach a diff, so it misses them. Use it to start a conversation with an engineer, and bring the context the code cannot show.
How does developer productivity measurement handle fixes and maintenance?
Each category is scored and reported separately: features, maintenance, tests, documentation, and fixes. You see the work mix shift month by month, and cleanup is reported as cleanup.
Can engineering productivity measurement isolate the effect of AI?
Not on its own. Headcount, scope, and process change in the same quarters AI arrives. Navigara keeps those changes beside the trend, and the AI ROI page adds tool costs and roadmap context.
What should we review after a developer productivity measurement?
Open the commits behind the biggest change and ask the team what happened. Pick one thing to change, then compare the same measures next month. Read the engineering productivity measurement method.
See where your teams
stood a year ago.
Your first readout covers twelve months, backfilled from your existing commits, in the first week.