From Friction to Flow: How Great DevEx Makes Everything Awesome

The central claim of this talk is that writing code stopped being the bottleneck, and that this is bad news rather than good news. Dr. Nicole Forsgren argues that AI coding assistants have made the inner loop dramatically faster while leaving the outer loop — review, testing, approvals, coordination, deployment — exactly as slow as it was, which means every pre-existing point of friction is now more expensive and more visible than before. Her prescription is to stop asking "how do we improve productivity" and start asking what it is actually like to build and ship software in your organization, then systematically find and remove the friction that answer exposes.

Forsgren has led productivity efforts at Microsoft, GitHub, and Google, and is the author of Accelerate and the second edition of The DevOps Handbook. She is best known for measuring the technology delivery process and, per her InfoQ bio, as lead investigator on that research. The InfoQ page lists this as a 37-minute, 33-second presentation from QCon San Francisco 2025, published with a "Recorded at" date of March 24, 2026. Note on sources: the InfoQ transcript for this session ends with the speaker's resources slide and contains no audience Q&A, so these notes draw on the presented material only. Passages marked Context below are supplementary explanation added for readers unfamiliar with a term, not claims made in the talk.

What You Will Learn

• Why faster code generation makes deployment bottlenecks more expensive rather than less, and why Forsgren treats this as an amplification of old problems.
• The three-part DevEx framework — feedback loops, flow state, cognitive load — and how the three reinforce each other.
• What Forsgren reports high-performing teams look like on the four DORA metrics, including the caveat she attaches to deployment frequency.
• Three concrete strategies for making a business case that leaders act on, drawn from named examples at Amazon, LinkedIn, and Block.
• A process of about seven improvement steps, a heuristic for picking a first win, and how she applies RICE prioritization to a realistic set of candidate improvements.
• What changes and what does not change about measurement when AI enters the workflow, including trust calibration and why lines of code got worse as a metric.
• The four mistakes she most often sees improvement efforts make.

The Productivity Paradox

Forsgren opens by testing the room's assumption that AI has solved productivity, and rejects it. Her observation is that AI is helping some things while making many others more challenging — or, more precisely, that it is surfacing to executives everything practitioners already knew. She calls it an "I told you so" moment. Where work involves friction, toil, or manual steps, AI has not solved it, or at least has not solved it yet.

The paradox is stated in terms of the gap between the two loops. Code can now be generated in minutes or seconds, and people from any business unit and any background can vibe code an app, push it, and get some use out of it. Deployment, meanwhile, is often taking longer. Forsgren notes wryly that her slide said days and that she was being optimistic; in the large companies she works with the real figure is usually months, and she says a lot of the biggest companies are finding deployment times still measured in several months. Producing code does not fix everything downstream of producing code.

Context: the inner loop is the tight cycle an individual developer runs — write, build, test, iterate locally. The outer loop is everything between a finished change and a customer using it: review, integration, security and legal approval, release coordination, and deployment. Forsgren uses this distinction throughout, and it is the frame that makes her paradox precise.

Two Stories, Thirteen Years Apart

She grounds the argument in two incidents. The first is Knight Capital in 2012. An engineer deployed code in what she describes as a very routine, very standard change. The deployment script reactivated an old feature flag. The deployment was manual and there were no automated tests. In 45 minutes, $460 million was gone. Her point is what the retrospective found: the daily developer experience — manual deploys, no test automation, stale flags — was where the risk actually lived. And the lesson everyone drew was that this could never happen again.

The second is from earlier in the year of the talk. A user she names as Jason was using a Replit AI coding assistant to build a database. He explicitly told it to make no changes to live data and set a code freeze. Forsgren's summary is "new tools, but a lot of the same problems", and "if anything, it was just faster now". The transcript does not spell out the mechanics of what the assistant did; she uses the case as evidence that an explicit instruction and a declared freeze were not sufficient controls, exactly as a deployment script and an absent test suite were not sufficient controls in 2012.

