Nicole Forsgren is one of the world’s leading experts on developer productivity — she co-created the DORA framework, co-authored the book Accelerate, and has held research and leadership roles at Google, GitHub, and Microsoft. In this episode, she discusses how to measure developer productivity, the limits of metrics like PRs and diffs, the SPACE and DORA frameworks, developer experience, onboarding as a diagnostic tool, culture change, and how AI is reshaping the field.
PRs and Diffs Are Useful but Dangerous as Solo Metrics
PRs and diffs give a reasonable view of what work is getting done and where blockers exist in the development pipeline, but they are terrible as standalone productivity measures.
Senior engineers often have low PR output because their work shifts to unblocking others, architecture, design, mentoring, and reviews — none of which show up as commits.
Using PR data as part of a broader constellation of metrics (e.g., time to PR review, build times, deployment outcomes) can reveal friction points like bad assignment processes, slow toolchains, or integration gaps.
The real risk is that non-technical leaders or executives want simple performance scores to evaluate engineers without understanding context — this is a long-standing desire in business, not a new phenomenon, and it leads to gaming and misinterpretation.
SPACE: A Holistic Framework for Measuring Developer Productivity
The SPACE framework (Satisfaction, Performance, Activity, Communication & Collaboration, Efficiency & Flow) was created to address the limitations of relying on any single category of metric.
Satisfaction: Ask developers directly — they can quickly tell you if tools or processes are broken, even when system-level data looks fine. A toolchain can appear fast and automated while every handoff point is manual and painful.
Performance: Outcome metrics like quality, stability, security, and customer impact — the hardest to measure but the most important.
Activity: Counts like commits, PRs, and deployments — easy to grab but narrow.
Communication & Collaboration: Meeting load, API breakage, how well teams coordinate.
Efficiency & Flow: Time, handoffs, delays — where the work actually slows down.
Using at least three of these categories gives a much more accurate picture than any single metric.
DORA’s four metrics are actually an instantiation of SPACE: deployment frequency (activity), lead time (efficiency/flow), change failure rate and time to restore (performance).
DORA: Where It Helps and Where It Falls Short
The four DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore service) are strong signals for how well the development pipeline works and have been validated over 10+ years of research.
They are a good starting point for teams beginning to measure productivity.
DORA only covers commit to production — it intentionally excludes the earlier stages of design, prioritization, and coding, because those are harder to engineer for predictability.
DORA tells you how well you’re doing but not what to do — the broader DORA research program (the “big friendly diagram”) points to practices like automated testing, CI, and cloud adoption that improve the metrics.
Teams in constrained environments (air-gapped systems, mobile apps with store review) can adapt DORA by measuring up to the point within their control (e.g., pre-prod).
Developer experience — the full lived experience of doing the job day-to-day — is increasingly recognized as critical and goes well beyond what DORA measures.
Developer Experience: What It Means and Why It Matters
Developer experience is the lived experience of doing the job — what it actually feels like day-to-day.
It includes not just coding tools but also HR systems, expense systems, compliance processes, and any system a developer must interact with regularly.
A policy change that adds approval steps for data access can seem minor from the outside but can destroy productivity and cognitive flow for engineers debugging live issues.
Friction, broken systems, and unnecessary process drain the mental energy needed for creative, high-quality work.
Good developer experience at large companies (e.g., Google) can be excellent because of heavy investment in platform teams and tooling, but large legacy companies can also be terrible due to accumulated bureaucracy and legacy systems.
Startups move fast and have less bureaucracy but lack dedicated infrastructure and compliance teams, creating a different set of trade-offs.
Why Measuring Developer Productivity Is So Hard
Much of the work is invisible — you can’t walk up to a production line and see where software breaks.
Systems are increasing in complexity: cloud, distributed systems, AI, and model management all add layers of difficulty.
Leaders and executives often don’t feel the pain of using the systems their engineers use — they aren’t managing calendars in them or debugging with them for weeks at a time.
Some leaders, like former Stripe CTO David Singleton, periodically do development work themselves to stay connected to the reality of their engineers.
The best proxy for understanding developer pain is to honor their reality — ask developers what it’s like to work in the systems and listen to their answers without dismissing them.
Making the Case for Platform Teams and Developer Productivity Investment
The most effective way to argue for investment is to combine data and stories — numbers alone are abstract, stories alone are dismissed as one-offs.
Do rough “back of the napkin” math: estimate how much time engineers lose weekly to manual processes, slow builds, or broken tooling, and aggregate it across the team.
Pair the data with a real or composite story of “a day in the life” showing what development looks like now versus what it could look like.
Acknowledge to leadership that there is a tipping point — additional investment won’t yield proportional returns forever, and the goal is to reach a point where the workflow is “good enough” and then maintain it.
Frame the conversation around trade-offs: “We can repurpose engineers to fix this, but here’s the impact on product delivery if we don’t.”
In the current market, where companies are hesitant to hire more engineers, there’s a growing need to accept some pain and creatively solve the biggest bottlenecks rather than throwing headcount at the problem.
Characteristics of Highly Productive Teams
Psychological safety is consistently present — engineers feel safe taking risks, asking questions, and raising concerns.
Curiosity and openness — high-performing teams are willing to question whether their current way of working is the best way, even if something was “impossible” to solve years ago.
Onboarding time is a powerful diagnostic indicator — how long it takes a new hire to commit code reveals the health of documentation, tooling, and processes.
In one large organization, onboarding time for a new college graduate was the same as for a senior developer switching divisions — several months — because documentation was non-existent and tooling changed completely.
The best teams in that organization achieved 60-day onboarding.
Even a simple “dummy PR” exercise (e.g., fix a title) completed in the first week or two increased measurable productivity by 30–50% for the rest of the year, because new hires had gone through the full process early and surfaced obvious problems.
Brooks’s Law (adding people to a late project makes it later) may not apply at companies with extremely fast onboarding (e.g., Meta), where new hires push code on day one and internal transfers can be productive almost immediately because the monorepo and tooling are consistent.
Internal transfers should be treated as onboarding to a new system, not just a new team — if the toolchain, documentation, and processes are different, it’s effectively a new hire experience.
Culture Change: How It Actually Happens
You cannot change “tech culture” in isolation — you need to change the broader organizational culture.
Microsoft under Satya Nadella is a notable example of successful cultural transformation.
Research by John Shook shows that changing the way people do their work bubbles up to change culture, rather than the other way around — if you want people to work differently, change their tools and processes first.
Introducing faster, less-friction tooling changes people’s lived experience, which then shifts culture — but this must be paired with communication, education, and commitment from leadership at multiple levels.
For individual contributors or middle managers who can’t set company-wide strategy:
Do a listening tour in your first 90 days, write up observations, sanity-check them with the team, and identify one or two high-impact areas to improve.
Build allies and social capital before pushing change — newcomers who try to change things immediately often face pushback and leave disappointed.
Create quick wins (e.g., hack days to fix paper cuts) that are visible and impactful.
Align incentives: if you say improving the workflow matters, reflect that in performance reviews and one-on-ones — otherwise the effort washes away.
How AI Is Changing Developer Productivity
DORA metrics remain useful — they measure the “outer loop” of the development process, which AI doesn’t fundamentally change.
SPACE is still applicable, but trust is becoming a much larger factor — developers now have to evaluate whether they can trust the output of AI tools, which is a new cognitive burden that didn’t exist with traditional compilers or IDEs.
Early research (including a study by GitHub’s Office of the Chief Economist) found that experienced developers using AI coding assistants produced code that was easier to read, had better approval rates, and saw over a 50% increase in unit tests passing.
AI is expanding beyond the IDE — there are significant opportunities in release engineering and deployment, where LLMs can synthesize data from builds, documentation, and downstream systems to support faster, more informed risk-based decisions.
Developers should experiment with AI tools (Copilot, Tabnine, Cursor, Claude) to find what works for their workflow — some prefer inline autocomplete, others prefer pasting skeleton code into a chat interface and iterating.
Flow state matters — some developers find constant AI suggestions interruptive and turn them off, while others integrate them seamlessly. There’s no single right answer; developers need to find their own workflow.
The mental model may need to shift from “coding” to “driving” or “guiding” — comparing AI-assisted work to traditional coding is comparing two different things.
AI adoption in software engineering is spreading faster than any previous technology shift (faster than cloud), and the field is still in the early stages of figuring out how to work with these tools effectively.
Rapid Fire
What Nicole misses most about full-time coding: The rush of hacking something up, figuring out the best way to structure code, and the excitement of shipping to production — she’s found a proxy in research strategy.
Next book: A developer experience book co-authored with Abby Noto, covering data collection, communication, ROI analysis, and practical examples of surveys and operationalization for ICs, managers, and leaders.
Most impactful productivity tool: Having an incredible PM/TPM who uplevels the work — and personally, using Claude as a fast-thinking partner and rubber duck.
Recommended reads: Inspired by Marty Cagan (product management), Outlive by Peter Attia (health/longevity), and Ender’s Game by Orson Scott Card (for fun).
