Frictionless: why great developer experience can help teams win in the ‘AI age’
Exclusive excerpts from the newly-released book ‘Frictionless’, by Nicole Forsgren and Abi Noda.
Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. If you’ve been forwarded this email, you can subscribe here.
Begin researching developer productivity, and you’re likely to soon encounter the work of Nicole Forsgren, as lead author of the best-selling book Accelerate, and creator of the widely-adopted DORA and SPACE developer productivity frameworks. And, beyond SPACE is the DevEx framework for productivity measurement, created by Abi Noda in collaboration with Nicole.
When I heard that the pair’s work together has continued in a new book about developer experience, I wanted to know more, and had the chance to sit down for a conversation about this big project of theirs.
Frictionless was released two weeks ago, and Nicole and Noda have been nice enough to share an excerpt from their new title with readers of the Pragmatic Engineer, below.
The back cover of Frictionless reads:
“AI can generate code in minutes — so why does shipping software still take forever?
The answer is friction: the invisible barriers that turn quick wins into endless delays. While your competitors ship daily updates, your developers burn out fighting broken tools instead of solving real problems”.
Personally, the lack of impact by AI coding tools to date upon the speed of development and quality of software, is amusing to me. If I take the apps I use, websites I visit, and services I access via software, I don’t see signs of faster iteration, higher quality, and fewer bugs since AI started shaking up the tech industry. An exception might be AI labs that release new features at eye-catching speed, often faster than much nimbler startups, but it could be argued those begin as experimental features.
What I like about Frictionless is that it gives a step-by-step approach for developers to smooth their own workflows and be more productive. If it helps teams and companies to move faster and produce more and better software – this is a win for everyone!
This article begins with our conversation, followed by two excerpts from the new book. We cover:
How Frictionless relates to Accelerate, DORA, and SPACE. An obvious question, but I had to ask.
Writing process. Frictionless took more than 3 years to write – including a “full rewrite”
Making the business case to reduce developer friction. Excerpt from the new book, chapter 9.
How AI changes (and doesn’t change) the metrics you need. Chapter 59 of the book.
To hear more about developer productivity from Nicole, see this podcast episode with her in The Pragmatic Engineer Podcast.
My usual disclaimer: As with all my recommendations, I was not paid to recommend this book, and none of the links are affiliates. See my ethics statement for more details.
1. How Frictionless relates to Accelerate, DORA, and SPACE
When developer productivity is discussed, your book Accelerate often gets a mention. How does Frictionless relate to it – and what makes it different?
Nicole: “Great question! The two are complementary but different in their foundations. Accelerate distills years of research connecting software delivery performance to business outcomes—it tells you what matters and why, but leaves the how to the reader. Frictionless is built from years of hands-on work advising teams on DevEx improvements, and it’s designed to help you actually do the work.
Where Accelerate is research-backed insights, Frictionless is a practitioner’s guide. It gives you a seven-step process you can start wherever you are, plus organizational change frameworks, metrics guidance, and 100+ pages of workbooks. Many of the practices are informed by research, but the book is ultimately about what we’ve seen work in the real world when teams try to improve developer experience.
So, if Accelerate is the ‘why,’ Frictionless is the ‘how’”.
DORA, SPACE and this book
To what extent does the new book build upon the DORA and SPACE frameworks?
Nicole: “They’re all deeply connected, Frictionless is really the natural evolution of this work.
DORA and Accelerate was about improving software delivery through technical, cultural, and process changes. Yes, we focused on business outcomes, but a core goal was always to make work better for engineers. Frictionless extends that same idea: start by identifying inefficiencies in the system, talk to developers about where their work is difficult, and you can improve both business outcomes and developer experience.
SPACE gave us a framework for measuring complex work like software development. Measurement is critical to any DevEx initiative, and we dedicate a full chapter to how AI is changing what we need to measure and how we should think about metrics differently.
But here’s the key difference: Frictionless goes beyond measurement. Metrics alone don’t create change. You also need to sell the initiative to leadership, advocate for change across your organization, plan communications, manage organizational change—all the messy, human work of actually making improvements happen. That’s what this book is designed to help with”.
2. Writing Process
It’s always interesting to learn what goes into writing a book. What made you both decide to take on this project?
Nicole: “This is a great question, since I didn’t think I would write another book. However, I realized a couple of things after talking to teams and leaders across many companies and industries: there was increased attention upon, and a push to improve, developer experience. Also, many questions and challenges were very similar: how do I start, how do I prioritize, and how do I convince the business that DevEx is important?”
Abi: “Over the past several years, I’ve worked hands-on with Developer Productivity (DevProd) leaders at hundreds of organizations. The same questions and challenges came up repeatedly, so a book felt inevitable. When Nicole reached out about teaming up in 2022, it was a no-brainer to finally make it happen. As a fun fact, I bought the domain developerexperiencebook.com in February 2021 – so about a year before we started writing the book!”
How long did the writing take?
Nicole: “The whole process took about 3.5 years, but it wasn’t linear. I had a false start where I’d written several thousand words and realized it was way too pedantic; basically a research book with chapters explaining methods, but nothing immediately actionable. I scrapped it and started over.
This was the point when I reached out to Abi. We’d written a couple of papers together before, and his work at DX was giving him incredible insights into the key challenges teams face, and what actually works to improve DevEx. The combination is perfect: I brought the frameworks and experience from working with teams, and he brought the frontline practitioner perspective and patterns he was seeing across hundreds of companies.
Together, we built something practical: the step-by-step process, the workbooks, the real-world examples. Much better than my first attempt!”
Where did you get inspiration for the practices shared in the book?
Nicole: “Honestly, it all comes from actual work: collaborating or advising actual teams and actual DevEx improvement projects”.
Abi: “As Nicole mentioned, we didn’t go reaching for ideas or conduct research specifically for the book. Everything we put into it comes directly from our existing research and practical experience”.
What are your favorite parts of the book, and do any details stick out in particular?
Nicole: “I love the section on treating metrics like a product. But if I had to pick one story, it’s how Dave Anderson was able to drive improvements at Amazon. What made it stick with me was how he could influence real change without authority by sharing a dashboard”.
Note from Gergely: longtime newsletter readers and podcast listeners may find Dave Anderson’s name familiar: he authored the popular guest post, A Day in the Life of a Senior Manager at Amazon, and has been a guest on the Pragmatic Engineer podcast.
Abi: “Translating developer experience into business terms (Chapter 9) is a topic that’s especially meaningful to me. Developers – and most engineering leaders – instinctively understand how essential a strong developer experience is. But helping non-technical leaders see its strategic importance can be challenging.
In the chapter, we highlight the story of Mike Fisher, former CTO of Etsy, who led a transformative developer-experience initiative that not only accelerated engineering teams, but was backed by hard, quantifiable ROI”.
What has the feedback about the book been like, so far?
Nicole: “It’s been really positive, overall. A lot of folks are finding ways to get unstuck, or engage with people at work in new ways. I’ve had a few folks insist the AI transformation will change everything, but the core of the book is really about how we build software, how to spot inefficiencies, and how to effect change.
And, as many of us are seeing, AI amplifies everything. Sometimes, it’s how much we can prototype and experiment, and other times, it’s our friction points and bottlenecks. So, while workflows may change, the fundamental importance of reducing friction doesn’t”.
Abi: “Like shipping a product, putting a book out into the world is exciting and also nerve wracking! I’ve been grateful for all the support we’ve been receiving, as well as feedback.
I think this book lands at a critical moment for the industry. AI is creating enormous excitement and rapid change, and that makes the fundamentals of measurement and developer experience more important than ever”.
Frictionless is organized into five parts:
Part I: Understanding DevEx
Part II: The three essential parts of DevEx (feedback loops, flow state, cognitive load)
Part III: Making the business case [to invest in DevEx]
Part IV: Improving DevEx: a 7-step process
Part V: Evolving and sustaining DevEx
With that, let’s jump into two full chapters of the book, from parts III and V.
The excerpts below are from Frictionless, by Nicole Forsgren and Abi Noda. Copyright © 2025 by Nicole Forsgren, Abi Noda. Published by Shift Key Press. Used with permission.
3. Making the business case to reduce developer friction
Chapter 9 from Part III: Making the Business Case.
Understanding developer experience and its business impact is just the beginning. The real challenge is securing the resources and organizational support needed to make meaningful improvements. Most DevEx initiatives fail not because of poor technical execution, but because they can’t effectively communicate their value to decision-makers.
In this part, we explore how successful teams have translated developer pain points into compelling business cases that resonate with executives. You’ll learn how to connect DevEx improvements to financial outcomes, align with existing strategic priorities, and position your work as a solution to leadership’s most pressing concerns. These approaches are designed to be durable—while the specific tools and technologies you advocate for will evolve with AI and other innovations, the fundamental methods for investigating problems, gathering data, and communicating business value remain constant. Whether you’re seeking initial funding for DevEx improvements or defending existing investments, these chapters will show you proven approaches for building leadership support.
Translate developer experience into business value
C-suite executives speak the language of business outcomes.
While “improving developer satisfaction” or reducing lead times” might resonate with engineering leaders, executive decision-makers need to see clear connections to financial impact. Business leaders are evaluated on metrics like revenue growth, profitability, and market share—so your DevEx proposals must connect directly to these financial outcomes.
This doesn’t mean executives don’t care about developer well-being. Rather, they need to understand how developer experience investments translate to business results. This financial framing is crucial when selling your strategy (Step 5) and demonstrating value (Step 7).
Talk about recovering time: Convert developer hours into dollar value. Developer time has clear financial value. You can:
Measure hours spent on unnecessary toil or waiting for builds/tests.
Multiply this time by the fully loaded hourly cost of developers.
Present these savings as “recaptured productivity dollars” or “free headcount.”
For example, if your team of 50 developers each wastes 5 hours weekly on build-related delays at a fully loaded cost of $100/hour, that’s $25,000 in weekly productivity losses—or $1.3 million annually.
Alternatively, express this as “free headcount,” for example, 50 developers × 5 hours lost weekly = 250 total hours wasted. Based on a 40-hour workweek, that’s equivalent to gaining 6.25 additional developers without increasing your budget. This framing resonates particularly well when hiring freezes are in place or during tight labor markets. To safeguard your credibility, be sure to actually measure real, credible time savings.
The financial impact is substantial. When teams improve developer experience, those benefits compound. A $250,000 developer who recovers just 10 percent of their time by avoiding tooling friction represents $25,000 in reclaimed value. Multiply that across an entire engineering organization, and it’s equivalent to dozens or hundreds of “free” developers.
But the benefits don’t stop there—faster toolchains enable organizations to build, experiment, and iterate more rapidly, creating business value that can climb into the millions. And that’s before accounting for the compounding effects on delivery timelines, team morale, and customer satisfaction.
Etsy’s $2.5M DevEx investment: A business case in action
As Etsy’s engineering team rapidly grew from 250 to nearly 1,000 developers, leadership recognized that productivity would suffer without investment in developer experience.
CTO Mike Fisher’s approach to securing buy-in was straightforward: Translate improvements into business language. Instead of explaining technical changes to deployment processes, he told executives the work would save 50 percent of engineering hours spent waiting for deployments—equivalent to a quarter of a full-time engineer’s salary. The result was an initiative that dedicated 20 percent of engineering capacity to improve DevEx in four key areas: Crafting products, developing and deploying, building with data, and reducing toil.
The initiative, which took 18 months, was so successful that it led to ongoing investment in developer-experience work, integrated into Etsy’s standard operations. Their key insight: Scale people, process, and technology together, or productivity suffers regardless of growth.
Talk about saving money: Quantify cost savings. Improved developer experience delivers tangible cost savings that directly impact your financial statements. By enhancing automation, streamlining workflows, and eliminating redundancies, you can substantially reduce operational expenses.
For example, strategic DevEx investments can:
Decrease vendor costs through process optimization and tool consolidation.
Reduce cloud computing expenses by improving test efficiency (eliminating redundant tests).
Lower infrastructure costs through optimized build processes that require less processing power.
Minimize expensive production incidents through better quality controls.
When making your business case, focus on these hard cost savings with specific projections whenever possible. This includes both the immediate savings from reduced delivery costs—as developers ship features faster with less friction—and the long-term savings from improved talent retention. Executives respond strongly to initiatives that demonstrate clear paths to expense reduction while maintaining or improving output quality.
Strategic standardization: How Block delivered millions in savings
Block is a leading fintech company made up of brands like Square, CashApp, and Tidal. Rather than pursuing standardization for its own sake, they centered their DevEx strategy on consolidating tools to create well-supported golden paths for developers.
When making their business case, Block’s team could have focused on abstract benefits such as developer satisfaction or code throughput. Instead, they focused on the dollar-impact that engineering friction and avoidable reliability incidents were having on the business..
The business-focused approach paid off. Their developer experience initiative was funded and delivered impressive results in 12 months. Thanks to investments in better developer environments, golden paths, and AI tooling, they saw millions of dollars in documented savings and double-digit improvements in developer satisfaction scores.
Talk about making money: Accelerating revenue through DevEx. While developer experience initiatives aren’t direct revenue generators, they significantly accelerate your existing revenue streams. For software-driven companies, revenue growth depends on five key factors:
Feature velocity (how quickly new capabilities reach customers).
Feature quality (how well new capabilities meet customer needs).
Experimentation speed (how quickly you can test and iterate on new ideas).
Service reliability (how consistently your products perform).
Security posture (how well you protect customer data and trust).
All five factors depend on effective developer workflows. Consider the AI transformation, where companies racing to integrate AI capabilities into their products are pursuing increased revenue, competitive advantage, and expanded market share. However, these AI features must be:
Designed and coded.
Reviewed for quality.
Built and tested.
Integrated into existing systems and products.
Securely deployed.
Maintained and improved.
When developers wrestle with suboptimal tools and fragmented processes, these technical bottlenecks become business problems. Your company faces delayed market entry, compromised quality, and security vulnerabilities—all directly hitting revenue.
Consider this: If competitors release AI features quarterly while your team needs six months due to workflow inefficiencies, you’re not just accumulating technical debt, you’re experiencing actual revenue losses and diminishing market relevance. Smart DevEx investments create a multiplier effect where your existing teams deliver more value faster, enhancing revenue streams and capturing market opportunities before competitors do.
Accelerating revenue growth: Capital One’s DevEx transformation
Capital One dramatically transformed their market position by strategically investing in developer experience and cloud infrastructure.
Before their DevEx overhaul, launching new financial products took 6-9 months, limiting the company’s competitive agility. By standardizing development environments, implementing modern CI/CD pipelines, and embracing cloud-native technologies, Capital One slashed delivery times from months to weeks or days.
The business impact was fast and measurable. Faster deployment cycles meant Capital One could capture market opportunities before competitors, respond quickly to customer needs, and optimize revenue-generating features through rapid iteration.
Capital One secured executive buy-in by directly connecting their DevEx investments to accelerated time-to-market and customer acquisition—metrics that translate directly to revenue growth. Their story demonstrates how improving developer workflows isn’t just a technical win—it’s a powerful revenue accelerator.
Talk about proven correlations: Link technical metrics to business outcomes. Sometimes the most powerful business cases come from identifying correlations between technical metrics and business outcomes.
In How to Measure Anything, Douglas Hubbard writes, “If you can correlate two things to each other, and then if you can correlate one of them to money, then you can express them both in terms of money.”
At eBay, a breakthrough analysis showed that every 10 millisecond improvement in page speed translated to millions of dollars in increased web purchases. This correlation transformed how the business viewed page speed—from a technical concern to a critical revenue driver deserving investment.
A specific example of this approach is the developer experience index (DXI), developed by DX. The DXI score is the average of 14 survey questions that ask developers about different aspects of their development process. By correlating this score against self-reported time loss, DX has found that each one-point gain in DXI score translates to saving 13 minutes per week per developer, equivalent to 10 hours annually. This correlation allows organizations to predict financial impact from DevEx improvements.
You can apply this same approach to developer experience:
Correlate developer satisfaction scores with reduced time-to-market.
Link build system reliability to fewer production incidents.
Connect onboarding experience improvements to faster new-hire productivity.
However, be cautious of trying to tie a developer productivity metric straight to revenue—a common mistake in this space. DevEx leaders attempt this, they don’t know how to get started, and then they give up trying to convince their management of the value of their work.
Storytelling matters more than the exact numbers
When building your DevEx business case, perfect is the enemy of good. Many leaders get stuck trying to calculate perfectly precise ROI figures or collect perfect data. This perfectionism is rarely necessary.
In most situations, reasonably credible data is sufficient—what really matters is how you weave that data into a compelling narrative. While data points make good headlines or proof points, they need a clear, concise story to be meaningful to decision-makers.
Remember: Even the most impressive numbers rarely speak for themselves. Your presentation skills, narrative structure, and understanding of your audience’s priorities will ultimately determine whether your business case succeeds. We discuss this more in Step 5: Sell Your Strategy.
4. How AI changes (and doesn’t change) the metrics you need
The excerpt below is Chapter 59 from Part V: Evolving and Sustaining DevEx
AI changes what developers do every day, so your metrics need to change too.
The good news? The measurement fundamentals you just learned still apply. As AI tools become woven into daily development work, you’re probably wondering: “Do I need to throw out everything I know about measuring developer experience?” The short answer is no—but the longer answer is more interesting.
The fundamentals still matter. The SPACE framework and DORA metrics remain relevant because developers still need fast builds, reliable deployments, good documentation, and strong collaboration—and AI often amplifies the pain of bad foundations rather than masking them. Flow and friction haven’t gone anywhere: Developers still need focus, and slow pipelines, flaky tests, and unclear ownership still break it. And while AI shifts what developers do, it doesn’t change their need for clarity, autonomy, mastery, and purpose.
Applying SPACE to AI-Augmented Development
In Chapter 58, we introduced the SPACE framework as a way to balance your metrics across five dimensions. That framework remains just as valuable when measuring AI-augmented workflows—you just need to ask slightly different questions:
Satisfaction: How do developers feel about AI tools? Do the tools improve or frustrate their work experience? Are they satisfied with the quality of AI suggestions?
Performance: Are outcomes improving with AI assistance? Track defect rates, feature completion times, and time-to-resolution for incidents.
Activity: What are the AI usage patterns? Monitor suggestion acceptance rates, what types of work get delegated to AI, and where AI gets used most (tests, docs, debugging).
Communication: How does AI affect collaboration? Are code reviews shifting from syntax to architecture? Are developers asking AI instead of peers? Is documentation improving or declining?
Efficiency: Where does AI save time versus create overhead? Measure workflow changes, time saved on routine tasks, and friction from context gaps or validation effort.
Consider adding a sixth dimension: Trust. How much do developers trust AI-generated code, comments, and recommendations? This affects both adoption patterns and the value teams ultimately derive from AI tools.
AI doesn’t just speed up existing work—it changes workflows. Developers aren’t just writing code; they’re reviewing, prompting, and steering AI. And here’s what most people miss: Most AI usage involves reasoning about information rather than generating it. Developers spend more time using AI to write summaries, compare alternatives, conduct smart searches, and synthesize research than generating code. This means existing metrics that capture time spent coding or lines of code written miss the bulk of AI-augmented work—the time spent crafting prompts, reviewing suggestions, and making decisions based on AI synthesis.
New metrics can help answer new, emerging questions. Track prompting efficiency—how many attempts developers need before getting a useful AI suggestion. Measure validation effort—the time spent reviewing and correcting AI-generated code, which reveals whether AI truly saves time or just shifts where developers spend it. And monitor trust calibration—when developers trust AI too much (shipping bugs) versus too little (wasting time double-checking correct code). These metrics reveal friction that traditional measures like commit frequency or lines changed simply can’t capture.
AI usage telemetry can reveal important patterns and changes in workflows. Capture what types of work developers do themselves versus what they hand off to AI agents—this shows where AI is valuable and may reveal new system blockers. Deep insights also come from watching how AI reshapes team dynamics: Are engineers asking AI instead of peers for help? Are code reviews shifting from syntax nitpicks to architecture discussions? Are new developers getting up to speed faster because AI explains your internal codebase?
Most importantly, collect this data thoughtfully. AI instrumentation typically involves much more detail than other methods. Aggregate at the team level rather than tracking individuals, be transparent about what you’re measuring and why, and work with HR and legal partners early to establish clear privacy boundaries. The goal is to improve developer experience, not create surveillance.
Your metrics product also needs to adapt. Create segmented views that compare AI and non-AI performance. Build feedback loops that reveal where AI adds the most value. And introduce visualizations that track how AI affects collaboration patterns.
Use AI to build your AI metrics
There’s a helpful irony here: While AI changes what you need to measure, it can also help you build that measurement infrastructure faster.
Use AI coding assistants to:
Generate data pipeline code for collecting AI telemetry
Create dashboard prototypes and visualizations
Write scripts to analyze prompt patterns and acceptance rates
Build data transformation logic for aggregating team-level metrics
What once required weeks of custom development can now be scaffolded in hours. Just remember to validate AI-generated code carefully—especially for instrumentation that feeds critical decisions. And leverage AI for the scaffolding and boilerplate, while keeping human expertise focused on the measurement strategy and interpretation.
Mixed methods become even more important with AI. Logs tell you what AI suggested and what got accepted, but only surveys and interviews tell you why. Your telemetry might show developers rejecting 80% of AI suggestions for authentication code—but you need to talk to developers to learn whether that’s because AI hallucinates security vulnerabilities, doesn’t understand your internal frameworks, or because developers don’t trust it for security-critical work. The “what” reveals patterns; the “why” reveals the root cause and tells you what to fix.
The shift from output to outcomes becomes critical. AI makes it painfully obvious that lines of code was always a bad metric—but more importantly, it forces us to connect our metrics to what actually matters. Developer productivity isn’t the goal; faster customer value delivery is. That means measuring problem-solving speed (time from idea to working solution), breadth of exploration (how many approaches developers can test), and cognitive load (whether AI helps or overwhelms). These outcome-focused metrics tell you what actually moves the needle on business value, not just code volume.
Behind the scenes, your infrastructure needs to evolve—and not just for developer workflows. Traditional telemetry doesn’t capture AI interaction loops, so you need new instrumentation for prompting workflows, completions, and accept/reject events. These real-time metrics reveal patterns and friction that retrospective analysis can miss.
But don’t stop there—instrument agentic workflows too. Tracking what agents do reveals which tasks are best suited for automation and which require human judgment. It also shows how delegation to agents affects developers’ mental models of the system: Does offloading routine tasks free developers to think architecturally, or does it create blind spots where they lose understanding of how things work?
Start by auditing your existing metrics through an AI lens. Ask: “Does this metric still capture what we care about?” and “What important tasks, workflows, and feedback loops does our data miss?” Don’t throw everything out and don’t start over from scratch—add data that fills important gaps and helps you answer new questions.
Your metrics strategy should also anticipate questions stakeholders will ask about AI adoption: “Where is AI providing the most value?” “Are we seeing quality trade-offs?” “Which teams are benefiting most?” Your metrics should answer these, not just operational velocity questions. Having these insights ready builds confidence in your AI implementation strategy while helping teams make better decisions about where and how to leverage these tools.
The bottom line: AI changes what you measure, but not why you measure it. You’re still trying to understand and improve developer experience—the SPACE framework still applies, as shown in the callout above. The fundamentals remain sound; you just need new instruments to capture the new reality.
End of excerpt.
Takeaways
Gergely, again. Thanks to Nicole and Abi for talking with me, and sharing excerpts from Frictionless. You can buy the book here, and download a free DevEx workbook that accompanies the title.
Before AI tools started to spread, larger tech companies invested in developer experience. Amazon calls this area “builder experience”, Spotify uses “R&D experience”, and other places use terms like “engineering experience”, or “maker experience” as per Frictionless.
With AI coding tools in use, there are expectations that productivity should increase for us devs – basically; assuming these AI tools are any good, products should be built faster, and iteration speed should improve. But we seem to be going back to basics in figuring out why this happens at some companies, but not at others.
Engineering leaders finally have a case for the resources of time and money to reduce/remove processes, improve tooling, and make developer experience better at both small and large teams.
I like Frictionless because it doesn’t talk about how to use AI differently or “better”: instead, it provides suggestions about removing annoying friction from devs’ day-to-day lives.
Thanks, Nicole and Abi for writing this book; hopefully it makes the case easier for reducing developer friction at your workplace, too!
For more reading on developer productivity, check out these deepdives:
How tech companies measure the impact of AI on software development
Measuring developer productivity: 17 real-world examples. Examples from Google, LinkedIn, Peloton and other companies
The story of technology: Doing more, with less. AI continues this trend while having the benefits of some seriously-strong adoption signals. Personally, I have loved how it's unlocked capabilities for me that I would not have been able to execute against even a year or so ago. Wild.