Context: a feature flag is a runtime switch that turns a code path on or off without redeploying. Flags that outlive their purpose are a well-known hazard precisely because the code behind them remains shipped and reachable. Forsgren does not define the term in the talk.

Better Questions

The reframe she proposes replaces "how do we improve productivity" with three questions: what is it actually like to build and ship software here, how can I deliver value faster, and how can this be sustainable. The sustainability question is personal for her — she mentions having burned out twice and does not recommend it — and it is the reason she frames DevEx work as building things sustainably rather than as squeezing more throughput out of people.

She also dispatches the objection that this only matters to software companies. Every company is a software company, and in her view the ones insisting they are not represent the biggest opportunity, since they keep writing software while denying that they do. Her illustration is banking: she has not lately been to a bank that holds her money as gold bars.

What Friction Actually Looks Like

Forsgren makes friction concrete before quantifying it. Her examples are a new hire still waiting for database access in week three; a pull request that sits for days because it was assigned to the wrong person, is stuck in a queue, or the reviewer is on leave; a build pipeline that crashes again, which she jokes means more xkcd swords in the hallway; and a deploy that requires manual coordination across several teams and several tools plus group decision-making about risk. She groups the sources as onboarding, codebase, integration, process, review, development friction, and deployment friction, and stresses that some of the worst offenders are not technical at all — they are process, approvals, and what she calls "not my job" friction.

Context: the xkcd reference is to the comic in which developers sword-fight in the hallway because the code is compiling. She uses it as shorthand for waiting on a build.

The cost figures she cites, presented as the slide to photograph if you need to convince a manager, come from a handful of different studies:

She names McKinsey for the first figure only and does not name the sources of the other two, so treat them as figures she reported rather than citations you can follow. Her framing is that this is no longer about comfort but about competitive survival — with the aside that developer happiness matters on its own terms because happy developers make happy software.

The AI-specific twist is that friction has become more expensive and more visible. The questions she poses are capacity questions: can test suites handle the new load, can build pipelines handle it, and can reviewers get through enough pull requests for everything now arriving? Her answer is: not always.

The DevEx Framework

Forsgren prefers "developer experience" to "productivity" as the organizing concept, because productivity talk drifts toward pushing more lines of code through the system rather than removing obstacles. Her positive framing of the target is a developer experience that is easy, seamless, and delightful. The framework has three parts, and she is explicit that there are several ways to decompose DevEx and that these are the ones she likes.

Feedback loops are how long it takes to get from a question to an answer: searching an internal codebase, getting a review, or finding out whether the build passed. Her AI corollary is that faster code generation simply demands faster validation. Her worked contrast is a 10-minute build versus a two-hour build. With a 10-minute build you stay in flow, experiment quickly, decide quickly, and learn continuously. With a long one you context-switch while waiting — possibly provisioning a whole new environment to work on a different task in a different repo, which leaves you holding several parallel tasks in your head, something she notes people are bad at — you delay decisions, you run fewer experiments, and you learn much more slowly. She points out that this is the picture for a two-hour build, and that she has worked with teams that have 30-hour builds, where even scheduling and spacing the builds becomes a design problem. The remedies she names for slow builds are incremental or parallelized builds, clear ownership, and automation.

Flow state is the ability to focus on hard problems. Her key point is that interruptions do not merely cost the minutes lost; they cost the context and the depth of what you were doing. She also flags that AI has changed the shape of flow: developers no longer sit and write code for hours, they prompt, get immediate feedback, then accept, review, and rewrite. She likens it to Stack Overflow on steroids, and notes that this different rhythm feeds directly into cognitive load.

Cognitive load is how much mental capacity is available for the work you are actually focused on. Her questions are whether the process, the deployment tools, or a test suite that throws a failure with no explanation are making it worse. She cites research by Gloria Mark putting the maximum time a human can spend on really hard, deep work at about four hours a day, and frames the whole discipline around that constraint: if you get four hours, what are you spending them on? AI adds load here too, because there are simply more tools to master — prompting, different coding agents, MCP, agentic workflows.

Context: MCP (Model Context Protocol) is a standard for connecting models to external tools and data sources. Forsgren mentions it in a list of things developers now have to learn and does not expand on it.

