(upbeat techno music) >> 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, actually the Westin St. Francis on Union Square, historical 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 Allspaw join 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, the tech is talked about but as you brought up, where is 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, 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. But it doesn't really get our attention. >> Right. >> And it doesn't get our attention because that seems normal and that's the sort of, this assumption that there's a like a quiet sort of background and that an incident is sort of like a punctuation of something bad and that otherwise sticks up, you know, like Mount Hood, right? >> Right, right. >> But the fact of the matter is there's so much going on. >> Right. >> 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? >> No. >> Because they're all completely co-mingled, all the time? >> Yeah, and that's what fascinating. What I like and we always 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. >> Right, right. >> 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 link 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 this thing from happening again? And you summarized it really, really well and you talked about the post mortem which you said, "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. I think that 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. It's difficult but it's not impossible, it can be learned, it can be taught and my hope is that sort of these sorts of bringing attention to the topics will get people to be curious and want to understand more. >> Right and 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, >> Yeah. >> In the post mortem. >> Yeah. >> Document the concerns in the post mortem. 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 and that's the thing, is if the goal is to fix, and that is the goal, you're going to 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 re prioritization, recalibration of what's important so we'll be happy to put effort into that but yet, it seems disingenuous to phone it in. >> Right. >> When it comes to understanding incidents. >> Right, right. You got on to so many things, we could go forever and ever. One of things you talked about and it's often spoke about, is 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 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 not only is that problem perceived but then documented, resolved and talked about after the fact. Really important. >> Yeah, yeah, absolutely and there's something really paradoxical about that. 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 the software industry, will bring attention to a 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 this one, you know these couple of characters made it such that it was a near miss. It wasn't a big deal. Is that an incident, right? >> Right, right. >> On the one hand you could 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, high consequence domain? >> Right. >> They've learned, aviation is 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 it might go poorly the next time. >> Right, so what triggers the action to recognize that you had a near miss? And is that working it's way into best practices dev ops? >> Well, I mean, at my organization, at Etsy, I certainly, full disclosure, I made quite a good number of mistakes at Etsy. This isn't one of them. Getting into habit of what had happened there was people sending PSA e-mails, public service announcements and 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. So FYI if you're doing this, don't do this. Everything's cool and I'm going to 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 in the similar spot. >> Right. How's it codified and how is it communicated. So another concept you touched on, which has a broader implication, but you talked about specifically and really that's diversity of opinions leads to better decision making and you gave some examples of bringing in disparate members of various teams with different experiences, points of view. >> Yeah. >> To pull out things like the esoteric knowledge, to pull out the institutional knowledge. >> Yeah. >> But more importantly, to pull out a different point of view. So we hear about it a lot with diversity of teams, and sects, and culture, et cetera but even with the context of solving an engineering problem diversity and points of view does lead to better problem solving. >> I want to make 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. Perspective you can probably, that's word you can probably go with. I wouldn't say diversity of opinion, that has a connotation that is not concrete enough. >> Okay. >> 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 this different variations of it. >> Right. >> Yeah, I mean the general sense is, but the phrase diversity of opinion generally has like a connotation of the individual attribute of a person. I'm not talking about that. I'm talking about the-- >> These are individual attributes that have been gleaned through experience-- >> It's not an attribute, it's experience. >> It's experience, right okay. >> Right, exactly. An attribute of me is that I'm 5'9", my experience is that I have seen Apache break in a myriad of different, surprising ways, right? (laughter) There's sort of the difference. >> Right, 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 know, 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? >> Oh yeah. >> Or not trade off, I mean but there's consequences to the action. >> Oh yeah, absolutely, absolutely. And again, I think coping with complexity requires an equal amount of complexity, right? You might not say that a 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. I like very much a renewed emphasis on building, maintaining and sort of, resolving incidents with software as much more benefiting from collaborative work. >> Right, right. >> Meaning real sort of teamwork. >> Right. >> Not just sort of sparse collaboration. >> Right, right. Well John, it's a fascinating field, we could go on all day long. >> Yes we could. >> Unfortunately, we're going to have to leave it there but really, really enjoyed the conversation. >> Great. >> And also the keynote earlier today. >> Great thanks a lot. Thanks for talking. >> Alright, thank you. He's John, I'm Jeff, you're watching theCUBE. We're at PagerDuty Summit at the Westin St. Francis, Union Square. Thanks for watching. (upbeat techno music)

