How to Measure Developer Experience (Without Turning It Into a Scorecard)

Developer experience is how it feels to get work done at your company. How long you sit there waiting for a build. How much you have to hold in your head to ship one change. Whether you ever get three hours to yourself.

The best breakdown I've seen is from a 2023 paper by Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler. They took 25-plus factors and boiled them down to three:

Feedback loops. How fast do you find out whether the thing you did worked? That's your build, your tests, your CI—and it's people, too. How long until someone reviews your PR, or answers your question in chat. A slow loop costs more than the waiting. People batch up changes, go do something else, and forget where they were. That's where the hours go.

Cognitive load. How much do you have to know to get one task done? At 8x8 we had hundreds of APIs that looked like they came from a dozen different companies, and documentation spread out across 7+ places. Our engineers weren't slow. Every task just started with figuring out which of the seven docs was the right one.

Flow. How often do you get a real stretch of focus? Meetings, on-call noise, unplanned work, chat pings—they chop the day up. The hard problems get solved in flow. Great tooling and no focus time still ships slow.

Every number on this page maps to one of those three. If a metric doesn't, I don't collect it. The same paper suggests measuring each one two ways—ask people, and pull from systems:

The one that surprised me the first time I read it: Google surveyed 622 developers across three companies to see what predicts how productive people feel. The top three had nothing to do with tools. Being into the job. Peers who back your ideas. Useful feedback. The Developer Thriving study (1,282 developers, 12+ industries) landed in the same place.

I say this to every engineering leader I work with: we aren't computers. You can't throw more megahertz at people and expect linear improvements. Life happens. Context switching has real costs. Happy developers are productive developers—most of the time. If your measurement program only counts commits, you're counting the wrong thing.

One more, because it bites. DORA's 2024 report found that unstable priorities tank productivity and spike burnout, even when leadership and docs are good. If your metrics program reads like a stack ranking—congratulations, you just added another unstable priority.

This is the framework I use. Most teams do the first step and stop.

1. Measure: establish your baseline. You need to know where you are. Pick metrics that matter to your business and track them consistently. This is the easy part—most teams stop here. A spreadsheet is fine for the first quarter. Seriously.

2. Understand: ask why it's that way. Your deployment takes two hours. Okay, why? Are you doing gradual rollouts to 1% of traffic at a time? Do you have 100 million users where an outage would be catastrophic? Is there a manual approval gate because a regulator said so? Maybe two hours isn't a problem. Maybe two hours is exactly what smart looks like for your situation. I've seen teams obsess over a "slow" 30-minute CI pipeline, only to discover those 30 minutes included the test coverage that had prevented multiple production incidents. Cutting them would've been optimizing in the wrong direction.

3. Correlate: connect it to outcomes, and to humans. Fast deployments are great—unless they're fast because you removed the safety checks. High commit frequency looks impressive, until you realize it's because someone's force-pushing to fix their own mistakes. When McKinsey put out "Yes, you can measure software developer productivity" in 2023, Kent Beck and Gergely Orosz took it apart, and their point is the one to keep: most of these metrics measure effort and output. What you want is outcome and impact.

When you're staring at a number, ask:

• Why is this metric what it is? Not "is it good or bad," but what adds up to this number?
• What would "better" actually mean for our business? Faster isn't always better. Sometimes slower and safer wins.
• What are we optimizing for? Speed? Safety? Consistency? Developer experience? You can't have all of them at once.
• Does this connect to something we care about, or is it just easy to measure?
• Have we asked the humans involved?

Your developers know where the friction is. Sometimes the best metric is a conversation.

Surveys are the backbone of this, because a lot of what matters (how much is in your head, whether you can focus, whether you like your job) only exists in people's heads. Google has run its engineering satisfaction survey every quarter since 2018. Here's how I run one that engineers don't roll their eyes at.

Keep it short and keep it the same. 15 to 25 questions on a 5-point agree/disagree scale, the same core questions every time so you can see the trend, then two or three open-ended questions at the end. That's where the real answers are. A few I always include:

Every 8 to 12 weeks. Quarterly works for most orgs. Laura Tacho at DX puts it well: by the next survey, people should be able to notice that something changed because of what they said last time. Worried about survey fatigue at scale? Do what Google does—split engineers into three random groups and survey one group per quarter. Everyone answers once a year and you still get a quarterly read.

