Let’s be careful out there

Paul: [00:00:00] Actually, you can cut that out. I’m just— shut up, shut up, you shut your face.

Matty: It’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matty Stratton, and I have 2 great guests with me today. But first, a word from our sponsors. Want to learn how to turn ops into opportunity? Join over 1,000 developers, IT practitioners, and business leaders from September 10th to 12th for PagerDuty Summit 2018, where you’ll discover the latest innovations to improve real-time operations. Hear from leading minds like John Allspaw and Charity Majors, learn from innovative companies like HashiCorp and Microsoft, and receive training from our own developers at PagerDuty University. So what are you waiting for? Go to pagerduty.com/summit and use SUMPROMO10. That’s SUMPROMO, the number 10, for 10% off your registration today. Don’t miss out on the first-ever re:Deploy conference taking place August 16th and 17th in San Francisco. We’re here to explore what it really means to build solid, sustainable infrastructures, not only for our code, but for our organizations and people as well. We all know that we care about the technology, but it’s becoming increasingly clear that we need to consider the impact that these choices have on the people responsible for the technology as well. Redeploy was born from a passion for resilience engineering, the ability of a system to withstand changes in its environment and still function. We believe teams can not only survive but thrive when faced with failure. Visit re-deploy.io to register. Use the discount code MATTY, M-A-T-T-Y, to receive 20% off the ticket price. Your application sits on layers of dynamic infrastructure and supporting services. Datadog brings you visibility into every part of your infrastructure, plus APM for monitoring your application’s performance. Dashboarding, collaboration tools, and alerts let you develop your own workflow for observability and incident response. Datadog integrates seamlessly with all of your apps and systems, from Slack to Amazon Web Services, so you can get visibility in minutes. Go to arresteddevops.com/datadog to get started with Datadog and get a free t-shirt. With full observability, distributed tracing, and customizable visualizations, Datadog is loved and trusted by thousands of enterprises, including Salesforce, PagerDuty, and Zendesk. If you haven’t tried Datadog at your company or on your side project, go to arresteddevops.com/datadog to get a free t-shirt and support Arrested DevOps.

[00:02:43] So a few months ago, we had Paul Reed on the show chatting about all sorts of fun DevOps things, including the wonders of how we do podcasting, much to Bridget’s chagrin. But Paul’s been working on a thesis that is really relevant to our industry and a lot of things that are near and dear to how we think about— maybe it’s just the safety within our industry. Maybe we think about how we do postmortems, how we think about getting better and being more resilient. So we want to talk about that today. But before we get into that, Paul, can you tell the listeners what, what program are you working on that you’re actually writing a thesis?

Paul: I don’t know if you’re doing it just for, just for fun because I, I am not doing it just for fun, although I will say it’s been, been very interesting. And first, by the way, thanks for having me back on the show. We had a lot of fun last, the end of last year doing kind of a fireside chat. I believe you called me Grandpa Paul.

Matty: Grandpa Paul. It was the fireside chat with Grandpa Paul.

Paul: Yeah.

Matty: I think if you want to listen to that, Go to arresteddevops.com/grandpapaul.

Paul: [00:03:44] Yeah, appreciate it. Thanks for that, Matt. No, so the program that I’m finishing up is the Human Factors and System Safety program at Lund University. And if you’re familiar with, you know, a lot of people have thrown some names around of books that if you’ve looked at, like how to do retrospectives and postmortems, the Field Guide to Understanding Human Error, you’ll hear, was written by a gentleman named Sidney Dekker. So you’ll hear his name a lot, Sidney Dekker. He founded this program a number of years ago. And he actually founded it in the School of Engineering, because as a human factors person, he was getting type rated in the 737. And he was, was studying, you know, how to, you know, fly a 737. And he found all of these corner questions and weirdness around how, like, how the pilots do things, how the airline industry does things. And he kind of just started to decide, decided to start, you know, looking at this and thinking about it, and sort of became, you know, an expert in that area from his experience with that. So he founded this degree. And what’s interesting, I think, about it is when you look at my classmates, they’re all like pilots and air traffic controllers. And we’ve got accident investigators and doctors. There’s a orthopedic trauma surgeon is one of my classmates, and he works in New York, and he’s the surgeon that if your arm gets ripped off in a car accident, if they bring the arm in and you in, he sews it back on. I mean, so just people from very different parts of the industry. John Allspaw, you’ve probably heard of him, CTO or was the CTO of Etsy, and then also conference chair of Velocity. He went through this program 3 years ago, 2 years ago. So I’m sort of the second IT person to have gone through the program, which is funny because all my classmates ask for IT help when we need to get into the, you know, search for research papers and stuff like that. But that’s the program. And so it’s a 2-year program, just finishing up the thesis. And the thesis that I was working on really focused on postmortems, retrospectives, and what our industry actually does and how actually how we use what we do after we do a postmortem. If you take a look at John’s thesis, and his thesis is fascinating too, he was really looking at how do we make decisions under high-tempo, high-stress situations? How do engineers— what heuristics do they use to make the trade-offs when they’re working an incident? Then I’m looking at, okay, after the incident, how do we use the artifacts I keep referring to them, the artifacts that get generated. So these are things like postmortem reports. And some of those findings turn out to be very interesting. It turns out that, that I think a lot of the stories we tell each other at conferences about how we do postmortems are in— there’s lots of edges to that. And so that’s what the research actually showed.

Matty: [00:07:01] So you’ve been talking about that, you know, you’re really the only— well, you’re only the second IT person who’ve gone through this, this program. And, you know, your classmates are from these, these different industries. What are some of the things that, that you’ve found that as you’ve talked with your classmates, kind of worked on, maybe worked on projects, maybe some things that they have found interesting or different, maybe some of the lessons from, from tech that might be applicable? Because we do this a lot. We sit there and we’re like, what can we learn from the auto industry? What can we learn from FEMA? What can we learn from first responders? And then it’s like, they got to be able to learn something from us, right? You know, that’s just fair.

