Ep. #15, One Year of Progressive Delivery

Book Birthday and the Evals Question

Kim Harrison: And speaking of birthdays.

Adam Zimman: And speaking of birthdays.

Heidi Waterhouse: It's our book birthday. We wrote a book, and then it got out into the world, and people get to read it.

Adam: And then we kept talking about it. Because it turns out, all those things that we talked about in the book...

Heidi: I feel like our psychic powers were pretty on for this year.

James Governor: I think we did okay. I was worried. We were worried at one point during the book. It had taken a while to achieve takeoff, and then AI just started demolishing all of the foundations of the... Yes, Kim?

Kim: Not to interrupt, but what were we worried about?

James: AI. I think it was apparent, as we were writing the book, that the sands were shifting, the foundations were less clear. Any book that was not about AI and the SDLC, was it going to be relevant? To be fair, books in the age of the agentic SDLC is open to question because everything's changing so fast. But it turns out, I think, that if we look at the core of what we wrote, it is as relevant as ever for agents.

And in fact, there are areas, I've said this before, that it turns out that this world of evals, you really can't do evals without progressive delivery. Or even, evals are sort of progressive delivery.

Heidi: So unpack what you mean by evals here, because I think you're using it in a very agentic way.

James: Basically, being able to understand the behaviors of models in their harnesses, i.e. agents, that is something that you need to experiment with. You may need to do rollbacks.

They're basically modern unit tests. They're sort of unit tests for agentic software.

And testing is a big part of progressive delivery. And so if we're looking at evals, you need to close that loop. So you need to be doing observability. I think if we think about the things that we spoke about in a book, and observability was certainly a big part of that, closing the loop so that you could have good, useful, fast feedback loops.

Experimentation. How does this model behave in a particular context? How does an application behave in a particular context?

So I think that I've been super happy because I go back to the book and I'm like, well, this stuff is relevant. And it's nice to have written something that is relevant when you're going through the big change in this industry arguably ever.

Adam: I think one of the things that's interesting on the topic of evals that I've started to notice is that as their role has become and is continuing to change, I've seen more and more developers talking about the Third Loop.

Because not only are they thinking about it, from what I've seen more in the context of the end users, but developers, because of the way that they're doing evals, are becoming the user and are thinking about things in the context of, oh, I'm going to try this thing.

I'm going to do an eval of this new agent or whatever. And there's a feedback loop process that they're participatory in that is part of the adoption cycle, especially in the teams that are doing agentic development and trying to share within their team or within their org, there's a lot more conversation taking place on not so much the development and operations loops, but on the adoption loop. And that notion of feedback of, okay, well, how do we continue to monitor? How do we continue to observe and improve? How do we start to think about the optionality for rollbacks or roll forward in a way that used to be very, very tightly coupled to the end user is now becoming much more of an internal process.

The Core Concepts, One Year On

James: So I sort of ruined everything by talking about evals because I could have just said, look, let's look at the core concepts of the book. Okay, so alignment. That's word of the year, isn't it? And okay, it may be used in a very specific way by some people that seem to be kind of cult-like.

Heidi: A little cult-flavored.

James: But autonomy, 2026 was the year of autonomous agents. And we were writing about humans and how you could enable them to be autonomous. But all the discipline required to enable successful autonomy where you lay down intent and then allow the developer or the agent to go and build something, absolutely on point.

Abundance. There has never been more software. We're a little bit worried about abundance. It's a word that's got some sort of currency by some people that annoy some people.

But we were like, wait, this is what we're faced with. There is more software and more infrastructure than ever. Absolutely nailed it.

Adam: The one thing on abundance that I would say that I didn't see coming, but we probably could have, was we didn't talk anywhere in the abundance sections of the book about too much abundance.

James: Oh, we did. We did. We 100% did.

Adam: Remind me. Because that's the part that I want to be able to point to because I feel like it's the distinction between can I and should I.

Heidi: Abundance without alignment is overwhelm.

Adam: That's fair.

James: And abundance has a downside. Just because there's a lot of resources, that could be a problem, right? We use too many resources. So we've got all of this software, but alongside that, what is everyone worried about this year? Cost of tokens.

Adam: True.

James: Because abundance is amazing, but you do need constraints. And we talked about that.

Automation. I think you'll find...

Adam: That has become a topic, yeah.

