Frictionless: why great developer experience can help teams win in the ‘AI age’
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:
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:
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 SPACEWhen developer productivity is discussed, your book Accelerate often gets a mention. How does Frictionless relate to it – and what makes it different?
DORA, SPACE and this bookTo what extent does the new book build upon the DORA and SPACE frameworks?
2. Writing ProcessIt’s always interesting to learn what goes into writing a book. What made you both decide to take on this project?
How long did the writing take?
Where did you get inspiration for the practices shared in the book?
What are your favorite parts of the book, and do any details stick out in particular?
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.
What has the feedback about the book been like, so far?
Frictionless is organized into five parts:
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 frictionChapter 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 valueC-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:
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 actionAs 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:
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 savingsBlock 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:
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:
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 transformationCapital 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:
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 numbersWhen 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 needThe 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 DevelopmentIn 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:
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 metricsThere’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:
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. TakeawaysGergely, 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:
You’re on the free list for The Pragmatic Engineer. For the full experience, become a paying subscriber. Many readers expense this newsletter within their company’s training/learning/development budget. If you have such a budget, here’s an email you could send to your manager. This post is public, so feel free to share and forward it. If you enjoyed this post, you might enjoy my book, The Software Engineer's Guidebook: navigating senior, tech lead, staff and principal positions at tech companies and startups.
|
Comments
Post a Comment