Ep. #7, Exploring DORA and Progressive Delivery with Nathen Harvey

Nathen Harvey: Hi, everyone, I'm Nathen Harvey. I lead up the DORA program here at Google Cloud. DORA, if you're unfamiliar with it, or even if you are, doesn't matter, it's still the same thing. It is a research program that looks into the capabilities and conditions that high performing technology driven teams and organizations need to thrive.

This research has been going for over a decade now and we've learned a whole lot about software delivery performance, which is kind of our center of gravity. And as you might imagine, we've been looking a lot into how is AI changing that recently?

James Governor: I think that's the best introduction I've ever heard anyone ever do of themselves and their organization. I need to work on that. That was very good.

Nathen: There you go.

James: Now, the one thing I got to ask Nathen, I am old enough to remember when the D in DORA stood for DevOps.

Nathen: Yeah.

James: And y' all decided that actually, perhaps there's a broader thing you need to look at. So say a bit about that. Why it's, it's not-- We're not in DevOps anymore.

Nathen: Yeah, yeah, yeah. So we have, over the past few years, we've de-acronymed DORA. So DORA stands for nothing, which doesn't sound great when you say it out loud. So what we lean on in terms of what we stand for, our real principle is our tagline, which is get better at getting better.

We want to help teams and organizations go on this journey of continuous learning and improvement. Now, part of the reason that we've de-acronymed is that that word DevOps today can do a couple of things.

One, I think when we start conversations, it can close as many doors as it opens. and the reason I say that is because DevOps has been around for 15 years and lots of people have tried to do the DevOps with varying levels of success.

And so when you start a conversation with DevOps, in some organizations, they're like, "you know what? We tried that. It didn't work for us. We've moved on past that. We've moved on to SRE or platform engineering, or everything is AI." So that DevOps, we're not ready to talk about that or willing to talk about that.

I think another issue that we run into, unfortunately, one of the things that happened over the 15 years of developing DevOps is that a lot of DevOps teams emerged. And, if you go back to the original principles of DevOps, it was about getting dev and ops to collaborate together. And we all knew that the best way to do that was to put a team between them. No, no, wait, that's not what we do.

Adam Zimman: Haha!

Heidi Waterhouse: No, no. Could we have a team and some process?

Nathen: Haha. Yeah, like, we knew that that was not good. But even still, there are DevOps teams and DevOps engineers.

James: Is it now, it's to put an agent between them?

Nathen: Yes, now we put an agent between them. Absolutely. That will solve all of our collaboration issues. Haha.

But so, like, when we go out and we run an annual survey as part of our research, if we call it the DevOps survey, there are so many people that look at that survey and go, "well, that's not for me. I'll forward it to the DevOps team and they can participate in that survey."

But our survey has always targeted technical practitioners and leaders, sort of regardless of what role you play, all the way across the software development lifecycle. So I would say that starts with executives, includes product managers who are making decisions, like prioritization decisions. It goes through to software engineers, all the way through to those SREs that are answering the pager when something goes wrong.

Even, I would argue, marketing and customer support, like the people that are really close to the customers, we want to understand, how do they participate in this whole software development lifecycle?

James: Oh, oh, I know this one.

Heidi: Are you telling us that it matters how people feel about the software they use?

Nathen: Yeah. It might matter a little bit. Especially if what you want them to do is to use more of it. It might matter.

Adam: Turns out people don't just want more software.

Nathen: It's not just, "More, more. Give me more software. All I want is more software."

Adam: People want to be able to do things with it or like have it be useful or--

Nathen: Yeah. And sometimes as much as we talk about like you know, shipping software, sometimes people want the software to work the same as it did yesterday and not be surprised every day with changes that are happening.

James: I think in this AI era, sometimes it feels more like people are shitting software than shipping it.

Nathen: Yeah. Well, we do talk about a shit left-- shift left, haha which, what are we doing on the left? Yeah, so it happens.

James: Haha. So from fecal matters, let's get back to the matter at hand, which is software development. We do think that's really important. Progressive Delivery, the mission we're on, certainly that the user, that the conversation, certainly their feelings and what they need from a product. Super important.

That's in fact the name of the podcast, the Third Loop. You know, we had the dev and the ops loops for many years and we're trying to encourage people to really include the user in that journey much more closely. So I think that's super exciting to us.

Nathen: Yeah, it is one of the places that we've been exploring also, we talk about this as user centrism or having a user centric focus. We look at that in the DORA research and we find actually one of the things that we saw, I think it was 2024 and reported that if you want to improve product performance, actually user centricity is more important than software delivery performance.