James: There may be a little bit of automation happening. And if we look at the challenges of automation, GitHub, as a case study in the book, they've suffered. The automation, the scale that they were built for is struggling with the abundance that we are currently experiencing. And I think companies across the SDLC are in that position.

So the core concepts, and again, alignment, as I say, there is an AI meaning of that. But what we're actually doing, what we're talking about in any given sense is, are we using technology to serve the needs of humans? That is alignment, right? So maybe we should have just said how to do AI right.

But I'm very comfortable that the framework of the things that people should be intentional about thinking about how to build great products and services for humans, for users, and now agents, because they're going to be doing some of that consumption role. I think we did okay. These have been core discussions this year.

Hype, Tooling, and Process

Heidi: I think one of the things that I worried about when AI sort of crashed down on the middle of the book, which is really what it felt like, it felt like getting a wave fall on your head. A lot of what we were worried about was hype and not what was actually going to come out.

And I think that's a really important lesson for us to take. I was listening to a World War II biography like I do, and he's like, no battle report is ever as good or as bad as the first report.

And I think that's really true about how we talked about AI. It is neither as good nor as bad as we were told two years ago.

And all of our progress needs to be sort of mediated through that, okay, let's get more information before we really know how we feel about this.

Adam: I think another thing that has struck me in going back to some sections of the book was I feel like we tried really hard to talk about tooling. And looking back now, I'm just like, huh, how well has some of that stuff aged? The concepts and the objectives, I think that's where we started from. And I think that that came through and is still absolutely relevant, even more so.

But it is interesting to see how, as we got more specific about tools or explicit processes, those things are really shifting underneath, right? The tools that people are using, the tools that people are continuing to find success with are also really changing.

Kim: And I would add to this, what is a tooling issue, a compute issue, and what is a people issue? When is this actually process? And whatever we want to call that tool today and what it might become even in six months from now, how much of that is still just the people deciding what the process should be?

Adam: I think you're right. I think that there's absolutely that notion of tools should support your process. They shouldn't replace it. And I think that this is where it's been interesting to see how people that deployed tools and expected that to solve their challenges or problems are even more disappointed now than they used to be.

Heidi: I paid all this money for a tool that was supposed to do the thing. Well, you still have to know what the thing is. I'm sorry.

Adam: It's like what we talked about with Jennifer a little bit in terms of organizations that tried to move too fast with AI without thinking about their data layer first. And it turns out all they ended up with was more of a hot mess.

But I think that this is where so much of that notion of alignment that we talk about comes into play of not just alignment between the humans, but thinking about it from a resources perspective. How are you actually making sure that your systems can talk to each other and have awareness of each other?

Heidi: So I think that's an interesting problem because it's almost an automation problem. It's almost not alignment or even autonomy. It's almost just, what if we had APIs?

Adam: Well, in automation in context of, I go back to, I think that one of the best descriptions that I read about automation, and not saying she coined this, but I thought she explained it extraordinarily well, was actually Emily Freeman's explanation of automation in DevOps for Dummies.

I just thought she did a great job. She had some great examples. And ultimately what it comes down to is you can't automate a process that you don't understand.

And one of the things that I think a lot of people started to do or try to do with AI in the early days, and even now people are still trying to do this, is they're trying to get AI to do things in an automated fashion when they don't really actually understand the steps in the process or the components that are needed to be able to bring together. And I think that's where things go off the rails pretty quick.

James: Oh my God. We're just in an era of going off the rails, which is why you need some focusing principles to help you maintain some focus. You should read this book called Progressive Delivery and it might help you.

Abdication, Abundance, and Security

Adam: I've also been thinking about the brief part that we put in the book around responsibility, or the notion of delegation versus abdication. And this is something that I'm trying to figure out how this is going to resolve. Because this is something that I think is coming up more and more, where we are increasingly abdicating to AI, especially when things do go off the rails. And it's like, oh, the computer did that, so it's not our fault.

Heidi: Yeah, sorry we rejected 90% of those health insurance claims. It was the computer. Who programmed the computer? Angry goose.

Adam: That's one that I think is going to be an interesting topic of conversation in the year to come. I think that there's definitely going to be some continued, unfortunately, harm done in that capacity.

James: Well, they should make us god emperors. And then things might be good.

Adam: I'm going to destroy the world, so someone should stop me. Please stop me.

James: Yes, that view of alignment is quite weird. As I say, for me, especially things like really thinking through abundance.

Just because you can doesn't mean you should.