Paul: Yeah, yeah, totally. Well, so, so one of the major things that I run into that you see in talking with my classmates is they often— like, I’ve told stories and we’ve researched cases where, you know, it’s like, you know, the old joke, oh, you know, the website’s down, I can’t download my cat GIFs, right? Things like that. Or even, you know, one of the famous cases that we look at, Knight Capital, that involved a high-frequency trading firm that took the company out of business and they lost, you know, $500 about $500 million in 45 minutes, which is a lot of money to lose in 45 minutes. But that, for that company, was sort of an existential crisis of sorts. So even though it’s serious, you know, you’ll then talk to the doctors in the room and they’re like, yeah, you know, I prescribed a medication and the pharmacy filled it wrong and we killed a patient, right? Or one of my classmates, actually, he’s an investigator for I want to say the Danish military. He gets sent in when they do live-fire exercises, training exercises, and somebody gets killed. The military wants to know, okay, where did that live-fire exercise go wrong? There is this weird sort of, as we’re talking about the problems, and all of my classmates are great, so it was not always like trying to one-up each other or anything like that. We’re all dealing with high-tempo, high-stress, high-consequence situations. The one thing I think that you see being realized in all of those industries, and we had a very fascinating conversation about this the last time I was out. By the way, the program’s in Sweden, and it’s funny, you go there in January the first time, so it’s very cold, and then you go in June and it’s actually very nice, and then you go in December again, it’s very cold again. But one of the things that they all pointed out is the impact of technology on their industries, their own industries, right? You know, in healthcare, like electronic health records and, you know, hacking, you know, security as it relates to all of that, you know, that’s a big thing. If you look at the— my class didn’t have any transportation, like road safety transportation people, but, you know, the NTSB released today the report on the Uber crash that killed someone in Arizona. So that’s all software and technology and computers. You go into the flight deck of any modern, you know, airliner, there’s computers all over the place, right? So I think having technology people as a part of the program gives another lens and another dimension to a lot of the discussions in so much as there were questions about why, why do compute, you know, why, why, how did this interface get designed? Or how did this get tested?

Matty: [00:10:34] And, you know, I may not have the specifics sound like Those sound like questions that we ask.

Paul: Yes, exactly.

Matty: We’re, we’re a little more rhetorical when we say it usually.

Paul: Yes. Yes. But I mean, it’s interesting to hear, you know, them talk about like the questions they have about the mechanics of how a piece of software got into their emergency room or got into their chemical plant. And to have somebody at least be able to talk about, well, at a high level, this is how we develop software and bring some context to that, I think is, is, was super helpful. And it really is making a lot of these conversations more valuable and more actionable in these other industries. The other thing that I would point out that is fascinating, so I was kind of the second person to go through this program, second IT person. It’s kind of funny, they call me like the IT DevOps person to go through the program. But we also see now Nora Jones from Netflix is in the year after me. She’s currently in the program. Casey Rosenthal also was at Netflix, but is now at a startup. If you’ve heard of chaos engineering, he, he worked on the chaos engineering and traffic team. That’s where Nora actually works at Netflix now. But he was on that team at Netflix and kind of coined the term chaos engineering. So they are in the program themselves. I know Jessica DeVita was at one of the learning labs that they do, which are actually open to the public. So I think what is, you know, and I was actually just DMing John on Twitter this morning, I think one of the things that makes us both really excited, but also very happy is that people are starting— it’s starting to resonate in ways in the industry where people are like, hey, this is something that, you know, you might want to have someone on your team delve into a little more, kind of dig into this a little more and understand some of the nuances. Because it really— I will say this, it opens up the way you think about the world. When I read postmortems, public ones, when I work with clients and read their private ones, their, you know, their internal postmortems, mortems, when I read NTSB reports, it just turns the way that we think about the world kind of on its head. And that’s always, I think, good for our industry to kind of get perturbed that way in a little bit and get us to think about these things a little differently.

Matty: [00:13:01] What does safety really mean when we think about it in IT? Because I think we talk about wanting to be safe, and a lot of times maybe that’s perceived as protecting our systems or building resiliency or even as simple as saying we’re going to make it safe by making it redundant.

Paul: Right, right.

Matty: You know, so what— but something tells me there’s probably a little more to it, maybe a little more nuance. Well, yeah, availability.

Paul: Yeah, yeah, definitely. So there’s a lot of ways to answer this question. I think one of the things a lot of people struggle with is that word safety itself. Like they don’t— may not, you know, to go back to the cat GIFs example, Um, they may, they may say, well, you know, I’m just, I’m just, I run a website where I sell, you know, Etsy’s a great example, right? So I run a website where I sell products. It’s, you know, it’s not, it’s not that big a deal. There’s not safety consequences, right? And I think the people, John having worked at Etsy, would argue with me as well he should. Um, and people working at Etsy would argue with me as well they should. But my point is, is I think a lot of times people may say, I don’t work in a safety group, like I’m not doing flight control software. I’m not doing nuclear power plant software, which I always giggle at because if you remember back in the day, if you ever read the Java EULA, the end user license agreement they had to click through, one of the things it said in there is this, the JVM or the Java runtime may not be used in a list of industries. And it was like chemical plants, nuclear power plants.

Matty: [00:14:28] The Chef, the Chef EULA is like that. I remember. And I remember that it’s a thing where you can’t use it like in astrophysics, like, like, it can’t be used, like, in spacecraft either.

Paul: Right.

Matty: And it’s funny, because like the SpaceX people use Chef, right? And it’s sort of like, it’s, yeah, you look at that, and you’re just like, oh, I guess you sort of do have to protect yourself.

Paul: Right, right. And so, but, but so there are a lot of people that see that, and they’re like, oh, well, I’m not using it. I’m not doing anything like that. So I don’t have to worry about this stuff.

Matty: Right.

Paul: So there is kind of a question of what do we mean by safety? I’d say 2 things. One is there’s always the financial sort of safety of the business. And we talk a lot about this in DevOps. You have to care about your role in how the business makes money. You have to understand that. We need to sort of understand the end-to-end value stream. You know, I know you’ve talked about— I’m sure you’ve talked about a lot on Arrested DevOps. I know we used to talk about on the Ship Show, this whole idea that you really should understand sort of how things work from a business perspective. So in some sense, there is always a safety of the Like, we should be mindful of that. So there’s that part. And some people may say, well, I don’t find that compelling, and I understand that. The other thing that I think is an idea that is starting to take hold, and, you know, I think is, you know, we’re kind of over the— what’s that— the early adopter trough. This is not a shocking statement to make. I think the idea of complex systems, complex adaptive systems, complex sociotechnical systems is, you know, people are starting to get, yeah, I work in a complex system? The answer there is we don’t actually know all the ways that our technologies that we work on get used. For instance, I’ll give you 2 examples. One is an example I give in a presentation where there were these pet feeders, these PetNet pet feeders, and there was a cloud outage of some sort. It turned out that they were Wi-Fi enabled so you could get on your smartphone and feed Fluffy at 2:00 PM when Fluffy wants lunch or whatever. There was a cloud outage and it turns out that these pet feeders like starved people’s pets for like a day, right? And if you’re not, if you’re on vacation and you’re expecting this thing to work like that, that’s certainly a safety, can be a safety issue. So that was one thing. And it turns out it’s not that the service itself went down, it’s that the whatever service they were relying on had a, had an issue, the cloud service they were relying on had an issue. So we live in an increasingly interconnected world. In fact, I’m just thinking about another one. Here’s another example. You might not think that your cable service is safety critical, but it turns out that there was an article about how all of the security hardware that Comcast sold as part of their security product, when you disconnected it from the network, it would safe fail to unlocked. So there was this story about you could go outside, cut someone’s cable, and then all the locks would just unlock, which is kind of weird, right? So I think safety in the complex interconnected world that we have, especially with Internet of Things. Like, it’s not always clear that the thing we’re working on is relied on by someone else in potentially a safety-critical way. The other story that I like to tell is there was a story in the last 6 months about Netflix reached out to someone that they were a little worried about because they had watched every episode, I believe, of The Office. But it might have been something else, straight for like 80 hours or something like this. And there was something in the usage patterns, the data, and there was an article about this where they reached out to this person because they were worried about them. So Netflix is an interesting example in particular because you don’t think of internet TV or watching your favorite show as sort of a safety-critical problem. But how many of us, you know, have a really stressful day and we just want to get home and we want to, you know, get dinner on the table and just relax And it can actually cause, you know, a panic attack or stress that again we don’t know about. So it’s not like it’s Netflix’s fault if it’s down or something like that. But the point is, I think a lot of times we expect certain services to work. I know, for instance, when I turn on my PlayStation and I haven’t turned it on for, you know, a couple weeks and I just want to play my video game and it wants me to update, like, that drives me insane. And I’m like, you know, banging the table. I just want to, you know, shoot zombies or whatever. You know, those are examples that are low-key. They’re not Not necessarily quote unquote what we might think of as safety, but I think it’s interesting that Netflix reached out to someone and they asked, are you okay? For every case that we hear of, which we don’t hear of many like that, how many do we not hear of where somebody was in a bad mood and something bad happened? And I’ll leave bad in quotes and open to interpretation. So I think the point is that it goes back to technology is permeating, Marc Andreessen, Software is Eating the World, right? Our lives, and it’s popping up in ways we never expected. And so, when you say safety, it’s like, even if you’re not in safety-critical systems, which, you know, you might be in a surprising way, you need to think about these things because at some point in your career, there’s a very high chance you might be.

