# Developer Experience Survey: [Organisation] [Survey cycle]

> Survey instrument and results report for measuring developer
> experience: objectives, the framework mapping (DevEx feedback loops,
> cognitive load and flow state; SPACE dimensions; DORA capabilities),
> privacy and anonymity rules for survey data, administration, an
> original question bank, the analysis method, a results report with
> worked data, and the action plan. Concepts follow the DevEx (ACM Queue,
> 2023) and SPACE (ACM Queue, 2021) frameworks and the DORA capability
> catalogue at dora.dev (CC BY 4.0). Replace every `[bracketed]` value
> and every row marked *Example*. Privacy sections describe common
> practice under the EU GDPR (Regulation (EU) 2016/679); this is a
> documentation format, not legal advice. The worked example uses
> Corvid Commerce, a fictional SaaS company.

<!--
Guidance: How to use this template
- Use one document per survey cycle. Part A (sections 1 to 6) is the
  instrument and its rules: approve it before launch and keep it stable
  across cycles so trends stay comparable. Part B (sections 7 to 10) is
  the results report.
- Settle privacy first (section 3). Developers answer honestly only when
  they trust that answers cannot be traced to them and will not be used
  against them. Involve the data protection officer and, where one
  exists, the works council before the first launch.
- Keep the core question bank short (about 25 to 35 items, under 15
  minutes). Rotate optional modules instead of adding questions.
- A survey without visible action destroys the next response rate.
  Publish results and actions within four weeks of closing.
- Related documents: Software Delivery Performance Report
  (`dev/delivery-performance-report`) uses these results as perception
  data; Engineering Strategy (`dev/engineering-strategy`); Internal
  Developer Platform Charter
  (`architecture/internal-developer-platform-charter`); Data Protection
  Impact Assessment (`compliance/dpia`); Onboarding Guide
  (`dev/onboarding-guide`).
-->

## Document control

<!-- Guidance: Identify the cycle, the population and who may see raw data. Changes to the question bank after launch are not allowed; record them for the next cycle. -->

| Field | Value |
|---|---|
| Document ID | [DXS-2026-Q3] |
| Survey cycle | [Quarterly / Half-yearly] [cycle name] |
| Population | [Number] people in [roles and organisations in scope] |
| Field period | [YYYY-MM-DD] to [YYYY-MM-DD] |
| Question bank version | [QB-2.1] |
| Survey tool and hosting region | [Tool], [region] |
| Raw data custodian | [@people-analytics or @engineering-effectiveness] |
| Minimum reporting group size | [5] respondents |
| Version | [0.1] |
| Status | [Draft / Approved for launch / In field / Results published / Closed] |
| Owner | [@engineering-effectiveness-lead] |
| Approvers/reviewers | [@vp-engineering], [@dpo], [@works-council-rep], [@hr-business-partner] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal; raw data Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| VP Engineering (sponsor) | [@name] | [Approve / Approve with changes / Reject] | YYYY-MM-DD |
| Data protection officer | [@name] | [Decision] | YYYY-MM-DD |
| Works council or employee representative (where applicable) | [@name] | [Decision] | YYYY-MM-DD |
| Engineering effectiveness lead (owner) | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft of instrument |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for launch after DPO and works council review |
| 2.0 | YYYY-MM-DD | [@name] | *Example:* Results report (Part B) added |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

Part A: Instrument