We've had all of these discussions this year about, and as an alignment question, we can joke about unfettered access to models and what that might mean and whether that's a good and bad thing. Do I think that a model... enough of the P-Doom already. But on the other hand, there is absolutely no doubt.

Again, okay, let's look at abundance, upside, downside. Abundance and security. And what the models have done in terms of new approaches, what's the progressive delivery of modern software, right? In making it secure.

Heidi: Given enough agents, all security is shallow?

James: Well, certainly being a maintainer at the moment really sucks. Absolutely. But questions about when we as customers accept software, security is raising all sorts of issues from that perspective.

And I think our security will get better in the longer term. But in the short term, the spike of CVEs, the spike of vulnerabilities is absolutely brutal. And that does change your posture vis-a-vis.

Historically, in the book, we write, oh, wouldn't it be great if the user could decide when they adopt the new software? That's something we probably missed in the book. We didn't write enough about older versions of software, maybe insecure.

Adam: I think we mentioned it. I think that the biggest shift that we didn't see coming with AI or talk about with AI was not only that the older versions might be insecure, but the ability for exploitation was becoming cheaper and cheaper.

Heidi: Sort of like the rainbow tables moment.

James: Tell me more. We don't know about that. You better tell us about the...

Heidi: Oh, okay. So it used to be, and this is a dim memory, but it used to be harder to crack some things, and then somebody published a bunch of tables that basically cryptographically, there were predictable patterns in some kinds of cryptography. And so you applied a rainbow table to it and it was easier to access than the people who had built it had expected.

Adam: I was thinking about, you talk about the influx and CVEs, and it's not like people in security will tell you that they've always been there, right? And that it was just more function of, did we know about them, or were they published, or were they actively exploited? But I think that the rate of being able to discover and the scope of the bugs that are being discovered and exploitations that are being discovered is also just gone this crazy acceleration. Even users who want to stay up to date are struggling.

I think about it in the context of, this goes back to our initial thesis that software is now everywhere, right? And are you actually paying attention to updating the software in your home automation or in your refrigerators in France?

Heidi: Or South Korea, which, Samsung attempted to do an update and it bricked a bunch of computers right before New Year's.

Adam: The one last night, apparently, or two nights ago, there was hackers that hacked into supermarkets across France and turned refrigeration temperature up to 50 degrees Celsius for six hours. Well, that'll do it. And I was just like, okay, who thought that their refrigeration system was going to be the subject of a hacker attack a few years ago? That wasn't in my dance card.

Heidi: Well, and I think that one of the other things is the human factors of security. It is now trivially easy to imitate my voice on the phone and get money out of my parents. It used to be the joke about whether you needed normal security or whether Mossad was after you.

But we're all operating at a level where it is so much more than we expected even two years ago because it's easy to automate this kind of attack, this sort of personal phishing attack. Spear phishing used to be reserved for executives and now it's, hello, everybody.

Tastemakers, One-Shots, and Fin

Kim: A question I wanted to ask the group is, in the past year, AI was a surprise to us. We had to quickly throw that into the book before we published. And then we knew we were going to work on this podcast, and it was going to be about the Third Loop and delivering value to users and how do you do the Third Loop, right?

And we've been rather obsessed with AI this whole year. And one of the things that's come up in the question of using AI and knowing that you're delivering value is how do you use it right and how do you know what good looks like? What is the place of the person? Because there's so much that can be automated, but there are elements that AI can't do. And that's been an exciting journey for many people.

And the fact that people still probably are very necessary, at least today, and I think will be for a while.

And the expert of tomorrow will be a tastemaker, will be somebody who knows what good looks like.

James: I think you're right. So one of the things, just the whole question about do we jettison everything we knew about developing software because the models are so good. And the obsession with one-shotting everything. Let us one-shot it. Why do software engineering when you can one-shot it?

Adam: There's an interesting, I think, distinction between the, I know nothing about the problem and I'm going to just one-shot it versus some of the stuff that we talked about with Chad Fowler, which was the idea that your software should be able to be dynamically generated based on a specification that's built up over time.

I think that the idea that you can do a one-pass generative development on a well-defined specification for a tightly-scoped piece of software, you could still call that a one-shot because you're only asking one prompt, but it's completely different than you saying, I know nothing about this problem space and I want you to create an application that's going to build a robot that's going to take them to the moon.

James: Very fair. We could get back to that.

Progressive delivery and specs. But really interesting presentation recently from a company called Fin. They used to be called Intercom.

