We build agentic harnesses for engineering orgs, which means we spend most of our time trying to help customers converge on metrics that still mean something. We have run many iterations of this across thousands of engineers, testing each set quickly and discarding what broke. Here is what we learned.
Four things are worth mapping once you stop trusting the old frameworks, and the rest of this post walks each one:
- Volume, cross-referenced rather than scored, to find where work concentrates and where it gets stuck.
- Quality, graded on a consistent rubric across everything that merges.
- Meaningful review coverage, weighted by effort, with an explicit rubber-stamp rate.
- Concurrency and rounds, the only two metrics we still measure per person.
Start with what stopped working.
DORA is now only a health check#
DORA is the four-metric standard — deployment frequency, lead time for changes, change failure rate, time to restore — that Google's DevOps Research and Assessment team established as the common vocabulary for delivery performance. It still measures something real. What it now measures is a pipeline full of agent-generated code moving through the same deployment machinery it always described.
That makes the four keys lagging indicators. They are useful the way a fever is useful: if lead time triples, something upstream broke and you should go find it. They are not something you can point at and optimize if what you want is to move faster. Nothing in the four keys tells you whether the constraint is retrieval quality, review capacity, or a single repo where every hard change lands.
SPACE did not survive the shift#
SPACE is a composite framework — satisfaction, performance, activity, communication, efficiency — and the original paper was right about its central claim: productivity is multidimensional and no single metric captures it. Two things break it in an agentic org.
The first is that several components rely on volume metrics, and volume is now completely busted. Unless you are very careful, you are composing a score out of game-able inputs that reward over-engineering and code bloat. Because it is a composite, one broken dimension undermines the whole number rather than showing up as one bad row.
The second is that it misplaces root causes. SPACE was built around metrics that used to be a function of an employee's own behaviour. Most of them are now a function of how your agents are configured and how well the org has integrated them. Applying those metrics to individuals produces performance conversations where no behaviour change on the individual's part would move the number. The DevEx work that followed SPACE — feedback loops, cognitive load, flow state — localizes better, because all three are properties of the system the engineer works inside.
Measure the org, not the individual#
An engineering org is a system of humans, agents, repositories and harnesses, and it is a much more complex one than a group of people collaborating. Measuring it at the employee level carries a specific risk: you train your team to work around problems instead of deploying a fix. The behaviour you get is local optimization by people who cannot see the constraint.
It is very likely that most of your leverage sits in optimizing the systems your team uses rather than in individual performance. So look for patterns first, then look at the outliers. People behaving drastically differently from everyone else is a signal that some system is only serving part of your team — one pod with a good harness, one repo where retrieval works, one team that figured out the review chain.
Cross-reference volume instead of scoring it#
Volume is a terrible objective and a genuinely useful lens. Do not put it in a scorecard; cross-reference it to find where work happens and where it gets stuck.
- Which repositories burn the most tokens. Agents there may be working harder to assemble context, which lowers quality and raises cost at the same time. That is a repo-shape problem, not an engineer problem.
- Where the complex work concentrates, by repo and by team. If most of your genuinely hard changes land in two repos, that is where optimization pays first.
Grade what merges#
Quality is the one measure that has to be applied to everything that merges, on a consistent rubric, across every repo. Sampling defeats the purpose, because the failure you are looking for is systemic. The most common thing we find: an org is running effective coding agents that spot real gaps, and merging anyway, because the checks are not gating. The findings exist. Nobody is required to act on them. We grade every merged PR for exactly this reason, and expose it as a tab you can slice by team.
Meaningful review coverage is the harder question#
Meaningful review coverage is the share of your high-risk work that got appropriate scrutiny — which is a very different question from what share of PRs got approved. Meaningful review is genuinely hard when volume is high, so measure the two things that reveal whether it is happening:
- Rubber-stamp rate. Approvals with no change requested and no substantive comment.
- Review coverage weighted by effort, not by count. It is very easy to post excellent coverage numbers where every hard PR is waved through and every trivial one collects three comments.
Weighting by effort is the part most teams skip, and it is the part that changes the answer. Comparing your own distribution against how other orgs in the cohort look is usually more informative than a target.
Two metrics are worth tracking per person#
Concurrency and rounds are the two individual metrics we still recommend, because both are leading indicators rather than verdicts.
- Concurrency tells you how many parallel threads someone is working on. It raises the ceiling on how much work a person can take on as agents get more autonomous, and it is learnable.
- Rounds is how many passes it takes for a change to land. It improves with better prompting and with making your codebase more legible to agents. If one team is going through more rounds than everyone else, their harness needs work — that is a finding about the harness, delivered through a per-person number.
Note what both have in common: a bad reading points at something you can go fix, and neither one is improved by writing more code. That is the test to apply to any individual metric before you adopt it.
Never assume this is fixed#
Metric obsolescence is the default condition now. Whatever you are using today will most likely be obsolete by the end of 2026, ours included. The durable skill is not picking the right framework — it is obsessively setting objectives that compound into business outcomes, and navigating the nuance of whether you are actually hitting them, while the industry keeps moving this fast.
If you want the operational side of this rather than the measurement side, João wrote up what the teams above 100% gains changed in Q1 — the review chain, the codebase changes, and the pod shape these metrics are designed to observe. There is also a note on how hiring changes once the work looks like this.
Want to see where your org sits on any of these? Book a diagnostic call and we will run your data before the call ends. More plays live on the Playbook column.