In fact, you can have better product performance if you're just focused on your users and what they want than you can by improving the rate at which you ship or something along those lines. But it is really important that we're getting more and more connected to the users. Frankly, I think AI used in the right way can help with that. It's not guaranteed to help with that, but it can help with that.

Adam: Why don't you provide an example of what you would advocate for the right way for AI to be able to positively impact this kind of metric of user centricity.

Nathen: Yeah. I'll give you a real life example from a customer that I worked with. This particular customer is in the realm of manufacturing appliances that ship out to customers. And some of these appliances happen to sit on customers kitchen counters.

One of the appliances is a stand mixer. Right? So like you can mix up your cookies and your cakes and whatever and they added some AI to their mixer because, well, as you know James, that's what everyone who purchases a mixer wants is how do I connect this to the Internet and some AI on the back end.

James: A hundred percent. That is always what we are looking for. Haha.

Nathen: Yes, yes. As you can imagine, like, the AI capability gave the customers, the users of this stand mixer, opportunities to like, tell it what ingredients they had or ask it for recipes. The cool thing about this from a user centric perspective was that the software engineering team and the product team on the other side of that could actually look at the logs of those conversations.

And that helped them really have a much deeper empathy for how are the customers actually using this stand mixer? What are they trying to accomplish? And so being able to, like, in real time or near real time, but with high levels of fidelity.

Not some survey that we ran that got customer satisfaction, but rather, here's how the customer is directly interacting with our product and we can use that to inform what are we going to prioritize for the next release of this software.

And to me, that tight loop is the thing that's so powerful and that's also how we measure user centricity. Are you actually getting feedback from users and are you using that to regularly reprioritize the things that are on your roadmap?

Adam: I'm sorry, I'm still being a little bit caught off guard by the idea that you weren't actually joking that there was AI in the stand mixer. Haha.

Nathen: Oh no, I'm quite serious.

Adam: And that there was a customer audience that was actually participating in the utilization of this feature. Yes, I am caught unaware. Haha.

Heidi: Get with the times, Adam.

Adam: I know. Apparently I need a new mixer. Mine doesn't have the AI in it.

Nathen: Right.

Adam: And so did they then what did they do with this feedback that they were able to kind of see? And did they do things productive?

Nathen: I think that they did do things productive. You know, when I talked with them, it was still pretty early on, but I think that they were looking at like, all right, well, the recipe feature is something that people are using a lot. So like, let's make sure that we're digging into that and maybe even starting to gather some feedback from the users on how this recipe went.

Like they had, I think, difficulty levels for their recipes as well. And so collecting user feedback, like, "you said this was a three. It felt like an eight to me in terms of difficulty. So, maybe you need to adjust that."

And so I think it both helped features that they wanted to ship, but also then help them improve and iterate on the content that they were providing to the users. And of course features versus content, like, from a user perspective, from that stand mixer user, I don't differentiate them. I just want to make the best biscuits that I can with this mixer.

Adam: That's fair. See, but now I'm like, my head's immediately going to the fact that, like, if I were to actually have AI in my mixer, I'd want it to be, like, measuring temperature and viscosity--

Nathen: And it does all of that.

Heidi: Okay, if it could fix my pastry dough problem--

Nathen: Yes.

Adam: Or be able to no longer have to continue to check my buttercream when it's cooling.

Nathen: Yes.

Adam: And confirm that it's actually come together suddenly. I mean, I'm not sure how much I'd pay for that functionality, but it would be something that would be useful to me.

Nathen: Yes. And so there are tons of sensors that are built into this mixer that are providing input to that AI, and it is looking at things like temperature and the viscosity of the thing that it's mixing and giving you suggestions on like, "whoa, whoa, whoa. Turn it off or turn it up or. You're using the wrong attachment, Adam. of course it's not working properly."

Heidi: Like, did you mean to do that with the whisk, or would you like the dough blade?

Nathen: Yeah, yeah.

Adam: All right. okay. This was a phenomenal example that I was not expecting. Interestingly, we have actually talked before on the podcast about like, IoT and, like, how you would potentially do Progressive Delivery or think about this notion of the user feedback loop with IoT devices. Because for that reason, it's like, sometimes you have the offline state. Right?

But this is a whole new way of mixing things together. Haha.

Nathen: It really is.

James: So, I mean, now we've mixed things up a little.

Heidi: Haha. Yeah.

James: One of the things that I find fascinating about the DORA report, and I think that my smarter colleague, Rachel Stephens does a good job of a close reading every year and comes out with some interesting insights to add to the insights that y'all have. You know, where are we now? What's the state of the art? How is AI changing the way that we're building products?