So basically, customer service. Historically sort of multimodal customer service. It didn't matter whether it was a phone or SMS or whatever. Great company. Anyway, they become completely AI-pilled.

And so what they were talking about, some really interesting things. So for example, no code change, no pull request, can be more than 150 lines of code. Now, they do use models to decide, is this something that needs to be looked at? Or can we let it through the system more? So they're using models for verification, but they still need to be 150 lines that they're verifying, as opposed to just some huge blob, but also then all sorts of interesting questions in human factors.

So they were doing progressive delivery in order to understand the efficacy of the models. So their SDLC bot is called Shrek. So let's think about false positives. From a cost perspective, when you're using as much AI as they are and your developers have set out intent, the agents are off doing work, they are doing these code to be checked in and verified by agents and see whether it does require a developer to look at it or whether we can just ship it through the system.

Interesting things, they run experiments. And so, again, really back to this question of evals. What they would do, so for example, oh, wait, we could use a cheaper model. We could use a cheaper model to look at the software that you get maybe either the same model or maybe one of the models is really good at building software, but actually one of the cheaper ones can go through the process.

Then they would discover that, oh no, in fact this cheaper model they were trying was creating far more false positives that was making the developers really unhappy. So then they rolled it back. You've got to go back to the other model that you were using because your new model was creating too many false positives. So I think in the interplay, they measure everything. So as they look at how they can, they are all about continuing to do software engineering, and they're certainly around experimentation, the use of rollbacks, fast feedback loops, observability is all part of this.

Fin is 100% using progressive delivery in rolling out the models so that they can support the developers in doing their best work for the customer. And I just keep seeing this stuff all the time. It's exciting.

Heidi: That is exciting, and it's so clear how closing that Third Loop makes you responsive in a way that we have to be. We cannot wait until the market speaks because that's such a lagging indicator.

Adam: Yeah. Especially now, right?

Controlled Delivery and Software Factories

Okay, so it's the birthday party. And I think one of the things that post-writing the book that has been very good this year is having had a slight fallow period. Heidi is gainfully employed. How is that?

Heidi: That's gone really well. It's very interesting because I'm getting to work on progressive delivery concepts. I have a blog post sitting in the queue about controlled delivery, which is how do we know that we are sending out what we think we're sending out? Because that's something that's sort of been evolving.

When we had shrink wrap, people either bought it or didn't. When we had SaaS, we started knowing who was doing it, but we haven't really thought about whether people are using all the features and whether we track that. And controlled delivery, with feature flags, with all of our delivery tools, gives us the ability to say, I don't want to send it to these people because they're not ready for it for whatever reason, software or whatever. Or I want to send it to this group.

And we started talking about that as a feature flags concept, but I think it's bigger than that.

I think it's more important to say, how are you controlling who gets which features?

James: So policy-based progressive delivery, in effect. Cool. So Adam, even you have a job. How's that?

Adam: I've had multiple. Look, I think that it's been interesting. The group that I'm with now has been in the midst of all the things that are cutting edge of trends in AI, but not working for frontier model provider that is playing that game, but thinking about it of, how do you make people successful? What are the needs that a team that is building with agents and doing agentic development need from an infrastructure perspective? And how are we able to really facilitate this notion of humans working with robots?

Thinking about it, what's that interface layer need to look like? Both from the robot side of what are the spaces and primitives that are needed to be able to provide agents the ability to get work done, as well as from a human side, what does that interface layer look like? What are the things from a tooling perspective, from a visibility perspective, observability perspective that humans need to be successful?

And one of the things that's really been interesting for us has really been starting to think about also, what does this start to look like for not just individual human with multiple agents, but as we start to think of teams of humans, organizations of humans that are doing development? We have some really interesting customers that are using us as their software factory, right? And what I mean by that is that they're basically saying, hey, look, we have a set of humans that are traditional developers that are actually building tools and building, maintaining a portal for other builders to come in and actually build applications.

And this is a really, you think about it, one of our customers, got a quote from them the other day that said that you're like the Lovable for an enterprise. And I was just like, I'm not sure that's a good thing, but you seem to think it is. And you're growing really well. So your end customers seem happy, but they have this idea where they want to enable what we've talked about with progressive delivery.

How do we enable the people that are closest to the problem to be able to articulate and build the solution? And whether that was through mechanisms like feature flags where we could say, hey, look, let the features be accessible to the humans that need them. But it's also now, forget about those features having to be built by some engineer that's two, three degrees removed from it.

