Software teams have long chased the holy grail of developer productivity. Is it the number of lines of code produced? The velocity of completed story points? For years, many have tried to boil productivity down to simple metrics, only to find that it’s not so simple. Recent research paints a clearer (and sometimes surprising) picture of what makes developers truly productive – and it’s much more about developer experience than brute output.
In this post, we’ll dive into some of the most influential recent studies on developer productivity and highlight what they found.
Beyond Lines of Code: Productivity is Multi-Dimensional (SPACE Framework)
Research Summary
Back in 2021, a group of researchers led by Dr. Nicole Forsgren (creator of the DORA metrics) along with Dr. Margaret-Anne Storey and colleagues at GitHub and Microsoft introduced the SPACE framework. This framework was a wake-up call: it argued that developer productivity isn’t one-dimensional at all. In fact, SPACE spans five dimensions:
- Satisfaction and well-being – How happy and fulfilled developers are in their work
- Performance – The outcomes (quality, impact) of their work
- Activity – The volume of output or actions (commits, pull requests, etc.)
- Communication and Collaboration – How well developers work together and share knowledge
- Efficiency and Flow – How effectively work is done with minimal interruptions (think “in the zone” coding time)
Forsgren et al. emphasized that you can’t capture productivity with a single metric – no “one metric to rule them all.” Focusing only on, say, lines of code or number of commits can be misleading.
{{cta}}
For example, a senior engineer might produce fewer commits yet deliver more value through code reviews, mentoring, and architectural decisions. The SPACE paper busted common myths, like the idea that productivity is just about developer activity or tools. In reality, human factors like a supportive culture and healthy environment matter just as much. Work that often goes unseen – mentoring, knowledge sharing, reducing technical debt – can be critical to a team’s overall productivity even if it doesn’t immediately show up in activity metrics.
One striking insight was that while good tools and efficient processes are important, they aren’t the whole story; organizational culture and developer well-being have substantial impact on productivity too. For instance, an engineering team might speed up their CI pipeline (tools) but if the team culture is blame-oriented or developers are burnt out, overall productivity won’t improve much.
SPACE gave leaders and teams a vocabulary to discuss productivity more constructively. True productivity comes from a balanced environment where developers are happy, collaborative, and able to maintain flow, in addition to delivering working software. This multidimensional stance has now become almost common wisdom, but it was a necessary course-correction.
The Faros AI Take
At Faros AI, we see the SPACE framework as more than a measurement model—it’s a foundation for better conversations and smarter decisions. By elevating dimensions like satisfaction, collaboration, and flow, SPACE equips leaders with both the vocabulary and evidence to advocate for investments that don’t always show up on the roadmap but are essential for long-term outcomes. That might mean improving onboarding, refactoring neglected services, or carving out focus time—all efforts that typically get overlooked in favor of feature delivery.
We also appreciate how SPACE naturally discourages gaming. When you track just one dimension—say, PR count—it’s easy for developers to optimize toward the metric rather than the mission. But when you’re balancing activity, performance, satisfaction, and flow, it’s harder to fake impact and easier to have an honest conversation about tradeoffs. This built-in tension fosters more trustworthy data and better decision-making at every level.
Finally, SPACE moves the conversation beyond anecdotal performance assessments. Whether you're comparing two teams working in different domains or evaluating how mentorship and code review affect team outcomes, the framework enables more nuanced and equitable analysis. It supports a shift from reactive evaluations to proactive organizational insight.
Developer Experience (DevEx): The Developer-Centric Approach
If SPACE outlined what to measure, the next question became how do we improve those dimensions?
Research Summary
Enter the concept of Developer Experience (DevEx) – basically, the idea that by improving the day-to-day experience of developers, you inherently boost their productivity. In 2023, Abi Noda, Dr. Margaret-Anne Storey, Dr. Nicole Forsgren, and Dr. Michaela Greiler published “DevEx: What Actually Drives Productivity,” which doubled down on making productivity developer-centric.
Instead of viewing productivity as just an output to be measured, they approached it from the perspective of developers’ lived experience: what friction do developers encounter, and how does removing that friction help them get more done?
The research argues that improving DevEx is the key to improving productivity. They identified three core dimensions of DevEx: Feedback loops, Cognitive load, and Flow state.
- Feedback loops: How quickly and effectively developers get feedback from their tools and team. For example, how long do you wait for CI builds and tests? Are code reviews prompt or do PRs sit idle for days? Fast feedback keeps developers moving forward; slow feedback causes frustration and idle time.
- Cognitive load: How easy or hard it is for developers to understand the codebase, systems, and processes. High cognitive load (e.g., convoluted code, unclear requirements, too many tools) makes developers spend mental energy on overhead rather than creative work. Reducing cognitive load—through clear documentation, simpler designs, and intuitive tooling—frees up brainpower for actual problem-solving.
- Flow state: The ability for a developer to get into deep, uninterrupted work. We’ve all felt this: those hours where you’re “in the zone” and making great progress. Achieving flow requires minimizing interruptions – fewer random meetings, less “ping pong” between tasks, and a workspace that lets you focus.
The paper provided a measurement framework that combines developers’ own feedback (via surveys or check-ins on these dimensions) with data from engineering systems (like instrumentation on build times, deploy frequency, etc. By marrying subjective and objective data, leaders can pinpoint where the biggest friction lies. For example, developers might report that “code review wait times” are a major pain (subjective feedback), and the system data might show that indeed the average PR sits for 2 days awaiting review. That’s a clear area to improve.
The DevEx approach is somewhat a response to the contrarian view that “productivity is just about output, and developer happiness is a nice-to-have.” Some skeptics might say, “Isn’t this just about keeping developers happy, and maybe coddling them?” The research here provides evidence that it’s not just feel-good fluff – it’s directly tied to outcomes.
In fact, a 2020 McKinsey study cited in the paper found that companies with top-tier developer environments had 4-5x higher revenue growth than competitors, underlining that DevEx investments yield real business results. Also, as a counterpoint to pure output metrics, the research notes that focusing only on output misses the complex reality of software work. It can even create bad incentives (like writing lots of code that isn’t needed).
Yes, we ultimately care about output, but the way to get sustainable, high-quality output is by improving the developer’s day-to-day experience. It’s a shift from an old-school factory mindset to a more human-centric approach. As the paper says, many organizations are now establishing dedicated “DevEx” or platform engineering teams to systematically improve these factors—something that would have sounded radical a decade ago.
The Faros AI Take
Improving developer experience starts by measuring it when it matters. At Faros AI, we’ve found that just-in-time surveys—triggered by key workflow events like submitting a PR, triggering a build, or closing a ticket—offer far more context than quarterly or ad hoc surveys. They let you understand sentiment in the moment, capturing pain points that would otherwise fade from memory.
But sentiment alone doesn’t tell the whole story. That’s why we pair survey feedback with telemetry from engineering systems like version control, build pipelines, and deployment logs. The combination allows us to distinguish between perception and root cause. In one customer example, developers cited code review delays as a persistent friction point. But when we analyzed the data, we discovered that the real delay occurred after merge—during the deployment to production. This clarity helped the team focus on their true bottleneck, rather than spend cycles optimizing the wrong part of the process.
What makes the DevEx framework powerful is its ability to tie subjective experience to objective outcomes. When developers say “this process feels slow,” we can now quantify the impact—and prioritize solutions that produce measurable results. This goes beyond feel-good improvements: it’s about building engineering systems that scale with both velocity and morale.
Data-Driven DevEx: Microsoft’s Engineering Thrive
Research Summary
So, how do these ideas play out in a real, large-scale engineering org? A great example comes from Microsoft’s internal initiative called Engineering Thrive (often stylized as EngThrive). In early 2024, Dr. Nicole Forsgren and colleagues (including Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, and Margaret-Anne Storey) published “DevEx in Action: A study of developer experience and its tangible impact.” This was essentially Microsoft’s implementation of the DevEx philosophy across the company, and they shared some powerful results.
What is Engineering Thrive? It’s a cross-company effort at Microsoft to track and improve developer experience using a blend of objective telemetry (things like build times, PR statistics, incident rates) and subjective survey data (how engineers feel about their workflows). EngThrive anchors on four pillars that mirror the ideas we’ve discussed: Speed, Ease, Quality, and Culture. In practice, that means they collect metrics on how fast engineers can get things done (speed), how easy and friction-free the processes and tools are (ease, which relates to cognitive load), the quality of the outcomes (quality could include code quality or reliability metrics), and the health of the team’s working environment (culture, akin to satisfaction and well-being).
Microsoft studied over 32,000 developer survey responses across 177 countries to quantify the benefits of improving Developer Experience. Here’s a quick summary of the Engineering Thrive findings:
- Flow Time: Developers with sufficient deep focus time felt ~50% more productive. (Protect those no-meeting blocks on your calendar!)
- Engaging Work: Working on interesting, well-scoped tasks yielded a 30% boost in productivity.
- Easy-to-Understand Code/Systems: Reducing complexity led to 40% higher productivity, and intuitive processes drove 50% more innovation.
- Fast Feedback: Teams with quick code reviews and support saw 20% higher innovation, and fast answers to dev questions correlated with 50% less tech debt downstream.
These are hard, tangible benefits tied to things that improve developer experience. It’s a strong vindication that happy, enabled developers do better work.
Microsoft’s example with EngThrive is causing many large tech orgs to take note. It demonstrates a way to quantify the formerly unquantifiable. By treating developer experience as a first-class citizen (with metrics and investment, just like customer experience), they’re seeing real engineering performance gains. This is pretty much rewriting the playbook for engineering management.
The Faros AI Take
Microsoft’s Engineering Thrive initiative is a compelling example of what’s possible when organizations treat developer experience with the same seriousness as system performance. At Faros AI, we take a similar approach: we combine telemetry—build times, PR throughput, deployment cadence, calendar data—with role-aware pulse surveys and behavioral analytics to paint a full picture of developer experience across the engineering lifecycle.
One of the strongest lessons from Thrive is the measurable impact of protecting deep work. Focus time isn’t just a cultural perk—it directly correlates with velocity, throughput, and innovation. That insight has informed how we help teams visualize and defend focus time through our calendar, IDE, and workflow integrations. With better visibility into how engineers are spending their time—and where interruptions are creeping in—teams can identify and address bottlenecks before they impact delivery.
Another advantage of our approach is scale. While Microsoft’s internal dataset is uniquely valuable, it’s just one company. We’re collaborating with researchers like Brian Houck to understand how DevEx drivers play out across a much wider set of organizations. That external perspective helps leaders benchmark their environments and prioritize DevEx investments that align with both their goals and their constraints.
Ultimately, Engineering Thrive shows what’s possible when you take a scientific approach to developer experience. At Faros AI, we’re building the tooling that lets any engineering org—not just a tech giant—realize those benefits.
The Human Side: When “Bad Days” Derail Productivity
We’ve talked a lot about positive drivers of productivity (flow, good tools, fast feedback). Equally important is understanding the negative side—what drags developers down. After all, even one really bad day can wipe out a week’s worth of progress if it leads to bugs or burnout.
Research Summary
In late 2024, a mixed-methods study by Jenna Butler (Microsoft) along with researchers at Purdue University (Ike Obi) and University of Victoria (M.-A. Storey again, among others) tackled this issue. They titled it “Identifying Factors Contributing to ‘Bad Days’ for Software Developers,” and it’s eye-opening for anyone who leads an engineering team.
The study found that not all bad days are random – there are common themes that consistently ruin developers’ productivity. Three primary factors emerged as the usual suspects behind a “bad day”:
- Tooling and Infrastructure issues: This was the #1 cause of bad days. Think of things like flaky tests, slow build pipelines, broken CI/CD, or dev environment outages. Nothing is more frustrating than when your tools fail you. Developers reported that unreliable tools were a frequent trigger for a bad day.
- Process Inefficiencies: This includes unclear project ownership, lack of documentation, or rapidly changing priorities from leadership. In other words, organizational chaos. Senior developers in particular cited these as major problems—for instance, if it’s unclear who’s responsible for a piece of the system or when priorities keep shifting, it creates thrash and cynicism. One can only pull the fire alarm on developers so many times before it kills their enthusiasm.
- Team Dynamics and Communication: Interpersonal and team issues also ranked high. This ranged from poor communication and coordination to outright conflicts or lack of support within the team. Interestingly, junior developers were more affected by team dynamics— likely because they rely more on guidance and peer feedback. A junior dev can feel stuck and have a bad day if code reviews come with harsh criticism or if they feel ignored when seeking help.
The study used multiple methods—interviews, surveys, even having 79 developers keep a daily diary for a month about their moods and work—to paint a full picture. They didn’t just stop at what devs said; they also analyzed telemetry (source control data, build logs, etc.) from 131 participants to see if the “bad day” feelings showed up in the numbers.
And guess what—they did. When developers reported a bad day due to something like PR delays, the data showed those developers actually had 23.8% longer PR cycle times and 48.8% longer PR pickup times compared to those who didn’t cite PR delays. In other words, their gut feeling that “code reviews are taking forever” was backed by hard data: reviews were slower, objectively. Similarly, those who complained about slow builds had build times ~26% longer on average than those who didn't. This validates that developer sentiment correlates with real efficiency killers. It also busts the myth some might hold that “developers are whining about nothing.” Clearly, when they feel pain, it’s usually for a good reason.
A few more interesting nuggets: The survey found that the single biggest specific factor for a bad day was pull request delays outside of one’s control. They also observed the impact of bad days on morale: Senior devs experiencing frequent bad days reported frustration turning into disillusionment, even saying it made them consider quitting if it went on too long. Junior devs, on the other hand, often internalized bad days—blaming themselves and feeling imposter syndrome. Both are concerning outcomes that can hurt a team long-term (losing senior talent or demotivating juniors).
The study shows that we can often prevent bad days by fixing systemic issues (like investing in more reliable infrastructure or clearer processes). It quantifies the cost of a bad day—lost productivity, slower cycle times—which builds the case that improving developer experience isn’t coddling developers, it’s preventing waste.
The Faros AI Take
Bad days are inevitable—but when they become patterns, they point to deeper structural issues. At Faros AI, we help teams surface those patterns early through micro-surveys and behavioral analytics. Our event-driven surveys are tied to specific engineering moments: finishing a pull request, submitting an incident report, completing a retro. That lets us capture sentiment when it’s fresh and context-rich, rather than asking developers to recall vague impressions from weeks ago.
We then correlate that feedback with telemetry data—PR cycle times, review duration, build failures, meeting load—to identify the underlying causes of frustration. In some cases, the data reveals unexpected insights. For instance, senior engineers might be mentoring so heavily that they don’t have time to code, while junior devs might internalize blockers instead of asking for help. When we overlay data by role, team structure, and collaboration patterns, we can pinpoint where friction is accumulating—and where interventions like clearer documentation, dedicated onboarding time, or process automation will have the biggest payoff.
Most importantly, this approach shifts leaders from reactive to proactive. Instead of waiting for a spike in attrition or a dip in delivery, they can see the warning signs in advance—and create an environment where developers have fewer bad days, more flow time, and stronger long-term engagement.
Bringing It All Together: Productivity Through a New Lens
The big takeaway across all these studies? Developer productivity is driven by far more than raw output—it’s fundamentally driven by the environment we create for developers. When developers have clear goals, psychological safety, reliable tools, fast feedback, and time to focus, they thrive. Productivity soars almost as a byproduct of a great developer experience. Conversely, when developers are mired in broken pipelines, unclear processes, or toxic team dynamics, productivity plummets—no matter how “talented” or hardworking the individuals are.
For engineering teams out there, these insights suggest a few practical things:
- Measure wisely: Use multi-dimensional metrics (e.g., a mix of deployment frequency, pull-request turnaround, developer satisfaction scores, etc.) rather than a single number to gauge productivity.
- Foster a good developer experience: Treat internal developer platforms and tooling as products; aim for fast builds, clear documentation, and low-friction processes. Equally, cultivate a supportive team culture and values focus time.
- Listen to your developers: Their qualitative feedback can point you directly to bottlenecks. If several engineers say “our test suite is too slow” or “I spend too much time fighting build scripts,” that’s gold—and now we know fixing those will likely yield measurable gains. Marry that with system telemetry so you know where precisely what to address and can chart and prove the positive impact when you fix it.
- Balance output with well-being: Don’t celebrate Herculean coding sprints without checking if the team is burning out. High activity with low morale is a red flag (as seen during the pandemic remote work spurts that masked developer struggles. Aim for sustainable productivity, not short spurts followed by crashes.
Contact us today to learn more about how Faros AI can help you optimize your teams' prodcutvity.
.webp)