And is it enabling or making it harder to include that third loop and the user feedback? What new insights from the DORA report have you got for us that we should really be thinking about for perhaps the next edition of the book? Or, like, what is changing?

The look on Heidi's face when I said that out loud. That was amazing. I too am not a great poker player, Heidi. Haha.

Heidi: Haha. Never have been.

James: That was very good. Like what's changing in the report and you know, what do people listening to the podcast need to know about what's happening with the state of the art?

Nathen: Yeah, for sure, for sure. And just before I answer that, I was in a conversation a few months ago with Martin Fowler and the idea of second editions of books came up and I'll just share some advice for you that I heard from him, who he heard from someone else. But it is that the second edition should always be shorter than the first.

Heidi: That seems right, honestly.

Nathen: Yeah, maybe that will help, I don't know. But so what does DORA tell us about the state of AI and the state of the art within software development?

I think that when we look at the research, the top level message and finding that we have is AI really acts as an amplifier.

And when we think about amplifying something, I don't know, you can think about your favorite band and maybe they play a stadium and you amplify them and they get pretty good. Like you can hear them from the back. But you can also maybe think about, maybe the high school bands that you were in that met in the garage. You probably don't want to amplify that.

I mean, I wasn't there for the garage. I'm sure your high school band was amazing, but you probably don't want to amplify it in the same way. And we kind of see the same thing with software delivery. Those teams that, have a nice sustainable way to get product into production, get feedback from users, select the right products to build, throw in a little bit of AI and things get a little bit better.

And those teams where they're, that isn't the case, where they're disconnected from their users, where they're working as kind of a software factory. I take a ticket off of the backlog, I write some code, I send it on down the line and hope for the best.

The pain that they feel, the bottlenecks that they run into, you feel them more acutely. I think that one of the earliest places that this shows up for most teams is in the review cycles. Code review has forever been a bottleneck with software delivery in many, many organizations. And what we did as an industry, we got these great new tools that help us generate a lot of code. And so we scaled up our ability and the speed with which we generate code. And we did nothing or very little to change our capacity for reviewing that code.

And so we're sending 10x100x1000x more code through this same constraint that is the code review process. And you just feel the pain of that more, the way that that sort of manifests in the software delivery performance metrics. What we saw two years ago was that throughput was down and that stability was down. So you were shipping less, and when you did, you were more likely to roll that back.

What we saw in 2025 was that throughput has started to recover, so you're able to ship a little bit more with AI. But instability has not recovered. In fact, it continues to be bad. So we're rolling back more changes.

And I think that when it comes to things like Progressive Delivery, I don't know, this is a for me it's a very strong advertisement for Progressive Delivery. We want to be able to roll things out to users that matter and in a controlled way so that if something does go wrong, the blast radius is very, very small. And I really think that AI puts a lot of pressure--

I kind of think of AI putting pressure on the entire software development lifecycle in three different ways. First, if we start in the middle, you've got to have a good pipeline to get your changes into the hands of the users. W e sometimes say you ship to learn. Like whatever you're building is the wrong thing. I can guarantee it, but it's maybe righter or more correct than the thing that's currently in production. But you won't know until you put it in the hands of users. So you have to be able to ship your ideas. If you can't ship your ideas, you can't learn.

James: I'm going to be inviting Charity Majors to talk about this. I think it was Kim who had noticed that Charity has started talking about the fourth trimester, which is. yeah, until you ship the thing, you don't really know what's going on. And it's certainly not the end of the story that moment.

And so getting feedback, understanding. I just thought that was an interesting way of thinking. And yeah, we'll be asking-- God, I hope she says yes now. We're pre -announcing it. You know, Charity had said she would join us, but that, I think will be one of the topics of conversation.

Adam: Yeah, no, I mean, I think that an interesting point about, this thing that she talks about is, the way I've heard her discuss this kind of notion of what she calls the fourth trimester, which, is the idea of relating back to the separation between developers and operators is the idea that, if you're a developer and you think that when something lands in production, you have handed anything off, you're probably doing it wrong.

And that, this notion of the fourth trimester is that your product or your feature or your code can't actually be finished until it has actually been in contact with your users. And so that means that there is inevitably going to be things that need to be done that need to be, you know, fixed, updated, changed, when you actually have that new code or code or product in contact with your users.

And so this is the idea that like developers continue to need to be involved for that test and production phase in order for the product to fully actually be delivered.

Nathen: Absolutely.