What if you can actually enable the end user to be building those features for themselves? What does that start to look like? How does that start to change what we think about as software delivery, when you can have, we've exposed our agentic harness in some of our applications, right, where you can actually click a button in the corner and say, I wish that this feature acted like this, or I wish that I had this feature in addition to be able to map to my workflow or the way that I think about this problem. You wait five minutes.

Heidi: So how do we even call those features that we release? That's a really interesting swamp.

Adam: Well, the crazy part is you wait five minutes, it comes back, says refresh your webpage or refresh your app, and it's there. And so the challenge that we're starting to confront is, well, what does this mean from a perspective of deviation?

I remember years ago, I wrote a blog post comparing feature flags to choose-your-own-adventure book. Right? And now it's a function of, OK, well, what if those adventures are being written by the reader as opposed to predefined by the author? And what does that do to your narrative? What does that do to the scope of your application?

Heidi: What does that do to your ownership? If other people are writing their own choose-your-own-adventure, how is that my book?

Adam: And in some cases, it may not be, right? But in other cases, you say, hey, look, I want to constrain what maybe a user can do from a compliance standards perspective. If you've got a banking app, it may be okay if you want to change the way your dashboard looks. But it may not be okay if you want to change the way that money transfers.

Right? And if you're in healthcare app, you may want to change the way, again, that you do alerting, but you can't change who has access to patient data. So I think that there's definitely some constraints that can be put on this, but it's been really fascinating to see how this notion of the choice or decision point is, honestly, Heidi, to your vision of this democratization or full delegation of software development, I'm starting to see it actually happen. And that's crazy.

Software That Happens to You

Heidi: It is. And I think much like the literacy that I used as an analogy for this, it's upsetting a lot of structures of power. And that's really both interesting and terrifying because we keep those structures of power around for a reason. They might be a bad reason, but it's a reason.

Adam: Well, it's like Stephen's book about Kingmakers, right? And I think about this all the time of how many times have we had in this past year the conversation around who is a developer and what is the distinction between a builder and a developer, and what is a software engineer? I think that there still absolutely is a difference, a distinction in the way that individuals think about problems or the layers that are needed to be able to get to a particular outcome.

But I do think that we have changed the way in which people can interface with computers. And for many people, they have no interest in going back.

Heidi: It goes back to something that I was interested in a long time ago, is that there are people who consider computer slash software as something that they can manipulate, who consider it their tool, and there are people who consider it an environmental thing. Software is the thing that happens to them.

And I honestly think there are a lot more people in the software is the thing that happens to me camp.

And we just don't talk to them very much because obviously we hang out with people who think software is the thing you do. But I wonder how it feels to be that person and somebody says, well, now you can make your own software. Why would I want to do that? Software happens at me. I don't have an interest in that.

Adam: It's funny you say that because we were having a conversation that came up at work the other day was this notion of a product that we need to exist. And we're not sure that we're the ones to build it, but we were all agreeing that we are the tech support, IT support for our families and extended friend groups oftentimes. And wouldn't it be nice if there was a way for us to, using the robots, have a little bit better control and visibility and preemptive ability to be able to avoid disaster for friends...

Heidi: It just leaps in front of the button and doesn't let you buy that printer?

Adam: Or is capable of doing systems management and security, vulnerability testing across your parents-in-law or parents' systems to make sure that they're secure and they're not being phished. Or you're paying attention to the random IoT components that they've installed in their home to make sure that they're being updated, or that the batteries on their locks are being appropriately kept refreshed. All the things, right?

Heidi: That would be both amazing and, as a vector for abuse, incredibly terrifying.

Adam: Absolutely. And I think that this is true, I could argue that this is true of so many technologies, right? But there is definitely this increasing divide with this accelerated rate of change that we talked about in the book, we talked about over the past year, where there are a lot of people that are being left behind.

And there are a lot of people that are being disenfranchised. This is something that we've talked about. And so is there a light at the end of the tunnel that we can look to that is not an oncoming train, but is actually technology helping to solve these challenges?

Slop, Signage, and Taste

Kim: We're also seeing people using, as you mentioned, using technology. I'm in this small rural beach town and there's mom and pop cafes everywhere and hotels that are using AI. You've got 50-something-year-old grandmas running their own cafes, making new menus and signage, and they figured it out.

James: Please don't use it for fucking signage.