The response rate is the metric you earn. A typical developer survey at a mid-to-large company gets around 30%. Companies with a real DevEx program get 80% or more, and that's about where execs should start trusting org-wide numbers. Turns out the survey tool has almost nothing to do with it. People answer when they believe something will happen with the answers. So: anonymous, and say so. Only report groups of five or more. Publish last time's results and what you did about them before you send the next one. Have engineering leadership send it, not HR. Two weeks open, one reminder.

Segment it, don't average it. "3.8 out of 5 on build satisfaction, org-wide" tells you nothing. Cut it by team, by tenure (people under six months see friction the veterans have gone blind to), by platform, by role. The gap between groups is your first project.

Small team? Under 20 engineers, skip the survey infrastructure. Ask three questions in every 1:1 and write the answers down. How do you feel about your ability to get work done? What's blocking you? What would make your day better? Tally the themes once a month. You'll have better data than most surveys produce.

How does this fit with DORA and SPACE? They're not competing. DORA measures delivery. SPACE keeps you honest about measuring more than throughput. What's on this page is the layer underneath both: why your DORA numbers look the way they do. (DX Core 4 packages the same idea into four buckets with a survey index in the middle. DX claims each one-point improvement is worth about 13 minutes per developer per week. Vendor number, take it as one—but it's a fine starting question set.)

Measuring without acting is worse than not measuring at all. It teaches your engineers that feedback goes into a void.

Week one, before you open a single chart, read every free-text answer and tag it by theme. Feedback is gold, even when it's noisy. Complaints often mask legitimate patterns. Find the root cause, not just the loudest voice.

Week two, pick one thing. Not five. One thing most engineers will notice when it's fixed. At 8x8, "the docs are in seven places" beat every other complaint. Getting everything into one searchable site with a style guide wasn't glamorous. It was the fix everyone felt.

Week three, publish the results and the plan to the whole org—the good, the bad, and "we're not fixing this yet, here's why." Then say what you are fixing, who owns it, and when they'll hear about it again. If you build it, they won't come. You have to tell them. Chat, all-hands, the onboarding site, email. The onus of communication is on the communicator, and in a remote world there's no harm in over-communicating.

Then fix it, and watch the number that should move (CI p90, time to first deploy, questions per week in #help). When the next survey goes out, you want to open with "you told us X, we did Y, here's what changed." That's what gets you the 80% response rate.

I've watched this fail the same few ways.

Measuring individuals. Commits per engineer on a dashboard the VP can sort by name. Don't. Team level and org level only. When a measure becomes a target it stops being a good measure—Goodhart's law, and I've never seen it lose. If people are gaming your metrics, you built the wrong incentive.

Cargo-culting the dashboard. Google's own engineering book starts every measurement with one question: what decision will this change? If the answer is "none," don't measure it.

Surveying and then doing nothing. The annual engagement survey goes out, results land in a deck, nothing changes, and next year the response rate drops from 40% to 25%. Don't send a survey without engineering time already budgeted to act on it. If you can't promise to fix at least one thing, don't ask.

Trusting only the numbers, or only the feelings. "The data says CI is fast" while everyone complains about CI. Google's productivity team checks the logs against what people report, and the other way around. When they disagree, that's the finding. Go talk to people.

And the new one: "We rolled out AI coding tools, so productivity is up." DORA's 2024 data tied AI adoption to small gains in flow and satisfaction—and to lower throughput and noticeably lower delivery stability. Their 2025 report's line is that AI amplifies whatever your org already is. Measure stability next to adoption or you'll throw a party for a regression.

Talk to ten engineers across teams and tenure this week. Shadow one new hire from laptop to first merged change and count the waits. Pull the free data—CI times, PR pickup, deploy counts—into a spreadsheet.

By the end of the month, run the first survey. By day 45, publish the results and commit to one fix with an owner and a date. By day 90, ship it, send the second survey with a "you told us, we did" preamble, and compare response rates. If they went up, it's working. If not, you skipped a step.

Measuring is easy. Understanding is hard. That's why Google, Microsoft, and GitHub have whole teams for this. Don't look at your metrics and wonder if they're "good enough." Look at them and ask what they're telling you about how work gets done here. The goal was never to stack rank anybody. It's to find the papercuts, reduce friction, and help people do their best work.

If you're wrestling with this at your company—tracking a bunch of stuff and not sure you're learning anything—drop me a note. I'd love to compare notes.

-Matt