Adam: I mean, how do you think about that in the context of-- Is this something that you all have looked at from a data perspective or have talked about in terms of, when you do think about developer productivity or you know, efficiency or things like that, have you ever thought about asking this idea of like, the kind of post 30 days of deployment or, you know 30 days of release, is it like, how many fixes go in or how many, you know, like some type of metric that shows that like development is still engaged and involved?

Nathen: Yeah, I would say that we don't really do that outside of sort of our user centric questions around like, are you actually getting feedback from users, are you actually listening to it? And most importantly, are you actually acting on it? But I think one of the things, that center of gravity that we have around software delivery performance--

The whole idea there is based on the idea that you always need to change software. The minute you launch something new is the first minute that you get actual feedback and the feedback is inevitably going to be change this software. It's not going to be that direct, but that's going to be what has to happen. And then once you change it, you're going to learn something else and you're going to need to change it again and change it again and change it. We're never done with software. So we have to have this ability to ship it.

Adam: The other part of this is that, something that we've been talking a fair amount about of, with this notion of the third loop, is how do we start to think about observability in the context of user acceptance, user adoption?

Nathen: Yeah.

Adam: And how do we help people to understand the tooling and the methodologies associated with that? I've definitely seen things where you started to indicate, like, these are things you should be doing. Have you gotten to the point where you've taken a step further and started recommending tools or recommending actions that people can take to be able to become better at this?

Nathen: Sure. I would say that DORA never recommends tools. We are platform agnostic, so I don't do that. As long as you're using Gemini--

Adam: Haha!

Heidi: Haha.

Nathen: And Google Cloud and all things Google Cloud.

James: Chrome on the front end, some Flutter.

Nathen: Absolutely, absolutely. Sorry. The DORA hat fell off me for a second there and the Google Cloud employee hat popped on. Let me get rid of that now. Yeah.

So I do think what's fascinating here, Adam, and that you're uncovering, like, and this is where AI puts the pressure on the other sides of the software development life cycle. Like, we can build anything we want now. We can absolutely build anything we want. But what should we build and why should we build it, and for whom are we building it? These questions.

So, like, that whole product development side becomes much, much more important. And then, all right, so we shipped it. Did it do what we expected? And I think all of this is driving us to really revisit this idea that what we're doing is experimenting with every--

Every line of code that we write is an experiment. And we have to have that experimental mindset where we sit down and we come up with a hypothesis. We believe that by changing this feature, we're going to see user signups or activations increase. You can't know if that's done the minute you ship. You can't know until sometime later.

I was actually talking with Max Kanat-Alexander, you might know him. He spent some time at Google and then at LinkedIn, and now he's at Capital One running developer experience there.

But one of the things that he said in a talk earlier this week that really resonated with me, if you are a person that thrives on fast feedback and really understanding, like, how does the work that you do, like, how does it land? You should get into photography, not software development.

Heidi: Yeah.

Nathen: Because software development, like, the changes and the decisions that you make within software development take months, sometimes years, to really understand what are the ramifications of these decisions that we made. And if we're thinking only about, like, success is shipping, that's not success.

Adam: Right. Well, I mean, I think that you made an interesting statement just now and you said, "did it do what we expected," from the perspective of the developer builder. Right?

Nathen: Yeah.

Adam: And I think that this is something we've talked a fair amount about of, especially right now with like, generative AI tools and things like that, that are helping developers deliver code and changes faster than ever before. You know, like, there's so many--

Nathen: Sorry, I gotta push back on that. I think AI is helping developers build code faster than ever before.

Heidi: Oh, what's the distinction?

Nathen: But depending on how you're using it, it may not be helping you deliver code any faster. Depending on how you define deliver. And I would define it as in production.

Adam: What I would say is that I think that it definitely varies across the spectrum of, kind of people teams and organizations. But I would say that on the outliers of the people that are moving faster than has ever been moved before, they are in fact, delivering more code than they ever have before. But I understand your caveat.

I think that the question that we ask ourselves, and we've asked others on the show frequently, is that more code doesn't guarantee greater value. And I think that this is where we talk obviously in the book, about how do you build the right thing for the right people at the right time.

But this is definitely true for that notion of this AI acceleration or amplification that we've talked about. And it's really fascinating to me that the flip side of that is also true in the sense that if you're building in a way that allows for greater observability and visibility of how your users are actually interacting with your features and products, code paths, you actually now have an amazing tool from an aggregation and distillation perspective to be able to actually get deeper into the signal of what it is that people are getting value from that you're delivering.

And use that as a flywheel to be able to say, hey, look, we should be building more on this thing and being able to kind of like, help to focus those efforts. But we haven't necessarily seen that happening on the regular.

