Nicole Forsgren on why AI speeds up coding but not shipping
The Pragmatic Engineer
At The Pragmatic Summit, Nicole Forsgren, co-author of Accelerate and author of the new book Frictionless, discussed a tension that runs through the book: AI helps developers write software faster than ever, yet delivery often stays slow. Forsgren now works at Google on how people build software, including what they called "agent experience." Their answer centered on bottlenecks that sit outside the coding loop, the changed nature of cognitive load when working with agents, and the need for measurement that goes beyond counting output.
What Forsgren is working on now
Forsgren described their current work as a continuation of what they have always done: figuring out how to improve the way people build software. That now includes making agents smarter and better so that humans can work with them more effectively. Borrowing a line from Laura Tacho earlier in the day, Forsgren joked that if we can't call it developer experience, we can call it agent experience "and then it's all going to work."
A large part of the job is still measuring hard things like productivity. Forsgren acknowledged, echoing an earlier session, that productivity measurement was already weak and has become "extra bad." They argued that the alternative is worse. Developers often dislike productivity metrics because they can feel like an attack, but without any signal, decisions come down to a director's or VP's gut feel. Some kind of signal, they said, is better than vibes.
Inner loop acceleration, outer loop overload
The host pointed to a claim at the start of Frictionless: AI is producing software faster than ever, yet shipping is still slow. Forsgren's explanation was that the industry focused generative AI on the coding inner loop because that is where the results are visible and where "all of the dopamine hit comes." The systems downstream of coding, such as security review, launch processes, deployment, and code review, were already known to be imperfect. They worked well enough, often because a handful of people managed them. AI, in Forsgren's words, "threw gas on the fire."
The result, as Forsgren described it, is that teams are now chasing constraints and bottlenecks much more visibly than before. In the short term more work did get out the door. Now both technical systems and human processes are being overwhelmed.
Where the bottlenecks show up: review and release
Asked for concrete examples, Forsgren said the answer depends on where an organization is in its process, but code review comes up often. Humans were already a bottleneck in review, and AI has made it worse in a specific way. Some companies had automated review for fairly straightforward changes. They have removed that automation when AI is involved because they worry about the verifiability or reliability of AI-generated code. The review burden has shifted back onto people.
The second area Forsgren sees in conversations with companies is deployment and release. For many engineers this is a black box, but it is often run by humans: selecting the right candidate build, verifying it, working out cherry-picks, rebundling, and sending it out. When one or two people, or a small group, make those decisions and do shared sense-making, the process does not scale to the volume of changes AI now produces.
Organizations still organize: process debt and onboarding
The host raised a scenario from the book, which is based on a true story. A new hire using AI tools produces a first contribution, and it then sits for two or three weeks because code review didn't flag it and the new hire lacks database access. The host asked how common this is, given that many people in the audience work at startups where going from code to production is quick.
Forsgren's reply was that "organizations are still going to organize." Review processes where one person must sign off, and all the structure built to make work more uniform, are often exactly what slows teams down. Coding is speeding up, and agents are starting to help with review and other tasks. According to Forsgren, though, many companies have only recently started to think about applying AI to the human, business-process side of delivery. Until they do, that side will keep slowing things down.
Onboarding illustrates the point. Waiting two weeks for database access was historically tolerable: "not great," but fine most of the time. Now a new hire can commit code on day one, and most companies are not structured for that. Etsy famously had engineers commit code on their first day, but Etsy expected it; other companies do not. Forsgren described one or two cases involving an intern who, because of policies and supply-chain problems, went about two weeks without a laptop and worked on a loaner. The intern had committed a lot of code before the laptop arrived. For one particularly secure piece of work, nobody could figure out how to make it fit, because the source didn't match where the systems expected it to come from. Forsgren's broader point was that AI is putting a spotlight on friction that used to be acceptable and now really slows teams down.
The DevEx framework: flow, cognitive load, feedback loops
The host asked Forsgren to explain the DevEx framework, which predates the AI wave. Forsgren described three pieces that support one another: flow state, cognitive load, and feedback loops. (Forsgren briefly forgot the third and turned to Laura Tacho in the audience for help.)
Feedback loops matter for flow. Waiting 20 minutes, or a week, for an answer or a review breaks concentration, and that also makes cognitive load harder to manage. Forsgren defined cognitive load as the work the brain has to do. Some of it is inherent: difficult tasks take brainpower. Easy things should not. Returning to a codebase after time away carries high cognitive load, while staying in it lets much of that work come "for free." An arcane 100-step process may be straightforward, but it still takes a lot of effort. Forsgren repeated a theme from other talks, that what's good for humans is good for systems. Well-structured code, good documentation, and clearly defined APIs help people and, by implication, agents.
Forsgren also cited Gloria Mark's research on focus, which they summarized as finding that humans max out at about three to four hours a day of truly deep work. They said it makes them laugh when executives demand eight hours of intense work: "Not with humans." The question now is how to use those few hours well when working with AI. For many people, deep work means blocking the calendar and focusing on one thing. Many AI models are highly interruptive, and Forsgren said individuals and organizations need to rethink how they manage cognitive load now that the nature of the work has changed.
Why faster feedback can be exhausting
The host described something many in the room have experienced. Agents such as Claude Code return results very quickly, yet working with them is tiring. Fast feedback loops were long an ideal, and now that they have arrived, cognitive load seems to go up. Is that good or bad?
Forsgren said it is simply different. Fast feedback used to help because, for example, a quick answer about a library let you continue with only a brief pause. Now feedback can arrive so fast that developers must rebuild their mental model "dozens of times in like a 30-minute period." Feedback that outpaces a person's ability to keep up, or tools that inject completions before the person is ready, can be disruptive. Forsgren said they sometimes turn the tool off to write for a while and then let it review. They stressed that this is largely an open question. People are starting to study it, but the environment six months earlier was very different from the current one.
The host added an example from a conversation with Mitchell Hashimoto, founder of HashiCorp. Hashimoto keeps an agent running alongside him but has turned off all notifications. He kicks off a task and checks back only when he is ready, regardless of when it finished. The host suggested that people may be discovering their own working styles.
Flow depends on people, not just tools
The host noted that Frictionless argues flow state depends on more than tooling. It also depends on psychological safety, project ownership, how technical decisions are made, and autonomy. If AI tooling makes flow easier to reach, might people still struggle because those other elements are missing?
"Tech is easy, people are hard," Forsgren replied. Getting into flow requires understanding what you are doing, having clear direction and goals, and knowing the purpose of the work, not just having a well-scoped feature, so that you can make informed decisions. It also requires the psychological safety to take a risk or ask a teammate for help.
Forsgren referred to Kent Beck calling AI tools "genies" and said working with a handful of genies is not the same as working with a handful of friends. The energy and the conversations differ, and the tools "just agree with us constantly." Forsgren joked that the AI always tells them how smart they are when they know what they said was dumb. They said they could not think of a paper or book they had written entirely alone. They typically draft most of it and then need someone to point out holes, what they're missing, and what makes sense in their head but not to others. In Forsgren's view, AI tools and agents are not there yet: sometimes they guess well, and sometimes they go in a completely orthogonal direction.
The deleted chapters of Frictionless
The host asked Forsgren to tell the story of the book's early drafts. Forsgren explained that as a former software engineer turned researcher, they wrote the way researchers write: lots of detail and background, with the point arriving around page 105. Early on, they produced several chapters on how to do research as a non-researcher, covering how to write good survey questions and how to talk to people to understand them. It was detailed and easy to follow, and it was also, in Forsgren's words, "100 pages that no one needs to read ever."
Forsgren threw it out and asked Abby to co-write the book, partly to be told when they went down a rabbit hole. The material was eventually turned into workbooks at the back of the book, with tables to fill in and checklists, to make it practical and actionable. Forsgren described this as their personal problem with flow: getting into flow and writing for the wrong audience or at the wrong altitude. The same happens when coding with agents. They sometimes give an agent a broad instruction that should have been more detailed and only discover this an hour in.
Is "wasted" effort actually necessary?
The host suggested a takeaway: that effort was not wasted. The time spent writing the wrong thing produced learning that led to a better result, something a "one-shot" approach would not have delivered. With agents able to generate endlessly, might humans need to relearn the value of such effort?
Forsgren agreed. Being able to clearly articulate a problem, thesis, or idea does not happen without trying. They then raised what they called an open question that interests them. When they did more coding, they had a feel for the system from working in it constantly. They didn't know the whole system, which was huge, but could whiteboard the core reasonably well. Now code changes so fast that it is unclear how people will build mental models of their systems. Forsgren said the goal is not only to reduce cognitive load or improve flow, but to help people understand their systems. As a visual person, when AI tools first came out they constantly asked for Mermaid diagrams because they needed the tool to "whiteboard with me." Forsgren expects this to look different for each person, but said our brains simply work better when we take that time.
What to measure: "it depends," and why
The host turned to the question engineering leaders face from CEOs and boards: we are paying a lot for AI tools, so how do we measure the return? Forsgren said this is literally their job, and the answer is always "it depends," joking that everyone could go into consulting.
Forsgren said it depends on the question being asked. When someone asks whether they are more productive, Forsgren asks what they mean by productive and what it would look like, noting that just as code has smells, "productivity smells" exist too. If the answer is lines of code or PRs, Forsgren asks what that tells them. Does it get a feature to customers faster? If yes, is it the right feature, and do we know that? Which part of the end-to-end process is being amplified? Do they also want more ideas, more code, more reviews, more of everything? Usually the answer is no.
Forsgren said measurement is still evolving and pointed to the SPACE framework as useful. They walked through it:
- Satisfaction: how satisfied people are with the tool or process.
- Performance: an outcome, such as quality.
- Activity: anything you can count.
- Collaboration and communication: between people, which Forsgren said is evolving, or between systems.
- Efficiency and flow: being in flow, or simply the time it takes to move through the system.
Forsgren said they have heard many people at the event talk about velocity. Speed can be good, they said, but the question is what guardrails you want around it for quality and satisfaction. If you brute-force speed, "something's going to break."
Risk-based decisions instead of "all fast" or "all slow"
In response to a question from another session about sacrificing quality for speed, Forsgren said some teams do this, but intentionally. They don't describe it as sacrificing quality. They describe it as a risk-based decision. Forsgren gave the example of teams running rapid experiments. If they can ship an experiment in an hour to a very small percentage of users, they accept the risk of latency problems or crashes for that small group, then roll it back and have their answer. Forsgren argued that the right metrics support these deliberate trade-offs instead of defaulting to all fast or all slow. They still see teams that are "all slow," some in security, because they want to pump the brakes. Forsgren called that understandable but said those teams are now overwhelmed by how much there is to do.
Security and regulation in an agent world
The host described a conversation from a small event the day before. Non-developers are getting access to Claude Code and becoming very productive, and at one large publicly traded company a business developer built a useful sales tool and accidentally made it available to the whole world. It was caught in time. The host also relayed that David Cramer of Sentry said the annual security training developers tend to yawn through will need to become far more interactive and engaging, and everyone in the business will need to take it. The host concluded that it is a good time to be in security.
Forsgren agreed and said definitions of security are shifting: what counts as secure, which signals matter, and what levels of security are important. They pointed to regulations in certain countries requiring at least two people to review code before deployment. Over the past decade or two, improvements were made so that passing a set of automated checks and tests could count as one reviewer. Forsgren asked what that means now that agents are involved. They said the industry will need creative, meaningfully consistent solutions, and will need to educate not only the industry but also regulators.
Adoption and engagement as starting metrics
The host asked what a VP of engineering rolling out tools like Claude Code or Codex should measure tactically, while respecting developer privacy and avoiding junk data. Forsgren again said it depends, but that they tend to start with adoption, while admitting they don't like adoption metrics.
Their reasoning is that developers are "a gloriously cranky bunch" who won't use awful tools unless they have no alternative. Forsgren recalled a company insisting its developers had to use a particular CI/CD system; Forsgren bet $20 the developers were quietly spinning up Jenkins, and they were. Adoption therefore gives an early signal about satisfaction. It also matters because people who don't engage with a tool can't learn its capabilities or "kick the sides." They might love it at first and discover weaknesses later, or dislike it and never return.
Engagement comes next: how much people use the tool and for which tasks. Forsgren noted that earlier studies found the tools are used often for fairly straightforward work, and that it helps to watch how people use them. Beyond that, the metrics depend on the goal. Does the VP want usage, or speed? If speed, is it the inner coding loop or features end to end? The latter requires a much more holistic view of the whole system, especially in what Forsgren called "some magical agentic future" where agents are self-driving, which they said is "another metrics rant."
Explicit permission and executive sponsorship
The host mentioned that Rajeev Rajan, Atlassian's CISO and the next speaker, had told everyone at Atlassian they had his explicit permission to spend 10% of their time experimenting with AI systems. Is this top-down approach useful?
Forsgren said it is important in general. It is essentially communications and change management, "the really old-school stuff." They argued it matters especially now because there is so much fear, risk, and uncertainty around AI tools: will I be fired for using them, and what if I make a mistake? Across a handful of companies, Forsgren said they have seen explicit executive sponsorship make a big difference, not only in adoption but in people trying new things and feeling safe to fail within guardrails. They noted that some places have long given a prize to whoever takes down production. Without going that far, such attitudes help pressure-test the systems teams work in.
Supporting yourself through the change
The host asked why Frictionless ends with a chapter titled "Support yourself through challenging work." Forsgren said the final section covers supporting organizations, teams, and yourself through change. Many of the engineering leaders they interviewed for the book said supporting themselves was as important as giving their teams formal executive support for new tools. Any change, whether a new DevEx initiative or an AI rollout, involves a great deal that is unknown, and these are hard problems.
Forsgren recommended having a few people to talk to, what they attributed to "Rose Whitley" as having "your own board of directors." Such people let you safely say what is happening, for example: I have an exec review, I need an opinion, and I only understand half of this, so can you talk it through with me? Forsgren connected this to burnout, citing Christine Maslach's research. Burnout is not just overwork, which Forsgren described as simply getting tired. A critical component is misalignment with your values. Forsgren said that talking things through helped them, and others reported the same, to understand whether their values aligned with the work. Often they found they did, which relieved some of the pressure.
Seeing the system: a frictionless organization in two to three years
Finally, the host asked what a largely frictionless organization might look like in two to three years, and where attendees should start this week. Beyond reading the book, Forsgren noted that the workbooks are free online.
As a self-described metrics person, Forsgren framed the answer around data through a chain of conditions. Suppose there is a future where agents can self-drive and self-improve and organizations run better; Forsgren called this "maybe" true and "a stretch." For that to be true, agents must be able to see and understand the system and improve what needs fixing. For that, humans must be able to see and understand the system and act on it. And for that, the system must be visible, especially when teams move very fast. Right now humans act as a stopgap. People talk to one another and carry tacit knowledge, such as knowing that a problem in one area is usually about the build. Agents won't be able to do that, Forsgren said, "or if they are, like, we probably don't want that."
Forsgren's recommendation was to find easy, cheap ways to surface the signals that inform decisions. The instrumentation doesn't need to be heavyweight, and agents can probably help build it. The steps are to identify the touchpoints that matter, decide which signals you want, make them cheap to collect, and make sense of them, while accepting that they will change. The front end of software development, from idea and design through coding, has already been "smooshed" because teams can prototype so quickly. Forsgren fully expects parts of the outer loop to collapse too as more efficient approaches emerge. In the interim, they said, it helps to know where the quality gates and signals are and to watch where they shift, or whether they disappear, as the process collapses.
The host closed by returning to the personal board of directors: finding peers, ideally at other companies, forming a group chat, and comparing notes. With so much change, the host said, the only certainty is that things will keep changing, and peers in similar industries are likely to share a similar "it depends." Forsgren agreed and said this has been among the most helpful things for them. It lets them test whether an idea makes sense, whether what they see matches what others see, and, when it doesn't, whether things are actually different or people are just using different words. Beyond direct conversations, they keep a back channel with a handful of people they know, respect, and feel safe with, where they can drop a question at any time.
Nicole, it is so nice to have you here. Last time that you and me talked in more long-form in a way that a lot of you could enjoy was on the podcast and back then Frictionless was not yet out. You were working somewhere else. Now Frictionless is out. Congratulations. You're now doing a fun and exciting job at Google. Can you tell us a little bit about what you're up to these days and what keeps you up at night?
Oh my gosh, how much time do we have? Very similar work, right? Like how can we think about improving the way people build software? How can we think about... I love that, you know, Laura mentioned this this morning. If we can't call it developer experience, just call it agent experience and then it's all going to work. Thinking of ways that we can make agents smarter and better so that we can work with them better. How do we measure really hard things like productivity, cuz, you know, Martin mentioned in the last session the measurements were already kind of bad and now they're like extra bad.
So how can we find ways? Because on the one hand we don't love a productivity metric because it can feel like an attack. But if we have nothing, right? If this is just vibes. I'm sure we've all been in a meeting with a director or a VP or something where they just have a gut feel. Is this just how we should go? You know, they don't seem to be super open to it if agents just go on gut feel. So having some kind of signal's helpful.
One thing that struck me about your book, either the very beginning or the back cover, it says that AI is helping us create software faster than ever and yet delivery or shipping is just still so slow. How do these two things go together? What is happening in between?
So, I think there's a few things, right? One is that we all started focusing on GenAI in the coding, you know, that inner loop, because we can see it and that's where all of the dopamine hit comes, that's where it's all very exciting. And then, as we go to ship, we've had systems that we already knew could probably be improved, but it was fine, right? There were a handful of people probably managing a security review process or a launch process or a deployment process, or, you know, sometimes reviews were a little slow and they got backed up. Well, now we just threw gas on the fire and so all of that is a problem.
And so, what we're doing... I liked how, you know, Tiwa mentioned it this morning. Now we're kind of chasing those constraints, we're chasing the bottlenecks in a way that it's much more obvious than it was in the past. And so, in the immediate term, yeah, we were getting more out, but now our systems, whether technology systems or human systems or processes, are really kind of getting overwhelmed.
Do you have some specific examples? We don't need to name specific companies, but a thing where, oh, you know, now they're using all these AI tools, but these are the things that are slowing them down.
There are a handful of things. And it kind of changes depending on where they are in the process. Review ends up surfacing quite a bit, right? Because we're putting so much work on it. And not only that, but humans were already a bit of a bottleneck in the review process. Now it can be worse because fairly straightforward changes that some companies had automation around reviewing, they've removed that reviewing because AI is involved and they're worried about the verifiability or the reliability of the code. And so, now that review burden has shifted.
I still talk to, you know, a handful of companies. We're seeing quite a bit in that deployment and release process, right? That's kind of an empty black box for a lot of folks who don't know how the sausage is made, but so many times that process has been managed by humans because you're selecting the right candidate build and you're verifying it and you're figuring out cherry picks and then you rebundle and then you send it out, and that doesn't scale if you have one or two or a handful of people trying to make group decisions and do group sense making.
Mhm. And in the book, I realize the book came out before Opus 4.5, but it described this scenario which seems really alien, but obviously it's based on a true story, that there's a new hire joining a company using AI tools. This person turns out her first contribution and then for I think two or three weeks it sits there because the code review didn't flag it, she doesn't have access to the database.
Can you tell me a little bit about some of these things? Some people sitting here are actually working at startups where it's just a common thing to go from deployment to shipping pretty quickly. How common are these things which are just surprising people, of like, oh, these things are being stuck, people are just twiddling their thumbs for a while? And do you see this being the same? Do you see, because of AI, pressure being on removing these things and recognizing them? What are trends that you're observing?
I think one thing I'm seeing that probably won't surprise a bunch of folks here is organizations are still going to organize, right? So, when you've got some review process and we wait two weeks, or the one person has to sign off on it, but that person's like, "Oof." Or all of the things that we have structured process around to try to make things more uniform are often the things that slow us down.
And so, again, while we're kind of speeding up that inner loop and now we're starting to see agents do more around, you know, reviewing and a handful of other tasks, a lot of companies haven't started until now thinking about how we could apply AI to the very human, very business process part of it. And so, that will keep slowing us down until we find a way to address it, right?
And a lot of that comes with when I first start, you know, I get database access, and not having database access for 2 weeks has historically usually been fine. Maybe not great, but 90% of the time it was fine. Well, now you can be committing code on your first day in ways that the company wasn't necessarily structured for, right? Like Etsy famously, you know, you would commit code on your first day, but they knew that was coming. All of these other companies don't know that's coming.
I knew of one or two cases with an intern where because of policies and a couple of supply chain snafus, they didn't get their laptop for like 2 weeks. So, they were on a loaner. They had committed a lot of code before their laptop showed up, and there was one particularly secure thing they were working on. They couldn't figure out how to make that work because it didn't match. The source didn't match where they thought it would. And so, I think we're really seeing kind of an emphasis, a spotlight on the things that were kind of fine before, and it's that friction that really slows us down now.
One thing you've been so good at, and I paid so much attention to your work, and I think it's influenced myself and a lot of other people in the industry, is measuring, how we can measure these very hard to measure things. You went through a lot of iterations. We have DORA, we have SPACE, we have the DevEx framework, and more. And the DevEx framework, this was pre-AI. Can we talk a little bit about what the DevEx framework is, and then one part of it is cognitive load, how that feeds into AI?
Yes. So, there are many ways to think about developer experience, but one that I find kind of useful is there are three pieces that kind of fit together. So, there's flow state, there's cognitive load, and there's... Why am I forgetting the last one, Laura? Feedback loops. Feedback loops. I'll look at Laura. Thanks, Laura.
And they all kind of support each other, right? Because when I'm in the flow, the feedback loops are really important. If I have to wait 20 minutes, if I have to wait a week to get a question answered or a review back, then I break my flow. That makes it harder for cognitive load as well.
So, cognitive load is basically the work that our brain needs to do. And there is some inherent level of cognitive load in something we do, right? So, something that's difficult is going to take more brain power, but things that are easy should not take brain power. But sometimes ramping into a code base when we haven't been in it for a while, that's higher cognitive load. And so, if I'm already there, I can get a bunch of that work for free. Or anytime I have to deal with a really arcane process and go through 100 steps, it's easy cuz it's straightforward, but it takes a lot of work, right?
And that's where, you know, thinking about the human can be really helpful because, as was called out in a couple talks earlier, what's good for humans is good for systems. If I have well-structured code, if I have well-structured documentation, if I have APIs that are clearly defined and I know what those interfaces look like, it can be really helpful.
And then, I will say it's kind of revisiting this question now of how do we want to think about cognitive load? Because I want to say Gloria Mark has done some really incredible work on focus. And humans max out at about 3 to 4 hours a day of really, really hard deep work, right? Which always makes me laugh when executives are like, "We need 8 hours of intense work." And I'm like, "Not with humans." Our brains don't do that.
And so now, when we have these 3 or 4 hours, how can we use them best? And what does it mean when we're working with AI and with agents? Because for some of us, good deep work means I block my calendar and I can get really embedded and I can do one thing and I can think really hard. And now a lot of the models are very interruptive, right? I'm getting pinged all the time. And so how can I change the way I work, or how can I think about managing my own cognitive load, and how can we think about it more broadly in organizations, knowing that the nature of the work that we're doing in many cases has really changed?
And one interesting thing I see with agents, and all of you will be seeing it, is the feedback loop is faster, right? You tell it do this and it comes back, especially some tools like Claude Code are very good at doing that. And then you start to get really tired cuz, using your terminology, the cognitive load increases with faster feedback loops. And it seems so counterintuitive because before AI we were all about iteration, fast feedback loops. We were never ever close to having these fast feedback loops. So what is happening? Is this good? Is this bad? Is it good that we're having faster feedback loops but bad that we're having more cognitive load? It feels like such a contradiction.
I think it's just different, right? So fast feedback loops were good before because, for example, if I had a question about a library and someone could get back to me, then I could continue on, right? There was a bit of a pause but I kept going. Well, now I'm getting feedback so quickly that I'm having to sometimes rebuild my mental model dozens of times in a 30-minute period. And so getting fast feedback is good, but if it's faster than I know how to keep up with, or if it's interrupting, because, you know, sometimes they just want to inject text when I am not ready for them to do that completion.
And so, you know, sometimes I'll just turn it off because I just need to write for a second and then I'll let it review. I will say right now a lot of this is kind of an open question. People are starting to look at it, but also what the environments were like 6 months ago was very different than what they are like now. So, this is kind of evolving.
It's interesting when you said you turn it off, cuz I was talking with Mitchell Hashimoto, founder of HashiCorp, about a week ago and he was telling me that his workflow is he has an agent always side by side that usually runs, but he turned off all notifications because he only wants to go when he is ready. And he kicks it off with something and he doesn't care when it finishes. And I feel people might be starting to discover their working style on what works and what doesn't.
But speaking of flow state, being in the flow used to be amazing as an engineer. I used to be really efficient in the flow. And now with AI you can also kind of get in the flow maybe a little bit easier. In your book you did mention something interesting, and this is about the tooling, but you said that flow state does not only depend on tooling. You specifically said how things like psychological safety, project ownership, technical decisions, how much autonomy you have, all those matter. How do you see this changing with AI, where the tooling seems to be really good at getting in the flow, but could we see that people are actually still struggling to get into the flow because they're lacking a lot of those things?
Well, tech is easy, people are hard. And so, you know, sometimes getting in the flow really is about understanding what I'm doing, having very clear direction and goals and knowing what my work is doing. So, it's well scoped, but I not only have a well scoped feature or something, I also know what the purpose of it is so that I can make informed decisions. Some of it is having that psychological safety so that I know that I can take a risk on something or I can ask someone on my team.
And, you know, Kent mentioned, when he was calling AI the genies, when we're working with the genie, that's not the same thing. We may have a handful of genies, but that's different from having a handful of friends, right? In part because the energy's different, the conversations are different. Also, they just agree with us constantly. I'm always so smart and I'm like, I know that was dumb. I know that was very dumb.
And I will say I do my best work... I can't think of any paper, as one example, paper or book I've written on my own, because many times I get them started and I'll write most of it and then I'm like, I really need someone to tell me where a hole is, where am I dumb, what am I missing, what makes perfect sense in my head but does not make sense to them when I say it. And our AI tools and agents just aren't there yet. Sometimes they guess really well and sometimes they guess in a completely orthogonal direction.
On that one, do you want to tell the story about Frictionless, the book, when you started writing it and then you went back and I think you deleted a good part of it, right?
Listen, I was a software engineer for years and then I was a researcher and I was writing a bunch. Researchers write a very particular way. There's a lot of detail, there's a lot of background, and on page like 105 you get to the point. And so I had started it, I was maybe working with someone, we kind of chatted about it, but I get through this whole section of the book and I realize I've created several chapters of basically how to do research when you're not a researcher. Like how to write good survey questions, how to talk to people so you understand. It was incredibly detailed and easy to understand and 100 pages that no one needs to read ever.
No one is going to read this, and so I just tossed it and reached out to Abi and I was like, do you want to write this book? I think I have an idea of the direction I'm going. Also, tell me if I get in a rabbit hole. Cuz it made sense and it was right. Also, no one wants to read that. And we ended up turning it into workbooks in the back, which were great because then it's like fill in the
table, check the thing, make it really useful and actionable.
So that I'm not great at... That's my problem with flow states. I'll get in a flow and I'll write for the wrong audience or I'll write at the wrong altitude. Or I'll code at the wrong level of specificity, especially with agents, right? Sometimes I'll just give it something broad and that really should have been more detailed, but by the time I find that out, we're an hour in and...
But I wonder if one takeaway might be that effort is not gone wasted, right? You spend a lot of time in flow state writing, let's say the wrong thing, and learning, and then the end result was something special, something that would have not happened if you would have so-called one-shot it. We talk so much about one-shotting things. Do you think we might have to really relearn that effort and wasted energy even as a human, when agents can do infinite of these things, might be helpful for us?
Oh, I agree. You know, one is being able to clearly articulate the problem or the thesis or the idea. Without trying, I don't get there, right? And that's true of so many things. I think it's both in terms of learning things and getting your hands around them.
But one open question that I think is really interesting to me is, back when I was doing more coding, I kind of had a feel for the system because I was coding it all the time. Did I know the system? No, it was huge, right? But I knew my core; I could whiteboard it reasonably well. And now we're coding and things are changing so rapidly. I think there's a really interesting open question around how we can help support and build these mental models, not just in a way that reduces cognitive load or improves flow, but helps us understand our systems.
For me, I'm a visual person, so years ago when it was first coming out, I was asking it for Mermaid diagrams all the time, right? I needed to see what it... I needed it to whiteboard with me. And I think that'll be different for everyone else, but without taking that time... our brains just work that way better, right? Our brains just work that way better.
So we talk about taking the time, and then we want to understand it's a long, long change. But this one's a question for everyone in an engineering leadership position who is being hammered by their CEO and board and all of these things saying, all right, we're paying a bunch of money for this stuff, and I already see the naughty... How do we measure it? And they're going to ask you, you've all been at this excellent conversation with Nicole, what did Nicole say? What metrics should we measure? Can we actually talk honestly about where we are, what can work, and how you think about this? And you must get this so much.
That is my job. It depends. It is always "it depends." We can all go into consulting now and just make a ton of money.
It really does, though. It depends on what question it is you're trying to ask, right? So when someone says, "Am I being more productive?" then I'll say, "Well, what do you mean by productive? How do I know when I see it? What shape does it take?" Right? Code smells have a thing, productivity smells have a thing, right? And sometimes it's lines of code or PRs or something, and I'm like, "Okay, so what do you learn from that? Does that help you get a feature out to a customer faster?" And sometimes they're like, "Well, yeah." And I'm like, "Okay, is it the right feature? Do we know it's the right feature? And what part of that end-to-end process are we amplifying? Do you also want more ideas and more lines of code and more reviews and more of everything?" And they're like, "Well, no." I'm like, I'm just asking questions, right? And so I think that can help.
Now, what are we using to measure productivity now? I will say it's evolving, right? So the SPACE framework ends up being really helpful. SPACE is satisfaction: how satisfied you are with the thing. Performance: what's an outcome? There's quality or something. Activity is a count: anything you can count. C is collaboration and communication, which can be between people, which we're seeing evolving, or between systems. And then E is efficiency and flow. So that can be if we're in a flow, or it can be just the time it takes to get through the system, right?
And I know I've heard a couple of people say here that everyone's talking about velocity, and they want things to be faster, and they care about velocity, and I'm like, I hear you. Yes, that can be good. What are the guardrails that you want to put in place, right? How do we want to think about quality? How do we want to think about satisfaction? How do we want to think about whatever? Because if we just brute force it, something's going to break, right? And there are ways where we can make informed decisions.
So I've worked with teams who... There was a question in one of the other sessions about sacrificing quality for speed. Some teams can, but when they do it, they're doing it very, very intentionally. They don't say they're sacrificing quality. They say they're making a risk-based decision. But this is fair, though. They're running a rapid experiment. They want signal really, really quickly, and if they can get an experiment out in an hour, and they can run it against some very small percentage, then they're willing to take the risk of lower latency or a crash or something for that very small percentage, and then they back it out, and then they get an answer. So I think with the right metrics in place, it really helps us make those risk-based decisions versus all fast or all slow.
And I do still see some teams that are all slow because they just want to pump the brakes. You know, some folks in security. Which is understandable, but now they're kind of on fire, right? Their feet are on fire because there's just so much to do.
Well, yeah, especially when the rest of the business outside... We talked yesterday, we had a small event, and we talked about how David Cramer from Sentry was talking about how a lot of non-developers are getting access to Claude Code, and they're loving it and they're so productive. Oh, this might have actually been someone from a larger publicly traded company, which I won't name, but one of the business developers created this awesome tool to, I think, look at sales proxies and all that, and then accidentally made it available for the whole world. And they caught it in time, but now there's a lot of those folks. And I think David Cramer from Sentry was saying, yeah, we have this annual training where developers go and they kind of yawn, but we will need to make this a lot more interactive and engaging, and everyone in the business will have to go. So there's going to be this fun challenge. So now it sounds like it's a good time to be in security.
It really is. Well, and because now there's also kind of evolving, I don't want to say evolving definitions of security, right? Like something's kind of secure, kind of not, but what are the signals that we're looking for? What are the levels of security that are important? There are even some good questions around, you know, with some of the regulations in certain countries, you had to have at least two people review the code before it can deploy. What does that mean? Are there ways that we can revisit some of that now? There were some improvements made over the last decade or two so that if you passed a set of automated checks and tests, that would count as one person, right? Well, now it's two. Well, what happens when we have agents now? And so I think some of this will be important for us to discover and think about really creative ways to solve the problem in ways that are meaningfully consistent, and also educate not just the rest of the industry but regulatory fields, right?
Today, if you're a VP of engineering sitting in this group and you are in the process of rolling out all these AI agents, from Claude Code, it might be Codex, it might be other vendors, we mentioned the importance of measuring things. What would your suggestion be: specific things that you can, and probably it's not harmful, it's probably helpful, to measure already at a tactical level? And how would you get the strategy of what to measure, so you actually have the right data, you're thinking about not necessarily invading too much of developer privacy, and not collecting junk data?
It depends. So I will say I tend to start with adoption. I am not a fan of an adoption metric. I don't like it, but also devs are a gloriously cranky bunch. We are not going to use tools that are awful unless it's the only option, there's almost no other option. I'm going to sound old when I say this, but I one time had a company tell me, "Oh, well, they have to use that CI/CD system." I'm like, 20 bucks they're just spinning up Jenkins. And they were, right?
And so I think adoption can give us some early signals, in part to satisfaction. Because if a tool is awful, then they won't use it. And if we aren't engaging with the tool, so then we can look at engagement. If we're not engaging with it, then we can't understand, right? We don't know what the capabilities are, we don't know how to kick the sides. You know, we might love it immediately and decide it's amazing and then later find out what its weaknesses are. We might hate it and never go back, but I think that can help.
Engagement is another one, which is how much are people using it and for what kind of tasks? And so there's some tooling that... and I know earlier studies found that for fairly straightforward work, it gets used quite often, right? And so we can also watch how people are using that.
Now, I'll come back to "it depends," right? What is it that you're going for as a hypothetical VP of engineering? Do you want people using it? Do you want them to get faster? Because everyone talks about faster, right? And then what do you mean by faster? Is it the inner-loop coding part? Is it features end to end? Because then you have to take a much more holistic look at the whole system, especially if we're talking about some magical agentic future where they're all self-driving. But that's another metrics rant.
And outside of just measuring, one thing that I heard is an interesting approach is giving explicit permission. Rajeev Rajan, Atlassian's CISO, who will be our speaker in the next one, at Atlassian sent a message telling everyone, "For 10% of your time, you have my explicit permission to experiment with these systems and just see how they work." How do you see these kinds of approaches, which feel a little bit top-down, but also, I guess, create a bit more safe space? Do you see this being useful in general for new technology, or especially right now?
I think it's important in general, right? It's basically comms and change management. It's the really old-school stuff. I think it's especially important now, though, because there's so much fear and risk and unknown around using AI tools. Will I be fired for using them? What if I make a mistake by using them? And so I'm seeing across at least a handful of companies that explicit exec sponsorship makes a huge difference in not just using them, but trying new things and feeling safe to fail within, you know, guardrails. And I know for years there have been places where if you take down all of prod, you get some kind of prize. Without taking that to its extreme, that can also be helpful, because they're helping pressure test the systems that we work in right now.
In your book, which is about, again, removing friction, having a way to move better, faster, etc., towards the end there's a whole chapter on self-support. The chapter is called "Support yourself through challenging work." Can you tell us about why you wrote a whole section on it, and just advice on how folks can support themselves, how you see either yourself or your peers getting through this pretty intense time?
Yeah. So the context of that last section was supporting organizations through change, supporting your teams through change, and supporting yourself. And it was interesting because I interviewed several handfuls of engineering leaders as we were talking about some of this, and more than a few of them said it was really important for them to not just support their teams, you know, provide executive formal support for using new tools and systems, but also themselves. Because anytime you're going through any kind of change, whether you're kicking off a brand new DevEx initiative or you're rolling out AI, especially now when everything is so new, there's a lot that's unknown there. These are really hard problems, right?
And so having a couple folks that you can talk to... I want to say Rose Whitley said you should have your own board of directors. Because then we can bounce ideas past people. We can safely say what is happening: "I have to go to an exec review, and I need to have an opinion, and I understand half of this. Can you talk this through with me?"
And I think that also helps with burnout, right? Because burnout, we know, Christine Maslach has done some really great work where burnout is a combination of things. It's working too hard, right? But that actually isn't burnout. That's just getting tired. Another piece that's super critical to burnout is not having your values aligned. And so sometimes I have found that talking through with people, and others who told me the same, is understanding where your values are, if your values align, and then if they don't. And many times they found that they did align, and it relieved some of that pressure that they were under.
And finally, looking ahead, in two to three years' time, how would you envision a more or less frictionless organization operating? A company that takes this very seriously. They are adopting AI tools. They're like, all right, let's remove the friction points. What would that look like? And if you're sitting in this room today and you want to walk away and start doing something this week, where would you start? On top of, of course, getting the book and reading it.
Workbooks are also free online. You can go find those.
So a couple things for the frictionless future. I'm a metrics person, so my answer is going to be about data. But I think, you know, I've been having conversations with folks for a handful of months now around: if we think there's this future world where agents can self-drive and self-improve and they can do all the things and our organizations run better, for that to be true... So that's going to be true, maybe. Maybe not, but it's a stretch. For that to be true, agents need to be able to see and understand the system. And agents need to be able to improve the things that need fixed. For that to be true, humans need to be able to see and understand the system and then take action to fix it. And for that to be true, we've got to see the system, right? Particularly when we're moving really, really quickly.
Right now, humans are a stopgap, right? We'll talk to people, we understand the system. I just know that when there's a problem over here, it's usually about the build, right? Agents aren't going to be able to do that, or if they are, we probably don't want that. And so how can we think about ways to easily and cheaply surface some of the signals that can help us make decisions? And it doesn't have to be super heavyweight, although agents can also probably help us build some instrumentation, that's
Pretty good, right? So, how can we think about ways to, first of all, identify what are the touchpoints that we care about? Where are the signals that we want to see? How can we make it cheap and easy to get a hold of those? And then how can we kind of sense-make around them and realize that's going to change, right?
Like there's several phases in writing software. There's having the idea and coming up with the design and then coding it, and right now, that whole front end has been kind of smooshed, because many times we can just prototype really, really rapidly and kind of solidify some of what we're thinking in terms of ideas and coding.
So I fully expect that part of the outer loop is just going to be collapsed as well, right? Because we'll find more efficient ways to do that. But it's going to be helpful if in the interim we know where some of those touchpoints are, right? Like what are we looking for? What are the quality gates? What are the signals that show us something is working well or not? And then if we collapse, then where do those signals shift to? Or do they get to disappear?
Yeah, and it feels to me that with so much change coming, one thing that feels really important to me, that again was in the book and we just talked about it, is having this personal board of directors: finding peers who ideally work at different companies. You might meet some people here, you might already know them. Reach out to them, and it sounds like it's a time where everyone will be happy to get together to have coffee, create a WhatsApp group or just a group message with a few of you, and you talk: I'm doing this, I'm seeing this, I'm doing this, I'm seeing this. Because it seems like the only certain thing is it will change and it will depend what works for you. So if you get like-minded people in similar industries, the "it depends" will probably be more similar to a lot of you, right?
Yeah. And I found that to be some of the most helpful and the most beneficial for me: can I bounce an idea off someone? Is the way I'm explaining it making sense? Are the things that I'm seeing similar to the things that you're seeing? And if yes, what could that mean? And if no, is it actually different or are we just using different words? Right? And so that, I think, especially when we're in a time of change at all, but especially this rapid, it's super, super helpful.
And I also just keep, I've got like the back channel, right? So sometimes it's talking to someone, and sometimes it's just popping a question at a back channel with a handful of folks that you know and respect and you feel safe with.
Article published