 from Union Square in downtown San Francisco. It's theCUBE, covering PagerDuty Summit 18. Now, here's Jeff Frick. Hey, welcome back everybody. Jeff Frick here with theCUBE. We're in downtown San Francisco. I can see the western St. Francis on Union Square, historic property, this beautiful ballroom, lots of brocade and fancy stuff from another era, but we're talking about this era and the era of information. We're here at PagerDuty Summit and we're really excited to have one of the keynote speakers, John Ospal joining us. He is the co-founder of Adaptive Capacity Labs. John, great job on the keynote. Thanks, thanks a lot. I'm glad that it landed. You know, it's funny. We go to literally hundreds of tech conferences a year and so often, you know, the tech has talked about, but as you brought up, where's the human factors? Where are the people? Where in all these lovely diagrams, as you pointed out, with beautiful lines and everything is very straight and boxes are very clear. That's not really how the real world works at all. No, no, yeah, that's what I find really fascinating, which is that with a lot of, certainly get a lot of attention to incidents when they show up, outages and that sort of thing, but we don't get a real shot at understanding how non-incidents happen and they happen all the time, right? Outages are being prevented all day long and sort of, but it doesn't really get our attention and it doesn't get our attention because that seems normal and that's the sort of assumption that there's like a quiet sort of background and that an incident is sort of like a punctuation of something bad and that otherwise sticks up like Mount Hood, right? But the fact of the matter is there's so much going on and that's actually that stuff that's going on is this activity that people are doing to prevent outages continually and that's what I find fascinating. So you really never get like your classic kind of experiment where you can isolate the variables, right? Because they're all completely commingled all the time. Yeah and that's what's fascinating that what I like, what we say is that we study cognitive work and the difference between sort of these types of human factors and cognitive work studies and the difference between that and say sort of classic psychology is classic psychology can be done in a lab. We study cognition in the wild, as they say, the natural laboratory that is the world. Right. And the other thing I thought you brought up which was really interesting is really kind of what's the point, right? Is the point just to fix it? Is the point to try to identify this little thing and fix it? Or is the point kind of a higher level objective which is to actually learn so that we're doing the things in the future that keep the sync from happening again and you summarized it really, really well and you're talking about the post boredom which you said, you know, are you doing this report to be read? Or are you doing it to be filed? Very different objectives going to have a very different report at the end of the process. Right, right, right, yeah. And I think that that's the sort of the danger is if we, as an industry, I think we just need to bring some attention to that and the good news is that it's hard work to look at incidents in a different way. It's a way that we're not used to. It's effectively qualitative research. And so it's difficult but it's not impossible. It can be learned, it can be taught and my hope is that these sorts of bringing attention to the topics will get people to be curious and want to understand more. Right, and it'd really take it up a notch and I think again you have some really easy to implement lessons there like what are the questions? Document the questions in the post boredom. Document the concerns in the post boredom. Did those concerns happen? Did they not happen? Why didn't they happen? So really kind of take it up a level from the incident really as kind of a catalyst for a conversation and learning but that's really not what the foundational effort should be around is fixing that little thing. Right, right, well that's the thing is that if the goal is to fix then and that is the goal. You're gonna find something to fix. It may or may not be helpful. What you fix comes from exploring and there are things that shouldn't be fixed right now. Everybody's making decisions. I mean this is the entire premise of Agile which is that continual, iterative, reprioritization, recalibration of what's important. So we'll be happy to put effort into that but yet it doesn't, it seems disingenuous to phone it in when it comes to understanding incidents. Right, you got into so many things we could go forever and ever. One of the things you talked about and it's often spoke about as you know winners write the history books. It was really about the bias that you bring to a problem. What do you think is the most important and what filter and lens are you both looking at the problem, reporting the problem and then you know, or diagnosing and then reporting the problem which may or may not be root cause, may or may not be the most important thing about that but those biases influences the way not only is that problem perceived but then documented, resolved and talked about after the fact. Really important. Yeah, absolutely. And there's something really paradoxical about that. And one of the things that it brings to mind is that I don't think that yet we are in a world where we, when I say we, I mean software industry will bring attention to or report on near misses. The scenarios where you know what you thought you were in Dev but you were in prod and you ran a command that if it had a couple of other parameters, it would have destroyed everything but it turns out that actually it was, it was this one, you know, there's a couple of characters made it such that it was a near miss. It wasn't a, you know, it wasn't a big deal. Do you, is that an incident? Right? Right, right. So if, on the one hand you can say well, there are no customer impact. Right. So therefore let me look up on my, oh no, that's not an incident. So therefore we shouldn't pay any attention to it. But think of any other sort of high tempo, sort of high consequence domain, they've learned aviation isn't a good example. There are organizations in aviation that will actually and they find them to be incredibly useful because they're low risk things to pay attention to. It didn't happen this time, but we can bring attention to the possibility that we might, it might go poorly the next time. Right. So what triggers the action to recognize that you had a near miss? And is that, you know, working its way into best practices DevOps? Well, I mean, my organization at Etsy, I certainly, I'll, full disclosure, I made quite a good number of mistakes at Etsy. This isn't one of them. And getting into habit of, you know, what had happened there was people sending PSA emails, public service announcements. And they were basically, it was basically, the format was, hey everybody, check this out. I was doing this and I went to go do blah and I almost exploded everybody. Like that, so, so FYI, if you're doing this, don't do it. Everything's cool. I'm gonna put in these things to sort of help it out, but until we get that done, be really careful about this part, you know, whatever. Even just that, even small things like that, keep the topic of how precarious these scenarios can be in the minds of people who aren't experiencing incidents. Right, right. Tomorrow you might be that one or tomorrow you might be, and so here's your colleague, like taking the time to spend some effort, could be saving your bacon tomorrow. Right. You might be doing it in a similar spot. Right, but how's it codified and how is it communicated? I mean, so another concept you touched on, which has a broader implication, but you talked about it specifically and really that's diversity of opinions leads to better decision-making. And you gave some examples of, you know, bringing in disparate members of various teams with different experiences, points of view, to pull out things like the esoteric knowledge, to pull out the institutional knowledge. But more importantly, to pull out a different point of view. So we hear about it a lot with, you know, diversity of teams and sex and culture, et cetera, but even within the context of solving an engineering problem, you know, diversity and points of view does lead to better problem solving. So I want to make a sort of a crisp clarification. It is the variety of perspectives. Actually, the variety of expertise and the variety of experience, not opinions or perspectives. Perspectives, you can probably, that's a word you can probably go with, but I wouldn't say diversity of opinion. That has a connotation that is not concrete enough. What we're talking about is cognitive work, how people assess, this is something that requires my attention, it requires my attention in these ways, based on my experience with this particular type of problem over, you know, this different variations of it. So yeah, I mean, the general sense is, but the phrase diversity of opinion generally has a connotation of the individual attributes of a person. I'm not talking about that. I'm talking about the- These are individual attributes that have been gleamed through experience. It's not individual, it's not an attribute, it's experience. It's experience, right. Right, exactly. An attribute of me is that I'm five foot nine. My experience is that I have seen Apache break in a myriad of different surprising ways. Right, there's the sort of the difference. Right, the difference, okay. But then the other point you brought up even in that conversation was, it's always messy, there's always trade-offs is, you get management overhead as soon as you have more than one person working on a problem. Right now you have communication overhead, you've got management overhead. So now you're pulling resources from actually devoting it to the task at hand of trying to solve the problem versus having to devote resources to bring other people up to speed, communicate, et cetera. So it's not even a really easy trade-off. Yeah. I mean, but there's consequences to the action. Oh yeah, absolutely, absolutely. And again, I think that coping with complexity requires an equal amount of complexity, right? You might not say that baseball team that is very good at doing double plays, right? Which is a pretty hard thing to pull off even in professional baseball. Would you say that the coach represents overhead? I don't know if you would say it that way, exactly. But there's certainly limitations to the sports metaphor, but I certainly, I like very much a renewed emphasis on building, maintaining, and sort of resolving incidents with software as much more benefiting from collaboration, collaborative work, meaning real sort of teamwork, not just sort of the sort of sparse collaboration. Well, John, it's a fascinating field we could go on all day long, and of course you're going to have to leave it there but really, really enjoyed the conversation and also the keynote earlier today. Great, thanks a lot. Thanks for talking. All right, thank you. He's John, I'm Jeff. You're watching theCUBE. At the Weston St. Francis Union Square. Thanks for watching.