Matty: [00:19:48] This is really on point. There’s a lot of conversation about this, about understanding making your software humane and understanding the responsibility, the social responsibility you have with your software. You know, there’s a conversation with the, uh, what’s the Google Duplex? Isn’t that what that’s called? The, the thing where Google will say um and ah.

Paul: Oh, right.

Matty: Yep. And, and they’re like, oh, well, you know, you look at it and you’re like, oh, I totally see how this solves the problem of having my little, you know, Android robot call to order my pizza instead of me having to do it or everything. But then what are all the, you know, the ramifications of doing that? Of, you know, around identity theft and impersonation and things like that.

Paul: Well, there’s a great example today. There was just something, an article that came out literally today that was talking about how there was a conver— set of conversations that were taken off of somebody’s Alexa home box. And this family had outfitted their entire house with these Alexas, and it mailed the conversations or sent the conversations to the guys, the husbands employee who happened to be in his contact list. And so what was interesting is like the employee contacted the guy and was like, um, I think I’m getting a bunch of these conversations from, from your house. And so, and he was like, I think you’ve been hacked. And the husband was like, nah, that’s not true. And the person sent them some of the recordings, and sure enough, it was a number of recordings from inside their house. And what’s interesting about that is they sent it off to Amazon, and Amazon was like, yeah, this is wrong, this is not supposed it’s not supposed to work like that. But they didn’t really explain why it happened. They didn’t really offer anything reassuring about, yeah, you should trust Alexa. And it was interesting, as the wife is quoted in the article as saying, I unplugged all the Alexas and I am never using that technology ever again. Now, we can debate whether or not that’s the right answer, and we can debate whether or not Amazon did the right thing or the wrong thing. But again, that’s an example of connected everything and these these interactions can happen in ways that are a little surprising.

Matty: [00:21:55] To quote, you know, Patton Oswalt, it’s like science, always about coulda, never about shoulda.

Paul: Right, right, right. Definitely.

Matty: Wasn’t that a little bit of kind of, you know, we see this continually coming up with Facebook, which is, well, that’s not what we meant to do. Right.

Paul: And I think it’s, you know, well, this is one of those funny things, right, where people always say, oh, well, we didn’t— we didn’t— we just built the technology to like mimic humans and to like— we let humans train it. And it’s like, yeah, a lot of humans are just kind of bad. Like, they, you know, like— and I, I mean, so that sort of like humans can be shitty to each other, right?

Matty: Yeah.

Paul: And, and so when you, when you just let humans train AI without any sort of rules or thinking, like, bad, bad things will happen.

Matty: Well, was it that Microsoft AI?

Paul: Yeah, right.

Matty: That was—

Paul: it was the Microsoft bot.

Matty: It became racist. Yeah, exactly, exactly. Because terrible humans taught it how to be a terrible human.

Paul: And this is one of those, you know, where Black Mirror— like, technology can often be a black mirror.

Matty: [00:22:58] Um, but anyway, so I think it was Jesse Frazell who tweeted something like, look, people, Black Mirror is not supposed to be a how-to, right?

Paul: Exactly.

Matty: We’re not supposed to be aspirational about it.

Paul: Yes. Yeah, yeah. So I, you know, that this is the point that I want to make. I mean, so, so, uh, we, you know, we’ve been studying these issues and more people in tech are starting to study these issues with sort of an academic rigor, which is very refreshing. I mean, you know, we talk about, you know, you were asking about, does safety just mean more backups and more, you know, does resilience just mean more backups? And I have a presentation on this. But what’s interesting about that is, is that was the right answer, more backups and more redundancy. That was the right answer up until Three Mile Island. In fact, there were 3 incidents that caused everybody to think about that problem differently was Three Mile Island, Chernobyl, and the Challenger explosion. And you will study various parts of 2 of those. We don’t look much at Chernobyl, but in the program, really deep dive into Challenger. And it was just fascinating. But so the one thing though, so that’s a little bit about the program. The one thing I did want to talk about, because I think there’s some interesting impacts for our industry is around sort of the thesis findings. And so the question— I’ll read the official research question, but then I’ll explain it because it’s very academic language because, you know, it has to be. But the question is, in industrial practice, in what ways and to what purpose are the artifacts produced in a post-incident review process utilized by a software development and operations company? Say that fast 5 times. But really what I was trying to look at is, so we sit in a retrospective or a postmortem or a learning review or whatever we call it, and then we generate a bunch of paperwork. We do graphs and reports and timelines and we do something. We write those things down. We create Jira tickets or ServiceNow tickets or whatever it is, right? And we write this all up and then what do we actually do with that? Like in practice, what do we actually do? Do we just shove it in a drawer and ignore it? Do we use it to learn and get better? The answer is, of course, varied. I broke it down. I did an industry survey which had some notable findings, and we can talk about those. Then I also did a case study survey with a high-performing, what we might call a DevOps unicorn-type company. They were gracious enough to let me sit with them for a number of months and try to get an answer to this question. There are some really fascinating findings that are really counterintuitive to the way we might sort of think about this problem. So that’s basically what I’ve been sort of kind of down in the well looking at and trying to figure out for the last year.