1. [Purpose and objectives](#1-purpose-and-objectives)
2. [Framework mapping](#2-framework-mapping)
3. [Privacy, anonymity and data handling](#3-privacy-anonymity-and-data-handling)
4. [Population, sampling and administration](#4-population-sampling-and-administration)
5. [Question bank](#5-question-bank)
6. [Analysis method](#6-analysis-method)

Part B: Results

7. [Results report](#7-results-report)
8. [Findings](#8-findings)
9. [Action plan](#9-action-plan)
10. [Communication and follow-up](#10-communication-and-follow-up)
11. [Glossary and references](#11-glossary-and-references)

## 1. Purpose and objectives

<!-- Guidance: State the decisions the survey will inform. Questions: which investments (platform, tooling, process) depend on these answers? What would make you change course? Pitfall: a survey that measures everything and informs nothing. -->

The survey measures how developers experience their daily work, to find
the friction that slows delivery and harms well-being, and to check
whether improvement work is helping. It complements system data such as
the DORA delivery metrics: systems show what happened, people explain
why and reveal friction that no tool records.

| Objective ID | Objective | Decision it informs | Owner |
|---|---|---|---|
| OBJ-01 *(Example)* | Find the top three sources of friction per product area | Platform roadmap priorities for the next two quarters | [@platform-lead] |
| OBJ-02 *(Example)* | Track the effect of the merge queue and review rota on perceived feedback loops | Continue, change or stop the interventions | [@checkout-em] |
| OBJ-03 *(Example)* | Measure onboarding experience for people who joined in the last 6 months | Onboarding programme changes | [@engineering-managers] |
| OBJ-04 *(Example)* | Monitor sustainable pace and well-being | Staffing and on-call load decisions | [@vp-engineering] |
| [OBJ-NN] | [Objective] | [Decision] | [@owner] |

Out of scope: individual performance assessment, engagement topics
already covered by the company-wide HR survey, and compensation.

## 2. Framework mapping

<!-- Guidance: Map every question to a framework dimension so that results roll up consistently. Questions: does each dimension have at least two items? Is every item needed for an objective? Pitfall: questions that do not map to anything and are never analysed. -->

The instrument uses three complementary lenses. Their concepts are
summarised here in original words; read the cited articles for the full
argument.

| Lens | Dimensions used | How this survey uses it |
|---|---|---|
| DevEx (Noda, Storey, Forsgren, Greiler, 2023) | Feedback loops, cognitive load, flow state | Core of the instrument: the three areas where developers meet friction |
| SPACE (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, 2021) | Satisfaction and well-being, performance, activity, communication and collaboration, efficiency and flow | Ensures no single dimension stands in for productivity; satisfaction and collaboration items come from this lens |
| DORA capabilities (dora.dev) | Selected capabilities such as continuous integration, deployment automation, documentation quality, streamlining change approval, generative organisational culture, well-being | Perception of capabilities that the delivery performance report assesses |

```mermaid
flowchart TB
  Q["Question bank items"] --> DX["DevEx: feedback loops, cognitive load, flow state"]
  Q --> SP["SPACE: satisfaction, collaboration, efficiency"]
  Q --> DC["DORA capabilities: perception"]
  DX --> IDX["Dimension scores and drivers"]
  SP --> IDX
  DC --> IDX
  IDX --> ACT["Findings and action plan"]
  SYS["System metrics: DORA five metrics"] --> ACT
```

Other published frameworks exist, such as the DX Core 4. If you adopt
one, map its dimensions to the item IDs in section 5 instead of running
a second survey.

## 3. Privacy, anonymity and data handling

<!-- Guidance: Write the rules respondents will be shown, then follow them exactly. Questions: who can see raw responses? What is the smallest group you will report on? How long is raw data kept? Pitfall: promising anonymity while collecting team, role, tenure and location together, which can identify people in small teams. -->

### 3.1 Principles

The following rules are binding for everyone who designs, runs or
analyses the survey:

1. **PRV-01** Participation MUST be voluntary. Non-participation MUST NOT
   be recorded, reported to managers or followed up individually.
2. **PRV-02** Results MUST NOT be used for individual performance
   evaluation, promotion, compensation or disciplinary decisions.
3. **PRV-03** Results MUST be reported only for groups of at least the
   minimum reporting group size (*Example:* 5 respondents). Smaller groups
   are merged into the next level up.
4. **PRV-04** Demographic questions MUST be limited to what the analysis
   plan needs. Combinations of attributes that create a group below the
   minimum size MUST be suppressed in every view, including filters in
   dashboards.
5. **PRV-05** Raw responses MUST be accessible only to the named raw data
   custodian and a deputy. Managers MUST NOT receive raw data or free-text
   comments attributed to a team below the minimum size.
6. **PRV-06** Free-text comments MUST be screened before sharing to remove
   names, unique events and writing that could identify the author.
7. **PRV-07** Raw data SHOULD be deleted or irreversibly aggregated within
   the retention period in 3.3.
8. **PRV-08** Respondents MUST receive a privacy notice before the first
   question, stating purpose, data collected, who sees what, retention
   and contacts.

### 3.2 Anonymous or confidential

Decide which promise you make and use the correct word with respondents.

| Model | What it means | When to use | Consequences |
|---|---|---|---|
| Anonymous | No identifier is collected or linked; the tool cannot connect a response to a person | Default for most surveys | No follow-up with individuals; no linking to system data per person; cannot prevent duplicate answers except by single-use links not stored with responses |
| Confidential | A pseudonymous identifier is held by the custodian, for example to link to team or tenure from HR data | Longitudinal analysis, or to avoid asking demographic questions | Data stays personal data under the GDPR; requires stronger controls, a documented legal basis and often a DPIA |

Under the GDPR, information that cannot be related to an identifiable
person is outside its scope (see Recital 26), but data that is only
pseudonymised remains personal data. A survey that collects team, role
and tenure for a small group is rarely anonymous in fact. Check with
the data protection officer which model applies.

### 3.3 Data handling record

| Item | Rule *(Example values)* |
|---|---|
| Legal basis (if personal data is processed) | Legitimate interests, GDPR Art. 6(1)(f), with a documented balancing test; consent is weak in an employment relationship |
| Employment context | Check national rules and collective agreements adopted under GDPR Art. 88 and any co-determination rights of the works council |
| Transparency | Privacy notice per GDPR Art. 13 shown at the start of the survey |
| Data minimisation | Only the demographic fields in 5.7; no names, email or IP address stored with responses (GDPR Art. 5(1)(c)) |
| DPIA | Screen using Data Protection Impact Assessment (`compliance/dpia`) when the confidential model or linking to HR data is used |
| Tool and hosting | [Tool], data stored in [region]; processor agreement in place |
| Retention of raw responses | 24 months, to compare cycles; then delete (GDPR Art. 5(1)(e)) |
| Retention of aggregated results | Kept with this report |
| Access to raw data | [@raw-data-custodian] and [@deputy] only; access logged |
| Subject requests | Handled by [@dpo]; with the anonymous model, individual responses cannot be found |

### 3.4 Privacy notice text (original, adapt before use)

> This survey asks about your experience of building and shipping
> software at [Organisation]. It is voluntary and takes about [12]
> minutes. Answers are [anonymous / confidential]: nobody outside
> [custodian team] sees individual answers, and results are shown only
> for groups of [5] or more people. Results are never used to evaluate
> individuals. Raw answers are deleted after [24] months. Questions:
> [contact]. Privacy contact: [DPO contact].

## 4. Population, sampling and administration

<!-- Guidance: Define who is asked, when and how. Questions: census or sample? How will you reach a response rate high enough to report small groups? Pitfall: launching during a release freeze or holiday period and reading the low response rate as disengagement. -->

| Item | Decision *(Example values)* |
|---|---|
| Population | All software engineers, SREs, QA engineers and engineering managers, including contractors with 3 or more months of tenure (240 people) |
| Approach | Census (everyone invited); sampling only when the population exceeds about 1,000 |
| Cadence | Quarterly core survey; onboarding module for people with under 6 months of tenure |
| Field period | 10 working days, avoiding release freezes and public holidays |
| Channels | Single-use links by email; reminders on days 4 and 8 from the sponsor |
| Target response rate | At least 60% overall and in each reporting group |
| Language | English; [other languages] translated and back-translated before first use |
| Accessibility | Tool tested with screen readers and keyboard-only navigation |
| Pilot | 8 to 10 volunteers from different teams test wording and duration one cycle before first launch |

### 4.1 Timeline

| Step | Owner | Date *(Example)* |
|---|---|---|
| Question bank frozen | [@owner] | 2026-08-28 |
| Privacy review complete | [@dpo] | 2026-09-04 |
| Launch announcement by sponsor | [@vp-engineering] | 2026-09-07 |
| Field period | [@owner] | 2026-09-08 to 2026-09-21 (Tuesday to Monday, 10 working days) |
| Analysis and draft report | [@owner] | 2026-10-02 |
| Team readouts | [@engineering-managers] | 2026-10-05 to 2026-10-09 |
| Published results and action plan | [@owner] | 2026-10-16 |

## 5. Question bank

<!-- Guidance: Use these items as a starting point; the wording is original to this template. Keep item IDs stable across cycles and retire IDs instead of reusing them. Questions: is each item about one thing only, in the respondent's own experience, over a stated period? Pitfall: double-barrelled items ("fast and reliable") and leading wording. -->

Scale unless stated: five-point agreement (1 strongly disagree, 2
disagree, 3 neither, 4 agree, 5 strongly agree), plus "not applicable".
Reference period for all items: the last three months.

### 5.1 Feedback loops (DevEx)

| ID | Item | Dimension | Capability link |
|---|---|---|---|
| DX-FL-01 | CI results for my changes arrive fast enough that I stay in context while I wait. | Feedback loops | Continuous integration |
| DX-FL-02 | Waiting for code review rarely slows down my work. | Feedback loops | Streamlining change approval |
| DX-FL-03 | I can run and test my changes locally or in a personal environment without long setup. | Feedback loops | Test automation |
| DX-FL-04 | When something I shipped misbehaves in production, I find out quickly. | Feedback loops | Monitoring and observability |
| DX-FL-05 | I get answers to technical questions from other teams within a working day. | Feedback loops | Loosely coupled teams |

### 5.2 Cognitive load (DevEx)

| ID | Item | Dimension | Capability link |
|---|---|---|---|
| DX-CL-01 | The documentation I need for my work is accurate and easy to find. | Cognitive load | Documentation quality |
| DX-CL-02 | The codebase I work in most is easy to understand and change safely. | Cognitive load | Code maintainability |
| DX-CL-03 | I can release my changes to production without depending on one specific person. | Cognitive load | Deployment automation |
| DX-CL-04 | The number of tools and systems I must use to ship a change is reasonable. | Cognitive load | Platform engineering |
| DX-CL-05 | I understand how my work connects to the goals of my team. | Cognitive load | Visibility of work in the value stream |

### 5.3 Flow state (DevEx)

| ID | Item | Dimension | Capability link |
|---|---|---|---|
| DX-FS-01 | I get enough uninterrupted time for focused work in a typical week. | Flow state | Work in process limits |
| DX-FS-02 | Unplanned work (incidents, urgent requests) seldom pulls me away from planned work. | Flow state | Proactive failure notification |
| DX-FS-03 | I am rarely blocked waiting for another team to finish something. | Flow state | Loosely coupled teams |
| DX-FS-04 | In a typical week, how many hours of uninterrupted blocks of 2 hours or more do you get? (0, 1 to 4, 5 to 9, 10 to 14, 15 or more) | Flow state | Not applicable |

### 5.4 Satisfaction, collaboration and culture (SPACE and DORA)

| ID | Item | Dimension | Capability link |
|---|---|---|---|
| DX-SAT-01 | I would recommend my team's development tooling to a peer at another company. | SPACE: satisfaction | Empowering teams to choose tools |
| DX-SAT-02 | My workload is sustainable over the long term. | SPACE: well-being | Well-being |
| DX-COL-01 | It is safe to raise problems and bad news in my team. | SPACE: collaboration | Generative organisational culture |
| DX-COL-02 | Failures lead to learning rather than blame. | SPACE: collaboration | Generative organisational culture |
| DX-EFF-01 | Most of my time goes to work that I consider valuable. | SPACE: efficiency and flow | Not applicable |

### 5.5 Delivery practices (DORA perception)

| ID | Item | Dimension | Capability link |
|---|---|---|---|
| DX-DEL-01 | Deploying my team's service is routine and low-stress. | Feedback loops | Deployment automation |
| DX-DEL-02 | Change approval for my team's releases matches the risk of the change. | Cognitive load | Streamlining change approval |
| DX-DEL-03 | Security requirements are built into our tools and pipeline rather than added at the end. | Cognitive load | Pervasive security |

### 5.6 AI-assisted development module (optional)

| ID | Item | Scale |
|---|---|---|
| DX-AI-01 | How often did you use an approved AI coding assistant in the last month? | Never, monthly, weekly, daily |
| DX-AI-02 | I know what our organisation allows and does not allow when using AI tools for code. | Agreement |
| DX-AI-03 | AI assistance has reduced the time I spend on routine tasks. | Agreement |
| DX-AI-04 | I trust AI-generated code only after the same review and tests as other code. | Agreement |

### 5.7 Open questions and segmentation

| ID | Item |
|---|---|
| DX-OPEN-01 | What is the single biggest thing slowing you down right now? |
| DX-OPEN-02 | If you could fix one thing about how we build and ship software, what would it be? |
| DX-SEG-01 | Product area (list of areas, each with at least 10 people) |
| DX-SEG-02 | Tenure band: under 6 months, 6 to 24 months, over 24 months |
| DX-SEG-03 | Role family: individual contributor, manager |

Do not ask for team name, location, age, gender or exact job title
unless the analysis plan needs it and the privacy review approved it.

## 6. Analysis method

<!-- Guidance: Fix the method before you see the data. Questions: what counts as a meaningful change? How will you treat small groups and "not applicable"? Pitfall: reporting a 3-point change as an improvement when the margin of error is 4 points. -->

1. **Response rate**: `responses / invited`, overall and per reporting
   group. Flag groups below the target response rate.
2. **Favourable score** per item: share of answers 4 or 5 among valid
   answers (excluding "not applicable"). Also report unfavourable (1 or 2).
3. **Dimension score**: mean of the favourable scores of the items in
   the dimension, reported to whole percentage points.
4. **Margin of error** for a favourable share at 95% confidence, with
   finite population correction:
   `MoE = 1.96 * sqrt(p * (1 - p) / n) * sqrt((N - n) / (N - 1))`,
   where `n` is responses, `N` the population and `p` the share. Use
   `p = 0.5` for the worst case.
5. **Meaningful change** between cycles: compare the two shares as a
   difference of proportions. Its margin of error at 95% confidence is
   `MoE_diff = 1.96 * sqrt(p1 * (1 - p1) / n1 * fpc1 + p2 * (1 - p2) / n2 * fpc2)`,
   where `fpc = (N - n) / (N - 1)` for each cycle; this equals
   `sqrt(MoE_1^2 + MoE_2^2)`, about 1.4 times the single-cycle margin
   when both cycles are similar. Treat a change as real only when it
   exceeds `MoE_diff` and the group has at least 20 respondents in each
   cycle; otherwise label it "within noise". Because many people answer
   both cycles, the samples are not independent; the formula then
   overstates the noise slightly, which keeps the rule conservative.
   Dimension scores are means of item shares; use the item formula as an
   approximation for them and say so in the report.
6. **Drivers**: rank items by correlation with DX-EFF-01 or DX-SAT-02 to
   find which friction matters most; treat this as a pointer, not as
   proof of cause.
7. **Free text**: two people code comments independently into themes,
   agree a codebook, and report theme counts; quote only screened
   comments (PRV-06).
8. **Triangulation**: compare perception with system data in the
   Software Delivery Performance Report; investigate disagreements.
9. **Suppression**: apply PRV-03 and PRV-04 before any table leaves the
   custodian.

## 7. Results report

<!-- Guidance: Lead with the response rate and the three biggest messages, then the tables. Report groups only above the minimum size. Pitfall: a 40-row table with no interpretation. -->

### 7.1 Participation

*Example (Corvid Commerce, Q3 2026):* 168 of 240 invited people
responded, a response rate of 70.0%. The worst-case margin of error for
an organisation-wide favourable share is
`1.96 * sqrt(0.25 / 168) * sqrt(72 / 239)`, which is about ±4.1
percentage points (4.15 before rounding). For a change between two
cycles of this size, the worst-case margin of the difference is about
±5.9 points (`sqrt(2) * 4.15`), assuming the last cycle also had about
168 responses.

| Reporting group | Invited | Responses | Response rate | Reportable |
|---|---|---|---|---|
| Checkout area *(Example)* | 62 | 46 | 74.2% | Yes |
| Payments (Team Heron) *(Example)* | 15 | 12 | 80.0% | Yes |
| Catalog and search *(Example)* | 70 | 47 | 67.1% | Yes |
| Platform and SRE *(Example)* | 55 | 41 | 74.5% | Yes |
| Data *(Example)* | 38 | 22 | 57.9% | Yes, flagged below target |
| **Total** | **240** | **168** | **70.0%** | |

### 7.2 Dimension scores (organisation)

| Dimension | Items | Favourable last cycle | Favourable this cycle | Change | Reading |
|---|---|---|---|---|---|
| Feedback loops *(Example)* | DX-FL-01 to 05 | 54% | 60% | +6 | Borderline real change: +6 against about ±5.8 for the difference at the observed shares (±5.9 worst case); confirmed by DX-FL-01 at +15 |
| Cognitive load *(Example)* | DX-CL-01 to 05 | 49% | 51% | +2 | Within noise |
| Flow state *(Example)* | DX-FS-01 to 03 | 47% | 48% | +1 | Within noise |
| Satisfaction and collaboration *(Example)* | DX-SAT, DX-COL, DX-EFF | 66% | 68% | +2 | Within noise |
| [Dimension] | [Items] | [%] | [%] | [pp] | [Reading] |

### 7.3 Items to watch

| Item | Favourable | Unfavourable | Change | Comment |
|---|---|---|---|---|
| DX-FL-01 CI results fast enough *(Example)* | 68% | 14% | +15 | Parallel test stages and merge queue |
| DX-FL-02 Code review wait *(Example)* | 42% | 37% | -1 | Top friction theme in free text |
| DX-CL-01 Documentation accurate and findable *(Example)* | 38% | 40% | +1 | Second friction theme |
| DX-FS-01 Uninterrupted focus time *(Example)* | 50% | 27% | +2 | Meeting load in manager-heavy teams |
| DX-SAT-02 Sustainable workload *(Example)* | 61% | 18% | -3 | Lower in Payments (see 7.4) |

### 7.4 Segment view

| Item | Checkout area (n=46) *(Example)* | Payments (n=12) *(Example)* | Organisation (n=168) *(Example)* |
|---|---|---|---|
| DX-FL-01 | 71% | 50% | 68% |
| DX-FL-02 | 39% | 33% | 42% |
| DX-CL-03 | 70% | 25% | 63% |
| DX-FS-01 | 50% | 42% | 50% |
| DX-SAT-02 | 65% | 42% | 61% |

With 12 respondents, one answer moves a share by about 8 percentage
points; read the Payments column as a signal that agrees with the system
data (manual rollback known by one engineer), not as a precise value.

### 7.5 Free-text themes

| Theme | Comments | Share of 131 commenters | Example (screened, paraphrased) |
|---|---|---|---|
| Code review wait *(Example)* | 38 | 29% | Reviews sit for a day because the same two people review everything |
| Documentation drift *(Example)* | 27 | 21% | Runbooks describe the old deployment process |
| Release and rollback effort *(Example)* | 15 | 11% | Rolling back payments needs one specific engineer |
| [Theme] | [N] | [%] | [Paraphrase] |

Check: 38 / 131 = 29%, 27 / 131 = 21%, 15 / 131 = 11%.

## 8. Findings

<!-- Guidance: Combine survey results with system data. Each finding states evidence, cause and who is affected. Pitfall: findings that blame groups rather than describing system conditions. -->

| Finding ID | Finding | Evidence | Affected groups | Priority |
|---|---|---|---|---|
| DXF-01 *(Example)* | Feedback loops improved where CI changed | DX-FL-01 +15; delivery report lead time 29 h to 21 h | Checkout area | Information |
| DXF-02 *(Example)* | Code review wait is the top friction | DX-FL-02 at 42%; 29% of comments; review stage 9 h median | All product areas | High |
| DXF-03 *(Example)* | Release dependency on one person in Payments | DX-CL-03 at 25%; DX-SAT-02 at 42% | Payments | High |
| DXF-04 *(Example)* | Documentation is not trusted | DX-CL-01 at 38%; 21% of comments | All | Medium |
| [DXF-NN] | [Finding] | [Evidence] | [Groups] | [Priority] |

## 9. Action plan

<!-- Guidance: Commit to two to four actions organisation-wide, plus team-level actions owned by teams. Every action names the item that should move. Pitfall: an action list longer than the team can deliver, which teaches people the survey changes nothing. -->

| Action ID | Action | Finding | Owner | Due | Item expected to move | Target next cycle |
|---|---|---|---|---|---|---|
| DXA-01 *(Example)* | Review rota and a review service level of 4 working hours for the checkout teams | DXF-02 | [@checkout-em] | 2026-10-31 | DX-FL-02 | Above 55% |
| DXA-02 *(Example)* | Automated rollback for payments-gateway; two more trained engineers | DXF-03 | [@team-heron-lead] | 2026-11-30 | DX-CL-03 (Payments) | Above 60% |
| DXA-03 *(Example)* | Documentation ownership in the service catalogue with a review date per runbook | DXF-04 | [@platform-lead] | 2026-12-15 | DX-CL-01 | Above 50% |
| [DXA-NN] | [Action] | [DXF ID] | [@owner] | YYYY-MM-DD | [Item ID] | [Target] |

Actions DXA-01 and DXA-02 are the same work as ACT-2026Q3-02 and
ACT-2026Q3-01 in the delivery performance report; track them once and
cross-reference.

## 10. Communication and follow-up

<!-- Guidance: Plan how results reach people and how the loop closes. Questions: who presents results to each group? When do people hear what changed? Pitfall: sharing results only with leadership. -->

| Step | Audience | Content | Owner | When |
|---|---|---|---|---|
| Organisation readout | All invited | Response rate, dimension scores, top findings, committed actions | [@vp-engineering] | Within 4 weeks of close |
| Team readouts | Each reportable group | Group results, discussion of causes, team-level actions | [@engineering-managers] | Within 2 weeks after the organisation readout |
| Leadership review | Engineering leadership | Findings, investment decisions, links to the delivery report | [@owner] | Same quarter |
| Progress update | All invited | Status of each DXA action | [@owner] | Mid-cycle |
| "You said, we did" | All invited | Changes made since the last cycle, shown at the start of the next survey | [@owner] | Next launch |

Review the question bank once a year: retire items that never inform a
decision, check wording with a pilot, and record changes as a new
question bank version.

## 11. Glossary and references

<!-- Guidance: Define the terms as this survey uses them and list the sources with the version or date checked. -->

### 11.1 Glossary

| Term | Meaning in this survey |
|---|---|
| Developer experience | How developers perceive and feel about their daily work, tools and processes |
| Feedback loop | The time and quality of the response a developer gets to an action, such as a build, review or deployment |
| Cognitive load | The mental effort a developer needs to complete a task |
| Flow state | Periods of focused, uninterrupted work |
| Favourable score | Share of valid answers at 4 or 5 on the five-point scale |
| Minimum reporting group size | Smallest number of respondents for which results are shown |
| Anonymous / confidential | No link to a person exists / a link exists but is protected |
| Margin of error | Half-width of the 95% confidence interval for a share |

### 11.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Noda, Storey, Forsgren, Greiler, "DevEx: What Actually Drives Productivity", ACM Queue 21(2), DOI 10.1145/3595878 | 2023 | Three DevEx dimensions (concepts only) |
| Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, "The SPACE of Developer Productivity", ACM Queue 19(1) | 2021 | Five SPACE dimensions (concepts only) |
| DORA, Capabilities catalogue, https://dora.dev/capabilities/ | Checked 2026-10-24 | Capability names for item mapping |
| DORA, Software delivery performance metrics guide, https://dora.dev/guides/dora-metrics/ | Page updated 2026-01-05 | System data for triangulation |
| Regulation (EU) 2016/679 (GDPR), Art. 5, 6, 13, 35, 88 and Recital 26, https://eur-lex.europa.eu/eli/reg/2016/679/oj | Check the consolidated text | Privacy rules for survey data |
| DX Core 4 (DX) | 2024 | Named only as an alternative framework |

## Standard and licence note

Based on the concepts of the DevEx framework (ACM Queue, 2023) and the
SPACE framework (ACM Queue, 2021), cited for their dimensions only with
no text reproduced, and on capability names from the DORA capabilities
catalogue published at dora.dev by Google LLC under the Creative Commons
Attribution 4.0 International licence (CC BY 4.0,
https://creativecommons.org/licenses/by/4.0/). The question bank is
original wording written for this template. Privacy references to the
GDPR are paraphrased; this is a documentation format, not legal advice,
so check the consolidated text and national employment rules with your
data protection officer. DX Core 4 is named only. Google, DORA, ACM and
DX are trademarks of their owners; this template is not affiliated with
or endorsed by them. This template is original text written for this
collection. Check the current official versions before use. Template
licence: MIT.