Architecture And Data Flow

The three parts are not independent, and Forsgren describes them as reinforcing each other in a cycle. The diagram below renders the loop exactly as she narrates it — fast feedback preserves flow state and reduces load, reduced load improves focus and decision speed, protected flow accelerates learning that compounds over time, and the resulting new code and new ideas return you to the fast feedback loop. This is her described causal chain, drawn as a diagram; the visual layout is mine.

flowchart LR
    A[Fast feedback loops] --> B[Protected flow state]
    A --> C[Reduced cognitive load]
    C --> D[Better focus and faster decisions]
    B --> E[Accelerated learning that compounds]
    D --> F[New code and new ideas]
    E --> F
    F --> A

Context: a practical consequence of a reinforcing loop, which the talk does not spell out, is that you need not attack all three parts at once — an intervention anywhere propagates around the cycle. Shortening a build is simultaneously a feedback-loop, flow, and cognitive-load intervention, which is consistent with the weight Forsgren puts on build time.

What Good Looks Like

To answer "how good is achievable", Forsgren uses DORA, a framework of four metrics she describes as highly correlated with performance — two speed metrics and two stability metrics.

The asterisk on deployment frequency matters. Forsgren restates it as "or they can deploy whenever the business needs". Some environments cannot deploy hourly — her example is shipping to an App Store — and she insists that in those cases the cadence is a business decision, not a technical constraint. The test is whether you could deploy when needed, not whether you happen to.

Her observation about how these teams get there is that people usually answer with a technical solution, and that the technical solution is genuinely important — but that what it buys is low cognitive load, protected flow state, and fast feedback. Engineering away the things that should be engineered away is what lets people focus on what matters. Her conclusion is that these teams are not lucky; they systematically removed friction, and anyone can do that.

She also pre-empts the two symmetrical excuses she hears. Large companies tell her the numbers must come from startups that move fast without regulation or approvals. A week later a startup tells her the numbers must come from big companies with funding and resources they lack. Her data shows the pattern holds across all sizes and industries. The one industry difference she recalls seeing a few years ago was that retail did better, which she attributes to sustained competitive pressure: with that many competing retail platforms, and often a brick-and-mortar business attached, weak delivery is an existential problem.

Making The Business Case

The other objection she gets, once people accept the importance, is that there is no time for this work because there is a product to build. Her counter is arithmetic she calls back-of-the-napkin math: take 20 developers, each losing 30 minutes a day to a single friction point. That is 10 hours a day and 2,600 hours a year, which at $100 per hour is about $260,000 wasted annually. (The transcript renders the rate as "$100 a year", which the arithmetic makes clear is a transcription slip for an hourly rate.) The point of the exercise is that you are already spending the money — you are just spending it fighting the friction instead of removing it.

When she is pulled into large companies, the two questions she gets are how to make the business case and how to change the culture; the technology, she says half-seriously, they have figured out. She offers three strategies, each with a named example.

Visibility and accountability. Dave Anderson at Amazon was responsible for improving platform error rates with zero direct authority over any roadmaps. He created a monthly S-Team report — the S-Team being the CEO's directs — showing error rates by team, stack ranked, with the owning VP identified and highlighted. Within about a week, directors were coming to his office to get off the list. Forsgren's reading is not that people do not want to improve their systems, but that they have a lot to do, and that if something is not a leader's priority it is realistically not going to be anyone's priority. Surfacing the data creates the priority.

Simple data with clear action. Max Kanat-Alexander shared an example from LinkedIn, where the team built what they called the Developer Insights Hub. They had a large number of data points but started very simply. The platform would surface something like "build times increased by 20%", which prompts an obvious question — why did build times get worse — and supports a drill-down. In her example, the answer was that mobile developers in Singapore working on one particular repo hit a problem so outsized that it moved the aggregate. That is actionable. Showing every build time across every repo and every geography just in case is a flood of data that nobody can act on.