>> Narrator: From around the globe, It's theCube, with digital coverage, of Actifio data-driven 2020, brought to you by Actifio. >> Welcome back, I'm Stu Miniman, and this is theCube coverage of Actifio Data-driven 2020. Really excited to, dig into a fun topic. I have a Cube alumni with us he is a DevOps author, and researcher Gene Kim. Unicorn Project is the most recent, Gene, great to see you, thanks so much for joining us. >> Stu, great to see you again, here at the Actifio conference, this is all fantastic. >> Yeah, so your new book, it was much awaited out there, you know, Unicorn's always discussed out there, but you know, the Phoenix Project, as I said, is really this seminal, book when people say, What is that DevOps thing and how do I do it? So, why don't you give us a little bit as to The Unicorn Project, why is it important? Why we're excited to dig into this and, we'll, we'll tie it into the discussion we're having here for the next normal, at Actifio. >> For sure, yeah, in fact, yeah. As you might have heard in the keynote address, you know, the what, what vexed me, after the Phoenix project came out in 2013 is that there is still looming problems that still remain, seven years after the Phoenix project was written. And, you know, these problems I think are very important, around you and what does it really take to enable developers to truly be productive, instead of being locked in a tundra of technical debt. Two is, you know, how do we unlock truly the power of data so that we can help everyone make better decisions, whether it's a developer, or anyone, within the business units and the organizations that we serve. And then three is like, what are really the behaviors that we need from leadership to make these amazing transformations possible? And so The Unicorn Project really is, the fifth project retold, but instead of through the eyes of Ops leadership, is told through the eyes, of a phenomenal developer. And so it was amazing to revisit the, the Phoenix project universe, I in the same timeline, but told from a different point of view. And it was such a fun project to work on, just because, you know, to relive the story, and just expose all these other problems, not happening, not on the side, but from, the development and data side. >> Yeah. They've always these characters in there that, I know I personally, and many people I talked to can, you know, really associate with, there was a return of certain characters, quite prominent, like Brent, you know, don't be the bottleneck in your system. It's great, if you're a fighter firefighter, and can solve everything, but if everything has to come through you, you know, Pedro is always going off, he's getting no sleep and, you know, you'd just get stressed out. You talked a bit more, about the organization and there are the five ideals in the book. So maybe if you can, you know, strongly recommend, of course, anybody at ending active you, got a copy of the books they'll be able to read the whole thing, but, you know, give us the bumper sticker on some of those key learnings. >> Yeah, for sure, yeah. So the five ideals represents five ideas, I think are just very important, for everyone, the organization, serves, especially leadership. The first ideal is locality and simplicity. In other words, when you need to get something done, we should be able to get it done within our team, without having to do a lot of communication coordination, with people outside of our team. The worst, the most horrible feeling is that in order, to do a small little thing, you actually have, to have a, coordinated action that spans 15 teams, right. And that's why you can't get anything done, right? And so that's so much the hallmark of large complex organizations. The second ideal is that what I think the outcomes are, which is focused flow and joy, you know, I've not just now started to for the first time in 20 years, self identify, not as an ops person, but as a developer. And, I really now understand, why we got into technology in the first place. This so that we can solve the business problem at hand unencumbered by minute share. And that allows for a sense of focus flow and even joy. And I love how Dr. Mihaly Csikszentmihalyi, describe it. He said, flow is a state that we feel when we love our work, so much that we lose track of time, and maybe even sense of self. And so I think we all in technology understand, you know, that that is how it is on the best of days and how terrible it is, you know, when we don't have that sense of flow. Third ideal is improvement of daily work, being even more important than daily work itself. The notion is greatness is never free, we must create it and must prioritize it, for the psychological safety. And the fifth is customer focus. So those are all the things I think are so important, for modern leaders, because it really defines the future of work. >> Yeah, we love that flow and it happens otherwise we're stuck, in that waiting place as you quoted Dr. Csi. So one of my favorite books there, there also. So Gene, for this audience here, there was, you know, yes, CICD is wonderful and I need to be able to move and ship fast, but the real transformational power, for that organization was unlocking the value of data, which is, I think something that everybody here can. So maybe to talk a little bit about that you know, we, there there's, we've almost talked too much, you know, data is the new oil and things like that, but it's that, you know, that allowing everybody to tap in and leverage, you know, real time what's happening there were just at the early parts of the industry being able to unlock that future. >> Oh yeah, I love that phrase. Data is new oil, especially since oil, you know, the last 50 years, the standard Port 500 was dominated by, you know, resource extraction oil company and so forth. And now that is no longer true, it's dominated by the tech giants. And, Columbia there was a Columbia journalism review article that said, data's not only the new oil, is really the new soil. And for me, you know, my area of passion for the last seven years has been studying the DevOps enterprise community where, we're taking all the learnings that were really pioneered by the tech giants, Facebook, Amazon, Netflix, Google, Microsoft, and seeing how they're being adopted by the largest, most complex organizations on the planet, the best known brands across every industry vertical. And it's so true that, you know, where the real learning gets exploited right, is through data. I realized, this is how we get to know our customers better. This is how we understand their wants and needs. This is how we test, and make offers to them to see if they like it or not to see if they value it or not. And, and so for me, one of the best examples, of this was, the target transformation and Adidas how it was just an amazing example of, to what links they went to, to liberate developers from, being shackled by ancient systems of records, data warehouses, and truly enabled developers to get access to the data they need modify it, even delete information, all without having to be dependent on, you know, integration teams that were essentially holding them hostage for six to nine months. And, these programs really enable some of the most strategic programs at their organizations, you know, enabling hundreds of projects over the years. So, I think that is really, just showing to what extent, the value that is created by unlocking data for individuals. And sorry Stu, one more thing that I'm just always dazzled by my friend, Chris Berg. He told me that, somewhere between a third and a half of all company employees use data in their daily work. They either use data or manipulate data as part of the daily work, which, you know, that, population is actually larger than the number of developers in an organization. So it just shows you how big this problem is, and how much value we can create by addressing this problem. >> Well, it's interesting if it's only a third, we still have work to do. What we've been saying for years is, you know, when you talk about digital transformation, the thing that separates those that have transformed and those that haven't is data needs to be at the core. I just can't be doing things the way I was or doing things off intuition, you know, being data-driven, I'm sure you know, the same Gene, if you're not, if you don't have data, you know, you're just some other person with an opinion. >> Yeah, yeah. That's it this is a great point. And in Risto Siilasmaa's amazing book, Transforming Nokia, I mean, he was, he said exactly that. And he said something that was even more astonishing. He said, there's not only at the core, but data also has to be at the edges. You know, he was describing at Amazon, anyone can do an experiment @booking.com. Anyone can do an experiment to see, if they can create value for the customer. They don't need approvals from, committees or their manager. This is something that is really truly part of everyone's daily work. And so, to me, that was a huge aha moment that says, you know, to what degree, you know. Our cultures need to change so that we can not only, use data, but also create learnings and create new data, you know, that the rest of the organization can learn from as well. >> Yeah. One of the other things I definitely, you know, felt in your book, you synthesize so much of the learnings that you've had over the years from like the DevOps enterprise summit. The question I have for you is, you know, you hear some of these, you know, great stories, but the question is, our companies, are they moving fast enough? Have they transformed the entire business or have they taken, you know, we've got one slice of the business that is kind of modernized and we're going to get to the other 30 pieces along the way, but you know, there's wholesale change, you know, 2020 has had such a big impact. What's your thoughts on, you know, how we are doing in the enterprise on pace of change these days? >> That's a great question. I mean, I think some people, when they ask me, you know, how far are we into kind of total adoption of DevOps? It's a newer better way of working. And I would say probably somewhere between 5 and 7%, right, and the math I would take them through is, you know, there are about 20 million developers on the planet of which at best, I think, a million of them are working in a DevOps type way. But yet now that's only growing. I think it was an amazing presentation at DevOps surprise summit in London that was virtual from nationwide building society, the largest organization of its kind. It's a large financially mutually owned organization for housing in the UK. And, they touched about how, you know, post COVID post lockdown suddenly they found themselves able to do them reckless things that would have normally taken four years, in four weeks. And I think that's what almost every organization is learning these days is, when survival is at stake, you know, we can throw the rules out of the window, right. And do things in a way that are safe and responsible, but, you know, create satisfy the business urgent needs, like, you know, provisioning tens of thousand people to work from home safely. You know, I think the shows, I think it's such a powerful proof point of what technology can do when it is unleashed from, you know, perhaps unnecessarily burdensome rules and process. And I think the other point I would make Stu is that, what has been so rewarding is the population of these technology leaders presenting at DevOps enterprise, they're all being promoted, they're all being, being given new responsibilities because they, are demonstrating that they have the best longterm interest of the organization at heart. And, they're being given even more responsibilities because, to make a bigger impact through the organization. So I'm incredibly optimistic about the direction we're heading and even the pace we're going at. >> Well, Gene definitely 2020 has put a real highlight on how fast things have changed, not just work from home, but, but the homeschooling, you know, telehealth, there are so many things out there where there was no choice, but to move forward. So the, the second presentation you participated in was talking about that next normal. So give us a little bit of, you know, what does that mean? You know, what, what we should be looking at going forward? >> Yeah, it was great to catch up with my friend Paul Forte, who I've known for many, many years, and now, now a VP of sales at the Actifio and yeah, I think it is amazing that academic Dr. Colada Perez, she said, you know, in every turning point, you know, where, there's such a the stage for decades of economic prosperity usually comes, by something exactly like what we're going through now, a huge economic recession or depression, following a period of intense re regulations there's new, technology that's unlocking, you know, new ways of working. And she pointed exactly to what's happening in the Covid pandemic in terms of, how much, the way we're working is being revolutionized, not by choice, but out of necessity. And, you know, as she said, you know, we're now learning to what degree we can actually do our daily work without getting on airplanes or, you know, meeting people in person. So, I'm a hue, I have so many friends in the travel industry, right. I think we all want normalcy to return, but I think we are learning, you know, potentially, you know, there are more efficient ways to do things, that don't require a day of travel for a couple hour meeting and day to return, right. So, yeah, I think this is being demonstrated. I think this will unlock a whole bunch of ways of interacting that will create efficiency. So I don't think we're going, as you suggested, right. There will be a new normal, but the new normal is not going to be the same as your old normal. And I think it will be, in general for the better. >> So, Gene, you, you've gone to gotten to see some of the transformation happening in the organizations when it comes to developers, you know, the, the DevOps enterprise summit, the, the state of DevOps, you know. I think five years ago, we knew how important developers were, but there was such a gap between, well, the developers are kind of in the corner, they don't pay for anything. They're not tied to the enterprise. And today it feels like we have a more cohesive story that there, there is that if you put in The Unicorn Project, it's, you know, business and IT, you know. IT, and the developers can actually drive that change and the survival of the business. So, you know, are we there yet success or net developers now have a seat at the table? Or, you know, what do you see on that, that we still need to do? >> Yeah, I think we're still, I mean, I think we're getting there, we're closer than ever. And as my friend, Chris O'Malley the CEO of the famously resurgent mainframe vendor Compuware said, you know, it is, everyone is aware that you can't do any major initiatives these days without some investment in technology, right? In fact, you can't invest in anything without technology. So I think that is now better understood than ever. And, yeah, just the digital, it's a whole digital disruption, I think is really, no one needs to be convinced that if we organize large complex organizations, don't change, they're at a risk of, you know, being decimated by the organizations that can change using an exploiting technology, you know, to their benefit and to the other person's detriment. So, and that primarily comes through software and who creates software developers. So I, by the way, I love the Stripe it was a CFO for Stripe who said, the largest, constraint for them is, and their peers is not access to capital, it is access development talent. I think when you have CFOs talking like that, right. It does says it's suggested something really has changed in the economic environment that we all compete in. >> So, I mentioned that on the research side, one of the things I've loved reading over the years is that, fundamental discussion that, going faster does not mean, that I am sacrificing security, or, you know, the product itself, you know, in the last couple of years, it's, you know, what separates those really high performing companies, and, you know, just kind of the middle of the ground. So, what, what, what advice would you give out there, to make sure that I'm moving my company more along to those high performing methods. >> Yeah, but just to resonate with that, I was interviewing a friend of mine, Mike Nygaard, long time friend of mine, and we were talking on and we were recalling the first time we both heard the famous 2009 presentation doing 10 deploys a day, every day at flicker, by John Allspaw and Paul Hammond. And we were both incredulous, right there? We thought it was irresponsible reckless, and maybe even immoral what they were doing, because, you know, I think most organizations were doing three a year, and that was very problematic. How could one do 10 deploys a day. And I think, what we now know, with the size of evidence, especially through the state of DevOps research, is that, you know, for six years, 35,000 plus respondents, the only way that you can be reliable, and secure, is to do smaller deployments more frequently, right? It makes you, be able to respond quicker in the marketplace, allows you to have better stability and reliability in the operational environment, allows you to be more secure. It allows you to be able to, you know, increase market share, increase productivity, and, you know, have happier employees. So, you know, at this point, I think the research is so decisive, that, you know, we can, as a whole book accelerate, that really makes the case for that, that this is something that I now have moral certainty or even absolute certainty oh, right. It's, you know, self evident to me, and it, I think we should have confidence that that really is true. >> Wonderful work, Gene, thanks so much for giving us the update. I really appreciate it, some really good sessions here in Actifio, as well as the book. Thanks so much, great to talk to you. >> Stu is always a pleasure to see you again, and thank you so much. >> Alright, that's our coverage from Actifio Data-driven, be sure to check out thecube.net for all of the, on demand content, as well as, as I said, if you were part of the show, definitely recommend reading Gene's book, The Unicorn Project. I'm Stu Miniman. And thank you for watching the cube. (soft upbeat music)