Engineering performance, measured and scaled.
Every commit is graded in ETV. A pull request is the sum of its commits, a developer the sum of their pull requests, a team the sum of its developers. One unit, all the way up.
Trusted by engineering teams
feat(metrics): add five-way work categorization
Read onlyIntroduces a new capability that elevates tests and documentation into first-class, independent buckets, spanning the scoring engine, the schema and the reporting UI.
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.
Full commit message ⌄
- Files changed150
- Complexity25
- Engineering share55%
- AI augmentedYes
- Refactor2555%0.14ETV
backend/internal/agents/summary/llm.go
Include tests and docs metrics in prompt formatting
- Refactor2347%0.11ETV
frontend/components/reports/performance-report-content.tsx
Expand report charts to the five categories
- Feature1961%0.09ETV
backend/internal/agents/knowledge/routing.go
Route tests and docs through the scoring engine
- Migration838%0.07ETV
backend/store/migrations/0142_work_mix.sql
Store and aggregate the new metric fields
- +146 more files in this commit2.39ETV
It starts at the file change, because that is where the work is.
Counting commits or lines measures how much was typed. ETV grades what each change was worth: a model reads the diff against the repository around it and scores it.
What changed, not how much
New behavior, a fix, a refactor and a rename are not worth the same. The grade says so.
Every author, human or agent
Agent commits are graded like any other, so delegating work does not make it invisible.
One scale, all the way up
A file change and a company are reported in the same unit, so the numbers add up.
The methodology is public: how a change is scored, what the grader sees, where the scale comes from.
Read the ETV definitionA developer is the sum of their pull requests. A team is the sum of its developers.
Most metrics change shape as they move up the org: velocity for a team, cycle time for a group, a maturity score for the department, and nothing that reconciles. ETV is additive, so every level is the same measurement at a different altitude.
- 01File changeGraded from the diffA model reads the change in the context of the repository around it.0.07 – 0.14ETV
- 02CommitSum of its file changes150 files in this one, most of them worth very little on their own.2.80ETV
- 03Pull requestSum of its commitsThe unit reviewers already argue about, with a number attached.8.40ETV
- 04Developer, 12 monthsSum of their merged pull requestsA quiet month of hard work outranks a loud month of renames.354.2ETV
- 05Team, 12 monthsSum of its developersDivide by the months and you get 71.0 a month, the number that survives hiring.781.0ETV
Nothing is estimated on the way up and nothing is weighted, so any team number walks back down to the file changes it came from.
Attribution follows who was on the team, when.
Contributors keep the months they were there, joiners start where they joined, and agents get their own row. The rows always add up to the team.
- Petra LangVisionSWE354.2ETV63%$35.88+116%
- Marek DoležalVisionSWE308.0ETV47%$23.36+88%
- Sam WhitfieldVisionSWE75.3ETV20%$47.21+19%
- Iva Novákovájoined Apr '26VisionSWE17.6ETV100%$31.40New
- release-botVisionBot13.4ETV4%$89.41−92%
- Tomáš Rocaleft Q1 '26——12.5ETV38%——
Average team performance per month.
A month absorbs a bad sprint and is still a feedback loop. Averaged, it cannot be improved by hiring alone. Every file change is classified into one of five buckets, so you also see what the month was made of.
- 4
- 31
- 41
- 33
- 78
- 67
- 103
- 98
- 91
- 147
- 88
July was the loudest month and August the better one: fewer fixes, a higher share of features. Totals alone would have ranked them the other way round.
And the month written up, with citations.
Every period gets a written summary of what shipped and what got in the way, each claim linked to the commit behind it. Nobody has to assemble the update by hand.
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 (Petra)
Introduced a company context agent with background research and onboarding setup f642dca5 (Petra)
Established the data model, migrations and store layer for the quota system 3487b86a (Marek)
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 (Petra)
Refactoring decoupled the reconcile package from the collector service 4a30bb48 (Marek)
You can benchmark teams against each other. The interesting one is the team against itself, a year ago.
One unit means cross-team and cross-company comparisons come free. They are also the noisiest ones. Held against last year, the team is its own control group.
Against the other teams in your org
- Platform64.1
- Vision (you)58.9
- Growth41.2
- Billing28.7
Four teams, four codebases. The team holding a decade-old payments service loses this chart every quarter and is still your best team.
Against other companies
- Peer cohort, top quartile71.4
- Vision (you)58.9
- Peer cohort, median42.0
- 500 OSS Index35.6
Worth knowing before a board meeting, worth nothing as a goal. Their number carries their stack and their hiring market with it.
Against yourself, a year ago
- Q2 202658.9
- Q2 202524.8
Same codebase, same product, same review bar. When this moves, something you did moved it.
The same comparison, run in public.
The same engine runs live across the top 500 open source projects, six big-tech orgs included. The dashed line on each card is where that org stood twelve months ago. Public repositories grade lower per developer than product teams, so read the direction, not the level.
What this changes.
Open a review with average performance per month instead of commit counts
Tell hiring apart from improvement, because the total and the average are separate
Say whether last quarter's tooling or platform work actually landed
Walk any team number back to the commits it was summed from
See where your teams
stood a year ago.
The first run is backfilled from the commits already in your repositories, so you get twelve months of history in the first week instead of waiting a year for it.
Read-only
Nothing is pushed, closed or commented. We read your repositories and boards.
Not a surveillance tool
Reporting is per team by default. Per developer exists because the sum needs parts.
Every number walks back
Any figure opens down to the commits behind it, with the grade and the reason.