When a survey email or notification arrives during the day, many of us may find ourselves asking similar questions:
Why are these questions being asked, what is expected from me, will my answer create a positive or negative impact, or is it simply being collected for measurement purposes?
From the perspective of those sending out surveys, the question is usually why developers are not participating. When this question is brought to me, I had already been thinking about it for some time, especially since I work closely with developers. However, my first thought was not that developers do not want to give feedback or do not want to participate in surveys. On the contrary, I work with people who have very clear opinions in their daily workflows, who can easily articulate problems, and who do not hesitate to share them when the right environment is created. That is why I started looking at the issue from a slightly different angle.
Looking at it from that angle, the pattern I keep returning to is that low response rates are rarely about willingness. Developers stop responding when a survey asks too much at once, when its questions do not match their team’s context, and when it is not clear that their answers will lead to anything.
Long DevEx surveys and trying to learn everything at once
With surveys that are broad in scope and contain a large number of questions, I consistently observe the following:
Even if each question makes sense on its own, when viewed as a whole, the survey requires a significant amount of effort from the person answering.
For a developer, a survey like this turns into one more task wedged between code reviews, meetings, and the work they are actually expected to deliver. At that point, choosing not to respond usually reflects prioritization rather than indifference.
Another thing that stands out to me is that these long surveys usually try to cover many different topics at the same time. Processes, tools, communication, delivery speed, motivation, and similar topics are all asked within a single flow. When this happens, the person answering struggles to maintain a clear mental focus. A little feedback is given on everything, but nothing is truly understood in depth.
When I look at DevEx measurement, I encounter a similar situation. Trying to measure developer experience with a single survey tends to produce surface-level scores rather than a real understanding of the experience.
At this point, I believe that fewer but more focused questions, especially when they concentrate on a single DevEx dimension, produce much clearer and more actionable feedback.
Sending the same survey to everyone vs. asking the right question to the right team
Another area I started paying attention to is who the surveys are being sent to.
It is very common to send the identical survey, without any differentiation, to teams that have different structures, responsibilities, and challenges. Yet teams do not all face the same problems, and a given question does not mean the same thing to everyone. In such cases, we are effectively asking developers to respond to questions that do not really fit their team’s context, which usually results in shallow answers or none at all.
For example, let’s imagine sending a single-topic survey to a specific team, focused on a situation they have recently experienced. In that case, it is quite clear that both the response rate and the quality of insights would be higher. This is because such a survey allows the person answering to more clearly feel that “this question is about me.”
On the DevEx side, I also believe that producing meaningful insights requires trying to understand teams’ experiences within their own context.
Who evaluates the feedback matters as much as who answers it
Another important point here is how well the people evaluating the collected feedback understand the relevant teams or team groups.
When one or more people are familiar with teams’ dynamics, ways of working, constraints, and lived experiences, it becomes much easier to correctly interpret the reasons behind the answers. For this reason, I believe surveys cannot be considered independently of not only the questions being asked, but also who they are asked to and who evaluates them. Otherwise, DevEx metrics can easily become meaningless.
When feedback doesn’t lead to visible change
When all of this is taken into account, one key issue remains. It is the question we ask ourselves when a survey arrives, which I mentioned at the beginning: “Will this create an impact?” In many cases, a sense of uncertainty emerges around whether the answers given will actually lead to a meaningful outcome. So the issue is not only about not making time to respond or surveys being closed without creating any real change beyond reporting, but also about the belief in whether something will actually change.
If, when completing a survey, there is no way to know whether the answer will be read, whether it will feed into a decision, or whether it will simply vanish into a report, then deciding not to respond is a very understandable choice.
From what I have seen, openly communicating how survey results are reviewed and which actions follow them significantly shapes this perception. Even a small improvement that is clearly presented as “this happened because of your feedback” can entirely transform how people view the next survey.
What actually increases DevEx survey response rates
For this reason, the conclusion I have personally reached is that developers’ willingness to respond to surveys is directly related not only to the number of surveys, the question format, or who evaluates them, but also to whether their feedback is genuinely taken into account. When questions are more focused, directed to the right teams, and evaluated by people who understand those teams well, it becomes possible to see feedback turn into concrete impact. As this impact becomes visible, I believe survey participation will naturally increase over time.