my current place uses DX and it's well received, if done transparently and for the right reasons. there's a lot of very interesting research in these areas (e.g. EngThrive) where the focus is on measuring things that if gamed result in better outcomes
there's strong correlation when onboarding an engineer between the time to first/tenth/fiftieith PR and their PR throughput two years later, so the answer is make it really easy to do PRs when onboarding, and they saw the same outcome even if those initial PRs were trivial
through DORA/SPACE/DevEx they also found that asking your engineers if they feel productive is generally as useful and reliable than trying to measure every possible dimension - which is why DX is based largely around the survey with subjective responses. if you actually use those responses to address friction and frustration, from my experience you end up with more, better, easier work getting done
it's possible to work in a team that cares about measuring their effectiveness, and using those measurements to understand how to be more effective. most/all engineers will have an idea of how they could improve their work, but the reality when you actually spend time to measure often shows a lot of different things you might not have been aware of
IMO anyone using any kind of metrics effectively is measuring multiple things and everything has a counterbalance. if youre measuring PR throughout you should measure release cadence, change failure rate, mean time to restore, etc.
correlating all of these let's you know if you're accelerating one activity metric but getting worse in an outcome metric - lots if slop PRs but more incidents is obviously the wrong outcome, and can be addressed by improving local verification, safer deployments, faster rollbacks, better observability, etc.
even with AI writing the code (and much more) all of these things matter. actually seeing positive outcomes (and thus RoI from AI use) requires knowing what's signal and what's noise. ive spoken to founders who see anecdotal increases in everything negative as their AI code volume goes up, and none of them are actually measuring anything effectively enough to understand what to do about it
there's strong correlation when onboarding an engineer between the time to first/tenth/fiftieith PR and their PR throughput two years later, so the answer is make it really easy to do PRs when onboarding, and they saw the same outcome even if those initial PRs were trivial
through DORA/SPACE/DevEx they also found that asking your engineers if they feel productive is generally as useful and reliable than trying to measure every possible dimension - which is why DX is based largely around the survey with subjective responses. if you actually use those responses to address friction and frustration, from my experience you end up with more, better, easier work getting done
it's possible to work in a team that cares about measuring their effectiveness, and using those measurements to understand how to be more effective. most/all engineers will have an idea of how they could improve their work, but the reality when you actually spend time to measure often shows a lot of different things you might not have been aware of