Matty: [00:25:51] And what are you, what are you discovering?

Paul: Well, so I’ll ask you one question. One of the, one of the first questions that I asked in the survey is, because, you know, you’ve said, I know you’ve seen these debates on Twitter, what do we call it? You know, in the research question, I called it a post-analytic or post-incident analysis event. It’s a very long— right, it’s a very long way of saying that.

Matty: Now we have another word.

Paul: No, I know, I know. So, so what do you think is— uh, yeah, I know. What do you think is the most common industry term?

Matty: It’s— I still think it’s postmortem.

Paul: So post— you are right, postmortem by far, 60%, is the most common term. The next common term is down in 17%, which is retrospective So we mostly call it postmortems, which is kind of interesting.

Matty: Don’t get me wrong. I understand why there’s sort of this feeling that, oh, it’s not a very positive term and it’s fairly—

Paul: It’s got a lot of baggage.

Matty: [00:26:52] Inaccurate because it’s not like our system is dead. In fact, we resurrected it. You don’t do a postmortem on somebody that you save. You do a postmortem on— but that being said, at a certain point, you know, it’s like the DevOps engineer thing too. I get tired of tilting at certain windmills because I’m— and words matter sometimes and they don’t in other ways. And we could go off on a whole other thing about the paramilitarization talk, but there’s something to be said for some of it because we, you’re trying to say something. So anyway, my point is, while I totally understand why postmortem has certain feels around it, certain connotations, and may not be the most accurate term, if, you know, you said 60% of the industry is using that, maybe we got some other things we can, we can worry about first.

Paul: Yeah, no, definitely.

Matty: Besides just confusing things.

Paul: Well, so here’s the thing. You know, I’m a big fan, you’ll hear me say this, context matters, words matter. But, but I also, so I get the, and I agree with, with sort of the deconstruction of the nuance around postmortem. Um, I also deconstructed blameless, and, and I wrote a blog post on why blameless feels weird to some people, a lot of people maybe. And I, and I said, well, maybe we should call it blame-aware. But, but I don’t for a second believe that we’re not— we’re going to call it anything other than a blameless postmortem. That’s taken hold. But I, you know, I think, I think it’s worth sort of, you know, at least understanding that that is the most common term. In industry use. And the other terms are very far behind. You know, one of the ones too that I actually didn’t put on the survey but was a lot of write-ins answers were RCA or root cause analysis. So a good number of people call what they do a root cause analysis, which has interesting implications for how you think about the problem, right? One of the other interesting industry survey findings was that about, let’s see, the top 2 items that we collect when we do a retrospective, let’s call it, or a postmortem, are list of remediation items. So what are we going to fix? And then an event timeline. And both of these are up around 85-90%, right? We collect that sort of data. I suspect you don’t find that surprising. We’re all pretty, we all pretty much assume that it’s going to be timeline and remediation items.

Matty: [00:29:25] Those are, and they’re what seem to be logical as well.

Paul: Yeah.

Matty: Right. Based upon what, what we usually need to answer for. Right. Because think about what does, what does our management want to know? They want to know what happened and what are you going to do about it?

Paul: Right, exactly.

Matty: That’s what those, that’s ostensibly what those 2 artifacts provide.

Paul: Right. Yep. So, so the one thing, so hold that thought, because that turns out to come back later and be very interesting. I’ll share with you one couple, just a couple of highlights that are not aggregate data, but somebody actually wrote in as a write-in answer. It said, which of the following items are created or recorded? Somebody actually wrote in blame and fault. And I was like, oh, I’m so sorry for where you work. You know, we talked about that.

Matty: At least they were being honest.

Paul: They were being honest. Yeah.

Matty: I’m sure there were plenty of other survey respondents who, where that is actually is an artifact that’s created. That they did not identify that.

Paul: Yes. Yeah, definitely. And then this is the other thing that I found interesting in the survey is there were a number of, you know, this was sort of themes around the postmortem template data. There are a number of people that include as part of this process luck, this idea of luck. Where did we get lucky? And I just thought that was fascinating that some organizations look at sort luck is a thing and they understand what that means and they talk about it. How do we get lucky in an incident?

Matty: [00:30:54] So, well, you know what I mean? I was, I was going to make a joke and say, you know, maybe for them they consider their competitive advantage that they’re lucky. But I have a friend who that’s true for him. This dude is like, he’s just really lucky. That’s how he’s gotten through his life.

Paul: Yeah.

Matty: You know, I mean, he’s a, he’s a skilled individual, but you got to look at it and you’re like, you, you really did kind of fall backwards into an awful lot of stuff that could have gone really, really south for you. So Maybe some organizations do have the differentiator of this that, you know, they’ve got some golden horseshoe in their CEO’s office or something.

Paul: Maybe, yeah. I’ll say one other, a couple of other interesting things about the survey data. So, I ran some statistical analysis on it. And I found out that it’s statistically significant that if you look at the role, that people play. So they said, I’m an operations engineer, I’m a QA release engineer, I’m a developer, I’m a manager, were kind of the 2 big groups. It is statistically significant that operations engineers collect updates to their documentation and actually update documentation way more, or not way more, but notably more than either managers or developers. And this is kind of one of those intuitive things, like operations engineers have runbooks and sort of, you know, ways of debugging problems that they document. But the data did show that, that if you’re in operations and have that background, you’re more likely to sort of update your documentation as part of this stuff. The other thing I found that was statistically significant is larger organizations aren’t as open with their retrospective reports as smaller organizations.

Matty: [00:32:38] So you said that’s statistically significant, but did it— do you take that as a surprise? No.

Paul: So that’s the thing, right? Some— I mean, some of these things, when you’re looking at the statistics, and, and I, you know, I, I took a bunch of statistics in school, which, you know, it’s like you have to go back and look at it. Um, some of these surprising— there’s some of these findings aren’t surprising, but that’s the point. You want to have data that actually establishes sort of a relationship, right?

Matty: I, I had, I had a conversation with an analyst today when— or yesterday when I was at ChefCon and was kind of going through some of my usual tropes. And it was the first time somebody called me on one of them. And I don’t remember what it was, but she’s like, what’s the data that backs it up? And I was like, let me go ask Nicole. Yeah. Yep. Yep.

Paul: Oh, yeah. Yeah.

Matty: Yeah. I forgot my point. That was about the statistical— well, there’s the being about it being a surprise about the transparency. And then I was— what I wanted to ask you, though, this is— I remember what it was now. So you say about being transparent with their findings. Things, is that— and I don’t know how specific you got in the question— is that outside of the group, outside of the— or outside of the org, or just outside of the organization?

Paul: [00:33:44] That was internal to the company. So the point being that— so the point— yeah, so the point being that the question was worded around, are the artifacts or the reports, are they public inside your company? And do you know where to find them? And so bigger companies, they’re less public.

