{
  "id": 9441171,
  "title": "Measuring developer experience without a survey",
  "url": "https://urgent.news/2026/09/23/measuring-developer-experience-without-a-survey",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-23T22:55:37.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/vivek_itp/measuring-developer-experience-without-a-survey-5hj4"
  },
  "original_language": "en",
  "account": "When developers are serious about developer experience, sending surveys may be the first instinct, but it's not always the most useful method. The data needed is often already available in the systems they operate. Surveys can capture feelings, but they have three major issues. First, they are answered by people who are already engaged. Second, they measure sentiment at a single moment, not over time. Third, they take weeks to run, making any issues they uncover quickly forgotten or fixed.\n\nTo properly measure developer experience, focus on numbers that describe a developer's day rather than organization-wide deployment frequency. Waiting for a pipeline to complete or a repository to deploy can be significant pain points. Break down numbers per team or service and examine the distribution rather than averaging them. The interesting signal is usually in the tail.\n\nRe-run rate is another honest metric. If developers frequently re-run checks without making changes, it indicates the pipeline has stopped providing useful information. This is a clear measurement of trust and a leading indicator of issues. Track how often re-runs occur to identify areas where trust erodes.\n\nMeasure the entire developer experience path, not just your part of it. A platform team may have fast queues, but the real wait time can be between systems or in another team's inbox. Track the end-to-end experience, including every handoff, to get a complete picture of developer frustration.\n\nDeveloper questions are also a valuable metric. Support volume from developers represents moments where the platform failed to provide answers. Tallying and analyzing these questions reveals areas where the platform needs improvement. Watch trends rather than total counts, as a channel that gets quieter each quarter indicates the platform is learning, while stable volume and fast responses suggest a well-functioning platform.\n\nFocus on trends rather than benchmarks. Comparing against other companies' numbers is unproductive, as they often come from different contexts. Instead, compare your own numbers to previous periods to see if improvements are genuine. This approach considers all confounding factors and provides a more accurate assessment of progress.",
  "summary": "The usual first move when someone decides to take developer experience seriously is to send a survey. It is the obvious thing to do and it is rarely the most useful thing available, because the data you actually need is already sitting in systems you run. I am not against surveys. They capture things instrumentation cannot: whether people feel trusted, whether they think anyone is listening,…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}