Dollar impact. Block cared about developer satisfaction and developer experience, which is hard to make resonate with a business audience, so they translated friction into money using two numbers: the cost of the friction they could easily identify, and the cost of avoidable incidents. In 12 months they had millions in documented savings alongside an increase in developer satisfaction scores — because, as she puts it, systems that are easier to use are nicer to work with. Her general point is that internal platform improvements are usually a win-win; the hard part is communicating them the right way.

The Seven-Step Improvement Process

Forsgren presents a pattern of about seven steps — her own hedge on the count — developed with Abi Noda, co-founder and CEO of DX, based on conversations with hundreds of teams across large companies, small companies, tiny startups, and several industry verticals — all of which, she reports, follow the same general shape. Crucially, you can enter anywhere: start at step one if nothing has been done, or jump to strategy and priority if you are joining an initiative that has been running for years.

flowchart TD
    S1[1. Talk to someone] --> S2[2. Start small, get a quick win]
    S2 --> S3[3. Use data]
    S3 --> S4[4. Decide strategy and priority]
    S4 --> S5[5. Sell the strategy]
    S5 --> S6[6. Drive change at your scale]
    S6 --> S7[7. Evaluate and show value]
    S7 --> S3
    Entry([Enter at any step]) -.-> S1
    Entry -.-> S4

This diagram is my rendering of the sequence she described; the loop back from evaluation to data and the "enter anywhere" annotation reflect her statements that improvement is ongoing rather than a project and that you can start wherever you are, but the specific arrows are not from a slide she showed.

Step 1: Talk To Someone

Her strong recommendation is that whichever step you enter at, you go talk to a handful of people first. Before any surveys and before any metrics, ask what is getting in their way, and ask what they swear at every day — her promise is that developers will tell you. From those conversations you start collecting patterns, mapping the workflow, and examining the processes. The friction, she notes, is often at handoff points and at the boundaries between systems.

Step 2: Pick The First Win Carefully

Her heuristic for a first win has three criteria. It must be visible, meaning both that a developer will notice the improvement and that you can communicate it meaningfully to an executive. It must be achievable quickly — think weeks, a quarter at the very most. And it must benefit multiple teams: you will probably deep-dive with one team, but the problem should be big enough that a win there generalizes across many groups.

Step 3: Capture Data

Teams typically come back after the obvious low-hanging fruit is gone and ask what to do next; that is where data enters. She splits it into three categories: system data such as telemetry and logs; outcome data such as productivity, lead time, and defect rates; and impact data such as revenue, satisfaction, and time to value. Impact is the trickiest, and she suggests starting with the first two. She also defends surveys explicitly: getting reliable survey data across hundreds or thousands of engineers can be far faster and cheaper than instrumenting systems, and instrumentation is not only expensive but carries the risk that you instrumented the wrong thing.

Step 4: Prioritize With RICE

For prioritization she uses RICE: Reach (how many people are affected), Impact (how much their work improves, possibly measured in hours saved), Confidence (how certain you are this is doable), and Effort (how difficult, how much time, how much headcount and engineering time). The first three are better high; effort is better low. Her worked example compares three candidates:

She would start with the code review process: broad impact, high confidence, a quick win, and not too much effort. She adds that flaky test automation often takes a great deal of effort, though AI is helping there. The other advantage of this choice is that you can experiment locally, see what works, and then roll it out across a few more teams.

Beyond the RICE score she asks for a step back to weigh context-specific factors. Frequency — how often does the problem occur? Pain severity — is this a minor annoyance or a complete blocker? These two are not independent axes: the severity that matters is the product of frequency and impact. She makes the interaction explicit: people will absolutely hate something they only have to do monthly, while a slight annoyance that occurs every single day may cost more in aggregate. Strategic alignment — does it support business priorities, and is there an existing effort whose tailwind you can catch so you are not starting from scratch? Dependencies — she has several times seen a candidate that ranked second turn out to be the blocker for everything else on the list, which made it the right place to start.

Steps 5 to 7: Sell, Drive Change, Evaluate