Matty: So that’s actually, actually a really important distinction to make because I heard that incorrectly at first and said, well, of course not, thinking about, you know, these in-the-open postmortems, full transparency out like, you know, GitHub style or whatever kind of thing. And I was like, well, of course they don’t do that. But, but even having that happen inside the organization, that’s That bespeaks something very different. Right.

Paul: Well, it speaks— you know, we talk about silos all the time, and this is another way that information like that gets siloed.

Matty: When you talk to an organization about being transparent outside of the organization with their postmortems, a lot of times it can be like, well, okay, that’s going to cause, you know, for right or for wrong, it’s going to cause, you know, our customers to have doubts about our ability to perform provide service, or it may cause a problem with contractual agreements we have or things like that. And so whether or not that’s true, and again, I have thoughts that, you know, about that, about the former, it’s a little different when it’s inside the org, but it’s probably still coming from a similar place. So like you said, it’s, to me, I hear that and I think, first of all, it’s just how often is that, how much of that is just, it doesn’t occur to us. On my team to tell anybody outside of my team. And then also how much of it is if somebody challenged me to do that, would I push back on it?

Paul: [00:35:32] Right.

Matty: Because I don’t want— because I’m concerned reputationally about people understanding that we don’t provide service the way we’re supposed to, you know, because we have internal customers or things like that. They both do different things and probably for different reasons. You know, some of it just like you that, you know, based on the silos, just may not occur to somebody to be like, well, nobody will care.

Paul: Certainly there is that. I think, I think my sort of takeaway from that is that people without sort of a conscious bias to being transparent may, may unconsciously default to being less transparent. Not again because of malice or even the environment, although those could be factors, but more to your point, like, I didn’t know this was important.

Matty: Well, I think that’s something that we should probably keep in mind when we think about transformation, which is that, again, where do our biases come in when we hear a thing like that to think like, oh, you’re actively trying to keep this from someone when it’s reality? That’s just a culture that doesn’t default to transparency.

Paul: [00:36:35] Right. So actually, this is a really good segue because I wanted to look at sort of how the industry sort of looks at these things. And there’s some more data in there. And, you know, this is going to be published shortly. So if you’re kind of, you know, a nut for statistical analysis and little nuggets of data, you know, I’ll tweet it out when it’s finally up and you’re able to look at that. But it’s a great sort of segue into— then I went on to look at sort of a high-performing organization. And so I was able to spend some time with it. And there were like 2 or 3, I think, takeaway ways that were fascinating, that I think will be surprising to the industry. The organization that I looked at was an organization we all know of. For research protocol reasons, I can’t tell you who it is, but you would all know who it is. I mentioned they’re a DevOps unicorn, unicorny type company. There’s some more data in the thesis, so if you’re interested, you can dig into that. But again, it’s funny, in the thesis, I actually call them DevOps Co. because it’s It’s kind of like parts unlimited, right? But so I think the biggest thing that I found interesting is they don’t focus on remediation items. That is not the goal of the— they don’t call it a postmortem. In fact, they call it an after-incident review, although they’ve actually changed the names a few times. But that, I think, is the biggest thing that they’re They’re considered a high-performing organization, and yet the thing that we all collect, remediation items, they don’t place that much focus on. And they have a number of different ways to sort of combat, if you want to think of it that way, incidents and things that pop up in their system. But it’s not a static— they don’t collect a static list, checklist of remediation items. You have to fix these 13 things. And, and I, you know, I thought that was fascinating. It’s not intuitive, right? You, you know, uh, Matt, you, you and I were talking about that, how, uh, you know, the business wants to know how will this never happen again, and which, which in itself is a fallacy, right?

Matty: [00:38:55] Like, you’re— it goes back into this, like, How was it? Because that’s the thought, right? How is it never going to happen again? At least that’s a little more proactive than why did this happen? You know, because sometimes the why did this happen is what did you do wrong that made this happen?

Paul: Right, right. Yeah.

Matty: But so I used to get— yeah.

Paul: So, oh, go ahead.

Matty: I was just going to say, I used to get the fun one from a CTO that I worked with where we’d have a scenario and she would say, why weren’t you monitoring for this? And I said, because until this happened, we didn’t know it could.

Paul: Right, right. You know, exactly.

Matty: Yeah. I’m sorry. I left my crystal ball at home. And, you know, we do have to learn a little bit from failure, right? And that’s— I had a hallway conversation at ChefCon the other day about this very thing with a friend, you know, someone who works in a, you know, very conservative industry who again is like the, you know, we got to, you know, very concerned about all this change and blah, blah. And the point that I made to him was I said, the question I ask a lot of times when people say, well, we can’t do X because we have this process, process that is protecting. And the challenge I always give is, okay, how many times in the past year has your process saved you?

Paul: [00:40:05] Right, right.

Matty: And the problem is nobody can ever tell you, right? Right. Because it’s— and the thing is, it’s just as much of a guess. And the problem is when it’s a little process of, like, people have to sign off and, like, tell you that basically, because at the end of the day, a CCRB is your gut says it’s okay, right? You know, guess what? If we’re doing this with, like, test-driven stuff, I can show you data of every time that our process saved us.

Paul: Right.

Matty: Because it’ll show you every time a test didn’t pass.

Paul: Right, exactly. So, so, so there were, there were, yeah, yeah. So to your point, there were 3 major findings that were sort of counterintuitive or antithetical to the way the survey data said most of us do this. So the first one is they prefer, they have this process they called context sharing, or that’s my name for it. But, and I describe what that means in more detail, but their focus is to understand context and then to share it over action items. And in fact, there they have a setup where, where, you know, sometimes they may not— they may purposely, unconsciously not do a remediation item. They may just say, nope, we’re not doing it, right? And, and, and deal with the, the consequences of that. And it’s— that is a weird dichotomy because they are also a high-performing organization. So it’s like, how do they do that? And the answer to that, what you were talking about, about process and how process, like, did it save you? We don’t know. And also accreting all of this process. The other major use, or the second major use, of the artifact data that they collect and that they analyze and that they look at is to map their complex adaptive system or their complex socio-technical system. And what I mean by mapping it is they are able to see 2 things. They, they’re able to see connections within the system that, to your point where you were— the example you gave earlier, like monitoring— we didn’t know we had to monitor that, right? They are able to see connections between systems that they never would have known about, and they, they use it to map their complex system continuously. We talk about continuous everything. They use it as a way to continuously generate a map. Now, what’s fascinating is it’s not just technologically. It’s not just system A depends on system B in this weird way and we didn’t know it and now we do. They use it sociologically too, with people. For instance, I was able to talk to the security folks. They gave an example of where there was a— they have teams all over the world. There was a team an overseas team that was being attacked by a, you know, botnet or whatever it was. And that team didn’t know who to talk to. That’s an example of a linkage that should be there but isn’t. And so they were able to map that that’s a problem they need to solve. Or I should say, there was a connection there, but there was no way to get kind of data through that connection. It’s sort of like a dead connection, right, that they needed to, you know, make, make live and make it so that people knew what to do. Um, and so they map it sort of that way, but then the other way they map it is they map it, uh, where, you know, the old adage, where there’s smoke, there’s fire. They’re able to see little smoldering fires that are, you know, emitting smoke in their system before they blow up, and they’re able to do that through this process. And then the, the third one, um, that I thought was fascinating, it goes back to what we were talking about, about sharing that data. Is being able to curate and create tribal knowledge and this idea of organizational culture. That’s important when we were talking about what wouldn’t occur to anyone to share the data. Sharing the data and making really insightful, in-depth observations about their system and discoveries about their system is now part of their tribal knowledge. And actually, it’s part of their culture, their tribal knowledge. I’ll give you a really fascinating example. They don’t gate who can deploy and when they can deploy. Anybody can do it whenever they want, except there is a socially accepted kind of set of guidelines about when you deploy. And those have all been mostly generated by outages based on experience.

