An engineering org with good DORA numbers can still be a miserable place to work, and an org with bad ones often knows exactly why and cannot get anyone to fund the fix. Both situations are symptoms of measuring outputs without measuring friction.
That is the gap developer experience metrics fill. They are not a competing framework to DORA and SPACE — they are the upstream layer that explains why those numbers sit where they do.
The three dimensions
The framing that has held up best organises friction into three buckets. They are useful because each one has a different fix.
Feedback loops are how long it takes to find out whether what you did worked. Local test suite duration, CI wall-clock time, how long a pull request waits for review, how long until a change reaches an environment where someone can see it behave. Slow feedback does not merely delay work — it changes how people work, pushing them toward larger batches and more speculative changes because the cost of checking is high. A twenty-minute CI run does not cost twenty minutes; it costs the context the developer loses while waiting, and the three other things they started in the meantime.
Cognitive load is how much a person has to hold in their head to make a change safely. Undocumented tribal knowledge, a service boundary that does not match the domain, four ways to do configuration, a deploy process with a step everyone forgets. This is the dimension most invisible to management because it is carried silently by people who have been there longest, and it is the one that makes onboarding slow — see time to productivity for new hires for what that costs.
Flow state is whether uninterrupted time to do the work exists. This is where meeting load, interrupt culture and on-call rotation land. It is the dimension that activity data measures best and the one organisations most often damage without noticing, because each individual meeting looks reasonable.
Why this is the layer that moves money
DORA metrics are outcomes, and outcomes are hard to argue with and hard to act on. "Our change failure rate is 18%" is a fact that implies no particular intervention.
Friction metrics are diagnoses. "Our CI takes 24 minutes and the median PR waits 11 hours for review, so a one-line fix takes a day and a half to land" is the same problem stated in a form that names the work. One of those gets funded.
If AI assistance is part of the picture, the feedback-loop dimension is where its cost tends to land — measuring whether AI coding assistants actually help works through that.
This is also why DevEx data is the more useful thing to bring to a budget conversation. A platform investment justified on "developer happiness" competes badly against a feature. The same investment justified as "every engineer loses roughly forty minutes a day waiting on builds, across sixty engineers" is an arithmetic argument.
What to instrument
Most of this is already in systems you run, unglamorously waiting to be looked at.
From CI and version control: build and test duration at p50 and p95, CI queue wait, time from PR open to first review, time from approval to merge, deploy duration and frequency. The p95 matters more than the median here, because the tail is what people remember and what breaks flow.
From your platform: environment provisioning time, time to a working local setup from a clean machine, how often a developer is blocked on someone else's permission.
From calendars and activity data: meeting hours, fragmentation of the remaining time, and the size of the largest uninterrupted block in a typical day. The last of these is the single most diagnostic number for the flow dimension, and it is usually much smaller than anyone expects — our piece on focus time versus active hours covers why.
From people, via survey: which of the above they experience as the actual obstacle, and what they have stopped attempting because it is too painful. That second question is the one that surfaces the adapted-to friction.
The onboarding test
If you want one cheap diagnostic that captures all three dimensions at once, time how long it takes a new engineer to ship something small to production, and sit with them while they do it.
Every feedback loop, every piece of undocumented knowledge and every structural interruption shows up in that one exercise, in order, with a witness. Teams that run it routinely find things that have been costing everyone a day a month for years, invisible because the people affected stopped noticing.
It is also the most honest measure of cognitive load you will get, because a new person cannot route around what they do not know.
What not to do with this data
Two cautions, both learned expensively.
Do not attribute friction metrics to individuals. A developer with low flow time is usually the person absorbing interrupts for the team, which is a structural fact about your org and frequently a service they are providing. Scoring them on it is both unfair and counterproductive.
And do not let DevEx become a dashboard nobody acts on. The whole value of this layer is that it names actionable work. A friction metric reviewed quarterly and never fixed is worse than not measuring, because it establishes that the pain is known and tolerated. One fixed loop beats twelve measured ones.
Where ProdView fits
ProdView covers the flow dimension and part of the cognitive-load picture: activity and application metadata showing focus time, fragmentation, meeting load, how attention distributes across tools, and where context switching concentrates. Team-level by default, with employees seeing the same data their manager does. It is the measurement that tells you whether uninterrupted time exists at all.
When not to pick us: feedback-loop metrics come from your CI, VCS and deploy systems, not from desktop activity. Build time, review latency and deploy duration live there and should be measured there. A vendor claiming to derive them from activity data is overreaching. Use both layers — they genuinely answer different dimensions.
Try before you commit
Three seats are free forever, which is enough to find out what the largest uninterrupted block in your team's day actually is. Most engineering leaders guess high. The ROI calculator will price the gap once you know it.