Reducing a developer's performance to a single number, with no explanation of where it came from, is unfair — and useless for management. That is why the DevScore is built from six dimensions, each answering a different question about the work. The 0 to 100 score gives you the overall picture; the dimensions explain what went into it.
The six dimensions fall into two families: automated signals, collected from the workflow that already exists (Git, time tracking, AI tools), and leadership reviews, made by the team's manager and tech lead. Together they cut down on unfair readings: a number without context misleads, and so does perception without a number.
Automated signals
- Delivery pace: commits per working day and pull requests per week. Measures how often technical work turns into something reviewable — a healthy pace lowers the risk of surprises at the end of the cycle.
- Code contribution: alive lines (lines that stay active in the product) and change entropy. Measures contribution that leaves a material mark, including useful deletions during refactoring — not volume for volume's sake.
- AI adoption: tokens consumed per week across the tools the company provides. Measures actual usage, not value delivered — which is why it should always be read alongside the others.
- Time tracking: hours logged per week. Without reliable logging, capacity and cost come down to opinion; with it, planning and predictability have something to stand on.
Leadership reviews
- Hard skills (1 to 9 scale): code quality, architecture, best practices and command of the technologies, assessed by whoever leads on the technical side. It moves slowly — it describes maturity, not the mood of the period.
- Soft skills (1 to 6 scale): communication, collaboration, accountability and organization. Measures impact on how the team works, not likeability. Self-assessment does not enter the calculation.
Weights that follow the role
No dimension carries a universal fixed weight. Weights are configurable and always add up to 100%, reflecting what the company values at a given moment and in a given role. What you expect from a junior is not what you expect from a senior: it is common to put more weight on pace and hours early in a career (building cadence) and more weight on contribution and hard skills at senior level (depth instead of volume).
Reference bands and the ceiling
Every signal is compared against a healthy operating band — with a floor and a ceiling — not against the best person on the team. Below the band, the signal is insufficient. Inside it, the score climbs gradually. Above it, the signal saturates: more commits, more hours or more tokens do not buy score. Reference bands are also configurable by level, contract type and nature of the work, with governance in place: adjustments apply only to upcoming closings.
How to read the dimensions in practice
Two people can land on the same final score for completely different reasons. The right way to read it is always through the composition: where things are consistent, where there is room to grow. And a low score is a starting point for investigation, never a verdict — it may be a blocker, missing data, or work that automated metrics capture poorly.
Want the detail behind each dimension, with example bands and the logic for weights by seniority? Visit the Devint methodology page.