In 2014, a question that had frustrated engineering leaders for decades remained stubbornly unanswered: does investing in DevOps practices actually improve business outcomes, or is it just another expensive fad? Countless organizations were pouring resources into continuous delivery pipelines, automated testing, and infrastructure-as-code, but nobody had rigorous, peer-reviewed evidence that any of it mattered. Opinions were plentiful. Data was not. Then a researcher named Nicole Forsgren — with a PhD in Management Information Systems, expertise in psychometrics, and an obsessive commitment to statistical rigor — decided to measure what everyone else was merely arguing about. Over the next several years, Forsgren and her collaborators Jez Humble and Gene Kim designed and executed the largest scientific study of software delivery performance ever attempted. The result was the DORA (DevOps Research and Assessment) metrics framework and the book Accelerate, published in 2018, which proved — with the kind of evidence that would survive peer review in a top academic journal — that high-performing engineering teams deploy code 208 times more frequently than their low-performing counterparts, with 106 times faster lead times and 2,604 times faster recovery from failures. These numbers changed the industry. DORA metrics became the standard vocabulary for measuring engineering effectiveness at companies from startups to Fortune 500 enterprises. Forsgren had done something remarkable: she had turned DevOps from a movement based on anecdote into a discipline grounded in science.
Early Life and Academic Foundation
Nicole Forsgren grew up in the western United States with an early aptitude for both technology and research methodology. She pursued her undergraduate education in computer science before shifting her focus toward the intersection of technology and organizational behavior — a combination that would prove unusually powerful. She earned her PhD in Management Information Systems (MIS) from the University of Arizona, where she studied under researchers who specialized in measuring complex organizational phenomena using survey-based methodologies and structural equation modeling.
Her doctoral training was critical to everything that followed. Most people who study software engineering come from a pure computer science background. They understand code, systems, and architecture, but they lack formal training in how to measure human and organizational behavior at scale. Forsgren’s MIS training gave her expertise in psychometric survey design — the science of constructing questions that reliably measure latent constructs like “organizational culture” or “technical capability.” She learned structural equation modeling, a statistical technique that can untangle complex causal relationships between multiple variables simultaneously. And she studied organizational theory, giving her frameworks for understanding how technical practices interact with team dynamics, management structures, and business outcomes.
Before her DevOps research, Forsgren worked as a software developer and sysadmin, giving her practical experience with the systems she would later study. She also held academic positions, including a role as a professor at Clemson University, where she taught and conducted research on IT management and organizational performance. This combination of hands-on technical experience, academic rigor, and organizational theory expertise made her uniquely qualified to tackle the question of DevOps effectiveness — a problem that required understanding code pipelines, human psychology, and statistical methodology simultaneously.
The Breakthrough: DORA and the State of DevOps Reports
Designing the Study
In 2014, Forsgren partnered with Jez Humble (author of Continuous Delivery) and Gene Kim (author of The Phoenix Project) to launch what would become the DORA research program. The goal was straightforward but ambitious: rigorously measure software delivery performance across thousands of organizations and determine which technical practices, cultural factors, and management approaches actually drive high performance.
The methodological challenge was enormous. You cannot run controlled experiments on entire organizations — you cannot randomly assign half of a company to adopt continuous integration while the other half does not. Instead, Forsgren designed a cross-sectional survey study that used validated psychometric instruments to measure technical capabilities, cultural characteristics, and performance outcomes. She applied Likert-type scales (validated through exploratory and confirmatory factor analysis) to measure latent constructs like “trunk-based development adoption” or “Westrum organizational culture.” She then used structural equation modeling to identify causal pathways between practices and outcomes.
The survey was distributed globally each year starting in 2014, eventually collecting data from over 36,000 professionals across every industry and geography. Forsgren was meticulous about avoiding common survey pitfalls: she tested for common method bias, validated construct reliability using Cronbach’s alpha and composite reliability scores, confirmed discriminant validity, and checked for multicollinearity. This level of methodological rigor was unprecedented in the software engineering measurement space — most previous studies had relied on anecdotal case studies or unvalidated self-report metrics.
The Four Key Metrics
The most influential output of the DORA research was the identification of four key metrics that reliably measure software delivery performance. These metrics, now universally known as the “DORA metrics,” are:
- Deployment Frequency — How often an organization successfully releases to production. High performers deploy on demand (multiple times per day); low performers deploy between once per month and once every six months.
- Lead Time for Changes — The time it takes for a committed code change to reach production. High performers achieve lead times of less than one hour; low performers take between one month and six months.
- Mean Time to Restore (MTTR) — How quickly a service can be restored after an incident. High performers restore service in less than one hour; low performers take between one week and one month.
- Change Failure Rate — The percentage of deployments that cause a failure in production requiring remediation. High performers have a change failure rate of 0–15%; low performers have rates of 46–60%.
What made these metrics revolutionary was not just their identification but their validation. Forsgren proved statistically that these four metrics cluster together — teams that excel at one tend to excel at all four — and that they predict organizational performance outcomes including profitability, market share, and productivity. This demolished the long-standing assumption that speed and stability are tradeoffs. The data showed conclusively that the fastest teams are also the most stable. Speed and quality reinforce each other when the right practices are in place.
# Implementing DORA metrics tracking with a deployment event pipeline
# This approach captures the four key metrics Forsgren identified
from datetime import datetime, timedelta
from dataclasses import dataclass, field
from typing import Optional
from statistics import median
@dataclass
class DeploymentEvent:
"""Represents a single deployment to production."""
deploy_id: str
service: str
timestamp: datetime
commit_timestamp: datetime # when the change was first committed
caused_incident: bool = False
incident_resolved_at: Optional[datetime] = None
class DORAMetrics:
"""
Calculate the four DORA metrics from deployment events.
Nicole Forsgren's research proved these four metrics are
both sufficient and necessary to classify software delivery
performance. They are correlated but measure distinct
aspects of delivery capability.
"""
def __init__(self, events: list[DeploymentEvent]):
self.events = sorted(events, key=lambda e: e.timestamp)
def deployment_frequency(self, days: int = 30) -> float:
"""
Metric 1: How often the team deploys to production.
Elite: On-demand (multiple deploys per day)
High: Between once per day and once per week
Medium: Between once per week and once per month
Low: Between once per month and once every 6 months
"""
cutoff = datetime.now() - timedelta(days=days)
recent = [e for e in self.events if e.timestamp >= cutoff]
return len(recent) / days # deploys per day
def lead_time_for_changes(self) -> timedelta:
"""
Metric 2: Time from code commit to production deployment.
Elite: Less than one hour
High: Between one day and one week
Medium: Between one week and one month
Low: Between one month and six months
"""
lead_times = [
(e.timestamp - e.commit_timestamp)
for e in self.events
]
sorted_times = sorted(lead_times)
# Forsgren uses median to reduce outlier impact
return sorted_times[len(sorted_times) // 2] if sorted_times else timedelta(0)
def change_failure_rate(self) -> float:
"""
Metric 3: Percentage of deployments causing incidents.
Elite/High: 0-15%
Medium: 16-30%
Low: 46-60%
"""
if not self.events:
return 0.0
failures = sum(1 for e in self.events if e.caused_incident)
return failures / len(self.events)
def mean_time_to_restore(self) -> timedelta:
"""
Metric 4: How quickly service is restored after failure.
Elite: Less than one hour
High: Less than one day
Medium: Between one day and one week
Low: Between one week and one month
"""
restore_times = [
(e.incident_resolved_at - e.timestamp)
for e in self.events
if e.caused_incident and e.incident_resolved_at
]
if not restore_times:
return timedelta(0)
sorted_times = sorted(restore_times)
return sorted_times[len(sorted_times) // 2]
def classify_performance(self) -> str:
"""
Classify team into Forsgren's performance clusters.
The key insight: these metrics move TOGETHER.
High performers are fast AND stable.
"""
freq = self.deployment_frequency()
lt = self.lead_time_for_changes()
cfr = self.change_failure_rate()
mttr = self.mean_time_to_restore()
if (freq >= 1.0 and lt < timedelta(hours=1) and
cfr <= 0.15 and mttr < timedelta(hours=1)):
return "Elite"
elif (freq >= 1/7 and lt < timedelta(weeks=1) and
cfr <= 0.15 and mttr < timedelta(days=1)):
return "High"
elif (freq >= 1/30 and lt < timedelta(weeks=4) and
cfr <= 0.30 and mttr < timedelta(weeks=1)):
return "Medium"
else:
return "Low"
# Usage example — tracking a team's delivery performance
events = [
DeploymentEvent(
deploy_id="deploy-1847",
service="checkout-api",
timestamp=datetime(2025, 7, 15, 14, 22),
commit_timestamp=datetime(2025, 7, 15, 13, 45),
caused_incident=False
),
DeploymentEvent(
deploy_id="deploy-1848",
service="checkout-api",
timestamp=datetime(2025, 7, 15, 16, 10),
commit_timestamp=datetime(2025, 7, 15, 15, 30),
caused_incident=True,
incident_resolved_at=datetime(2025, 7, 15, 16, 38)
),
]
dora = DORAMetrics(events)
print(f"Deployment Frequency: {dora.deployment_frequency():.2f}/day")
print(f"Lead Time: {dora.lead_time_for_changes()}")
print(f"Change Failure Rate: {dora.change_failure_rate():.1%}")
print(f"MTTR: {dora.mean_time_to_restore()}")
print(f"Performance Tier: {dora.classify_performance()}")Cultural Factors: The Westrum Model
One of Forsgren's most important contributions was proving the relationship between organizational culture and technical performance. She adopted Ron Westrum's typology of organizational cultures — pathological (power-oriented), bureaucratic (rule-oriented), and generative (performance-oriented) — and demonstrated statistically that generative culture is a significant predictor of software delivery performance.
In a generative culture, information flows freely, messengers are not punished for bringing bad news, responsibilities are shared, cross-functional collaboration is encouraged, and failure leads to inquiry rather than blame. Forsgren's data showed that teams operating in generative cultures were significantly more likely to be high performers on all four DORA metrics. This was not a soft, feel-good finding — it was a statistically significant result backed by structural equation modeling with validated instruments across tens of thousands of respondents.
This finding had profound implications for engineering leadership. It meant that improving software delivery performance was not purely a technical problem. You could adopt every CI/CD tool and automation framework available, but if your culture punished failure and hoarded information, your metrics would remain poor. Conversely, a team with a healthy culture could achieve elite performance even with relatively simple tooling. Culture, Forsgren proved, was not an afterthought — it was a prerequisite.
Accelerate: From Research to Industry Standard
In 2018, Forsgren, Humble, and Kim published Accelerate: The Science of Lean Software and DevOps. The book synthesized four years of DORA research into a coherent framework that engineering leaders could immediately apply. It was structured in two parts: the first presented the findings and their practical implications; the second — written primarily by Forsgren — detailed the research methodology with enough rigor to satisfy academic reviewers.
The book's impact was extraordinary. Within two years, "DORA metrics" became standard vocabulary in engineering organizations worldwide. Companies including Google, Microsoft, Amazon, Spotify, and thousands of smaller firms adopted the four key metrics as their primary measures of engineering effectiveness. The phrase "Are you tracking your DORA metrics?" became as common in engineering leadership conversations as "Are you doing Agile?" had been a decade earlier.
What made Accelerate so influential was its combination of academic rigor and practical relevance. Previous DevOps books had been either purely anecdotal (case studies from specific companies) or purely theoretical (abstract principles without measurement). Forsgren's work provided something the industry desperately needed: proof. When an engineering VP argued for investment in automated testing or trunk-based development, they could now point to peer-reviewed research demonstrating the causal connection between those practices and business outcomes. This transformed DevOps advocacy from a faith-based initiative into an evidence-based one.
Google, GitHub, and Microsoft
In 2018, Google acquired DORA, bringing Forsgren and her research program into Google Cloud. At Google, Forsgren continued the annual State of DevOps reports and expanded the research into new areas, including the relationship between developer experience and organizational performance. She also worked on making DORA metrics operationally accessible — moving from survey-based measurement to platform-integrated metrics that teams could track automatically through their existing version control and deployment systems.
The Google acquisition gave the DORA program institutional stability and resources, but more importantly, it gave the metrics the imprimatur of one of the world's most respected engineering organizations. When Google publicly adopted DORA metrics as its framework for measuring engineering effectiveness, the remaining skeptics in the industry largely fell silent.
Forsgren subsequently moved to GitHub, where she became VP of Research and Strategy. At GitHub — owned by Microsoft since 2018 — she applied her research methodology to understanding developer productivity and experience at scale. Her work at GitHub expanded beyond deployment metrics to encompass the entire developer experience: how developers discover and evaluate tools, how code review processes affect productivity, and how engineering team structures influence delivery outcomes. This research influenced GitHub's product direction, including features designed to reduce friction in collaborative development workflows.
At GitHub, Forsgren also championed the concept of "developer experience" (DevEx) as a measurable, improvable dimension of engineering effectiveness — complementing DORA's focus on delivery metrics with attention to the human experience of building software. Her research on DevEx examines cognitive load, flow state disruptions, and the feedback loops that shape how productive and satisfied developers feel in their daily work.
Philosophy and Research Approach
Key Principles
Forsgren's intellectual approach is defined by a commitment to measurement rigor that is unusual in the software engineering world. She has repeatedly emphasized that you cannot improve what you do not measure, but equally important, that bad measurement is worse than no measurement at all. She has been vocal critic of vanity metrics — lines of code written, number of commits, story points completed — that feel quantitative but do not actually predict meaningful outcomes.
Her insistence on validated measurement instruments sets her apart from most technology researchers. In the social sciences, it is well understood that you cannot simply ask people "How good is your deployment process?" and expect a meaningful answer. The question must be decomposed into multiple specific items, each measuring a distinct facet of the underlying construct, and the instrument must be tested for reliability (do the items consistently measure the same thing?) and validity (does the instrument actually measure what it claims to measure?). Forsgren brought this discipline to an industry accustomed to gut feelings and anecdotal evidence.
She has also championed the idea that speed and stability are not tradeoffs — a finding that contradicts decades of conventional wisdom in software engineering. The traditional view held that moving fast inevitably means breaking things, and that stability requires moving slowly. Forsgren's data demolished this assumption. Elite performers deploy more frequently, with shorter lead times, lower failure rates, and faster recovery. The practices that enable speed — automated testing, continuous integration, trunk-based development, loosely coupled architectures — are the same practices that enable stability. This insight has been one of the most transformative findings in modern software engineering, and it is supported by robust statistical evidence across thousands of organizations.
# Demonstrating the speed-stability correlation Forsgren discovered
# This contradicts the traditional "move fast and break things" assumption
import json
from dataclasses import dataclass
@dataclass
class TeamPerformance:
"""Anonymized performance data illustrating Forsgren's key finding."""
team: str
deploy_freq_per_day: float
lead_time_hours: float
change_failure_pct: float
mttr_hours: float
# Forsgren's research showed this pattern across 36,000+ respondents:
# Speed and stability are NOT tradeoffs — they correlate POSITIVELY
sample_teams = [
# Elite performers: fast AND stable
TeamPerformance("Team Alpha", 4.2, 0.5, 3.0, 0.4),
TeamPerformance("Team Bravo", 2.8, 0.8, 5.0, 0.6),
# High performers
TeamPerformance("Team Charlie", 0.5, 24.0, 10.0, 4.0),
TeamPerformance("Team Delta", 0.3, 48.0, 12.0, 8.0),
# Low performers: slow AND unstable
TeamPerformance("Team Echo", 0.03, 720.0, 48.0, 168.0),
TeamPerformance("Team Foxtrot", 0.02,1440.0, 55.0, 336.0),
]
print("=" * 72)
print(f"{'Team':<16} {'Deploys/day':>12} {'Lead Time':>12} "
f"{'Fail Rate':>10} {'MTTR':>10}")
print("=" * 72)
for t in sample_teams:
lt_str = f"{t.lead_time_hours:.1f}h" if t.lead_time_hours < 24 \
else f"{t.lead_time_hours/24:.0f}d"
mttr_str = f"{t.mttr_hours:.1f}h" if t.mttr_hours < 24 \
else f"{t.mttr_hours/24:.0f}d"
print(f"{t.team:<16} {t.deploy_freq_per_day:>12.2f} "
f"{lt_str:>12} {t.change_failure_pct:>9.0f}% {mttr_str:>10}")
print("\n Key insight (Forsgren et al., 2018):")
print(" Elite teams deploy 208x more often than low performers")
print(" Yet they have 7x LOWER change failure rates")
print(" Speed and stability are NOT tradeoffs — they reinforce each other")On Metrics and Misuse
Forsgren has been consistently clear about the dangers of misusing DORA metrics. She has warned against using them as targets for individual performance evaluation — a practice that would trigger Goodhart's Law (when a measure becomes a target, it ceases to be a good measure). The metrics are designed to measure team and organizational capability, not individual productivity. Using them to evaluate individual engineers would incentivize gaming behavior — deploying empty commits to inflate deployment frequency, for example — and would destroy the psychological safety that her own research shows is necessary for high performance.
She has also emphasized that the metrics must be understood in context. A deployment frequency of once per day might be elite performance for a legacy banking system and underperformance for a cloud-native SaaS application. The metrics provide a framework for comparison and improvement, not absolute standards. Teams should use them to track their own trajectory over time, not to compare themselves unfavorably to companies operating in entirely different contexts.
Legacy and Influence
Nicole Forsgren's impact on the software industry extends across multiple dimensions. The DORA metrics framework has become the de facto standard for measuring software delivery performance worldwide. The annual State of DevOps reports, which she initiated and led, have been cited in thousands of conference talks, blog posts, and boardroom presentations. The book Accelerate has sold hundreds of thousands of copies and has been translated into multiple languages. Google's DORA team continues to publish research building on the foundation Forsgren established.
Her work has influenced platform engineering, a discipline that emerged partly in response to DORA's findings. If specific technical practices reliably predict high performance, then organizations should invest in internal platforms that make those practices easy to adopt. Platform teams at companies worldwide now explicitly design their systems to optimize DORA metrics — building deployment pipelines that minimize lead time, monitoring systems that accelerate MTTR, and testing frameworks that reduce change failure rates. Tools like modern project management platforms increasingly integrate DORA-aligned metrics to help teams track their delivery performance alongside their work planning.
Forsgren's influence on engineering management has been equally significant. Before DORA, engineering leaders often struggled to justify investments in technical practices — automated testing, refactoring, infrastructure modernization — because they lacked evidence connecting those investments to business outcomes. Forsgren provided that evidence. A CTO can now present data showing that investment in continuous delivery practices is statistically associated with improved profitability, market share, and employee satisfaction. This has shifted conversations about engineering investment from opinion-based to evidence-based across the industry.
Her emphasis on culture as a measurable driver of technical performance has also influenced how organizations think about team dynamics and management. The Westrum cultural model, which Forsgren operationalized and validated in the DevOps context, is now widely used by engineering organizations to assess and improve their team cultures. The finding that generative culture predicts technical performance has given engineering leaders a powerful argument for investing in psychological safety, information sharing, and cross-functional collaboration.
Perhaps most importantly, Forsgren established a model for how the software industry should evaluate its own practices: through rigorous, peer-reviewed research rather than anecdote, authority, or conference hype. She demonstrated that it is possible to apply the standards of social science research — validated instruments, appropriate statistical methods, transparent methodology — to questions about software engineering. This has raised the bar for claims about engineering effectiveness. When someone now asserts that a particular practice improves performance, the informed response is: "Show me the data. Show me the methodology. Has it been replicated?" This expectation of evidence is itself one of Forsgren's most enduring contributions to the field.
Key Facts
- Known for: Creating the DORA metrics framework, co-authoring Accelerate, leading the State of DevOps research program
- Education: PhD in Management Information Systems, University of Arizona; background in computer science
- Key roles: VP of Research & Strategy at GitHub/Microsoft, CEO & Chief Scientist at DORA, Researcher at Google Cloud, Professor at Clemson University
- Key projects: DORA (DevOps Research and Assessment), State of DevOps Reports (2014–present), Accelerate (2018)
- The Four DORA Metrics: Deployment Frequency, Lead Time for Changes, Mean Time to Restore, Change Failure Rate
- Key finding: Speed and stability are not tradeoffs — elite performers are both the fastest and the most stable
- Research scale: Over 36,000 survey respondents across multiple years, industries, and geographies
- Awards: Multiple technology leadership awards, Accelerate won the Shingo Publication Award
Frequently Asked Questions
Who is Nicole Forsgren?
Nicole Forsgren is a technology researcher, author, and executive who created the DORA (DevOps Research and Assessment) metrics framework — the industry-standard method for measuring software delivery performance. She holds a PhD in Management Information Systems and co-authored Accelerate: The Science of Lean Software and DevOps with Jez Humble and Gene Kim. She has held senior research positions at Google Cloud, GitHub, and Microsoft, and her work has fundamentally changed how the software industry measures and improves engineering effectiveness.
What are the DORA metrics?
The DORA metrics are four key measures of software delivery performance identified and validated by Nicole Forsgren's research: Deployment Frequency (how often a team deploys to production), Lead Time for Changes (time from code commit to production deployment), Mean Time to Restore (how quickly service is restored after an incident), and Change Failure Rate (percentage of deployments that cause production failures). Forsgren's research proved that these four metrics cluster together, predict business outcomes, and demonstrate that speed and stability reinforce each other rather than being tradeoffs.
What is the book Accelerate about?
Accelerate: The Science of Lean Software and DevOps (2018) presents the findings of the DORA research program, which analyzed software delivery performance across over 36,000 professionals worldwide. The book identifies the technical practices (continuous delivery, trunk-based development, automated testing), cultural factors (Westrum generative culture, psychological safety), and management approaches (lean product management, lightweight change approval) that statistically predict high software delivery performance and positive business outcomes. It is divided into a practical section on findings and implications, and a methodological section detailing the research approach.
Why are DORA metrics important?
DORA metrics are important because they provide the first rigorously validated, evidence-based framework for measuring software delivery performance. Before DORA, engineering organizations relied on vanity metrics (lines of code, story points) or anecdotal assessments that did not predict meaningful outcomes. Forsgren's research proved that the four DORA metrics reliably predict organizational performance including profitability and market share. They also demonstrated that the traditional assumption — that teams must choose between speed and stability — is false. This evidence has transformed how thousands of organizations invest in engineering practices, moving the conversation from opinion to data.
How did Nicole Forsgren change DevOps?
Forsgren transformed DevOps from a philosophy based on anecdote and intuition into a discipline grounded in peer-reviewed science. Before her research, DevOps advocates argued for practices like continuous delivery and automated testing based on case studies and personal experience. Forsgren provided statistical proof that specific technical practices and cultural factors cause measurable improvements in delivery performance and business outcomes. She also proved that organizational culture — particularly the presence of a generative, high-trust environment — is a statistically significant predictor of technical performance, making culture a first-class engineering concern rather than a soft, unmeasurable ideal.
