Skip to content
Nerdy beta

Improving Developer Experience

Measure the friction before you spend money on it

Engineering Metrics Developer Experience

Your engineers already know what slows them down. They have known for months, and they have told you in retros, in skip-levels, and in exit interviews. What you do not have is a way to tell which complaint is the expensive one, which teams are actually affected, and what any of it costs in delivery you never got.

This is a 4-6 week discovery program that measures developer experience across your engineering organization and converts the results into work you can schedule. We run it through our strategic partnership with DX, whose survey and analytics platform samples up to 16 drivers of developer productivity and reports them against four executive KPIs. A Nerd/Noir Senior Engineering Collaborator then works with your leaders to turn the hotspots into a prioritized improvement plan sized against likely return.

The output is not a dashboard. It is a ranked list of validated problems with an argument attached to each one.

Who It’s For

Engineering leaders accountable for delivery across more than one team: VPs of Engineering, CTOs, directors, and the platform or enablement leaders who will own the improvements. The survey covers the whole engineering organization, so this works best when leadership is prepared to publish the results internally and act on at least one finding. Teams read a survey they never hear back from as theater, and they answer the next one accordingly.

Format

  • Duration: 4-6 weeks end to end
  • Delivery: Remote. The survey reaches your engineers over Microsoft Teams, Slack, or email
  • Effort on your side: Onboarding consultation, survey setup, and an executive readout session

What You’ll Walk Away With

  • A developer experience snapshot of your engineering organization, scored across the drivers you selected
  • Four executive KPIs — speed, quality, ease of delivery, and weekly time loss — with industry benchmarks for each
  • An executive readout of the findings, including the friction points costing you the most delivery
  • Up to three interviews with teams or individuals who completed the survey, to explain the numbers the survey cannot
  • Up to 20 hours of post-survey collaboration with a Senior Engineering Collaborator
  • A high-level playbook for improving developer experience, sequenced by likely return and by how hard each item is to change
  • A measurement baseline you can re-run, so the next survey answers whether any of it worked

How It Works

Onboarding and Driver Selection

We start by deciding what to measure. The platform carries a library of drivers covering batch size, build processes, code review, codebase experience, deep work, documentation, ease of release, incident response, local development, on-call experience, production debugging, requirements quality, technical debt, test coverage, and more. You do not survey all of them. We work with your leaders to select the drivers that match your actual hypotheses about where the friction lives, then set up delivery to your engineering organization. Selecting drivers is itself diagnostic; the argument about what to measure surfaces disagreements your leadership team did not know it had.

Running the Survey

The survey goes out over the channel your engineers already use. Results come back scored by driver and rolled into the four executive KPIs, benchmarked against organizations of comparable size and industry. This phase is mostly waiting, and the thing that determines its value is response rate. We help you communicate the survey in a way that gets one, which means being specific about what will happen with the answers.

Executive Readout

We present the findings to your leadership: where the organization scores well, where it scores badly, and which of the bad scores are actually expensive. Benchmarks are useful here for calibration and dangerous for comparison, and we are explicit about the difference. A percentile is context, not a target.

Interviews and the Improvement Plan

Survey data tells you a driver scored badly. It does not tell you why, and the why is where the fix lives. We interview up to three teams or individuals to get behind the numbers, then work with your leaders to build the plan: what to change, in what order, and what evidence would tell you it worked. Items get framed as options with measurable upside rather than a cleanup backlog, the same way we frame work in Technical Investment.

If the interviews say your constraint is decision latency, unclear ownership, or a roadmap nobody believes, we will tell you that, and the plan will point at org design instead of tooling. A survey that only ever recommends more survey is a sales instrument.

What We Measure

Four executive KPIs sit at the top:

  • Speed — how quickly the organization turns work into value
  • Quality — whether engineers are building quality in rather than inspecting it later
  • Ease of Delivery — how much friction stands between a finished change and production
  • Weekly Time Loss — hours going to work that adds nothing, and where they go

Beneath them sit the individual drivers, and that is where every actionable finding lives. A composite score moving three points tells you nothing you can schedule. “Local environment setup is costing every new hire nine days” tells you exactly what to fix. See DX Core 4 for how the composite is built and where reading it as a single number will mislead you.

Attribution

This program is built on the DX Core 4, published by DX and authored by Abi Noda, Laura Tacho, Margaret-Anne Storey, Michaela Greiler, and Nicole Forsgren. The Core 4 folds together three earlier bodies of work: the DORA research (Forsgren, Humble, and Kim, 2018), the SPACE framework (Forsgren et al., 2021), and the DevEx dimensions (Noda et al., 2023).

We run this engagement on DX’s platform through a strategic partnership with DX. The survey instrument is theirs; the diagnosis, the interviews, and the improvement plan are ours.