Raw capture — raw/nicole-forsgren-ai-developer-productivity-2026.md

url: https://gist.github.com/a28965476df9359a180543d24fe3580e date_fetched: 2026-07-05 backfilled: true

You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert

AI supercharges the inner loop but breaks the outer loop. Gen AI gives a dopamine hit by speeding up coding, but existing review, deployment, and release processes—often manual, slow, and human-gated—get overwhelmed. The bottleneck just shifts downstream and becomes more obvious.

Old organizational friction becomes catastrophic. Processes that were “fine” before (waiting two weeks for database access, a laptop, or a single sign-off) now stall work immediately because AI lets new hires and interns commit code on day one. Friction that was once tolerable is now a hard blocker.

Fast feedback loops can increase cognitive load. Pre-AI, faster feedback was always better. Now, AI can force you to rebuild your mental model dozens of times in 30 minutes, or interrupt with unwanted completions. The nature of flow has changed, and managing cognitive load means sometimes turning the AI off.

Flow state depends on people, not just tooling. Psychological safety, clear goals, autonomy, and knowing the purpose of your work still matter more than any AI tool. AI agents always agree with you, so they can’t replace the human who tells you where you’re being dumb.

Measuring productivity requires asking “what do you mean by productive?” The SPACE framework (Satisfaction, Performance, Activity, Collaboration/communication, Efficiency/flow) helps teams make intentional, risk-based trade-offs instead of blindly chasing velocity. Start with adoption and engagement metrics, but tie them to real outcomes.

Explicit executive sponsorship unlocks safe experimentation. Giving people explicit permission (e.g., “10% of your time to experiment”) reduces fear and creates psychological safety to try, fail, and pressure-test systems.

Support yourself through change or you’ll burn out. Burnout isn’t just overwork; it’s misaligned values. Build a personal board of directors—trusted peers, often at other companies—to bounce ideas, sense-check, and stay grounded.

The frictionless future requires making the system visible. For agents (or humans) to self-improve, they need cheap, easy signals from the entire delivery pipeline. Instrument the touchpoints now, because those signals will shift as the development phases collapse.

Pithy and provocative quotes

“If we can’t call it developer experience, just call it agent experience, and then it’s all going to work.” — on the temptation to rebrand old problems.

“We all started focusing on gen AI and the coding, the inner loop, because we can see it. And that’s where all of the dopamine hit comes. … now we just threw gas on the fire.” — explaining why shipping is still slow despite AI.

“Tech is easy, people are hard.” — on why flow state still eludes teams with great AI tooling.

“I’m always so smart and I’m like, I know that was dumb. I know that was very dumb.” — on AI agents that never push back.

“I really need someone to tell me, like, where a hole is. Where am I dumb, what am I missing? … our AI tools and agents just aren’t there yet.” — on the irreplaceable value of human feedback.

“I am not a fan of an adoption metric. I don’t like it. But also devs are like a gloriously cranky bunch of … We are not going to use tools that are awful unless we absolutely … if it’s the only option.” — on why adoption is a grudgingly useful starting point.

“If we just brute force it, something’s going to break.” — on the danger of optimizing for velocity alone.

“Burnout is a combination of things. It’s working too hard. 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.” — reframing burnout for leaders.

Tools, practices, and methodologies

SPACE framework — A multi-dimensional productivity measurement framework: Satisfaction, Performance, Activity, Collaboration/communication, Efficiency/flow. Use it to move conversations from “are we faster?” to “what trade-offs are we making, and are they intentional?”

DevEx framework (flow state, cognitive load, feedback loops) — A lens for diagnosing developer experience. Use it to spot where AI is helping vs. hurting: fast feedback loops can spike cognitive load; flow state still requires clear goals and psychological safety that tools alone can’t provide.

Adoption and engagement metrics — Track whether developers are using AI tools (adoption) and how much/for what tasks (engagement). Adoption is a weak signal but a necessary early indicator of satisfaction and tool usefulness.

Personal board of directors — A hand-picked group of trusted peers (ideally outside your company) to stress-test ideas, talk through hard problems, and check value alignment. Use it to prevent burnout and navigate rapid change.

Explicit executive sponsorship — A top-down message giving people permission to experiment with AI tools (e.g., “10% of your time”). Creates psychological safety to try, fail, and learn within guardrails.

Risk-based decision making — Instead of “sacrificing quality for speed,” frame it as a deliberate, time-boxed experiment with clear metrics and a small blast radius. Use it to get fast signal without abandoning quality entirely.

