Developer experience survey: 14 questions on where engineers lose time

Two fields first, so every later answer can be cut by team and read against how much coding the person did.

1. Which team do you mostly work in?Short text (or a fixed list of team names)Swap this for a pick list of your real team names. Free text lets one person's spelling identify them.
2. In the last four weeks, how much of your time went on writing, reviewing or shipping code?Pick one of 5Exposure, not opinion. A lead who coded for two days reads the build questions differently from someone who coded every day.

How long a developer waits to learn whether their change works: the machine, the reviewer, the pipeline, the release.

1. A local build and test run is quick enough that I do not switch to something else while I wait.Strongly agree to strongly disagreeDisagreement means context switching while builds run, which costs more than the minutes on the clock.
2. Review of my changes usually starts within one working day.Strongly agree to strongly disagreeA review queue problem. Check it against your own review timestamps before blaming reviewers.
3. When the pipeline fails, the output tells me why without digging.Strongly agree to strongly disagreeLow scores usually mean flaky tests or logs nobody can read, not slow infrastructure.
4. Getting a merged change into production needs no manual chasing.Strongly agree to strongly disagreeManual release steps, approvals or a deploy only one person knows how to run.

The effort it takes to know enough to change something safely.

1. I can work out how a service I do not own behaves without having to ask someone.Strongly agree to strongly disagreeLow here and high on question 8 means the docs exist but do not cover other teams' services.
2. The documentation I rely on is accurate enough to act on.Strongly agree to strongly disagreeStale docs are worse than none: people act on them. Ask which ones in the open answer.
3. Getting access to a repository, tool or environment I need does not stall my work.Strongly agree to strongly disagreeOften the cheapest fix in the set: a request process nobody owns.

Whether the week leaves room for the kind of work that needs a long stretch of attention.

1. Most days I get at least one two-hour stretch without meetings or interruptions.Strongly agree to strongly disagreeTwo hours is the test because most real engineering tasks do not fit in the gaps between meetings.
2. Unplanned work rarely breaks up the work I had planned for the day.Strongly agree to strongly disagreeLow scores point at on-call load, support rotas or urgent requests landing on the same people.
3. In the last four weeks, which of these cost you the most time?Tick all that applyCount the ticks per option. This is the ranked fix list; "Nothing significant" sits first so a good month costs one tap.

One open answer, then the rating everything above explains.

1. If you could remove one thing that slows you down, what would it be?Long textOne thing, not a list. Forty single answers can be grouped and counted.
2. Overall, how would you rate your developer experience over the last four weeks?Pick one of 5The outcome. Read the three blocks above against it to see which one moves it.