TL;DR: DORA, SPACE and DX Core 4 all measure teams, and all of them explicitly warn against scoring individuals with their metrics. Meanwhile every manager still owes each person an honest answer to “how am I doing?”. This post is not a rubric. It is an approach: treat Git, Jira, Confluence and Slack as an evidence index that tells you where to look, build your own rubric per project, and show each person their own data before you show it to anyone else.
The gap nobody fills
If you go looking for how to measure engineering work, you find three good answers and none of them answers your question.
DORA measures software delivery performance through deployment frequency, lead time, change failure rate and recovery time, plus the technical, cultural and organizational capabilities behind them. SPACE widens the lens to Satisfaction, Performance, Activity, Communication and collaboration, and Efficiency and flow. DX Core 4 tries to unify all of it into Speed, Effectiveness, Quality and Impact (Swarmia’s comparison is the clearest side-by-side I found).
All three are team-level by design. Swarmia’s own writeup warns that metrics like PRs per developer “can encourage harmful behaviors if used for individual performance evaluation”.
The most-cited critique in this space says the same thing from another direction. When McKinsey published “Yes, you can measure software developer productivity” in 2023, Kent Beck and Gergely Orosz responded that four of the five proposed metrics measure effort or output rather than outcome, and that “the only folks who care about these metrics are the people collecting them. Customers don’t care.” Beck also brought a warning from his own experience at Facebook: once survey scores became tied to performance reviews, directors pressured managers for better scores and managers started negotiating with individual contributors for them. The measure stopped measuring.
Laura Tacho, writing specifically about individual developer performance, rejects lines of code, story points, deployment frequency, PR count and closed tickets as individual measures, on the grounds that “an individual cannot fully control their performance within a system where they are just one contributor”.
I think all of that is correct. And I also think it leaves a real problem unsolved, because a manager of eight people cannot opt out of forming a view about each of those eight people. If the tooling refuses to help, the view still gets formed. It just gets formed from memory, from who spoke most in the last stand-up, and from whoever happened to be visible during the last incident. That is not a more humane method. It is the same judgement with worse inputs.
So the question I find useful is not “can work data score a person”. It cannot. The question is: can work data make a manager’s existing judgement less arbitrary?
The reframe: index, not scoreboard
A scoreboard turns data into a verdict. An index turns data into a pointer.
The difference sounds semantic until you write the output. A scoreboard produces “Nam: 7.4”. An index produces “Nam’s changes cluster in the payment module, his reviews are the slowest to arrive and the most detailed, and three of the last five production issues in that module were caught in his review comments”. The first is indefensible the moment someone asks how the 7.4 was computed. The second is just a description, and its usefulness does not depend on the number being right.
Once you accept that the output is a description rather than a score, the design gets much easier, because you stop needing metrics that survive being weighted together.
Four questions to ask the data
Instead of “who performs best”, the four questions I would put to a body of work data:
1. What is the actual shape of this person’s work? Not volume. Distribution. Which parts of the system do they touch, how wide is that spread, do they go deep in one area or thin across many, has that changed over the last two quarters. Most of what people call a performance conversation is really a mismatch between the work someone is doing and the work everyone assumed they were doing.
2. Where does their work get stuck, and is the cause them or the system? A ticket sitting in review for six days, a branch waiting on an environment, a spec that changed twice mid-build. Work channels record waiting extremely well, and waiting is usually the largest single component of how long things take. Most of it is not attributable to the person. Knowing which part is not attributable is the point.
3. Who depends on them? Review requests routed to them, threads where their answer ended the discussion, documents other people’s work cites. This is the dimension activity counting misses hardest, and it is usually where the most valuable person on a team lives. It also, conveniently, cannot be inflated by working harder, only by being useful to other people.
4. What does the record not show? Mentoring, the unglamorous cleanup, the incident someone quietly prevented, the person who unblocks others in a call that leaves no artifact. Write this section into the output explicitly, as a permanent field, not as a caveat at the bottom. A report that names its own blind spots is one people will argue with productively. One that presents itself as complete is one people will simply distrust.
Five design rules
These are what I would hold to regardless of what the specific rubric ends up containing.
| Rule | Why |
|---|---|
| Every speed signal is paired with a quality counterweight | Cycle time alone rewards rushing. Cycle time next to rework rate does not. Any single-direction metric will be optimized in that single direction, which is the entire lesson of Goodhart’s law and of the Facebook survey story above |
| Role-specific, never one leaderboard | QA, DevOps, PM and dev leave completely different traces. Ranking them in one table does not compare people, it compares job descriptions |
| Trend against self, not rank against peers | ”Your review turnaround halved this quarter” is actionable. “You are 5th of 8” is not, and it is a fact about the other seven as much as about you |
| The person sees their own data first | This is the difference between a tool used for people and one used on them. It is also the emerging industry consensus, and it is not just an ethics argument: people who see their own numbers correct the ones that are wrong, and the data quality improves |
| Nothing enters the index that was not already visible to colleagues | A pull request, a ticket transition, a message in a team channel. Private messages, keystrokes, hours-at-desk are a different activity with a different name, and mixing the two poisons the first one |
That last rule matters more than it looks. A measurement program that engineers read as surveillance produces distorted data before it produces any insight, because the first thing people optimize is their appearance in it. The scope boundary is not a nicety bolted on at the end. It is what keeps the inputs honest.
Build your own rubric, per project
The reason this post has no rubric in it is that I do not believe a portable one exists.
What a good ticket looks like depends on how your team writes tickets. Whether commit history means anything depends on whether you squash. Whether Confluence authorship is signal depends on whether your team documents at all. A rubric copied from another company measures how closely you resemble that company.
The recipe I would use instead:
- Start from the job, not the data. Write down what you actually expect from each role this quarter, in plain sentences, before you look at any tool. This is Tacho’s point and I think it is the load-bearing one: decide what matters, then look for evidence of it. The reverse order gets you metrics that are easy to collect and irrelevant.
- Probe the data before you design. For each expectation, ask whether any channel could evidence it. Some will have none. Cut those from the measured set and keep them in the human conversation, rather than quietly substituting a nearby number that happens to be available.
- Run it on yourself first. If the description your own system produces of you feels unfair, it will be unfair to everyone else too, and you are the only person you can experiment on without cost.
- Show it to one person and ask what is wrong with it. Not “do you agree with the score”. “What is missing, and what does this get backwards”.
- Only then automate. A refresh cadence is the last step, not the first. The pipeline is easy. Knowing what belongs in it is not.
What I am not claiming
This approach does not produce a ranking, does not settle who deserves what, and does not work on a team whose tools are not used consistently enough to leave a trace. If your team ships from local branches and tracks work in a chat thread, there is nothing here to index, and no amount of tooling fixes that before the working habits change.
It is also worth saying plainly that none of this replaces talking to people. The whole value of an evidence index is that it makes the conversation more specific. It has no value at all if it replaces the conversation.
Sources
- Comparing popular developer productivity frameworks: DORA, SPACE, and DX Core 4 - Swarmia
- Measuring developer productivity? A response to McKinsey - Kent Beck and Gergely Orosz
- Using Metrics to Measure Individual Developer Performance - Laura Tacho