Nathen: Yeah, I would agree with that. I don't think we're seeing that happening yet. I think that it is a huge opportunity for us. And this is why, like, that observability and understanding how are the users interacting with my software and how does that inform the thing that I'm going to prioritize next, the prototype I'm going to build next, the small experiments I'm going to run next?

I think that that becomes super important. There has been research in the past, in fact, that looks at the viability of features, if you will. So if we put something behind, say a feature flag, how often does that new feature, how often does it provide value? How often does it net zero, how often does it decrease value?

In fact, DORA just published two weeks ago an ROI of AI Assisted Software Development. One of the things that we look at as part of the calculus there is of the features that you're shipping, how many are actually delivering more value to your business line or to your product? Right?

So a feature ostensibly might increase revenue, but how many of those features that you meant to increase revenue actually increase revenue, and by what percentage? And to be very clear, we don't know and it's very contextual. But we do provide a calculator that lets you take your context and put it in, take your assumptions and put it in and figure out what, what might that look like?

James: I think one of the interesting challenges that we're going to face, beginning to face, is that in fact, in this conversation as a whole, in the fourth trimester, in the third loop, in whatever language you want to use for, you need to get the product or service in the hands of users to really understand its value and perhaps know how it makes them feel or what the business value is, the revenue associated with it is.

The new challenge is that some of those users are going to be agents and we are now having to build for them. You know, we're seeing this with the, just the disciplines of DevRel are changing as we think about agent experience and, what is the role of markdown? How do we ensure that our docs look good to agents? We're going to be seeing a lot more of this.

I mean, my friend Rich Holman actually, he's just built a WordPress plugin designed so that it can take your WordPress instance and just make it much more supportive of markdown purely because, yeah, some of the users are going to be agents. And if we're if we're selling, doesn't matter what we're selling digitally, there are going to be agents out there helping their users to buy, build products and so on.

I mean, it's, it's a little bit early, but I do think that that, to my mind again, really supports the idea that you, you do need to be understanding the behavior of the system when it starts being under load, and, and you know, what is effective, what is not. The amount of pressure-- And again I talk about software delivery as a sort of a business process.

There is absolutely no doubt that agents are putting a huge amount of new load and strain on systems that were not fully designed for that. I think we've had some public disclosure from GitHub about that recently.

Adam: And we're talking not just little step functions, we're talking literally multiple orders of magnitude increase in the amount of traffic to and from endpoints.

Nathen: Yeah. I think I have two thoughts on this. First, James, you're right.

We are building things that agents are going to consume. But at the end of the day, any piece of software that we build is in service of other humans. There may be an agent that intermediates what we're doing for a human. But we have to understand and remember that we build software for people, people are the ones that use it.

James: A hundred percent. And I think that's where the observability and the analysis a nd the paying attention becomes even more important.

Adam: So question though, because like I was having this conversation yesterday actually with another colleague that you say that any software that we build is in service of humans.

Nathen: Mhm.

Adam: I would challenge you a little bit in the sense that I think there's an awful lot of software and frankly an increasing amount of it that is ultimately becoming middleware from a perspective of the end user. And like the one that came up in the context of this was, I've been in enterprise software for you know, almost 30 years in my career and have spent a lot of time advocating for paying attention to governance, risk and compliance as well as enterprise features like you know, dashboarding and reporting and the--

James: Wow Adam, you must be so much fun at parties. Haha.

Adam: I am the most fun at parties.

Heidi: Do you know what we keep in middleware? All the money.

Adam: But like this is the thing. If you think about it in the context of. Yes, it is. The outcome is in service of humans in some capacity. Right?

James: Yes.

Adam: But the way in which that outcome or output is being provided, it may not be in service of your humans at the end of the line to provide it in a shiny dashboard because what they really want is they sent their agent to go get it. The agent just wants the data and, ultimately it will present it in audio format because the person is driving at the time, or it will present it in a dashboard, but the dashboard is going to be blended or mixed with other data.

So having to cram your screenshotted JPEG into this other dashboard does them no good. So I do think that there is a change that's taking place in terms of the input-output mechanisms for a lot of our software. You know, you look at how people are using like OpenClaw or other claws out there where it's like, no, I do everything through my messaging chat on my phone now.

Nathen: Yes.

Adam: It's like, okay.

Nathen: So I do agree that there's a lot of middleware, that middleware, like it's in service of a human, the interface that you interact with that middleware with or that, that the interfaces that that middleware supports might not be directly used by a human.

Adam: Right.

Nathen: I still think it is important to understand, like, if I'm running middleware, I can't tell you how much reliability this middleware needs unless I understand how it's actually being consumed.