System instrumentation and signal surfacing — Identify the touchpoints and quality gates in your delivery pipeline and make them visible with lightweight data. Both humans and future agents need this to see bottlenecks and improve the system. Start cheap and expect the signals to shift as processes collapse.

Unanswered questions and omissions

What concrete metrics actually capture AI-driven productivity? The talk says “it depends” and points to SPACE, but never gives a specific, operationalized metric for AI’s impact beyond adoption/engagement. Leaders leave without a dashboard.

How do you satisfy “two-person review” regulations when agents write code? Raised as an open regulatory puzzle, but no path to resolution is offered.

How do engineers maintain a coherent mental model of systems when AI generates code faster than they can internalize it? The speaker calls this an “open question” and suggests mermaid diagrams, but no systematic solution is proposed.

What about the new frictions AI introduces? The talk focuses on old bottlenecks exposed by AI, but doesn’t explore over-reliance, skill atrophy, AI-generated security vulnerabilities, or the cost/environmental footprint of these tools.

How do you handle non-engineers building and accidentally exposing tools with AI? Mentioned in passing as a security challenge, but the organizational and governance implications are left unexplored.

What’s the counterargument? The talk assumes AI adoption is inevitable and good. Resistance from engineers who fear job loss or de-skilling is acknowledged only as “fear” to be managed with exec sponsorship, not as a legitimate concern with trade-offs.

How do you instrument legacy systems to make them “visible” to agents? The frictionless future vision depends on cheap, easy signals, but no guidance is given for the messy reality of brownfield environments where that data doesn’t exist.

Speaker A: 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 of what you're up to these days and what keeps you up at night?

Speaker B: 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 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? Because Martin mentioned in the last session, the measurements were already kind of bad and now they're 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 like 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. This is just how we should go. They don't seem to be super open to it if agents just go on gut feel. So having some kind of signal is helpful.

Speaker A: 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 like shipping is just still so slow. How do these two things go together? What is happening in between?

Speaker B: So I think there's a few things, right? One is that we all started focusing on gen AI and the coding, the 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. As we go to ship, we've had systems that we already knew they could probably be improved, but it was fine. There were a handful of people probably managing a security review process or a launch process or a deployment process, or 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, what we're doing. I liked how 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.

Speaker A: Do you have some specific examples? We don't need to name specific companies, but like a thing where like, oh, now they're using all these AI tools, but these are things that are slowing them down.

Speaker B: 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 because we're just, we're putting so much work on it. And not only that, but like humans were already a bit of a bottleneck in the review process. Now it can be worse because things that we fairly straightforward changes that some companies had automation around reviewing. They removed that reviewing because if AI is involved, then they're worried about the verifiability or the reliability of the code. And so now that review burden has shifted. I'm also seeing quite a bit. I still talk to a handful of companies. We're seeing quite a bit in that deployment and release process. That's 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

Speaker A: in the book. I realize the book came out before Opus 4.5, but it described this scenario which seems like 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 churns out her first contribution and then for I think two or three weeks it sits there because the, the code review didn't flag it, she didn't have access to the database. Can you tell me a little bit about some of these things? A lot of us, some people sitting here are actually working at startups where it's just common thing to go from deployment to shipping pretty quickly. How common are these things which are just surprising? People of, oh, these things are being stuck. People are just fiddling your 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?

Speaker B: I Think one thing I'm saying that probably won't surprise a bunch of folks here is organizations are still gonna organize. 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 as low as do. And so, again, while we're kind of speeding up that inner loop and now we're starting to see agents do more around 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, I get database access. And not having database access for two weeks is like, historically usually been fine. Maybe not great, but 90% of the time it was fine. Well, now when you can be committing code on your first day in ways that the company wasn't necessarily structured for Etsy, famously, 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 supply chain snafus, they didn't get their laptop for like two weeks. So they were on a loaner. They had committed a lot of code before their laptop showed up. And, like, no one in the system. There was like 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 and a spotlight on the things that we were kind of fine before. And it's that friction that really slows us down. Now,

Speaker A: one thing you've been like, 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. And one of the latest, you went through a lot of iterations. We have Dora, we have space, we have the devex framework and more. And in the devex framework, this was pre AI. Can we talk a little bit about what the devex framework is? And then like, one part of it is cognitive load, how that feeds into AI.

Speaker B: Yes. So there are many ways to think about developer experience. But one that I find kind of useful is there. 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?

Speaker A: Feedback loops.