The remaining steps are selling the strategy, driving change at your scale, and evaluating and showing value. "At your scale" is deliberate: it might be your job title as a director or VP, or it might be an engineer who has simply decided this is bad and wants things to be better where they are, with plenty of middle ground between. The scaling patterns below expand on what that means in practice.

Scaling DevEx: Three Scopes

Forsgren describes three scopes at which this work happens, distinguished less by seniority than by what kind of solution is appropriate.

At local scope, any individual contributor can act. Pick something small and obvious to your team, or suggest a Friday hack day to your manager, then prove the value and document what you learned so it can be shared more widely. The focus is your own team's processes and tools: what do we use now, what can I improve myself? Her point about this scope is that you become the example that creates demand — good news travels fast, and a couple of teams visibly having a better time is persuasive.

At middle ground — an engineering manager or second-line leader — you look for challenges common across teams, build a coalition, and find champions who care deeply. Here you want a few more proof points and slightly more scalable solutions: reusable tooling and runbooks rather than the purely custom work that suffices for one team. She is explicit that there are still no mandates at this level.

At global scope, where DevEx is your day job and you are embedded in the organization, the scope of projects you can tackle changes. You can think about resource allocation and flexing resources between areas, measure more systemically, and treat the work as strategic infrastructure rather than a series of improvements.

Measuring DevEx In The AI Era

Her answer to "what changes with AI" starts with what does not change: the fundamentals hold, and the SPACE framework still describes the dimensions worth measuring.

What shifts is the specific focus: you might be asking about an AI tool rather than a generalized workflow. DORA still matters for the same reason as before — it captures the process end to end — and she reports that many teams are doubling down on the inner loop even more than they had previously, optimizing writing and submitting code and treating everything past review as not their problem. Given the loop asymmetry, that is exactly the wrong direction.

The measurements that need to change are the ones tied to how work now actually happens. Instead of only measuring lines of code or PR feedback loops, she suggests looking at prompting — how long it takes to get an answer to a prompt, and how long to make progress across a handful of prompts. For agentic workflows, how are developers steering and creating the agents? For review, do our processes capture and improve AI-generated code as well as they historically did for human-written code? What is the code survivability of AI-written code — does it still make it through the pipeline? Is security different, is reliability different?

Lines of code, she says, was always a bad metric, and AI has made its meaninglessness obvious, because the volume is now enormous and extremely verbose with heavy commenting — while sometimes the best thing you can do is delete code. The replacements she proposes are qualitative in shape: prompting efficiency measured as how long it takes to get a suggestion that survives, how hard the output is to validate, whether AI itself can do the validating, and whether people are now spending all their time in code review because of the work slop arriving there.

Two AI-specific concepts get particular emphasis. Trust calibration is the balance between trusting AI output too much, which ships bugs, and trusting it too little, which either means not using AI at all or wasting time triple-checking everything. Workflow delegation is the question of what work goes to AI and what stays with humans, and she pushes past the obvious efficiency framing to the consequences: how does the split change cognitive load, how does it change your understanding of the system and your mental models, and how does it affect speed?

Mixed Methods, And Why They Matter

Her most important measurement recommendation is what researchers call mixed methods: collect data from systems and from people. System data tells you what is happening and often what is going wrong, but it usually cannot tell you why.

Her illustration comes from a team she spoke with a few months before the talk. They saw a huge rejection rate for AI code suggestions on an authentication area of the codebase, and the owning team could not work out why — was the tool simply awful there? The answer, once they asked people, was that the AI was hallucinating a great many security vulnerabilities. That gave them an action: they constrained AI on security-critical code, which saved the team a lot of time, since reviewing and rejecting suggestions still costs real effort even when some developers were auto-rejecting on the basis of recognizable AI code smells. She notes the team is still exploring solutions in that space. The lesson is that the system metric identified the anomaly and the human conversation supplied the explanation that made it actionable.

Her closing framing of the AI question is that the organizations winning with AI are not the ones that handed everyone Gemini CLI, GitHub Copilot, or Cursor — there are at least a dozen good options in any given week. They are the ones removing the friction that stands between generated code and a customer using it, which is what makes experiments and speed possible at all.