And so I think that what is happening is the interfaces are changing and some of the scale concerns certainly are changing. Right? The latency, just the amount of load that you're going to get from agents and so forth really, really is changing in ways that are very uncomfortable for a lot of people right now.

Adam: Yeah. I remember you know, years ago, I worked Signal FX in the early, early days you know, kind of one of the first, streaming monitoring, observability platforms. Right? And one of the things that we talk about was, sampling rate and what is actually useful to people.

And you know, obviously it had dependencies on, what it was being, what was being sampled, what the service was things like that. But I would argue that, like, some of this is changing because, what humans were able to look at a graph of and make heads or tails of from an observability perspective is different than what you potentially have with an agent.

Nathen: And I think on the positive side, anything we do to improve developer experience also improves agentic experience. The agentic experience maybe even accelerates the necessity to scale and improve that developer experience. But they're very closely related to one another.

But I think the thing that is very different now that is changing if we look beyond developer experience and agent experience is that you've got a whole new class of builders that are coming in.

You've got the business analyst over on the finance team who gets frustrated with the accounts payable system that we have internally. So they just go and build another--

Adam: Shadow AI?

Nathen: Hmm. Can you start using that? I don't know. That sounds really scary to me. But I do think I mean, I have a bunch of thoughts about this too, that I'll share. First, I think we need as organizations to be very clear about what sorts of applications does it make sense for that business analyst to go and build?

Is it something that that analyst is going to use on their own or just within their team that's never exposed to customers? And we have good guardrails around that. Great. Go solve your problem. Like, I'm not going to build you a dashboard. I'm going to give you access to all of our telemetry and a bot in front of it. You can go start asking the questions that you actually want answers to instead of looking at a dashboard.

But if we want to allow them to build something that they can ship to production. Boy, that sounds scary.

Adam: Well so I'm going to interrupt you just real quick and let you know there was a Wired article literally yesterday where they were actually starting to look into this of, the number of basically unsanctioned corporate applications with corporate data that are running on things like Lovable or Bolt.

Nathen: Yes.

Adam: Where people are just like, well, I just gave it my credentials. But it's publishing to an unsecured, completely addressable, you know, public website. Because they're just like, well, why would I put off on it? I gave it my credentials so, like, I'm the only one can use it, right? Well, no. Haha.

Nathen: Yep, yep. Totally, totally. And I ask teams all the time, like, what's stopping you from YOLOing that thing into production? And let's actually write down a list. That list is now your platform's roadmap.

The best leverage we can get out of software engineers right now is maybe enabling the business to build whatever they want and build it in a safe way that can be used where it should be used.

Kim Harrison: I like this.

Nathen: Right? And I think that it's wild and it's scary. And that analyst doesn't want to get woken up at 2am because the thing broke.

Adam: Or there was a data leak.

Nathen: Right. Or there was a data leak. Or what have you. But I think that this is, it's fascinating and we've like, let's be very clear, we've been down this road before, right. We've talked about citizen developers for a long time and low code and no code solutions and they haven't, I would argue, delivered on their promise and maybe this time it'll be different.

Kim: But wait, why would this time be different? What should we have learned before?

Nathen: I think the optimistic view of why this one might be different is because you can build faster, you can build more complex systems and software engineers as a profession already feel under threat. So if the AI is coming for my job, how do I make sure that my job provides the most value to my organization?

And this is where I think as a feature developer or an application developer today I stop building features, I stop building applications, I start building guardrails and harnesses that enable the business. I mean we've already mentioned on this show shadow AI and frankly I think we do ourselves a disservice when we talk about things like shadow AI because I think as technologists we tend to think of that as derogatory to the people that are building the shadow AI or the shadow IT. We've always been angry--

Heidi: Right. Like they're not professionals, like they're playing.

Nathen: Yeah, but what they are doing is they're solving their problem.

Adam: Oh, absolutely.

Nathen: Like, get out of the way IT, you're slowing us down. I can't solve the business because you're in the way, but I can solve it myself. So we need to partner with them.

Kim, to your question, like what do we need to do? We need to go have those conversations with them. We need to not scare them away from building, but enable them to build and help them and build the right collaboration and systems within our organizations that allow that to work.

Adam: Yeah. And I think that, depending on the organization, depending on the company, I think that what I've encountered is that it is less likely for an organization where someone feels inclined to do that to have the kind of top down buy in and prioritization to enable that behavior in a positive way.

Nathen: Yes.

Adam: And so I think that this is where things, kind of have always been the friction point. Right? Where like so much of the corporate systems that are put in place are there to gatekeep and control and the opportunities for feedback or change or outside going outside of process are intentionally limited.