Kim: I know. And my niece here commented, I know what's AI because they all have the same font. They all have the same color scheme. And she's 20 and she hates it. She's like, oh, this is so uncool.

Heidi: And the aesthetic is so toxic to some people. So I was looking at embroidery patterns for Carolyn and she said, oh, that one's slop.

And I'm like, no, I can see it printing out. It's fine. She's like, yeah, but it looks like slop. I'm like, huh.

Kim: As a writer, I am angry that the AI took my em dash. I use that. I have been using it. It learned from us. Some of the slop was us.

Adam: And we've talked about this as well. It's like, AI obviously looks like it's doing such an amazing job on all the things that you were not good at. And I think that this is, on the one hand, I hear you, James, that using AI for posters is horrible. You look at it from the perspective of...

James: No, no, I know, but it is horrible. People... Come on. Listen. We...

Heidi: Take a picture of your food, please.

James: Ah, yes.

Adam: You say that, but as a photographer, the number of bad photos of food that I've seen on a regular basis is horrible.

James: I know, but look, there's no excuse for that. Not in an age of digital abundance. Just keep snapping away with a decent Pixel or iPhone, and you'll get your results.

Kim: Okay, to be fair, in the OG days of Instagram, same thing happened. There was a lot of crap photography, and we got to the other side of it.

James: Okay, fine. But if you go into a restaurant that has on the front of the restaurant pictures of prawns, and those prawns have heads at both ends.

Heidi: Which is totally a thing, yeah.

James: Then, I don't know what to tell you, man.

Adam: Hey, I agree with you there.

Kim: I promise you that would never happen here. This is a fishing village. The fish do look accurate.

Heidi: Right, but how do their burgers look?

Kim: They're good at burgers, too.

Adam: Right. But I also think back to the evolution of software and computers as tools for imagery, period. And we've definitely gone through peaks and valleys of new tools coming out. Whether it was clip art, whether it was Print Shop Pro, whether it was, where all look same, right? Everything was, oh, you've obviously thought about this enough to get the new technology, but you didn't think about it enough to actually recognize that this is part of your brand or this is part of your identity.

And then we come back around and there start to be professionals that use these tools and are capable of being able to create uniqueness and true design. The same way that a software engineer is going to say, hey, look, I can use AI and still create good software. I have seen and I have recently been working with designers who are using AI to create truly incredible designs, and they're just like, look, I'm doing this in a way because I understand the same way that a software engineer...

James: It's what you said. It's exactly the same pattern. It's exactly the same pattern. But I'm so triggered by...

And I'm not the person in my family that is, I'm an AI lover compared to my daughter. If she knows I've gone anywhere near AI creating image, then I'm not her father.

Kim: The kids are not impressed. No, that's a really good point, James.

Adam: I think that also it's landing different with the kids in the sense that I think a lot of their media is being directly impacted by it. And so they're very sensitive to it. I also think that for kids that are in the teenage to mid-20s, they're looking at it and being like, this is ruining everything that I was led to believe would be, like, career path.

James: It would be nice if we could have a job at some point.

Where Do Juniors Learn?

Kim: Okay. So that's another question that came up in some of the discussions. How does this technology change the way that people work? And what does this look like for people at different stages within their career path, whether you're in university and learning? In fact, somebody recently recommended we should go talk to a professor.

So whether you're at that beginning point and you're learning, or you're an expert, or it's your first job, first week on the first job. How do you get started? Where is there space for you if we're automating pieces away? How is this shifting things? Not surprised that the kids are a bit miffed because it's ruining their first years out in what could have been an exciting career path.

Adam: 100%. So many organizations are also at this place where they're just like, we're not going to hire junior people anymore.

Heidi: We only hire seniors, yeah.

Adam: And it comes back to this conversation we started, right? They don't know what good looks like. The interesting conversation on that side is, how do they learn?

It used to be that so many of us learned because we ran full tilt into a wall that was our failure. And it's like, oh, we learned that lesson. That's not good. Let's try again.

But that notion of learning, just the neuroplasticity and learning through failure, is so much more valuable than learning through success. You don't learn through success, you learn through failure.

So I think that this is one of the huge challenges that I see for people that are coming into the workforce, especially in tech, is that there's a lower and lower willingness to tolerate things that aren't good and an expectation that you're going to be able to figure out what good looks like much faster without any type of training or mentorship or anything like that. And again, the answer, of course, is Progressive Delivery.