A developer experience survey you can run this week

Copy-ready questions from the published SPACE and DevEx frameworks, plus the part that decides whether anyone answers twice.

What a developer experience survey measures

A developer experience 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 failure mode is the design, not the questions. The survey runs annually, results arrive as a deck, and nothing a developer can point at changes. Next year fewer people answer, less honestly. A point-in-time survey measures developer experience; it does not improve it.

How Aurora Coach addresses it

An annual survey is Sense, run once a year. Aurora Coach senses every period and closes the loop visibly. The work lands in the Alignment domain (DevEx, tooling, cross-functional collaboration) and often Engineering.

  1. Sense and Analyze Every team member contributes context in an inverted pattern: the AI asks structured questions, each person answers in their own words, and integrations such as Aurora Coach for GitHub add quantitative signal. The AI synthesizes this collective context into a SWOT and maturity assessment grounded in the team’s actual situation, combined with outside knowledge, across six domains: Foundation, Product, Engineering, Operations, Workflow, and Alignment.
  2. Recommend, Refine, Commit The AI recommends concrete next steps with rationale, implementation steps, and success criteria. Team members vote and the team lead refines to fit the team’s reality; the AI never decides. The team commits to improvements it owns, tracked through periods.
  3. Execute and Re-evaluate The team does the work in its own context, alongside delivery. Next period’s analysis sees what changed; progress is visible against previous commitments, and context compounds. Visible loop-closing keeps response honesty alive.

The survey below is your baseline. Between surveys, free-text check-ins keep signal flowing without re-running the instrument.

The survey

Score each statement 1 to 5, strongly disagree to strongly agree.

Feedback loops

  1. CI results for a typical change come back fast enough that I stay on the task while waiting.
  2. Code reviews on my changes get a first response within one working day.
  3. I get answers to technical questions quickly enough to keep working.
  4. When something breaks in production, I can find out what happened without asking around.

Cognitive load

  1. I can work out how to do routine tasks (deploy, provision, debug) from our docs and tooling, without needing to find the right person.
  2. The parts of the codebase I work in are understandable enough that I make changes with confidence.
  3. The number of tools and systems I have to touch to ship one change feels reasonable.
  4. Our processes (tickets, approvals, handoffs) rarely require me to hold more in my head than the actual problem.

Flow state

  1. On a typical day I get at least one solid block of uninterrupted development time.
  2. Meetings are scheduled so that they do not fragment my focus time.
  3. I am rarely blocked waiting on another team or an approval to make progress.
  4. Unplanned work (incidents, urgent requests) rarely derails what I set out to do in a week.

Satisfaction and outcomes

  1. I would recommend my team to another engineer as a good place to build software.
  2. Most weeks, I end feeling that my effort went into work that mattered.

Open questions

  1. What one thing slowed you down the most in the past month?
  2. 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.

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. Twelve to fifteen questions is enough.

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.

Before you pitch the platform investment, run MapROI: free, no signup, about 5 minutes, and you get a tailored ROI analysis to put next to the survey results.

Map your ROI Start free trial