So it's like I think that, I hear you, and at the same time, you know, having kind of lived in those environments on both sides of the equation, like, both on the side of, like, someone who was on the security team that was trying to figure out, like, how do we find all the servers at the time that were running underneath people's desks?

You know, trying to, realize that, like, this was a risk to the company. This was a risk to the way that we were able to provide security and provide integrity for customer data, for our own data, internal documents, things like that.

But how do you start to have that conversation? How do you start to, like, disrupt that type of behavior? I think that's something that's always been a struggle. But I think that to your point, like, with AI, the barrier to entry is dropped through the floor.

Nathen: Yes. Well, and here's something that I do know.

I do know that the way you change culture and the way that you align incentives is by changing how people work. And tools reinforce and amplify and shape culture. And then your culture shapes and amplifies and reinforces the tools and the tool choices that you've made. We have a dramatic change in the tools that are available to everyone right now. I think it is important that we use this moment to help move us all closer to the cultures and the incentive plans that we want within our organizations. We're going to use these tools as the excuse to fix our culture. but the reality is we're going to start working in new ways.

And yes, I have been accused of having a Pollyanna-ish view of the world. Of course, I think everything is sunshine and rainbows. It's all coming. But this is the hard work that we have to do right now is really increase collaboration, increase alignment and clarity, increase incentives that are driving the business forward and that are serving our customers. And we can't do any of that if we don't know who our customers are and if we, if we aren't getting closer to our customers.

And this is why I think things like Progressive Delivery and some of the observability that we've been talking about and the learning that we've been talking about are more important than ever right now.

James: We're done. Come on.

Adam: Haha! End scene.

James: Haha. Like, yeah, that's perfect.

Adam: I mean, yeah, I think that this is this is where we're all at in terms of, like-- I think the interesting part is, going back to, you mentioned the idea that software is never done. And you know, we all kind of looked at Heidi because this was one of Heidi's, kind of primary assertions that software is never finished.

And I think that this is where like the just doing things to get them done used to be so much about the kind of scarcity of resourcing and time that we had and the time that needed to deliver. And we're at now at a point of--

Heidi: Abundance.

Nathen: Mhm. We are at a point of abundance. But I also think that getting things done, like part of that relied on the definition of done.

Adam: Yeah.

Nathen: And a lot of that, a lot of that relied on what role did you like, what was your title within the organization? Right? I mean this was the birth of DevOps. Right. Done for a dev was it's committed to the version control system. Somebody else ship it, somebody else manage it in production. Right?

And so the other thing that Charity has talked about for a long time is this idea of software ownership. Right? So do I have ownership and accountability responsibility for this code after I've hit push?

Adam: And that gets into a whole different conversation when you start to think about this code was built by an agent. And you know like hearing more and more conversations from senior developers who are like, "well no, I trust my agent now. I don't write code, I don't read code, I don't review code. And you know, like I trust in my ability to define tests and specifications and validation loops using the tools that are available with the robots."

And what does that do for accountability? What does that do for, like it's one thing when it's like a little mistake like oh, like I accidentally made dark mode the default. Sure. Like no, no big deal.

But what if that's like a oops, I just you know, kind of deleted a production database or exposed a customer account information. Is there accountability there? What does that mean? And how do you start to like think about that, with the services that you choose as a consumer?

Nathen: And it gets more complicated because if we're getting good at shipping and we're shipping a bunch of small changes all the time, the actual ramifications of those small changes might not become apparent again for months or maybe even years. Like I expose customer--

James: I was honestly, that's what I was thinking about right now. I mean I'm thinking about the 240th trimester.

Nathen: Exactly.

Heidi: Or day 300. That' s what we've been saying.

James: Day 300. Yeah.

Heidi: Like, it works great on day one. How's it work on day 300?

Adam: Yeah, well, and like, I think that increasingly, you're hearing from folks that have only ever built social apps or web services that are, kind of consumer web services. They potentially are just like, what? No, code doesn't ever run that long. It gets replaced before that.

Nathen: Right.

Adam: And it's like, oh, oh, sweet summer child. Haha.

Nathen: But I do think that that whole, like you mentioned those senior engineers that have that high level of trust in their agents. Right? Trust is definitely something that you have to build over time. Right? And looking at the length of that feedback, like I can build a whole lot of trust if I'm getting feedback right away.

Like I can build a whole lot of trust in my lane keep assist in my automobile. Like it takes about a week. And then I start to trust that, maybe even more than I should. Yeah, maybe even more than I should.

