As more companies establish C-level metrics for developer experience, leaders naturally want to measure the impact of their initiatives using these metrics.
The problem with setting goals against top-level metrics like overall developer satisfaction is that these metrics are affected by a wide array of factors. If satisfaction goes up, was it due to your improvement efforts or because the company announced global pay raises? If satisfaction goes down, does it mean that your improvements have failed or that your developers working on more difficult projects?
Top-level metrics like developer satisfaction are great for seeing the big picture of internal developer experience. But for measuring the impact of specific initiatives, it’s better to focus on the individual factors that efforts are tied to. For example, if you are rolling out new release tooling, measure developer sentiment toward release processes. Even better yet, measure specific parts of developers' workflows that have improved, like the number of manual steps it takes to deploy or how long it takes for a release to complete.
An additional way to measure the success of initiatives is by surveying developers to determine whether they think things have improved. For example: "91% of developers reported improvement in their development workflows". This may sound like an unconventional approach, but it's an easy and effective way to quantify the impact of improvement efforts.