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. 

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.

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.

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.