Speaker B: 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 something, an answer, 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 like 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, easy should not take brain power. But sometimes re ramping into a code base when we haven't been into 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 because it's straightforward, but it takes a lot of work. And that's where thinking about the human can be really helpful. Because it 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 cleanly 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 three to four hours a day. Really, really hard, deep work. Right. Which always makes me laugh when execs are like, we need eight hours of intense work. And I'm like, not with humans. Our brains don't do that. And so now when we have these three or four 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. I'm getting pinged all the time. 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 times has really changed.

Speaker A: One interesting thing I see with agents and all of you will be seeing it, is the feedback loop is faster. You tell it do this and it comes back. Especially some models like cloud code are very good at doing that. And then you start to get really tired because in using your terminology, the cognitive load increases by faster feedback loops. And it seems so counterintuitive because until before AI, we're always about iteration, fast feedback loops. We were never ever close to having these fast feedback loops. What is happening? Is this a net good? Is this an ad bad? Is it good that we're having faster feedback loops? But is it bad that we're having more cognitive load or how are you? It feels like such a contradiction.

Speaker B: I think it's just different, right? So fast feedback loops were good before because if I, for example, if I had a question about a library and someone could get back to me, then I could continue on. 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 it's not just 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, I think some of that is, you know, sometimes I'll just turn it off because I just like need to write for a second and then I'll let it review. So it's, I will say right now, like a lot of this is kind of an open question. People are starting to look at it. But also what the environments were like six months ago is very different than what they were like now. So it's just kind of evolving.

Speaker A: It's interesting when you said like you turn it off because I was talking with Michelle Hashimoto, founder of Hashicorp, about a week ago and he was telling me that his workflow is he has an agent always on the 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 we might be like 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. It used to be amazing. As an engineer, I used to be really efficient in the flow. And now with AI you can also 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 flow state does not only depend on tooling. You specifically said how things like psychological safety, project ownership, how technical decisions, how much autonomy you have, all those dependencies. 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?

Speaker B: Well, tech is easy, people are hard. And so sometimes getting 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 also not just have a well scoped feature or something, but I 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 is 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 so, and I will say I do my best work. Like I, I can't think of any paper as one example paper, a 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, like, 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 like our, our AI tools and agents just aren't there yet. Sometimes they guess really well and sometimes they guess in a completely orthogonal direction.

Speaker A: But on that one. Do you want to tell a story about the frictionless? The book when you started writing it and then you went back and I think you deleted a good part of it. Right?

Speaker B: 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. Like we kind of chatted about it. But I get through this whole section of the book and I realize there's. I've created several chapters of basically like how to do research when you're not researcher. Like how to write good survey questions, how to talk to people so you understand. It was incredibly like 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 like tossed it and reached out to ABHI and I was like, joanne, 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. Because it made sense and it was right. Also, no one's gonna. 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 state is 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. Sometimes I'll just give it something broad. I'm like, that really should have been more detailed. But by the time I find that out, we're an hour in and.

Speaker A: But I wonder if one takeaway might be that effort is not gone wasted. Right? You spent 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 shotted it. We talk about so much of one shotting things. Do you think like we might have to relearn that effort and wasted energy even as a human, when agents can do infinite of these things, it might be helpful for us.

Speaker B: Oh, I agree. 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 like learning things and kind of 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 kind of 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 can we help support and build these mental models, not just in a way that reduce cognitive load or improve flow, but help us understand our systems? Whether it's like, for me, I'm a visual person, so I. Years ago, when it was first coming out, I was asking it for mermaid diagrams all the time, right? Like, I needed to see what it kind of. I needed my. 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, right? Our brains just work that way better.

Speaker A: So we talk about taking the time and we want to understand it's a long change. But this one's a question for everyone in 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 that nodding, how do we measure it? And they're going to ask you, like, you all been with this excellent conversation with Nicole, and what did Nicole say? What metrics should we measure? And can we actually talk about, honestly, of where we are, what can work, and how you think about this? And you must get this so much.

Speaker B: 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 will say, what do you mean by productive? I know it when I see it. What shape does it take? Right? Like, code smells have a thing. Productivity smells have a thing, right? And sometimes it's lines of code or like 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? 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 kind of 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 everything? And they're like, well, no. I'm like, I. I'm just asking questions. I think that can help. Now, what are we using to measure productivity now? I will say, it's evolving 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, activities account, 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 like if we're in a flow or it can be the time, just the time it takes to get through the system. Right. And I know, I've heard a couple of people say here that, you know, 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 guard rules that you want to put in place? 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 and there are ways where we can make informed decisions. So I've worked with teams who, I will say 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. 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 like 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 like all slow because they just want to pump the brakes. Some folks in security, which is understandable, but it's now they're kind of on fire, their feet are on fire because there's just so much to do, especially

