What DevEx Keeps Finding and Never Carries
In 2026, Microsoft published a description of the measurement system it runs across tens of thousands of its developers. The system organises engineering productivity into three dimensions — speed, ease, and quality — with a fourth concern, thriving, held alongside them as a guardrail rather than an objective. Explaining why the guardrail is framed the way it is, the authors write that delight is an outcome of removing friction, not a goal unto itself.¹
That sentence is worth stopping on, because it makes a claim that the field it belongs to had already written down the negation of, fourteen years earlier, in the paper that gave the field its name.
The predicate that needs an object
Friction is a well-defined thing to remove. A build takes forty minutes; it could take four. An environment takes two days to provision; it could take twenty minutes. A review sits for a week; it could sit for an afternoon. Each of these is a cost imposed on the person doing the work, each is measurable, and each can be driven toward zero. The programme has a floor and the floor is reachable.
What sits outside that programme is not a further quantity of friction. It is a property of the work rather than of the conditions around it: whether the thing being built is worth building, and whether the person building it can regard the contribution as their own.
The reason friction removal cannot reach that property is not empirical. It follows from what the words have to mean. “Well-built” is not a self-contained predicate. It means well-built for something, and the something is supplied from outside the craft. A team can hold a standard of construction against itself for a considerable time without external validation arriving, and that is what carries good engineering through a fallow quarter. But the standard is instrumental. Remove the object for long enough and the predicate loses its subject matter, and the questioning that follows does not need to arrive from outside; it arrives on its own, because the grounds for holding the judgement have run out.
I came at this from an observation I cannot treat as evidence. Leading a team some years ago, I watched the same people, with the same skills and the same tooling, move between a period in which the work was something to be proud of and a period in which it was not, and the only variable I could see moving was what the work was. I record that as the question rather than the finding. My own conduct changed across that boundary and I am the person least placed to see it; project transitions carry phase effects that travel with them; and the novelty of a fresh problem predicts the same energy under any account of challenge and skill, with no reference to whether the output mattered. The argument above does not rest on any of that. It rests on what “good” has to mean in engineering.
The dimension that was there at the start
Developer experience received its first formal definition in 2012, from Fabian Fagerholm and Jürgen Münch.² They built it on the trilogy of mind: cognition, how developers think about their working environment; affect, how they feel about it; and conation, which they defined as the factors affecting how developers see the value of their contribution — the alignment of their own goals with the project’s, and their commitment to it.
The same paper, surveying what was known about individual performance, cites Frederick Herzberg. It states the distinction plainly: motivator factors relate to the work itself and can increase performance, while hygiene factors are unrelated to the work itself and produce dissatisfaction when they are missing.³
Herzberg’s two-factor theory has taken serious methodological criticism and this essay does not depend on it being correct. What matters is the sequence. The founding definition of developer experience contained a dimension about the worth of one’s own contribution, and it contained, in the surrounding survey, the distinction between conditions and the work itself. Both were written down at the beginning. The claim that delight is what remains after friction is removed is not a proposition the field failed to consider. It is a proposition the field had already recorded the opposite of.
The 2022 empirical study by Michaela Greiler, Margaret-Anne Storey and Abi Noda retains the conative dimension, though its framework diagram renders it as “expectations” rather than conation.⁴ The interviews behind that paper are full of the variable. Participants describe providing value to the business as among the most important things about their work; one describes an unglamorous bug fix as rewarding because it unblocked the business. The worst experience reported is being near the end of something and having the direction change completely, with one participant estimating that roughly thirty per cent of their output was immediately replaced. Recognition appears twice, once as a factor and once as a barrier: a developer whose test-suite work went unvalued reports feeling underappreciated and stopping any work beyond their job description. The paper’s own conclusion is that the barriers to improving developer experience are primarily organisational rather than technical.
Friction as the ontology
The compression arrives in 2023, in a practitioner article by Noda, Storey, Nicole Forsgren and Greiler.⁵ The definition survives intact: developer experience encompasses how developers feel about, think about, and value their work. The model does not. Three dimensions are distilled from the earlier twenty-five factors — feedback loops, cognitive load, and flow state — and the article states what they are for. Taken together, the three encapsulate the full range of friction types encountered by developers.
Friction becomes the ontology of the field in that sentence. Two of the definition’s three verbs have somewhere to live in the model. The third does not.
What the model then measured is a matter of record, because the same authors, joined by Kalliamvakou and Houck, took it into the field.⁶ That study grounds itself in work design theory, and the choice is worth pausing on. Work design theory is the tradition that has spent five decades establishing which properties of a job produce motivation, and its canonical motivational characteristics include task identity — completing a whole, identifiable piece of work — and task significance, the degree to which the work affects other people.
What the study draws out of that tradition is that novel work and freedom from noise support focus, that easy-to-understand tasks and well-designed information flows contribute to outcomes, and that timely feedback supports personal performance. For the second of those it cites a meta-analysis of 259 studies and some 220,000 participants, and cites it for two characteristics: job complexity and information processing.
Those two are not drawn from a different part of that literature. They sit in the same list of motivational work characteristics as task identity and task significance. The meta-analysis reports that its own findings for job complexity and information processing rest on few studies and small samples and should be read with caution, and it names both among the characteristics that remain insufficiently investigated. It also reports, in what it describes as the first meta-analytic test of the model, that experienced meaningfulness is the psychological state through which motivational characteristics principally reach work outcomes, with strong support for that mediation in the cases of skill variety, task identity and task significance.
The two characteristics taken into the developer experience model are the two the source itself calls under-evidenced. The ones left behind are the ones carrying the mediation the source calls most important.
The instrument that resulted has fourteen items. Flow state asks whether the developer has significant time for deep work, how often they are interrupted by something unplanned, and whether their coding tasks are more engaging than boring. Feedback loops ask how long it takes to get a technical question answered and what percentage of code reviews complete within four business hours. Cognitive load asks about the ease of deploying changes, the ease of understanding the code, whether processes are easy to figure out, and whether the tools are intuitive.
Thirteen of those fourteen are readings on the conditions around the work. Take a team building something that matters and a team building something nobody will use, hold the tooling and the process constant, and every one of the thirteen comes back the same.
The outcome measures behave differently, and that produces the characteristic failure of the instrument. Whether a developer felt productive or creative, whether they are looking for jobs elsewhere, whether the organisation is meeting its goals: these move when work stops being worth doing. So the study can see that something has gone wrong, at the outcome end, and it has almost nothing on the input side that can account for it.
Almost nothing, because of the fourteenth item.
The one that crossed
Whether the coding tasks are more engaging than boring is not a measure of friction. It is a property of the work rather than of the conditions around it, and it sits inside the flow state construct as one of three.
The study’s own analysis puts it near the top. An importance-performance analysis identifies deep work and engaging work as the two items with the largest potential impact on developer outcomes, and names the same two again as giving outsized support to organisational outcomes including innovation, retention and profitability. Separately, developers who find their work engaging report feeling thirty per cent more productive than those who find it boring.
Then the authors write the recommendation that follows from it. Rethinking how tasks are distributed, they suggest, and asking whether particular teams are regularly given work they find boring, or divorced from the company’s mission and customers.
That sentence is the variable. It is in a practitioner-facing article by six of the field’s principal researchers, attached to one of the two most impactful items in their own model, published in the same year as the compression.
It appears in no framework built afterwards. Not in DX Core 4. Not among the sixteen drivers of the Developer Experience Index. Not in the speed, ease and quality of EngThrive. One item crossed from the theory into a fielded instrument, ranked at the top of the analysis, was glossed in prose as a question about mission and customers, and did not survive the next step.
Two further results from the same study are worth recording. The hypothesis that feedback loops improve outcomes was only partially supported: they influenced team outcomes and had no significant effect at the developer or organisation level. And meaning appears in the 2023 model only folded into flow state, as autonomy over work structure, clear goals, and stimulating and challenging tasks. That is the challenge–skill balance, which is a claim about the difficulty of the work. A task can be perfectly calibrated to a person’s skill and still be pointless.
What the instruments were built to hold
Three frameworks have since been built on that foundation, and each of them reaches for the variable and comes back holding something else.
The Developer Experience Index, DX’s commercial measure, is described by its authors as a formative measure of whether the right conditions exist for developers to deliver effectively.⁷ Its stated route to higher productivity is the removal of friction. Sixteen drivers — build and test, change confidence, clear direction, code maintainability, customer focus, decision-making, deep work, dev environment, documentation, ease of release, incident handling, incremental delivery, local iteration speed, planning process, production debugging, review turnaround — are combined into a single score, which the document describes as protecting the index from the volatility of individual metrics. Whatever any one driver contributes, it is averaged. And the composite is validated against outcomes led by efficiency and time loss, with the headline claim being that each one-point gain corresponds to thirteen minutes per week of developer time saved.
Customer focus is the driver that might reach the variable, and its item wording is not published. It is also, in most enterprise and commercial software development, a survey question about a relationship that runs through a service platform rather than through any contact with a person. Either way the point is the same: it is one of sixteen inputs to a number validated against minutes.
DX Core 4 names one of its four metrics “Impact” and operationalises it as the percentage of time spent on new capabilities rather than maintenance. That is an investment-allocation figure. Microsoft’s EngThrive, built independently, reaches the same place by a different route: its north star for ease is an innovation time ratio, dividing developer hours into innovation, running the business, and overhead. Both frameworks classify the work by accounting category. Neither asks whether the new capability was worth building. EngThrive’s north star for speed, idea-to-customer, is glossed as measuring how long it takes to turn intent into impact, where impact means elapsed time and the intent is not the developer’s.
There is now a census of this landscape. In 2026, André Meyer, Patrick Meyer, Gail Murphy and Thomas Fritz curated the metrics in circulation across the scientific literature and the published practice of more than fifty engineering organisations.⁸ The dataset holds a hundred and twenty-two metrics, organised across eight dimensions.
One of them reads on whether the work was worth doing. It is called Impact, and its definition covers tangible outcomes and value delivered rather than raw output, and making significant contributions to one’s business unit so that the work has tangible effect. It ranks forty-sixth of a hundred and twenty-two by how many sources reference it. One company. Three research papers.
Get Bruno Baketarić’s stories in your inbox
Join Medium for free to get updates from this writer.
Developer satisfaction ranks first, cited by twenty-seven organisations and seventeen research sources. Adoption rate, the uptake by developers of the internal tooling they have been given, is cited by nineteen organisations. Daily, weekly and monthly active users for AI tools, a metric with a single research source behind it, is cited by seventeen.
The dataset records what organisations publish, not everything they do, and the claim should be scoped to that. What the field publishes and cites is a landscape in which the tooling’s uptake is measured nineteen times more often than the worth of the work it is used for.
The finding that never crosses
The obvious reading of that gap is that the field has not noticed. It has noticed repeatedly, and this is the part that makes the pattern worth describing rather than complaining about.
DORA’s 2024 report, working through a counterintuitive result about AI adoption, states in passing that the meaningfulness of development work derives from the impact of the solution created rather than from the writing of the code.⁹ The same report finds that organisations prioritising the end user produce higher-quality products with developers who are more productive, more satisfied and less likely to burn out, and that organisations can succeed without high delivery velocity and stability provided they are user-focused.
DORA’s 2025 report goes further and instruments the variable directly.¹⁰ Among the constructs it studies are authentic pride, using an established psychological measure; meaning of work; and psychological ownership, defined as the feeling that something is yours even when it does not belong to you. Pride rose with AI adoption, and the report’s own account of the mechanism runs through contribution rather than craft: more time on work perceived as valuable, and higher pride as a result. Meaning of work showed no movement at all. Psychological ownership was studied against one question — whether writing code with AI assistance makes the code feel less like yours — and found no association.
In 2026, Rudrajit Choudhuri, Eirini Kalliamvakou, Brian Houck and Thomas Zimmermann mapped developers’ daily work across four dimensions, two of which are value and identity.¹¹ They report that the gap between how developers work and how they want to work has not closed as AI adoption has risen, and has if anything widened, which leads them to suggest that framing AI as a tool that reduces toil and frees time for meaningful work may be too simple. Their most pessimistic projected future is a role in which humans approve machine-generated work at industrial scale, accountable for outcomes they do not fully understand and rewarded for the volume of approvals rather than the depth of the craft.
Five findings, across fourteen years, all pointing at the same variable. And the researchers are not a separate community from the framework builders. Storey appears on the 2022 study, on the 2023 compression, and as chief scientist at the vendor whose index the 2023 article’s lead author founded. Houck appears on EngThrive and on the 2026 identity study and has since joined that vendor. Forsgren, Greiler, Noda, Kalliamvakou and Zimmermann recur across the whole sequence.
The same people find it and then build instruments that cannot hold it.
Conditions, guardrails, environments
Where the variable does enter an instrument, it enters in a consistent grammatical position, and the position is the argument.
The DXI measures whether the right conditions exist. EngThrive’s dashboards deliberately exclude the individual level, on the stated grounds that the system measures the environment developers work in rather than the developers, and that managers are accountable for the environment they create. And where meaningfulness appears in EngThrive at all — it does appear, imported from Microsoft’s employee sentiment programme, which asks whether people feel empowered, energised, and that their work is meaningful — it sits inside the thriving guardrail, alongside a satisfaction score. The metric the organisation steers on within that guardrail is bad developer days, a composite of context switching, incident toil, build failures, insufficient focus time and compliance obligations. Fifty-two per cent of developer-days qualified.
A guardrail is a constraint. It is a thing not to be violated, and nobody optimises toward one. Conditions are provided to a population by a party that is not that population. An environment is something you find yourself in.
That grammar has a history. The research DORA’s four delivery metrics were drawn from was conducted in organisations where the team that wrote the software also owned the system that shipped it, and the deliberate separation of those two — a platform team operating the delivery machinery, delivery teams consuming it through a self-service interface — opened a gap between the unit being measured and the unit determining the measurement.¹² That separation is correct on every axis anyone measures, and it is not the subject of this essay. But it did two things and only one of them has been noticed. It broke the metrics’ legibility as statements about the team, and it converted a portion of what a team had authored into something a team was given.
The second of those is the half of the variable this essay began on. Whether a person can regard a contribution as their own turns on the decisions that determined how the thing came out, and a delivery system a team is handed contains none of theirs. Whoever built it may be proud of it, and that is a real achievement; the pride does not travel with the artefact to the people who receive it. The machinery itself was a chore for many teams and they were glad to be rid of it, so what went is not the machinery but the judgement inside it. And it goes unevenly, in the same way the legibility does: where the interface is thin and teams make real choices above it, most of that judgement stays with them, and where it is thick and gated, it does not.
DORA’s own recommendation, in the same 2024 report that names user-centricity as the strongest driver it found, is that internal developers should be treated as users, and internal platforms built as products delivering value to them. “User” is a role defined by not having made the thing. That is not a criticism of platform engineering, which is the right arrangement for most large organisations and produces better machinery than any team would build alone. It is an observation that the arrangement has a cost on an axis the instruments do not read, and that the construct which would read it — psychological ownership — exists in the field’s own toolkit and has been pointed at one question, about AI, and never at this one.
The list that includes the weather
EngThrive’s authors anticipate the obvious objection to all of this, and their answer is what makes the omission legible rather than inferred.
In a section on applying the framework beyond developer tools, they observe that a developer’s experience is shaped by factors that have nothing to do with software, and that many of those factors are outside an engineering leader’s power to change. They then reject that as a reason to leave anything out: measuring the impact of a factor is worthwhile even when the lever belongs to someone else, because a quantified effect gives leaders evidence to take to whoever can pull it.
Having stated that principle, they list what the framework has been applied to. Office buildings, where daylight and ventilation account for up to a ten per cent difference in engagement. Seattle weather, where snow days show up as an eighteen per cent drop in output. Vacation policy. Return-to-office mandates. The ratio of product managers to developers. Manager span of control. Organisational bureaucracy.
Whether the work was worth doing is not on the list.
The principle is theirs, the list is theirs, and the omission is visible against their own stated inclusiveness. No account of anyone’s motives is needed to describe it, and none would improve it. The framework was built to be a general-purpose language for evaluating anything that shapes the experience of engineering work, and it evaluates the ventilation.
What was never weighed
Set the whole sequence out and the shape is not one of decline. Nothing was lost. The dimension was named in 2012 and is still being measured in 2025; the finding was published in 2024 and republished in 2026; the constructs exist, validated, in the field’s flagship annual research. The variable has never gone missing.
What has never happened is that it entered an instrument as something to be improved rather than something not to be broken.
And that is why the thing reads as a discovery each time it is found. A measurement system defines what an organisation can be seen to be getting better at. Speed, ease and quality can be steered toward. Conditions can be provided, guardrails can be held, environments can be improved by whoever is accountable for them. Whether the work was worth doing sits at a different address, and the instruments that would have to carry it there are commissioned, built and read by people whose authority stops short of it.
So no organisation decides against it. There is no meeting at which the trade is made, no budget line where the two are compared, no dashboard on which one goes down as the other goes up. The choice is made on the axis that has numbers, by people acting reasonably on the best instrument available to them, and the other axis is not weighed and found wanting. It is not weighed.
¹ Brian Houck, Tim Bozarth, David Liu and Dean Carignan, “EngThrive: Make It Fast and Easy to Do Great Work,” 2026 (arXiv 2605.04259; also ACM Queue). The sentence closes the paper’s discussion of why thriving is framed through a friction composite rather than through delight.
² Fabian Fagerholm and Jürgen Münch, “Developer Experience: Concept and Definition,” Proceedings of the International Conference on Software and System Process (ICSSP 2012), 73–77. The conative dimension is set out in section III and in the paper’s conceptual framework diagram.
³ Frederick Herzberg, Work and the Nature of Man (1966), cited by Fagerholm and Münch in their survey of factors influencing individual performance. The two-factor theory has been criticised extensively on methodological grounds, principally that its asymmetry is an artefact of the critical incident technique and of self-serving attribution; see Robert House and Lawrence Wigdor, Personnel Psychology 20(4), 1967, and Nathan King, Psychological Bulletin 74(1), 1970. The argument here does not require the theory to hold.
⁴ Michaela Greiler, Margaret-Anne Storey and Abi Noda, “An Actionable Framework for Understanding and Improving Developer Experience,” IEEE Transactions on Software Engineering, 2022. Twenty-one semi-structured interviews.
⁵ Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, “DevEx: What Actually Drives Productivity,” ACM Queue 21(2), 2023.
⁶ Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck and Margaret-Anne Storey, “DevEx in Action: A study of its tangible impacts,” ACM Queue, November–December 2023; also Communications of the ACM 67(6), 42–51, 2024. The survey instrument is reproduced in the article’s Table 1. The study is cross-sectional, with 219 completed responses from 2,213 invitations, among developers at customers of one of the authors’ companies — limitations the authors state. Its work-design grounding is drawn principally from Sharon Parker, Toby Wall and John Cordery (2001) and from the meta-analysis of Stephen Humphrey, Jennifer Nahrgang and Frederick Morgeson (2007).
⁷ Abi Noda and Laura Tacho, “The one number you need to increase ROI per engineer,” DX. The sixteen drivers are listed in the document’s overall model diagram; its prose refers to fourteen dimensions.
⁸ André N. Meyer, Patrick Meyer, Gail C. Murphy and Thomas Fritz, “Too Many DevEx Metrics, Too Little Guidance,” ACM Queue, 2026. The dataset is open and the counts above are taken from it rather than from the article’s summary of it.
⁹ 2024 Accelerate State of DevOps Report, DORA. The report’s own reading of the AI results, which it calls the vacuum hypothesis, differs from the use made of them elsewhere; the observation cited here is from its discussion of what respondents judge to be valuable work.
¹⁰ State of AI-assisted Software Development, DORA, 2025. Authentic pride is measured using the instrument of Tracy, Cheng, Robins and Trzesniewski (2009).
¹¹ Rudrajit Choudhuri, Eirini Kalliamvakou, Brian Houck and Thomas Zimmermann, “The AI-Native Developer,” ACM Queue 24(2), 2026. Surveys of 1,300-plus developers and interviews with 22 AI-fluent practitioners. The characterisations above follow Houck’s own summary of the study rather than the article text.
¹² An earlier essay works through what that separation does to the four delivery metrics, and why the degradation is invisible from the metrics themselves: The Seam DORA Can’t See.
