Developer experience survey: from annual results deck to visible change
Teams run a developer experience survey to find what slows engineers down. The survey is the easy half. The full survey is right below, 16 questions, free to copy. The harder half, making the results move something, is the worked example at the bottom: a team whose first survey died, running the loop that replaced it.
What a developer experience survey measures
Most developer experience surveys run once, promise three fixes, fund none, and are never trusted again. The failure is in the design, not the questions: an annual, point-in-time survey measures developer experience, no part of it improves developer experience, and nothing owns the year in between.
The questions themselves are a solved problem. A good survey asks developers to rate the conditions they work in, not the output they produce; the standard basis is the three dimensions (feedback loops, cognitive load, flow state) from Noda, Storey, Forsgren, and Greiler's DevEx paper, plus satisfaction measures from the SPACE framework. The 16 below are built on both.
Nobody stops answering because they got busy. They stop because nothing happened last time.
Run the survey: 16 questions, free
Score each statement 1 to 5, strongly disagree to strongly agree.
Feedback loops
- CI results for a typical change come back fast enough that I stay on the task while waiting.
- Code reviews on my changes get a first response within one working day.
- I get answers to technical questions quickly enough to keep working.
- When something breaks in production, I can find out what happened without asking around.
Cognitive load
- I can work out how to do routine tasks (deploy, provision, debug) from our docs and tooling, without needing to find the right person.
- The parts of the codebase I work in are understandable enough that I make changes with confidence.
- The number of tools and systems I have to touch to ship one change feels reasonable.
- Our processes (tickets, approvals, handoffs) rarely require me to hold more in my head than the actual problem.
Flow state
- On a typical day I get at least one solid block of uninterrupted development time.
- Meetings are scheduled so that they do not fragment my focus time.
- I am rarely blocked waiting on another team or an approval to make progress.
- Unplanned work (incidents, urgent requests) rarely derails what I set out to do in a week.
Satisfaction and outcomes
- I would recommend my team to another engineer as a good place to build software.
- Most weeks, I end feeling that my effort went into work that mattered.
Open questions
- What one thing slowed you down the most in the past month?
- If you could change one thing about how we build and ship software here, what would it be?
Three rules for running it
Keep responses unattributed, or you measure compliance, not experience. Segment by team, never by person. Discuss the spread, not just the average: a 3.4 can hide half the team at 5 and half at 2; that split is the finding. And pick a cadence you can act on: a short pulse every period, each one answered by what changed since the last, beats an annual census nobody owns.
What questions should a developer experience survey include?
Organize questions around the three DevEx dimensions: feedback loops, cognitive load, and flow state. Add one or two satisfaction questions from the SPACE framework and at least two open questions. Fifteen or sixteen questions is enough; the survey on this page is sixteen.
How often should you run a DevEx survey?
Run the full survey no more than quarterly, with a short pulse every few weeks. The cadence matters less than the loop: if results visibly lead to changes, engineers keep answering.
What is the difference between a DevEx survey and DORA metrics?
DORA metrics measure delivery outcomes from system data. A DevEx survey measures what developers experience while producing those outcomes. DORA tells you the pipeline slowed down; the survey tells you why.
From a dead survey to changes: a worked example
Simulated team · Real product output A survey that dies after one round costs more than no survey, because the next ask gets answered by nobody. Here is the alternative on one team: the Keystone platform team at Aldermark Mutual, a fictional mutual insurer. Seven engineers serving 14 product teams. Their developer experience survey ran once, 18 months ago: three improvements promised, none funded, never run again. We scripted the inputs and ran them through Aurora Coach in production. Everything below is the product's real output.
1Sense and analyze
Every team member answers structured questions in their own words, and can take any thread further with the coach in a check-in. Two of them raised the dead survey in the same period.
The credibility trap, named
The team lead wants the signal back, and says a second one-off survey would burn the last credibility the team has. The coach, verbatim: “If you can’t point to visible changes from the first survey, even small ones, then you’re asking people to participate in theater.” The next turn prices the alternative: one 15-minute conversation per engineer every two weeks, two product teams each, 14 touchpoints a month, one per team they serve.
The same failure, from another seat
A second engineer, same period, brings a different worry: the channel where product teams ask his platform team for help has gone quiet, and he cannot tell satisfaction from resignation. The coach ties the two together. “The pattern of ‘ask, promise, don’t deliver, stop asking’ is exactly how teams learn that engagement is performative.”
2Recommend, refine, commit
The sessions roll up into a team analysis, and its recommendations become concrete suggestions the team votes on and commits to. The AI informs the decision, it does not make it.
General questions, one team’s answer
One suggestion of twelve, opened in full. Read the Context column: it argues from this team’s own history, “frustration from past improvement commitments that weren’t followed through,” and concludes that rebuilding trust in the improvement process comes before anything else. So the first move is deliberately small: “the smallest impediment that the team can fully resolve without external approval,” closed in two weeks, announced in public. The expected outcome is a template for tackling progressively larger impediments. The 16 questions above would have found this team's low trust; they could not have sequenced the repair. That is the difference between a survey result and a suggestion a team can commit to.
3Execute and re-evaluate
The team does the work in its own context, and the next period's analysis reads what changed. Keystone has run one period; the trend starts when the second one lands.
This is one use case. How the full product works is on the product overview.
Not ready to change anything today? You already have the 16-question survey above, copy buttons and all. If you want one improvement loop like these in your inbox each month, leave your email.
What this page cannot tell you is which of it applies to your team, this quarter. Aurora Coach works that out from your team's own words, recommends next steps with the reasoning, and the next period shows whether it held.
Both are free. The ROI mapper needs no signup and takes about two minutes. What team members write stays private to them: see AI governance.