Speaker A: when the rest of the business outside. We talked about yesterday, we had a small event and we talked about how David Kramer from Sentry was talking about how a lot of non developers are getting access to cloud code and they're loving it and they're so productive and this might have been actually someone from a larger publicly traded company which is, I won't name them, but one of the business developers created this awesome tool to I think look at sales process and all that. And then Accidentally made it available to the whole world and they caught it in time. But now there's a lot of those folks. And I think David Kramer from Century was saying, yeah, we have this annual training where developers go and they go kind of a yawn, but. 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 gonna be this fun challenge. So now sounds like it's a good time to be in security.

Speaker B: It really is. Well, and because now there's also kind of evolving, I don't wanna say evolving definitions of security. Right. Like something's kind of secure kind of now. 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 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? Right. Are there ways that we can revisit some of that now? And there were some improvements made over the last changes. Improvements over the last decade or two, so that if you passed a set of automated checks and tests and that would count as one person, Right. Well, now it's two. Well, what happens when we have agents now? Right. And so I think some of this will be important for us to kind of discover and think about really creative ways to solve the problem in ways that are meaningfully consistent and also educate the rest of not just the industry, but regulatory fields. Right.

Speaker A: Today, if you're a VP engineer sitting in this group and you are in the process of rolling out all these AI agents from cloth 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're actually. You have the right data. You're thinking about like, not necessarily invading too much of developer privacy and not collecting junk data.

Speaker B: It depends. A lot of it, kind of. 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 like a gloriously cranky bunch of. We are not going to use tools that are awful unless we absolutely like, if it's the only option. There's almost no other option. I'm going to sound old when I say this, but one time I 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. We don't know what the capabilities are. We don't know how to kick the sides. 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. There's some tooling that and I know earlier studies found that for fairly straightforward work it gets used quite often. We can also watch how people are using that now. I'll come back to it depends. What is it that you're going for as a hypothetical VP avenge? Do you want people using it? Do you want them to get faster? Because everyone talks about faster 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 features future where they're all self driving. But that's another metrics rant.

Speaker A: And outside of just measuring, one thing that I heard is an interesting approach is giving explicit permission. Rajiv Rajan, Atlassian's cco, who will be our speaker in the next one at Atlassian, he sends a message telling to 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 kind of approaches? Which feels a little bit top down, but it also I guess creates a bit more safe space. Do you see this being useful in general for new technology or especially right now?

Speaker B: I think it's important in general. Right. It's basically like comms and change management. It's like 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, kind of guardrails And I know, you know, for years there have been places where like, 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

Speaker A: in your book, which is about again, removing friction, having ways to move better, faster, et cetera. 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 supporting yourself or how you see peers getting through this pretty intense time.

Speaker B: 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 when I had been, I interviewed like a handful of many, 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, 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, your own, I want to say Rose Whiteley 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. I have to go to an exec review and I need to have an opinion. And like, I understand half of this. Like, can you talk this, 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. 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. Sometimes I have found that talking through people and others who told me the same is kind of 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 sort of like relieved some of that pressure that they were under.

Speaker A: And finally looking ahead, in two to three years time, how would you envision a more or less frictionless organization operating a company where like, takes this really seriously? They are adopting AI Tools, they're like, all right, let's remove the friction points. How would that look like? And if you're sitting in this room today and you want to walk away and you want to start doing something this week, where would you start? On top of, of course, getting the book and reading it.

Speaker B: Workbooks are also free online. You can go find those. So a couple of things for the kind of frictionless future. I'm a metrics person, so my answer is going to be about data. But I think I've been having conversations with folks for 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, 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. For that to be true. We got to see the system, particularly when we're moving really, really quickly. Right now, humans are a stopgap. 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. Agents aren't going to be able to do that, or if they are, we probably don't want that. How can we think about ways to 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 like 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 touch points that we care about? Where are the signals that we want to see? How could 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 then right now that whole front end's been kind of smushed 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 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 touch points 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?

Speaker A: Yeah. And it feels to me that with so much change coming, one thing that feels really important to me that again it was in the book and we just talked about 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 messaging group 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?

Speaker B: Yeah. And I found that to be some of the most helpful and the most beneficial for me is you know, 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 saying? 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 like popping a question in a back channel with a handful of folks that you know and respect and you feel safe with.