The Change Resilient Podcast Episode One: John Allspaw and the Foundational Essence of Software Resilience
Listeners, you will love this episode. Right out of the gate we interview one of the world's leading thinkers on software resilience, resilience engineering, and human factors.
John Allspaw is a founder of the Resilience in Software Foundation and a principal at Adaptive Capacity Labs. He previously served as CTO of Etsy, where his work helped shape many of the practices that became central to the DevOps movement.
John’s landmark 2009 talk with Paul Hammond, 10+ Deploys Per Day: Dev and Ops Cooperation, helped change how the industry thinks about the relationship between development and operations. John is also the author of The Art of Capacity Planning and Web Operations, and holds a master’s degree in Human Factors and Systems Safety from Lund University.
More recently, John’s work has focused deeply on resilience engineering, adaptive capacity, expertise, and how people actually make complex software systems work in the face of surprise and uncertainty.
Listen on Spotify and wherever you enjoy your podcasts.
Links from show references below:
Resilience in Software Foundation
Latent Risk from Auburn University
Show transcript:
INTRODUCTION
[00:00] Steve Semelsberger
Hello, everyone. Welcome to The Change Resilient podcast. My guest today is John Allspaw. John is one of the most influential thinkers at the intersection of software engineering, resilience, and human factors. He's a founder of the Resilience in Software Foundation and a principal at Adaptive Capacity Labs. He previously served as CTO of Etsy, where his work helped shape many of the practices that became central to the DevOps movement. John's landmark 2009 talk with Paul Hammond really helped change how the industry thinks about the relationship between development and operations. John is also the author of The Art of Capacity Planning and Web Operations, and he holds a master's degree in Human Factors and Systems Safety from Lund University. More recently, John's work has focused deeply on resilience engineering, adaptive capacity, expertise, and how people actually make complex software systems work in the face of surprise and uncertainty. John, it's great to have you. Welcome to The Change Resilient podcast.
[01:01] John Allspaw
Thanks for having me. I'm honored to be here.
[01:04] Steve Semelsberger
John and I just spent a few minutes talking about skateboarding. He's wearing a Mike McGill T-shirt, for those of you of the era. He and I are similar. It's really been fun getting to know John and immersing myself in his work. It's super important to things that I think a whole lot about. John, for many years you've helped people distinguish resilience from things like reliability, robustness, and failure prevention. If you look at the moment we're in right now—we're recording in late August 2026—what do you think the software industry still most fundamentally misunderstands about resilience?
WHAT RESILIENCE REALLY MEANS
[01:42] John Allspaw
It's better. The situation is better than it has been in the past. As many listeners probably know, naming turns out to be a hard problem. There's a colloquial definition of resilience—the way the term is typically used outside resilience engineering—and then there's the technical meaning. I think what people typically do is see resilience as what a colleague of ours used to call "reliability++": there's reliability, and if you say resilience, that must mean something even more awesome.
[02:38] Steve Semelsberger
Object-oriented reliability.
[02:41] John Allspaw
It does have a cachet. The term has both a colloquial meaning and a technical meaning. And there's nothing worse than being introduced to a community where all you hear is, "You're saying that wrong, and you're saying that wrong too, and are you sure you should be here?" That's obviously not what we want. But resilience does mean something different. What most people are describing is what resilience engineering would call robustness, which is a huge part of software engineering: putting things in place to mitigate or avoid situations we know are plausible. Timeouts and retries make systems more robust for particular conditions. Resilience, by contrast, is about the things you cannot anticipate—or situations you thought you anticipated, but whose details unfold so differently that you might as well not have. It's the unanticipated part. And that's hard for engineers. We want to make things that help people, and then we want to make sure those things keep helping people, so we fix things. It's like conversations with people close to us who may just want to vent. If you're like me, there's an almost invisible desire to turn the conversation into a problem statement so you can help. And they're saying, "No—just listen. I'm not asking you to fix it."
[05:30] Steve Semelsberger
I had that moment with my wife, John. We've been together 28 years.
[05:34] John Allspaw
Exactly. I think we're a bit addicted to fixing things because that's where we get satisfaction and reward. So it's difficult even to conceptualize that there are things that will happen that you cannot imagine right now. That's scary because it cuts against something deep in the ethos—the soul, maybe—of an engineer.
[06:15] Steve Semelsberger
Yeah.
[06:16] John Allspaw
Logically, on paper, we're human beings.
[06:18] Steve Semelsberger
Control as well, too. We love that.
[06:20] John Allspaw
Yes, exactly. The instinct is: if something unexpected happened, you must not have thought hard enough or prepared enough. And if you're the only one with the skills to deal with it, everything feels like it's on you. Anyway, that's my hypothesis for why this is so difficult.
[06:39] Steve Semelsberger
Now, this is the kind of stuff we like to talk about on this podcast.
[06:42] John Allspaw
Okay, all right.
[06:43] Steve Semelsberger
So feel free to follow the rabbit holes if you'd like.
[06:45] John Allspaw
I'll tell you that my colleague Dave Woods—there's a story. I want to say 2024 or 2025, I believe, at SREcon. There was a discussion track, and David Woods, who's certainly one of the chief troublemakers who spawned resilience engineering around the 2003 era...
[07:17] Steve Semelsberger
John, if you're an OG, he's an OG++.
[07:21] John Allspaw
Oh, I'm not even an OG. I'm a hanger-on. But Dave was leading a discussion, and Thai Wood, who works at Xero and is part of the Resilience in Software Foundation, I believe, asked Dave: do you regret calling this field resilience engineering? Because it's got some difficulty, right? I can't remember exactly what Dave said, but I was thinking about it, having played a part in continuous deployment. I didn't coin DevOps—that was Patrick Debois—but I remember saying to Thai, I don't think it would have mattered. He could have picked a different word, but there are all kinds of contortions made of terms that get made up. He could have called it adaptation engineering, which would not be terrible—not ideal—but that would have been hijacked in some ways, too. So I feel like this might actually have been the best choice, and it still got a little confused.
[08:55] Steve Semelsberger
If resilience engineering isn't about robustness, is the essence of your work with the Resilience in Software Foundation about adaptability—about what you write about as preparing to be unprepared? You've touched on that a couple of times.
[09:14] John Allspaw
Yeah.
[09:15] Steve Semelsberger
The sociotechnical approach is about letting go of some things and emphasizing other things that better equip us to step into the unknown.
[09:24] John Allspaw
I'm grateful for the multiple bits there. You started with the premise that resilience engineering is about robustness; it's actually not at all. Resilience engineering is really about everything that allows, enables, encourages, supports, expands, and augments adaptation to unforeseen events—and adaptability, the capability. I'll get to where you're going, but let me take a little detour.
[10:08] Steve Semelsberger
Good. I'm glad you corrected me. I wrote down robustness, and I think that was actually your anti-definition from before—I led you there.
[10:15] John Allspaw
Yeah.
[10:15] Steve Semelsberger
What do people misunderstand today? I'm really glad you're putting your finger on that.
ADAPTIVE CAPACITY: POTENTIAL VS. EXPRESSION
[10:19] John Allspaw
You can think about adaptive capacity using the high-school-physics idea of potential energy. If I lift this water bottle, it has more potential energy than it did before. Think of a ball at the top of a hill or a stretched rubber band: the potential is there, but it isn't active yet. When you let the ball go, that potential becomes kinetic energy. Adaptive capacity is similar. The idea wasn't born in resilience engineering; it has roots in fields like ecology and biology. Adaptive capacity is the potential to adapt. It is not the adaptation itself. When that capacity becomes active, we can think of that as an expression of resilience. In the analogy, resilience is kinetic energy and adaptive capacity is potential energy.
[11:44] Steve Semelsberger
Yep.
[11:44] John Allspaw
Right? So then, bear with me here. It'll be worth it. I don't know, you're in Austin, right?
[11:51] Steve Semelsberger
Austin, Texas. Yes, indeed.
[11:53] John Allspaw
In some parts of the country, what I'm thinking of is called a go-bag or a bug-out bag. If there's an emergency, it's a bag with supplies you might need. You grab it and go. Do you have one, or are you familiar with what I'm talking about?
[12:22] Steve Semelsberger
I do not have one. I was loosely familiar, and now I'm following you, so keep going.
[12:27] John Allspaw
Ever since Hurricane Sandy, I think a lot of New Yorkers are more familiar with the idea. A go-bag in my family is basically a reasonably large backpack with things you might take camping: matches, a knife, a magnifying glass, one of those hand-crank radios, batteries, screwdrivers, a couple of tools, water, snacks. We're big Clif Bar fans, so we keep Clif Bars in ours. The point is that you're preparing for a situation in which you may never use any of it.
[13:34] Steve Semelsberger
Yeah.
[13:35] John Allspaw
It takes a non-zero amount of energy and money. It's an investment of time, energy, and attention. If we're out of Clif Bars in the kitchen, I don't go raid the go-bag. We don't want to erode the resources in that bag. And many of those resources have multiple uses. A trash bag can also be a raincoat.
[14:12] Steve Semelsberger
There you go.
[14:13] John Allspaw
A screwdriver can also be a weapon. A magnifying glass can be a fire starter. Many things in a go-bag have multiple uses. You can't easily justify the money, time, and attention economically because you can't say exactly how those things will be used or what the return on the investment will be. The go-bag represents potential. When you need it and draw upon it, that's an expression of resilience. That's something quite particular to resilience and adaptive capacity. I don't know if that helps—it's still an analogy.
[15:20] Steve Semelsberger
It does help. Let's push it further, because I really like this idea of preparing to be unprepared—and the go-bag analogy.
[15:26] John Allspaw
Yeah.
[15:26] Steve Semelsberger
Those are factors we have as humans. What if we extend this to the organization and think about conditions within an organization that might increase adaptive capacity—this preparedness to be unprepared? What sort of organizational conditions can facilitate things like this?
BUILDING ADAPTIVE CAPACITY IN ORGANIZATIONS
[15:46] John Allspaw
Demo days. Lunch-and-learns. Architecture reviews. Any place where vicarious learning can happen—where you can understand something differently through someone else's experience. Code review is probably the most common and most studied example. Game days and chaos experiments can play a role too. Those are activities, though; you asked about conditions. We worked with one client that had multiple Git repositories spread across the organization. For the most part, anyone who was on call had access to nearly every repo. That had simply always been true, so nobody thought of it as a special capability. But in incident analysis, we saw responders constantly move across systems: "Maybe it's this. Let me look over there. No, maybe it's that." Broad access let them explore. If, in the name of compliance or security, you changed that so people could only access their own repos, you might unknowingly make adaptation much harder. That's the point: organizations can easily erode things that represent adaptive capacity without recognizing them as adaptive capacity. Historically, resilience engineering has often started with the idea that the capacity is already there—what my colleague Richard used to joke about as "the resilience is coming from inside the house." The first challenge is to identify those sources of adaptive capacity, then support, expand, or augment them. The other direction is more deliberate: introduce a new activity, intervention, or resource specifically to support adaptation. Both are forms of resilience engineering.
[20:46] Steve Semelsberger
Really cool. John, when you were talking about the go-bag before and the items in it, I don't recall if you mentioned a map. I'm of the age...
[20:55] John Allspaw
Oh, yeah.
[20:55] Steve Semelsberger
Before graduate school, I got into my 1991 Ford Explorer and drove 8,600 miles around the country. In 1995, doing that required copious paper maps. So I was thinking about the map, the go-bag, and the equivalent of a map for an engineering team. We talk about runbooks and playbooks. Are those kinds of maps? How would you extend the map concept to resilience and a moment of need?
[21:32] John Allspaw
A map helps you get where you're going, orient yourself, and infer things you may need along the way—gas, a bathroom, food. Those are anticipated needs. A map might also become a fire starter in an emergency, which is a use you didn't originally design it for. But it won't help with everything. A spare tire is an even cleaner example of robustness. A flat tire is plausible enough that we devote trunk space to carrying a spare. We don't carry a spare steering wheel because losing one is much less likely. A spare tire is preparation for a known class of problem. But there will always be situations where the spare tire doesn't help at all. The idea that we can prepare for everything is a fallacy. Things that have never happened before happen all the time.
SIGNALS, INTUITION, AND EXPERTISE
[23:32] Steve Semelsberger
Let's have fun with this some more. Last night my youngest son had his first high-school football game. He's a freshman on the B team—there are three freshman teams; that's how big football is here in Texas. We drove about two and a half hours from Austin to a town outside San Antonio. On the way back, around 8:30 at night on Interstate 35, a sensor told me I had a slow leak in one tire. I had to decide: pull over and change it myself, call for help, or add air and see how long I could go. In software, we also have earlier signals that may tell us something is going on before alerts fire, thresholds are crossed, and the observability or incident-management tools light up. Is there something analogous that helps us make earlier decisions about remediation and action?
[24:35] John Allspaw
What happened with the tire sensor is that your attention was directed. In cognitive systems engineering—and also in resilience engineering—we'd call that directed attention.
[24:53] Steve Semelsberger
Yeah.
[24:54] John Allspaw
If I step back from the specific sensor and interpret your question at a higher level, think about a company you've been at for a while. Most companies have people where, if something strange is happening and nobody quite understands it, everyone knows who to go talk to. "Go ask Sylvia." That name often isn't written down in a wiki; it's informal, but it's real. And people remember because Sylvia knows her shit. If Sylvia doesn't know, then we're in trouble. That comes from experience. An expert may have an intuition that a particular subsystem is on the precipice even without a clean piece of evidence. Maybe it gets through the next holiday season, but after that something needs to change. Those experts often don't look at the runbook because they wrote the runbook—and they know what not to pay attention to in it, because the runbook was written before this exact situation existed. That intuition can be very productive and often well calibrated. I had a Volkswagen and knew a master mechanic who could open the hood, listen for a moment, and tell me, "It's your valves." He couldn't see inside the engine. He knew because of expertise. That's the same thing Sylvia is doing. Expertise isn't all of adaptive capacity, but it's involved in almost every form of it, especially in recognizing when and where to draw on the capacity you have.
[29:04] Steve Semelsberger
Intuition was based on experience, coupled with data. By the way, my oldest son and I have a project car that we don't mostly work on ourselves. It's an E30 BMW with what's called an S52 engine swap, so it's the next-generation 3 Series engine. It's a Frankenstein of a car, and our guy is Paul—and Paul knows how to listen to it.
[29:26] John Allspaw
Oh, yeah.
[29:27] Steve Semelsberger
And he's right over there.
[29:29] John Allspaw
Oh, awesome.
[29:30] Steve Semelsberger
I'm super lucky to have him. And thinking about what you were describing, I was imagining some companies I know. At one large financial-services firm, there's a two-hour daily ritual where 15 to 20 people come together and look at hundreds of symptoms, issues, signals, and customer-support escalations from the day before. When you're advising companies on adaptive-capacity principles, I would think risk tolerance, system criticality, and industry context all matter a great deal. Could you talk about how you approach risk?
[30:16] John Allspaw
I mean, yeah, it's pretty straightforward. And it's great, because I get to plug something.
[30:28] Steve Semelsberger
Plugging encouraged, man. Go.
RISK IS CONTEXTUAL
[30:30] John Allspaw
When the topic of risk comes up with clients, we almost always respond with: tell me why. Say more about that. Human factors draws heavily from the world of safety, where risk is often treated in relation to a hazard and your distance from it—physical or otherwise. That distance is contextual. Risk isn't something that necessarily has the same value no matter who measures it; it's constructed. Colette Alexander, the president of the Resilience in Software Foundation, did her master's in Human Factors and Systems Safety at Lund University, the same program I attended. Her thesis examined how quantitative risk analyses and risk matrices are constructed and used, including in cybersecurity. It's worth reading. What we're interested in is: what makes you think this thing is riskier than that thing? Sometimes "risk" is being used to mean "possible and undesirable." Sometimes "big risk" means "likely." Sometimes it doesn't. When we hear a word like risk—or a word like cause—that's basically the word screaming, "Come ask more questions about me."
[33:35] Steve Semelsberger
There's a paper out of Auburn University—I know you love papers—and it has to do with the Latent Risk Index research the team at Auburn did. It's really cool. We'll also put it in the show notes, and I'll send it if you haven't seen it before.
[33:50] John Allspaw
Oh, completely.
[33:50] Steve Semelsberger
There's also the concept of risk as fear of negative outcomes. I'm hearing a lot of fear right now around the velocity and breadth of software being produced with AI-enabled development. I spoke with an SVP of Engineering running a 200-person developer team whose pushes are up roughly 2x, and the amount of code per push is also up roughly 2x over the last three or four months. There's market data suggesting incidents are up this year, but when I talk directly with CTOs and VPs of Engineering, I don't necessarily hear that. What I do hear is fear that, if an incident happens because the team didn't really build the code in the traditional sense, will they be able to figure out how to fix it?
[34:42] John Allspaw
Yeah.
[34:43] Steve Semelsberger
Are you seeing AI lead to—or at least correlate with—more incidents? Or what observations would you offer on this, John?
AI, THE SUBSTITUTION MYTH, AND COGNITIVE LOAD
[34:53] John Allspaw
First, the SVPs, CTOs, and directors you've spoken with who aren't reporting more incidents—I would ask if they're on call. I say this as a recovering CTO: we don't know what the fuck is going on. We know what's going on for the things we need to know about, and probably not much else. One explanation for the rapid growth of generative AI is the belief that we'll get economic gains by having it take over work people used to do, while the rest of the system stays basically the same and the outcome becomes faster or higher quality. Especially for distant stakeholders, reduced headcount is attractive because people are expensive. But this is the substitution myth. There is no one-for-one swap where everything else stays the same. AI creates new work. To get benefits from it, people have to learn new things and take on new roles. You move from operator to supervisor, from author to reviewer. I don't know many software engineers who say, "I'd rather review other people's code than write my own." Healthy code review has historically been sustained by reciprocity: I'll review yours, you'll review mine. With AI, that social contract changes. You have to set up the agent, describe the work, create the conditions for it to succeed, and then review what it produced. Whose life are we supposed to be improving? You're not simply freed up—you've created additional work so the thing can do the thing. It may still be very worthwhile, but it isn't free. The Faros AI engineering report, for example, reports roughly a 242% increase in incidents per pull request as teams move from low to high AI adoption, and about a 58% increase in monthly incidents. Beyond incidents, there's growing evidence of mental fatigue and cognitive strain in AI-assisted workflows. Developers face high decision density; reviewing more output can increase rather than reduce cognitive effort. If I have to choose who I want on call—an exhausted person or a non-exhausted person—I know which one I'd choose.
[40:29] Steve Semelsberger
Gallup polls continue to show disengagement among employees. Yeah, this is such an important area. As I was preparing for my conversation with you, John, something came up that I wasn't familiar with: something called the Law of Stretched Systems.
[40:45] John Allspaw
Yeah.
THE LAW OF STRETCHED SYSTEMS
[40:46] Steve Semelsberger
One description is that as we gain new capacity, we tend to consume that capacity by increasing the tempo and/or intensity of the work. I think that's kind of what you're describing here.
[40:59] John Allspaw
Exactly. Anti-lock brakes are a good example. There was a world where we didn't have them, and then we introduced them.
[41:19] Steve Semelsberger
Oh yeah. I had a car with drum brakes, John.
[41:21] John Allspaw
Yeah. Me too. I've replaced drum brakes.
[41:26] Steve Semelsberger
Wow.
[41:26] John Allspaw
Do you think people drive at the same speed?
[41:31] Steve Semelsberger
No, not at all. They drive closer, too.
[41:34] John Allspaw
Right. And from a business standpoint, if you have a new piece of capability that lets you do more or go faster, you're going to use it. In fact, it often doesn't make economic sense not to. The extra capacity gets consumed.
[41:54] Steve Semelsberger
It's amazing. Between Houston and Katy there's an enormous highway—something like 11 lanes in places—that cost billions to expand, and it filled right back up. At some point the road is so wide that even getting across it becomes part of the traffic problem.
[42:12] John Allspaw
That's the idea. I believe Larry Hirschhorn was the person who coined the Law of Stretched Systems, though it may have been Dave Woods—I think Richard Cook attributed it to Hirschhorn. In any case, it's an observable phenomenon. You can go out into the world and point to examples where new capacity is quickly absorbed by increased demand or intensity. That's what makes it useful as a law-like description.
[42:56] Steve Semelsberger
Yeah, no—sometimes...
[42:57] John Allspaw
...a misunderstanding.
[42:58] Steve Semelsberger
Unfortunately, "financial engineering" sometimes gets construed as what the Enron folks were doing. I think the kinds of engineering we've been talking about are mostly positive. A few minutes ago, when we were discussing risk, you mentioned Colette Alexander and her work. And a shout-out to the Resilience in Software Foundation: I recently joined. Colette was part of the team that welcomed seven newcomers, including me, and it's a really special organization. I sincerely encourage anyone interested in these topics to consider joining. We'll put the URL in the show notes. It's great work that you and the team are doing. I've got a couple of final subjects as we round things out.
[43:44] John Allspaw
Sure.
WHAT HAPPENS TO DEVOPS?
[43:45] Steve Semelsberger
If you look out five years from now, at the field we've been calling DevOps, do you think in the United States there will be more, fewer, or roughly the same number of people working in this core field?
[44:00] John Allspaw
In DevOps?
[44:02] Steve Semelsberger
Yes.
[44:03] John Allspaw
Because you're asking me, this may sound annoying. Do I think that five years from now people who write code and people who operate code—and are responsible for both—will still need to collaborate and coordinate their activities in a generative, mutually beneficial way that supports the business? Yes. That's essentially unpacking what DevOps meant from the beginning. Now let me put on a management-consultant costume for a moment.
[45:23] Steve Semelsberger
Remember, John is wearing a Mike McGill Powell Peralta '80s skateboard T-shirt right now.
[45:29] John Allspaw
Yeah.
[45:30] Steve Semelsberger
Which he and I talked about beforehand. Keep going.
[45:32] John Allspaw
Picture me perfectly coiffed, wearing a suit. If you saw me from afar, you'd ask, "Who's the golfer?" In that framing, DevOps is now an industry, a set of tools, a job description, all of those things. Will those still be around in five years? Probably. But it's also possible people will think about DevOps as a different thing—maybe the way we think about punch cards. People may even become nostalgic for DevOps at some point.
[46:25] Steve Semelsberger
In my first role, we did a lot of work with DBAs and sysadmins.
[46:29] John Allspaw
Yeah, yeah.
[46:31] Steve Semelsberger
Those concepts and roles don't exist in the same quantity, but if you look at the people running, operating, modifying, and ensuring...
[46:39] John Allspaw
Yeah.
[46:39] Steve Semelsberger
That's where I was trying to go with the question. The names and concepts change, but there are a lot more people now doing the operational work required to keep software running, recover when it fails, and sustain adaptive capacity. With AI, do you expect fewer people, roughly the same number, or more? A few months ago, many people were saying fewer. Then the argument became that maybe it evens out because people simply do more, faster. Now some people are saying there's no slowdown in software at all—we're just getting more done. I was curious whether you had a strong prediction.
[47:18] John Allspaw
I'll shy away from the prediction. I have views on how things are at the moment, but I try not to make confident predictions about technology and society.
[47:36] Steve Semelsberger
Yeah, it's a good dodge. I tried.
[47:38] John Allspaw
I'm a scientist as well as an engineer. Claiming confidence about technology's effect on the future of society would feel a little like saying I'm pretty sure gravity isn't real. So I won't call this a prediction. But I picked up on an assumption in your question: that adaptive capacity is something we can imbue into software or technology. I don't think that's the case, and one reason is simple: software cannot make commitments and software cannot be responsible. Nobody tells a customer, "We had a serious bug, so we're taking disciplinary action against our new employee named Claude." That's not how responsibility works. We review the code because we know we're responsible. Code-generating tools have existed for a long time, but the commitments and accountability still sit with people. As long as that's true, I can't imagine a world where the work we do—whatever we call it—isn't required. I also hope some unhelpful ideas disappear. Dave Woods sometimes calls them zombie ideas: concepts that persist despite weak support. Lines of code as a productivity measure is a classic example. At some point we realized that wasn't just imperfect—it was dumb. I hope more zombie ideas die over the next five years, and that the useful changes are more continuous than discontinuous.
[51:52] Steve Semelsberger
There was even a time when some businesses treated lines of code as a valuation property—as though enterprise value correlated with how much code was in the product.
[52:03] John Allspaw
Yeah!
[52:04] Steve Semelsberger
We didn't know what else to think about.
[52:06] John Allspaw
Yeah. The person who wrote about this—I can't remember exactly what year—said that using lines of code as a productivity measure amounts to professional malpractice at this point.
[52:21] Steve Semelsberger
Mmm, yeah, I like that.
[52:23] John Allspaw
So hopefully some zombies die between now and then. And hopefully the future looks like smoother versions of changes we're already seeing. I really hope that's the case. We don't want discontinuities. We know what those can look like.
[52:43] Steve Semelsberger
Well put, man. Let's wrap up. We've talked a lot about skateboarding and old cars and maps and things, but you and I are both big music people. Is there anything music can inspire us to—or even teach us—about resilience as you think about it applied to software?
MUSIC, IMPROVISATION, AND EXPERTISE
[53:05] John Allspaw
There are researchers in the resilience engineering community who are also musicians, and they've done real work on this—not just loose analogies. Playing music, especially improvised music, is cognitive work. You're doing multiple things at once, and there are ways to support that work and ways to inadvertently hinder it. There have been studies of jazz and improvised work. There's a great quote—I think it's Charlie Mingus—"You can't improvise on nothing." People sometimes think improvisation means just doing anything: press all the buttons, turn all the dials, pull all the levers. But that's not how musical improvisation works. There is a clear set of rules about dissonance, consonance, tension, and release, and expert musicians have internalized them. The Law of Fluency says that, from the outside, expertise often looks easy. You watch an expert musician and the work looks straightforward, but that belies how much is actually happening. Experts may not even consciously recognize everything they're doing anymore. And crucially, you're listening while you're playing. The best improvisers are incredible listeners. Listening and playing can't really be treated as separate contributions.
[55:50] Steve Semelsberger
I often talk my friends' ears off about non-dualistic approaches to things: the listening and the playing, the watching and the doing.
[56:00] John Allspaw
Yeah.
[56:00] Steve Semelsberger
I think there are some "wrong" notes when others are playing, man, and there's just this thing that happens. The space and the quote-unquote accidents often create the really interesting moments. So, sticking with music for one final set of questions: are you listening to anything you want to share with others, and/or are you going to see any shows this fall that you think might be cool there in Brooklyn or elsewhere?
WHAT JOHN IS LISTENING TO
[56:24] John Allspaw
I'm listening to a couple of things. I don't have any shows planned at the moment, but I am on the lookout for shows that start really early and let me sit down, because that's how old I am.
[56:44] Steve Semelsberger
We do that pretty well here in Austin. I saw Jason Isbell do a solo guitar show onstage.
[56:50] John Allspaw
Oh!
[56:50] Steve Semelsberger
A 7:45 show. I saw Goose and Mt. Joy back-to-back recently. They both started right around 8 o'clock. I heard that Goose played in somebody's backyard in Boulder, Colorado.
[57:03] Steve Semelsberger
So they played a backyard show getting ready for Red Rocks.
[57:07] John Allspaw
Yeah.
[57:07] Steve Semelsberger
Goose also plays three-hour shows, so...
[57:10] John Allspaw
Yeah.
[57:10] Steve Semelsberger
Hard to stick with two sets, you know?
[57:12] John Allspaw
Yeah. On that note, it's not a secret to people who know me: I went to college in the early '90s in western Massachusetts, which means by definition I went to a lot of Phish shows. Do I have a morning playlist with very particular live Phish songs? Yes. Is that all I listen to? Absolutely not. The thing that's had a big impact on me lately is a person in the UK called Owen Cuts. Every Friday he does Old Music Friday. Courtney Nash turned me on to it, and I turned Paul Osman on to it, and it keeps going. On Friday mornings I open Instagram—that's basically the only reason I open Instagram—and he starts the same way every time: "New music's cool, but have you ever heard old music?" He's a producer, an award-winning musician and DJ, and he gives you a little history. He'll play the beginning of a song and get so earnestly excited about how it starts. Sometimes he'll explain that the horn section is so good because those musicians used to sing in church together, and then he'll connect that record to something Snoop Dogg sampled later. It just warms my heart. It's the best beginning to every Friday.
[59:39] Steve Semelsberger
I love it. I'll give one back to you. There's a podcast called One Song, hosted by LUXXURY and Diallo Riddle. They're both music historians and lovers and players and DJs and creative forces, and they get the stems for songs.
[59:58] John Allspaw
Oh, yeah.
[59:59] Steve Semelsberger
And they cover everything from Led Zeppelin...
[1:00:00] John Allspaw
Exactly.
[1:00:01] Steve Semelsberger
...to A Tribe Called Quest and beyond.
[1:00:03] John Allspaw
Oh.
[1:00:03] Steve Semelsberger
And so they're of a similar ilk as you and I. They grew up listening to a lot of '70s and '90s, but there's '80s in there, there's 2000s, there's modern music. It's called One Song. It's one of my favorite podcasts. Awesome. We're also providing this as audio only, partially because I love SmartLess as well, with Jason Bateman, Sean Hayes, and Will Arnett. John and I have been able to kick back without worrying about what we look like—although I think we're looking pretty good here today, John.
[1:00:31] John Allspaw
Yeah, we've certainly looked worse, I'm willing to bet.
[1:00:34] Steve Semelsberger
I would gladly admit that. It's been such a pleasure having you on The Change Resilient podcast.
[1:00:39] John Allspaw
It's been a blast. It's fantastic.
[1:00:40] Steve Semelsberger
I learned a ton. I know our listeners have as well. Thank you so much, John.
[1:00:47] John Allspaw
I'd love to be back. This was really fun. This was great.