Matty: [00:44:19] Yeah, we all, you know, I always make my joke, I have a lot of rules about, you know, what about— they’re my Vegas rules. I mean, but they have to do with gambling, you know, I have to do with it. You know, but what do I do with my money when I’m in Vegas and things like that? And you want to know how every one of those rules came? They came from getting burned, right? Yeah, right. And, and so because of that, they, they stick. Yeah. But they, but they were never predictive. It wasn’t like, well, this is what— well, let me put it this way. All the rules that I come up with that aren’t based upon my experience, they don’t work so good. You know?

Paul: Right, right. Well, so, you know, that’s a great example, though. I’m sorry. That’s a great example, though. You were talking about process that, quote unquote, we think is saving And then you go look at those change control boards and it’s like, yeah, it’s just a gut feel, but it’s not based really on data. It’s sort of, did you fill out the right checkboxes? And that serves as a heuristic, but there’s all this heavyweight process around it. And one of the sort of meta findings is you can get the same outcomes by actually focusing on people’s guts and their gut feels about, does this feel right or wrong, but looking at it through, actually, we trust those people. It’s not because we had a big long checklist of things and we all checked it off and now everything’s fine. And you know how people play games with the checklists because we’ve all seen it, right? So those were the sort of major, kind of 3 major things that I think, like I said, are kind of counterintuitive or antithetical to certainly the survey data about how we do this stuff.

Matty: [00:45:48] Great. So for the second part of this episode, Paul and I are now joined by our friend Mary Thengvall, and we’re going to talk about resilience, resilient systems, resilient teams, and resilient humans, and maybe a cool event where you might be able to learn about those things. So welcome, Mary.

Mary: Hey, thanks. It’s great to be here.

Paul: Or as I’ve heard her described, Ember’s human.

Mary: Also true. I will go by that title.

Paul: So we’ve been talking about, you know, my thesis and safety and what does that mean and all of that. And Mary, you and I had some, some conversations about this and this idea of resilience. You hear it sort of in the academic space as resilience engineering, but bringing some of these ideas of resilient side of tech. So, you know, cloud, you have to be resilient. To cloud failures. But then, you know, I was looking at, you know, postmortems and retros or resilience kind of on the team side. And, you know, Mary and I were talking about it. And it’s like, Mary, you’ve been, you’ve been looking at how people treat each other resiliently in these sociotechnical systems in our work.

Mary: [00:47:05] Yeah, yeah. So I mean, I’ve been looking into how people treat each other as well as how we treat ourselves. I’ve dealt with burnout myself. I know a lot of other people who have as well, especially in the developer relations space. So I’ve been doing a lot of looking at both burnout prevention and how that can change, as well as what causes it, but also this idea of how to, how to make your team more resilient, how to make sure that people are being treated respectfully in the workplace, how to make sure that the amount of work that they’re being asked to do and the type of work that they’re being asked to do is both valuable work and work that they are invested in, but also is seen in context with the other work that’s happening in a way that’s valuable to the company as well as valuable to the individuals.

Paul: I just had an actually really interesting example of this where I tweeted this, I think just yesterday, that I think it’s an organizational anti-pattern when certain people’s vacations are more important than other people’s vacations. And, you know, that’s another example, right, where it’s connected to the work. It’s like, oh, you can’t leave to have a vacation because, you know, your work is too important. And somebody actually chimed in with the thread. I don’t know if you saw this, Matt, the thread, or Mary too, the thread about ops people being on call and developers who are like, I can’t, I don’t want to be on call. I have a family. It’s like, wait, so ops people shouldn’t have families? Is like, it’s funny, it’s like, did you hear what you just said? Like, right, you know? So, so yeah, um, and, and, you know, I think all of us, you know, uh, I was, I was noticing some of the, the Chef Comp photos about, um, I saw the poster that said Hug Life.

Matty: [00:48:46] Um, yeah, Hug Life. I did not choose Hug Life. Hug Life chose me.

Paul: Oh, there you go, there you go. Yeah, but no, I mean, um, I, I think there’s starting to be a consciousness about that too. Like, like, you know, it’s all people. You know, there’s a reason we say socio-technical systems, right?

Mary: A big part of it to me is, you know, people so often go, well, you know, you pay people the right price, they’re willing to do the, the extra time, be on call for longer, blah blah blah. And like, there are so many studies that have been done that, you know, have been cited in Forbes and psychology magazines and everything else that like You hit a cap on that eventually and you can’t pay people enough to get them online every day, all day, and to miss all of the family occasions and everything else. I had a fascinating conversation with someone about it the other week because they were like, well, yeah, but if I work harder now, then I can save more for the years to come. I’m like, that’s great if that works for you.

Paul: If you’re not dead because you’re working.

Mary: [00:49:48] If you’re not dead because of how much you’re working, exactly. I want to be able to live my life and have money to keep living tomorrow and enjoy my life that I’m living while I’m living it.

Paul: I’ll tell you a really funny story. I think I talked about this at one of the DevOpsDays open spaces somewhere, but I think it was actually in the context of pay talk. We were talking about the Silicon Valley myth that they tell everybody in their 20s, if you work enough, you’ll get stock and the stock will be worth a gajillion dollars and blah, blah, blah, blah, blah, blah, blah. And I was talking about how I did work for— I did work for not a startup, but there was an acquisition there and I made a little bit of money. And then I did work for a startup and they made no money, but they actually would not let me take vacation. So this was back when vacation was not unlimited and it was actually worth something. Something. So I cashed out my vacation and I got a chunk of money. So here’s the thing, the punchline to the story was like, so I’m like 33, and if somebody had asked me, would you like enough money to buy like a family minivan, or would you like to have lived your 20s? I think I would. As, as somebody who’s 35, I think I’d want my 20s back. Um, you know, it was the, the minivan is not worth the work that I put in in my 20s, uh, for that.