Trade-offs And Limitations

The talk's own list of failure modes is the clearest statement of its limits. Forsgren names four common mistakes in improvement efforts. Starting with data fails for two reasons: data does not talk to people — if you love a data point you still need a story to go with it — and an immature measurement program will inevitably reach for whatever data happens to be conveniently available, which was almost certainly not collected to measure the thing you care about. Doing everything at once fails because you cannot; picking one thing and doing it well is better. Optimizing only for executives fails her tree-in-the- woods test: if developers do not notice the improvement, the effort is in trouble. And treating it as a project — one deliverable and done — misses the goal, which is sustainable improvement engineered into the system over time.

Several other caveats are worth carrying out of the talk. The $260,000 example is explicitly napkin math built on assumed headcount, assumed time lost, and an assumed hourly rate — its function is to start a conversation, not to serve as a defensible estimate — and the seven-step process is derived from her and Abi Noda's consulting conversations rather than from a controlled study, presented as an observed pattern.

On measurement itself, the survey-versus-instrumentation trade-off cuts both ways: surveys are cheap and fast but self-reported, while instrumentation is expensive and can be pointed at the wrong thing. Her mixed-methods position is a direct response to the fact that neither source is sufficient. Finally, the AI measurement questions she raises — code survivability, whether review processes still work on generated code, whether security and reliability characteristics differ — are posed as open questions rather than answered, and the authentication anecdote is one team's finding rather than a general result about AI and security-critical code.

Practical Takeaways

Forsgren closes with one concrete action per role, which is the best summary of the method.

• If you are an IC: map your own workflow for a week and note every point where you lose 30 minutes to something that should not be a thing. Then interview one peer and check whether they see the same friction points you do.
• If you are a team lead: run a 30-minute retro asking what slowed us down this week that was not the work — or what took far longer than it should have. Her distinction is important: code review is work, but something inside the review process may be broken; a legal review that always takes a long time is process friction, not work.
• If you are a leader: talk to at least three people, and do the napkin math on a friction point or two, just to get a feel for where the cost sits in the organization.
• Whatever your scope: once you have identified the one thing, ask what is the smallest, easiest, quickest change that removes that friction point. Her final point is that small changes compound into transformation.

She also mentions a forthcoming book covering these steps in detail, and points to a companion website with roughly 100 pages of free workbooks: templates and frameworks, both a Quick RICE heuristic version and a more detailed RICE framework with examples, interview guides, example surveys with additional questions (she notes three or four questions suffice if you only want to find friction), and assorted rubrics and spreadsheets. The QR code with the URL was shown on the slide and is not legible in the transcript.

Key Terms

• DevEx (developer experience) — the day-to-day experience of building and shipping software, decomposed here into feedback loops, flow state, and cognitive load; Forsgren prefers it to "productivity" because it points at removing obstacles rather than increasing output volume.
• DORA metrics — four measures highly correlated with delivery performance: deployment frequency and lead time (speed), change fail rate and MTTR (stability).
• MTTR — mean time to restore; how long it takes to act on and mitigate a production failure.
• SPACE framework — a five-dimension model for choosing what to measure: satisfaction, performance, activity, communication and collaboration, and efficiency and flow.
• RICE — a prioritization score combining reach, impact, confidence, and effort; the first three are better high and effort is better low.
• Code survivability — whether AI-written code actually makes it through the pipeline. Forsgren raises it as a question worth measuring rather than defining a specific formula.
• Trust calibration — matching how much you trust AI output to how reliable it actually is; miscalibration in either direction is costly.
• Workflow delegation — the allocation of work between AI and humans, and the downstream effects on cognitive load, mental models, and speed.
• Mixed methods — combining system-generated data with data gathered from people, on the basis that systems show what is happening and people explain why.
• Work slop — low-quality AI-generated output that consumes reviewer time without contributing value. Forsgren uses the phrase in passing without defining or claiming it; it is not her coinage.

Reference: From Friction to Flow: How Great DevEx Makes Everything Awesome