Developer Productivity: DORA Metrics, SPACE, DevEx

Artyom starts with himself: he now runs the project and product office at Yandex, and before that spent nine years at Sber, which he joined almost straight out of university — reliability, then a project office, then a director-of-development role he calls a made-up job. In recent years his brief has been engineering efficiency: changing processes, new practices, moving onto platform solutions, rolling out copilots for developers. Hence his central claim: developer platforms should stop being built as engineers-for-engineers and start being built as products. The argument is an everyday one — the iPhone reset expectations of interfaces, first in business apps, now in internal tooling: nobody wants to read a manual for six months and climb to a grey-haired sage in the mountains to learn where the semicolon goes; everyone wants a big red button. Alexander sets the frame: Discovery is doing the right things, Delivery is doing things right, and the conversation is about Delivery.

Problems on the Discovery side reach Delivery anyway: in Artyom's regular Developer Experience surveys engineers increasingly report product confusion hitting their productivity — hence the metaphor of a car everyone makes faster without asking where it is going. Alexander describes platform rollout as an adaptive model: pilots with early adopters and a permissive regime first, and only once the core scenarios are covered do you force adoption and migrations; force it early and the hate is deserved, because people lived fine without you. The bad alternative is not improving the platform but raising the switch cost with your own syntax and hellish YAML files. Alexander adds the economics of scale: two platforms inside one company eventually get too expensive, and he recalls Will Larson's account of Uber, where entering every city on its own terms produced some 125 custom solutions, and a proposal to unify them was answered with a reference to company values. A strong platform is also a hiring argument: Artyom points at Spotify, which open-sourced its own.

Alexander opens the metrics part with a graveyard of older approaches: lines of code, resource utilisation, velocity. Each has its own way of being gamed — velocity inflates through estimates, a team measured on closed reviews chops tasks into smaller ones, and everyone has seen full utilisation in a clinic queue where the load is a hundred per cent and people still wait. Artyom quotes his former boss: a metric lives a quarter, two at most, and then people start hacking it, especially if a bonus depends on it. Alongside it Alexander recalls the law which, by his account, statisticians and sociologists arrived at simultaneously: once a metric becomes a target it stops being a good metric; and, hedged with an "if I remember rightly", Campbell's thesis that measured behaviour drifts. Artyom's conclusion is simple: measure what hurts. If test quality hurts, count defects found on the test environment and in production; at Sber and Yandex, he says, they track far more than four metrics.

Artyom never finished the Accelerate book, reading only the reports and articles; Alexander worked through the English original, where he reads three times slower and so thinks more. They walk through the DORA four — the model of DevOps Research and Assessment, the company Google later bought. Lead time is the basic metric to start with, Artyom says, but it falls apart on definitions: a product team counts from picking up the work to production, an internal contractor only to its own test environment, which is why their metrics system has a routing page: configure your Jira space and statuses first, look at a dashboard afterwards. On deployment frequency Alexander tells an origin story Artyom did not know: it was taken as a proxy for batch size, since asking about batch size in a survey made no sense — everyone's systems differ in scale. The idea comes from Just-in-Time: what matters is not how big a slice of sausage you cut but how often you cut it; small portions give low variability and let you tie an effect to its cause. Time to restore, for Artyom, is one thought: fast means the customer noticed nothing.

SPACE, from 2021, Alexander presents through his own visualisation: ordinary tables annoy him, so he draws radar charts — and what he likes is that the five axes decompose into three levels, individual, team and system. Artyom immediately forwarded the picture to a colleague preparing a product vision for efficiency metrics, saying Alexander had done the work and only a wiki page was left. Satisfaction and wellbeing provokes a psychological rejection in him — he comes to work to work for a salary, and motivating him to 150 per cent is his managers' job — but measuring satisfaction with tools and processes he considers right: measure the NPS of your own tooling and you end up next to a product approach, looking at your admin panel through the eyes of someone used to a bank's customer app. At the individual level the metrics help the engineer himself but must not appraise him: set a commit quota and people will simply commit more often.

In DevEx, from 2023, where Nicole Forsgren is again among the authors, Alexander notes that the name is also a trademark: the authors run a platform, and part of the research rests on engineers from companies already using it — people interested in the subject to begin with. The same section shows a step back: SPACE leaned on data from real systems, whereas DevEx returns to surveys, because a cloud product cannot dig through every company's logs. Google's model Alexander covers through the Software Engineering at Google book and the "Developer Productivity for Humans" article series: its researchers challenge incoming requests and refuse a study if nobody intends to act on the results, while measurement has shifted from tools to scenarios — instead of code review they phrase it as assuring the quality of code written by someone else, put reference points into the logs, and see not only the golden path but the real trajectory of documentation trips, phone calls and an improvised meeting. Artyom is rebuilding exactly this: the strategy agreed with his tech directors puts the scenario above the tool.