And I can do the same thing with the code that I'm writing. I can trust the agent to write the code correctly very, very quickly. It takes operational experience to understand, can I trust the agent to write code that is going to for a month, for six months?

And in all of these scenarios that I never imagined, because that's always been the case. You ship software and it gets used in ways that are wrong. Haha. You're wrong user, you're wrong, use it the right way.

James: The user's wrong and they're still using it 60 years later.

Nathen: Exactly.

Adam: Yeah. We did a whole episode on unattended code usage. You got a favorite story in that regard?

Nathen: I don't have a favorite story. I do have a funny story that's somewhat related. So a while back I was working running web operations at an organization and I convinced the entire organization to move from Subversion to Git.

Heidi: Ooh.

Nathen: And Git was pretty new. And I was at best an amateur Git user. But I was the operational person, so it was my responsibility to migrate the repositories. So I did so. And it was beautiful because it took all of the Subversion history into Git. So you could look at all of the history.

I'm sure there was a flag that I did not set that retained not only the history, but also the author of every change. As a result, I am the author of every change from that moment forward. And so still to this day, it's been easily 15 years since I worked there. But still to this day, if you went and ran Git Blame on some of the production code, it would definitely point to me.

And it was probably code that was written before I got there. And I can virtually guarantee that whoever the original, original author was did not intend that that code would still be running today. But here we are.

James: They're sure glad that you're getting the support calls.

Nathen: Yeah, I'm sure they are. I'm sure they are. Haha. Thank God for Nathen.

Kim: Such a team player.

Adam: It turns out that even in the age of agents, discrete audit logging and discrete agent naming are still going to be a thing that we probably want to care about.

Nathen: Yeah. And we're going to relearn all the lessons that we've learned about healthy approaches to accountability and blame, and people are going to just start throwing agents under the bus, and we're going to start firing agents.

Adam: You're saying you need to have blameless postmortems with your agent?

Nathen: Yeah. I mean--

James: Absolutely, we need that just culture.

Nathen: We do need that just culture.

James: I mean, it wasn't really the agent's fault that it deleted the production database.

Adam: Probably not. Probably not.

James: They will say it was my fault.

Adam: Of course. Yes, humbly.

Nathen: Well, I mean, that happens in blameless cultures all the time. We go into a postmortem and someone's like, blameless. No, no, I pushed the button. Yeah, but it wasn't your fault. No, no, I'm to blame. It happens with humans, it is happening with agents. Absolutely.

Kim: I have one question to wrap this up. Who else should we be talking to?

Nathen: Oh, see, this is always a hard question, because I truly believe the answer is the people that we don't know. The people that we hear from a lot, and maybe I'm one of those people, they're good and, like, we see a lot of different things.

But I would rather go talk to the person that's doing a bunch of AI stuff and not talking about it publicly. Someone that's lost, like, deep in the enterprise and is making good progress, but doesn't feel like they are or doesn't feel like they have a platform to go and talk about it. My goal is to go find those people.

Adam: I need an intro to the AI stand mixer folks that are actually dominating the third loop.

Nathen: Why not? Yeah.

Kim: Well, Nathen, the DORA team has a community.

Nathen: We do have a community. So a few years back, we launched the DORA community because, frankly, on my team, we had three or four people that were talking with customers and organizations a lot about DORA, and we kept hearing a lot of very similar questions. And we know that we don't have the answers. And it's much better for us to introduce you to someone else who has the same question or is going through the same struggle and is maybe at a different point in that struggle.

So we launched the DORA community, and today it's got over 4,000 practitioners and leaders and researchers that are all coming together and doing the thing that matters most with research. And that's not that you do the research. It's not that you read the research. It's that you take insights from the research and you put them into practice.

And that's what the DORA community does. They try to take insights from the research, put them into practice, and then come back together and share and learn how that's going. I often say that you should not trust our research. Don't believe it. Don't believe the hype, but use our research as the hypothesis for your next experiment. Because context matters. And this is why we've built the DORA community and we come together regularly to share and learn with each other.

Adam: And this community is for anyone, right?

Nathen: It's for absolutely anyone. Yeah.

Adam: All right. We will put a link in the show notes for how folks can actually join and participate. I know that I've had the opportunity to be able to join for quite a few DORA community discussions, and I'm always glad that I did. I think that it's a great group of people, and I'm so glad that you and your colleagues continue to host that. It's a great resource.

Nathen: Awesome. Thank you so much.

Heidi: Thanks so much, Nathen.

Nathen: Yeah. This has really been fun and my pleasure. It's been great. I love talking to y' all.