Mary: [00:51:07] Well, and I mean, going back to what we were talking about with some people’s vacation is worth more than others kind of a mentality. You’ve got some companies where the engineers go through a sprint and then they’ve got either time off or at least a little more relaxed pace for a little while. And I think one of the biggest problems that we run into with DevRel is this idea of, well, things are lower paced when it’s not conference season. It’s like, well, Well, kind of, but like if they’re lower paced then, then we’re going into prepping for conferences or writing more content and things like that. And so there’s never— and I know this happens with other careers as well, but since this is my area, there’s never really that like you have downtime during X month, right? And so there’s never the— like I’ve talked to so many folks in DevRel who are completely burned out and desperately need to take time off, and their response is, well, I can’t because I’ve got this company conference coming up, and then I have to prep a talk for this conference, and then I have to write this content, and if I step away from this, there’s no one else to handle it. And yet they’re not able to or willing to make themselves redundant because then they’re worried about working themselves out of a job.

Paul: [00:52:25] Yeah. No, I’m sorry. I was giggling because I remember, I know, I know, you know, we all know Jason Yee. And he was like, I’m in developer relations. So that means I write docs and talks. But, you know, I think this, this goes back into that sort of kind of safety sciences area, there is a recurring theme that we would, in tech, do very well to start being very deliberate about and thinking about. And it’s this idea of the sharp end of the system and the blunt end of the system. And the sharp end of the system is where most of us work. It’s where the work gets done. It’s the pointy, difficult part where you make all the trade-offs. And a lot of times you make those trade-offs without all the information. But the reason you were hired is because you’re a good engineer. And that’s that, you know, we were talking about that earlier, the change control board, that gut feel, right? You know, sometimes it’s a gut feel It’s the sharp pointy end of the system that is often messy and dirty. And the decisions, again, aren’t totally clear. We’re kind of in the fog when we’re making those decisions. And to the point, Mary, you were making is I think a lot of times we assume we know how work is done at the sharp end of the system, even in our own company. And to what you were saying, we don’t always, you know, this sort of like when you’re saying with Devorah, it’s like, you know, go take a break. It’s like, I can’t, I’ve got, you know, I’ve got other things that I need to do because you think you understand how that person does their job and that’s just not true. And, you know, that’s not, you know, there’s 2 kind of upshots to that is you should be open to learning more about what your colleagues are going through, which is sort of that resilient people piece, but also this sort of curiosity that no, maybe even if it’s a job you’d did, maybe you don’t know how it’s changed in the months that you, you know, since you did it.

Mary: [00:54:19] Right, right. And I think part of that goes back to just the knowing exactly how your work is providing value to the business and knowing, you know, being able to draw that line back to, cool, here’s the project that I’m currently working on. Here’s the goal that it’s contributing to. Here’s the 5 other things that landed on my plate from other departments throughout the day. And part of it is keeping track of your work and keeping track of what, what it is you’re responsible for and what it is you’re being called into on a regular basis. And part of that is making other people aware about that as well, right? And having to be your own PR system, if you will, to remind people, this is the work that I’m doing, this is why my work is valuable, this is also why I need time off.

Matty: So these are all really interesting things, and I want to— I know, like I alluded to at the beginning of this conversation here, that there might be some cool new event that the two of you might want to tell us about where we might learn more about things like that. Maybe.

Mary: [00:55:20] Maybe. Yeah, just might maybe be true.

Matty: Can you, can you tell us a little bit about it there?

Paul: Yeah, well, so, you know, the ideas I— that, that we were talking about at the beginning of the podcast about, you know, safety and how do you build resilient systems. I mentioned chaos engineering, all of that stuff I think is becoming sort of front of mind in a lot of ways, especially for organizations that are like, we totally have the DevOps thing down. And there’s this very interesting Zen— it’s a Zen diagram, but it’s also a Venn diagram. About the whole people part. And so Mary and I got to talking about this quite a while ago, actually. It was probably, what, 9 months, a year, more than a year, year and a half.

Mary: I don’t know. This last year has gone so—

Paul: time flies, right? When you’re having fun, time flies when you’re burnt out. No, but we think that it’s time to have a conversation about that and to figure out what sort of, you know, there’s this idea of resilience and resilience engineering, again, in other industries, that then there’s this sort of, in the safety sciences, they’ve been looking at this. What does that mean for us? I think, to the point, Matt, you and I were talking about, what can we, what can we as technologists bring back to that conversation? I think there’s a lot of meat there that we’re not entirely seeing yet. So Mary and I wanted to put together a conference where we could look at that intersection of the technology part, but also the organizational part and the people part. And so, we put together a conference called Redeploy. The RE is for resilience engineering. That’s going to be this August. And we are super stoked about it because I think it’s time to have some of these conversations and to figure out together what it means.

Mary: [00:57:15] Yeah. And I think the biggest thing for me has been seeing people come out of the woodwork work, you know, after we launched and say, look, this is a conversation we’ve needed to have for a really long time. Because if you look at it, it’s not something that you can break down into clean pieces of, you know, resilient tech, resilient people, resilient teams. They’re all interrelated. They’re all connected. You can’t have resilient people without having resilient teams to support them. You can’t have resilient tech without having the resilient people and the resilient teams teams and the right processes to get that up and running either. So, it’s been cool to see how people have come out of the woodwork and gone, yeah, we need to have these conversations. We need to be talking about this more, and see how the community has been responding to it.

Paul: And I really loved, by the way, Matt, you had mentioned early on, it’s like, oh, safety, that just means more resilience means more redundancy and more backups and more of that. And Here’s the point that I want to make about that is, as I said earlier, that is the way we used to think about it. If you were to just think about it, if somebody asked you that question, that would be a totally intuitive, off-the-cuff first answer. But we’ve learned over the years that it’s not enough. That’s also the weird dichotomy is that when we say, oh, we’ll just have backups, it’ll be fine. How many of us have run, as operations engineers, have run disaster recovery sites that when you actually turn them on in a disaster, they don’t work? So, it’s like we have this odd experience where it’s like, well, backups just mean more redundancy. But then also, we have this gut feeling of experiences where it’s like, no, it’s more than that. That’s not enough. That’s not the only answer that it can be to get you what you need when we’re talking about these huge complex systems and operating them and operating them safely and operating them with some level of resilience, whatever that means, right? So I know, I know, um, Mary and I are super excited about like figuring out what resilience means in technology, um, as an industry and all of that entails.

Matty: [00:59:21] It’s like you’re saying, it’s more than just a technology problem.

Paul: Yeah, totally.

Mary: Exactly.

Matty: Crazy. Yeah.

Paul: So yeah, we’re super stoked. It’s in August, mid-August.

Matty: Great. Where can people find out more about it?

Paul: redeploy.io. There’s a redeploy.io and it’s 16th and 17th, August 16th and 17th.

Mary: Okay. Yeah.

Matty: What can we do to be a part of it?

