Authors: Jakub Oleksy | [@JakubOleksy](https://github.com/JakubOleksy) and Matt Nigh | [@mattnigh](https://github.com/mattnigh)

It's a question that haunts engineering leaders, spawning an industry-wide obsession with metrics like lines of code written, pull request velocity, and deployment frequency. We've built dashboards, created frameworks, and spent countless hours trying to quantify developer output.

__But what if we're measuring the wrong things entirely?__

At GitHub, we've learned through scaling our own engineering teams that the best indicator of productivity isn't found in commit counts or deployment metrics---it's in developer satisfaction. Happy developers don't just write better code; they solve harder problems, collaborate more effectively, and build better products.

In this post, we'll explore why developer satisfaction isn't just a feel-good metric---it's a powerful tool for measuring and improving engineering productivity.

### The productivity measurement problem

Despite the tech industry's obsession with metrics and optimization, there's a striking paradox at its heart: *most organizations have no systematic way to measure developer productivity.*

This measurement vacuum isn't an oversight---it reflects the complexity of quantifying productivity where individual contributors might spend days solving problems that no one was even aware of when the week began.

The industry's attempts to tackle this measurement challenge have largely centered around deployment metrics popularized by DORA and others: 

-   __Deployment frequency (DF):__ This tells you how often code is getting shipped to production. High frequency indicates your team is iterating fast, delivering value, and unblocking work instead of letting it pile up.

-   __Lead time for changes (LT):__ Measures how long it takes to get code from commit to production. If this is slow, your process has friction---slowing down innovation and killing morale. The faster your lead time, the quicker you get ideas into users' hands and keep devs happy by letting them see their work live.

-   __Time to recover (TTR):__ Aka MTTR, this is how fast you can get things back to normal after an incident. Incidents will happen---no team is perfect. But if you can recover quickly, you're building a resilient system and protecting your team's (and users') sanity.

-   __Change failure rate (CFR):__ This is the percentage of changes that cause problems in production. Lower is better; it means you're shipping quality and aren't stuck firefighting all the time. If every deployment breaks things, it's a sign your systems and testing need help. Aim to reduce failure without slowing down, so your team can deploy with confidence.

While these metrics provide valuable operational insights, they capture only the mechanical aspects of software delivery--the "how fast" and "how often" of code deployment. They fail to account for crucial elements like satisfaction, innovation, and toil.

A team could excel at rapid deployments while building the wrong features or accumulating crippling technical debt. It's akin to measuring a restaurant's success solely by how quickly it serves food, while ignoring the quality of the cuisine or the opinions of the chefs that make the food.

> The most promising path forward may be counterintuitive: instead of focusing on direct productivity metrics, organizations should prioritize developer satisfaction. 

Research from [Dr. Nicole Forsgren](https://nicolefv.com/) and others [suggests that high-performing engineering organizations consistently correlate with high developer satisfaction scores.](https://queue.acm.org/detail.cfm?id=3454124) This makes sense--developers who feel equipped, empowered, and engaged are more likely to solve complex problems effectively, collaborate productively, and make sound technical decisions.

Developer satisfaction encompasses crucial factors that traditional metrics miss. Things like the quality of tools and workflows, the effectiveness of team structures, the amount of toil in daily work, and the balance between feature delivery and technical investment. 

When developers report high satisfaction, it indicates they have the resources, autonomy, and support needed to deliver their best work.

### Why developer satisfaction matters

At GitHub, we've discovered that developer satisfaction is the foundation of engineering excellence. Developer satisfaction isn't just about having a pleasant workplace---it's about creating an environment where people can do their best work. Said another way, happy developers are engaged developers. 

> When engineers feel supported and valued, they don't just write code---they invest themselves in solving your organization's hardest problems. They bring their full creativity to work, question assumptions, and push boundaries that others might accept as fixed.

This engagement naturally flows into better problem solving. A satisfied developer isn't just going through the motions of completing features or fixes; they're thinking deeply about architectural decisions, considering edge cases, and anticipating future needs. They're more likely to speak up when they see potential issues and propose innovative solutions rather than band-aid fixes.

But perhaps the most compelling aspect of developer satisfaction is its impact on retention. When developers are satisfied, they stay longer, building deep institutional knowledge and expertise that compounds over time. Each year a talented developer remains with your team isn't just another year of code---it's another year of accumulated context, refined judgment, and strengthened team relationships.

The simple truth is this: satisfied developers do their best work. Everything else---from code quality to system reliability to innovation---flows from this fundamental principle.

### The virtuous cycle

When you invest in developer satisfaction, something remarkable happens: you create a self-reinforcing cycle of improvement. At GitHub, we've witnessed this firsthand in how we build and evolve our own platform.

It starts with making meaningful improvements to your developer experience. These don't have to be massive overhauls---they can be as focused as streamlining a deployment process or automating a repetitive task. What matters is that developers see their pain points being addressed.

> When developers see their feedback turning into real changes, they become more engaged in the improvement process. They're more likely to provide detailed, thoughtful feedback about what's working and what isn't.

This high-quality feedback becomes the fuel for your next round of improvements. Your team can focus on changes that will have the most impact because you're working from real, ground-level insights rather than assumptions. Each improvement builds on the last, creating momentum that transforms your engineering culture.

The end result is a team that doesn't just adapt to change---it drives change. Your developers become active participants in shaping their work environment, leading to better tools, processes, and ultimately, better products.

### Conclusion

The path to exceptional engineering output isn't found in counting lines of code or measuring pull request velocity---it's built on the foundation of developer satisfaction. At GitHub, our journey has consistently shown that when developers are happy and engaged, everything else falls into place: code quality improves, innovation accelerates, and teams deliver better products.

Start measuring developer satisfaction today. Not next quarter, not after your next planning cycle---today. Begin with a simple survey, act on the feedback you receive, and watch how this fundamental shift in focus transforms your engineering culture.

If you don't know to start, begin by asking your developers some basic questions:

-   What are the top Developer Experience (DevEx) areas you think should be improved?

-   How satisfied are you with the tooling and workflows for your work in general?

-   How satisfied or dissatisfied are you with the following tooling and workflows around testing?

-   With regard to tools and workflows, what is your biggest pain point?

-   With regards to shipping changes, what is your biggest pain point?

-   Imagine you have a magic wand to improve one thing (even if it seems impossible) about our DevEx. What would it be?

If your organization leverages GitHub Copilot, consider adding questions like the below, [or use our survey](https://downloads.ctfassets.net/wfutmusr1t3h/66acuCKYqXme0aukY8Rn3x/a8c682946b0176db5860544ad85fffe7/2024-04-23-GitHub-CCI-LP-Copilot-Impact-Survey-NT-V003.pdf):

-   How satisfied are you with GitHub Copilot?

-   Which workflows do you want GitHub Copilot to help with?

-   Why are you not using GitHub Copilot?

-   Do you have any feedback on GitHub Copilot?

Developer happiness isn't just a nice-to-have; it's a critical success factor and a leading indicator of long-term productivity. When you prioritize developer satisfaction, you're not just investing in your team---you're investing in better software, stronger innovation, and a more resilient engineering culture.

In the end, it's simple: happy developers build better software. Start today, and see the difference it makes.

"How do we know if our developers are productive?"

/developer-productivity/

Why developer satisfaction is your best productivity metric