Mary: We’re actively looking for sponsors and we have a link to some information and an email address on the site. You can send us an email, sponsors@redeploy.io. You can also follow us on Twitter. We are there, @redeployconf, R-E-deploy-conf on Twitter.

Paul: That reminds me, I need to find some GIFs.

Mary: GIFs are the best. Yeah. And one of the things that we’re doing is we are, of course, talking about tickets and CFP and everything else, but we’re also going through and retweeting people who are talking about this type of stuff throughout the industry. So even if you aren’t able to make the conference but you’re interested in the topics, feel free to go there to find more information about that.

Paul: [01:00:31] And also the Twitter account is a good kind of watering hole to, as Mary was saying, we are retweeting people that are talking about it. But also if you want to join that conversation, it’s a great way to do it just because we know that there are a lot of people with a lot of experience And a lot of people that are interested and a lot of people with sort of like kind of questions or gut feels about what it is. And that’s what this is about. It’s for all of us to get together and sort of figure that out together.

Matty: Everybody come and join me and Mary and Paul and probably a bunch of other super rad people at Redeploy. And again, a reminder, you can find out all about it at re-deploy.io. We’ll put a link to it in the show notes if you, you know, you know, they have to try to remember that later. And so thank you, both of you. Thank you, Mary. Thank you, Paul, for joining today. This was fantastic and fun as always. In a really quick run, just a couple— I’ve got a couple checkouts. I don’t know if there’s anything cool that you guys want to talk about, but I’m here right now recording this. I just finished up at ChefConf. So 2 things that were very cool that were announced today were Chef Workstation, which is the next generation of making it easy to get Chef going on your workstation.

Paul: [01:01:53] As the name would imply.

Matty: It would. It would. It’s like 5 years ago when there was ChefDK and everyone, wow. And now they’re like, hey, this is like 3 billion times better than that. I’m like, but that was awesome too. And then also, you know, Automate 2.0 was released and I did an installation of it to do a demo and it’s so, so nice to install. It’s all habitatted up and it’s nice and pretty and all the things work.

Paul: I changed everything I saw. I changed my Twitter name to Paul Paul Reed having ChefCon FOMO.

Matty: Yeah, I will tell you too, if you’ve seen the pictures and stuff, the brand team did a phenomenal job with this show. I mean, everything— there’s just so many little subtle things they did for the look and the feel of it. And, you know, the stage looked amazing. And, you know, Trevor pointed out that he thought it was the set of Rent. Um, it looked really good. Uh, another thing to check out is, uh, if you know me, you know that I’m always fighting with my address book and contacts and trying to have a good solution for that. And This tool I’m going to talk about doesn’t really do anything about deduping or anything fun like that, but it’s a really good contact manager for macOS. So it’s called Cardhop. It’s the same folks, it’s Flexibits, it’s the same folks who make Fantastical. If you use that for your calendaring, which is also a cool tool, so you can find that in the App Store. It’s called Cardhop and I’m digging it, at least for now until, you know, I don’t know, 2 months from now when I forget that it exists and I have it on my computer. As most tools do.

Mary: [01:03:22] Yes, yes, I resemble that remark.

Matty: Yeah. Um, any, uh, anything, anything cool you’ve discovered lately that you want to share with the listeners?

Mary: Uh, if I’m allowed to plug my own stuff, I absolutely discovered something cool the other day.

Matty: Is it cool?

Paul: Yeah, must be cool, Mary.

Mary: Um, so for those of you who are involved in developer relations, community building type stuff, Um, I mentioned a few examples about resilient teams and resilient people with regards to that today, um, but my book is now officially available for pre-order on Amazon. So if you go there, you can either just look up my name, which is kind of surreal, um, or you can do a search for The Business Value of Developer Relations.

Matty: And I’m in the book too.

Mary: That’s not the only reason I was gonna say our host, our host Matt is in book.

Paul: So I gotta go, I need to go to amazon.com immediately.

Matty: And I just— one other is, you know, in the spirit of Mary, you know, promoting her own stuff, apparently you can’t, you know, be an internet brand without your own mailing list. So in addition to— there is the Arrested DevOps mailing list, the Banana Stand, which you can subscribe to at arresteddevops.com/bananastand. But a little— if you’re looking for a little bit more more news, more specifically about the stuff that I’m reading, you can subscribe to the DevOps Dispatch. So that’s at devopsdispatch.com, and I’ve been sending that out. It’s a, you know, kind of have some podcast episodes that I’ve been listening to, not necessarily recent ones, and given that I’ve been listening to old Ship Show stuff, you may find some of that coming up in the next issue. It’s also a good place to figure out where I’ve been, where I’ll be speaking next If you decide that matters to you, so yeah, devopsdispatch.com. And I have to give props to Mary for tuning me into curated, which is what I use for that. So I all cool tools I know about somehow come from Mary.

Paul: [01:05:18] I need to I need to note something. Don’t be stupid like I am, and I I typed devops-dispatch.com, which is nothing.

Matty: Oh, so this it’s nothing.

Paul: There is.

Matty: I was going to say, how could that be something inappropriate?

Paul: No, no, no, no, it’s nothing. I so you said DevOps Dispatch, and I. I think because we were talking about the hyphen in redeploy, I’m just automatically, I’m like, ama-zon.com doesn’t go anywhere.

Matty: Right. Well, you’re just shocked that I was able to get the domain that I wanted.

Paul: Don’t fear. And the top one right now is, yeah, the top one right now is Don’t Fear the Rebase, which I’m already pulled in.

Mary: Nice.

Paul: You’ll be, I’ll be grandpa ranting about it in 20 minutes.

Mary: Yeah.

Matty: Excellent.

Mary: Seriously though, if anyone else is looking for newsletter stuff. Curated is amazing. I use it for my own DevRel Weekly, and it’s, it’s a great, great, great resource.

Matty: That’s at curated.co. Is that how we say that domain, co, or do we say co?

Mary: I say co.

Matty: They say co. Curated.co. So finally, before we go, Paul and Mary, you want to let our listeners know where they can find you on the internets and maybe where they can find you in the real life coming up in the near term.

Paul: [01:06:29] In the real life. Mary, how can we find you?

Mary: Sure. You can find me on Twitter @Mary_Grace or MaryGrace.community is my website.

Paul: You can find me on the tweet sphere @JPaulReid. We mentioned that and JPaulReid.com and all of my speaking engagements. There’s a page on there if you’re interested and want to see me in the IRLs.

Matty: So, yeah, Mary and Paul, thank you again.

Mary: Thanks so much. It was great being here.

Paul: Yeah, thanks, man. Appreciate it.

Matty: Head on over to arresteddevops.com/safety for this episode’s show notes. The site also has our newsletter, past episodes, all the Arrested DevOps stuff you could ever want. Visit arresteddevops.com/itunes and leave us a review in the iTunes Store if you want to help other people find our podcast. I’m Matty at Matt Stratton. And remember, this is Arrested DevOps. And there’s always DevOps in the banana stand.