 Welcome again to another OpenShift Commons briefing today is Friday and as we want to do on Fridays we have folks to talk about transformation, organizational transformation, cultural shifts and all those kinds of wonderful things. And on today we have with us John Willis from the Global Transformation Office and he's going to have a conversation about conversations, organizational conversations. I'm going to let John take it away and introduce himself and we'll have live Q&A at the end. So John, take it away. Thank you. Great. Thanks Diane. Thanks for everything you do for this. This is an awesome, you and Chris, thank you so much. Yeah, so organizational conversations. What the heck is this? So hopefully I'll give you some insight of what I've been thinking about for the last two or three years and actually having some fun at Red Hat doing some of this stuff too. So, John Willis, I'm part of the Global Transformation Office and Jay Willis at Red Hat. Our team, if you've been coming here on Fridays, you've probably gotten to meet Andrew Clay Schaefer. He's my boss, one of my best friends. I've been working with him for years. We kind of co-created on the shoulder of giants with many other people but the DevOps movement. Kevin Bear next to him is one of the authors of the Phoenix Project. That's me on the short guy there. And then Jay Bloom to my right has been working with Kevin for years and I've known all these guys for years and they're just... I say that I feel like I'm Willy Wonker in the chocolate factory working with these guys. It's just an amazing team to be on. Andrew likes to say we wrote some books. So I was the co-author of the DevOps Handbook and the Beyond the Phoenix Project and I've got a fair amount of other publications that wouldn't fit on the page. So one of the things that I started thinking about, I won't give you my resume, go to my LinkedIn profile, Jay Willis at John Willis Atlanta, something nonsensical like that. I was a doctor and I had been like 12 years in vendor space. I was very early chef. I sold a company at Dell. I sold a company at Docker. And by the time I was ready to leave Docker, I was really excited about going out and being independent. I built enough mind share with the community. Before I had that run, which was about 12, maybe 15 years, nobody really knew me. By the time I was sort of ready to leave Docker, which is about three years ago, I built up enough mind share with the community. I thought, okay, I'm going to put a shingle out on the console. And I thought, okay, I'm going to use all the things in DevOps Handbook. Lean Value Stream Mapping, Impact Mapping, just this, this, this, hosting, there should carry. All these different things, sorry, I mangled that. But Lean. And in my first client, I realized every time I tried to inject a framework or a model, the conversation just stopped. And then, so, so I started going on this idea that, like, if you really want to find the truth, and you're going to the core of an organization's sort of behavior or problems, you know, you can't lean, agile, safe, or even, sorry, kids, even SRE your way around the bad organizational culture, or more importantly, bad, you know, institutionalized, sort of memory muscle, you know, bad behaviors. So I started, I didn't know, I still don't really know what a great name of it is. Pretty sure organizational conversations is not. It's just the one I call organizational anthropology. Other people have given it names to me. But it's really an idea where you, where I just literally go in and I have conversations with people. So typically, I get to work. The only way this works is to work, which is usually a CIO. I say, here's how this is going to work. In fact, what typically happens is people say, John, can you come in and sprinkle pixie dust all over our DevOps? And I'm like, yeah, sorry, it doesn't work that way. And then but what I can do is do this. And in a very few companies, and I'd be honest with you, a lot of times I'm interviewing the CIO because, you know, some chief of staff or somebody will bring me in to CIO tell the CIO, you need to hear John, you need to hear what he has to talk. And, and I'll, at the end of that, I'll go back to the person, the champion that tried to get me in and I'm like, you know what, your CIO is not ready for this. Like, you will be wasting your time and wasting your money. Right. So there's a synergy that I find where a CIO is willing to say, you know what, I'm going to take a try on this. And then they blast out of, you know, please pay attention, don't bring your laptops, you know, unless it's a fire, you know, but sit in the room with this person for an hour and a half or two hours in different groups and let him ask you questions. I want to see how it does that. Most people show up, right? And the one thing I've learned back to the frameworks, like my instinct, easily as a trainer, as somebody who speaks and, you know, tries to always sort of educate people, which is my nature, whether I'm presenting or not, is that when you're in these conversations, you want to correct people if they say something like, oh, let me teach you so that's not, you can't do that. You need to just listen. And that's sort of anybody's trying this model and just make sure. Because again, what you don't want to do is when you're into like 30 minutes of 15 or 20 people having this great conversation, telling you how things really work, you don't want anything to derail that. So the other thing I think a lot about is, you know, Andrew Clay Schaefer, you know, I think he's the first time I've seen him in DevOps where he took Andrew's grade at like metaphors. He's awesome. He did the blind, you know, DevOps, you know, sort of a DevOps, you know, blind person and, you know, sort of the elephant. And it's an old sort of metaphor. And I look at this as like, you know, this is what leadership, right? So the CEO is touching the trunk and he thinks it's a snake. Maybe the CTO, she's touching the tail and she thinks it's a rope on and on, right? But the thing is, this is sort of systemic of the problem, right? You have the blind IT, right, where Dev is touching and, you know, possibly just really just trash the metaphor. The leadership one is, you know, is a purple elephant and the IT one is an orange elephant. So they, again, not being able to see that the context is different from release and network and dev, right? So this is just, you know, we all know this, right? IT is an elephant, right? In today's world, it's a very, very complex structure. And, you know, I thought I'd have a little more fun, you know, that maybe government is just in compliance. It's not even an elephant, right? It's not even just a different color. It's the giant attacking rabbit, you know, the Trojan rabbit, right? Money Python, right? So how do you get the point, right? Like that is the problem, right? Sort of our context, our individual, our team, our group, even our leadership context are, you know, we see things with different, you know, you know, memory models or models, cognitive models, right? And so that's just human nature, right? So right off the bat, we're host. No, we'll do fine. So there's this notion, if you've ever started a company, or you do start a company, you'll be heard very early by somebody, usually your lawyer, that there's this thing called piercing the corporate veil. You know, as we said, if you don't act like a corporation, you know, the IRS could come in and say, you have no, you know, you have no journals, you have no sort of meeting notes. Anyway, they call it piercing the corporate veil. But I think this is like what I call piercing the organizational veil, right? Which is, you know, the veil is this adversary relationship of consultants come in. And then the people who are sort of doing the work are like, well, here comes the Bob's, right? The Bob's in office hours, a classic example, right? Like, you don't want to tell them anything or you're afraid to tell them anything or you need to always spin things that they're better than they aren't because you don't want to be the one that gets fired. So what I have to do is come in and earn trust or somebody who sort of evolves this model, earn trust so they don't seem like the bombs. And I need to, I can't ask you questions like how is your CMDB, how accurate is it? Oh, John, it's fine. You know, and you know, no open critical vulnerabilities or CVS is on your production assistance. No, no, no, John, don't worry, right? So you have to sort of gamify a little bit, but it's a trust. It's getting people to sort of open up to you. And actually, it's not that hard. You know, sometimes I walk in a room and I just say, hey, what's wrong with this place? And then I just take notes for another hour and a half. And you can't shut people up. And so it's conversations at the edge. It's another really important thing about this is that is that, you know, a lot of times when I come in, I've been called the anti-McKinsey, right? Which is like such a compliment, right? So I shouldn't call it any. So think of McKinsey as any one of the large consulting companies. But the model of most of our industry is they come in and they already know what they're going to tell you. And they do a little bit of lip service to, oh, we want to listen, but they don't. Really, they're just trying to convince senior leadership that they've listened and that they have the right answer. And so one of the things about this model, and I call it a model as a stretch, too. I don't really know what it is yet other than I know it works. So, is that I honestly, even though I have lots of sort of meta and process of how to do things, you know, as an educator, as an implementer, as a, you know, quote, unquote, thought leader, which is a terrible phrase, but for lack of a better one. But I really try not to go in with the solution. And the other thing is I don't really want to have an in-depth conversation with the leadership. You know, you'll see some examples in a model in a minute, but I want to have long, long conversations with people, what I call on the edge, the people who put their fingers on the keyboard. And if you can get enough of them to tell you what's going on, you give this beautiful look of outside in that most organizations have never really done to this level. You know, surveys, they don't work, right? Or let me speak. They don't give you this level of truth and depth to what your problems really are. I mean, I can generically walk in the door and say, I'm your bank. I'm pretty sure you have this, this, this and this problem. And chances are I'm about 80% right. And anybody else who has a reasonable understanding of what we do and things called DevOps or transformation. But the truth is I don't really know if I'm right. What I know I'm right is when I can connect the dots from what people say, right? So, and the other thing I realized over time is, you know, when you're going in and you're doing all this sort of analysis, so basically you're just discovery. I mean, you're just taking notes with hundreds of people. And then you have to figure out like, how do I take all this stuff? Because Joe said, oh my goodness, you know, we have no sense of priority here. You know, Sue says, well, our budgets are, you know, ridiculous. We get yearly budgets and they change every 3 weeks on what we should do, right? And you're not like, you're not getting all that stuff in like categorize discussions there. Like when you go back to your notes. And then so the first thing I realized is I had to come up with these sort of buckets and a reasonable way to sort of capture. And not all things are perfect. There certainly are other buckets, but I use this as my framing for how I go about trying to do like a quality, a qualitative analysis of everything I heard. And typically it stems into the 7, it could have been 6, it could have been a 7 just sounds cooler. Invisible work. We'll talk a little about that. You know, it's about work that's just, you know, downstream dependencies that aren't captured work that captured because you have so many different management systems. Management system toil. Probably the worst offender of management system toil is when I work in organization and I find they have 7 ways to capture work, you know, SharePoint, JIRA, message and email, you know, remedy tickets, right, work, work tickets and remedies, ARS. And none of that's aggregated or correlated. And in the end, a lot of data is missing from what you actually do. So not so it stems back to invisible and then misaligned a sentence. We know that that's a great narrative of the DevOps story. But, you know, we think the roadmap is this, but then I've been told I have to do this. And, you know, and even the Dev and Ops is this classic core chronic conflict, right? Dev, you know, classically Dev wants to move fast and get things out the door. Operations is resilience and scale and like, you know, so again the whole and again in those classic scenario, operations will get rewarded by reducing impact incidents. And those things, development will get rewarded based on delivering things on time and features, right? And right there, there's a misaligned a sentence. Tribal Ops, for any of you who have read the Phoenix project, right, the Brent classic example. You know, there are these sort of pockets of tacit knowledge that people just don't know. And, you know, when you start interviewing people and you'll get a flock of younger people who'll be like, I just never know how to do this. And then some sort of seasoned person back in room and say, oh, that's easy. You just go to Bob. And they're like, yeah, I went to Bob, but he's too busy. And, you know, and I asked Bob, could you explain how you do this? And Bob's like, I'd love to, but I don't have time, right? So the whole Brent character who is, you know, and the more often not it's not the person who's trying to preserve their job. It's somebody who likes to help everybody and tends to be, you know, doesn't really realize they're a bottleneck, right? You know, I think one point somebody categorized Brent as a rotten person and Gene Kim who wrote the book was like, you know, like, oh my God, no, if you read it that way, that was, that was totally not what we wanted. You know, and Kevin Barrow was a big part of who works on GTO was a big part of that Brent character as well. Incogoon organizational design when you go on and on, you know, the anywhere from and it's not just sort of, you know, the sort of waterfall, not waterfall, but, but microservices versus monoliths, right? That's a part of a sort of inverse Conway maneuver, if you're familiar with Conway's lore, but it's organizational as well. There's a great story of the Equifax breach right where the the CISO reported to the chief find the chief legal officer. And when they did the Congress actually did a post mortem you haven't read it it's a fantastic document. They interviewed the CISO and they asked, well, when you knew that the, you know, PII and there was like you were there was a compromise. Why didn't you go to the CIO and the answer was, I didn't think of it. And like that's a classic, I think Conway lore is I mean that their mindset was all the things that were required from a legal perspective, right? Just understanding complexity right through this. We'll talk a little bit about incidents and just understanding that these are complex systems you need to have system thinking you need to understand blameless. You know, it's a whole different way of thinking about failure. And then last but certainly not least, you know, security and what I love about this model is it almost always funnels down to something that I want I call security compliance data. So let me move on a little bit. You know, this is just a model from Elliot Gorat, who was the person who wrote the goal and that the Phoenix project was modeled off. It's about thinking about complexity in a different way. You know, in a lot of ways, when you go into an organization and you start asking questions, they start giving these abstract answers with what you're basically telling you stories where what you really need to do is find out. So I don't want those first order answers of the problem like John, the CMD is fine. Okay, let me ask you, what did you do last time when you had to deal with a remedy for sort of some incident to find all the systems that impact? Like I use my spreadsheet. Oh, why didn't you use the CMD? Oh, because it's a piece of junk. It's not accurate. And so the process I go through is this. I've kind of over time gotten to into model. It's a little different now. I've done a couple of virtual which are, it's just different. One client, one of the top three or four banks in the world I did last summer. I spent 30 days in London. That shouldn't give you a hint, but I actually became a bachelor and I interviewed 400 people. I just stayed there. I actually got to go to a pub at night, which is like a lifelong dream of mine. But the process is, you know, you have these initial calls. I'll talk about this pre-assessment leadership call. You know, I say I don't really want to hear from leadership too much, but there's a little bit of a head fake process I go through. And then there's the online analysis and to be clear, although I'm not a scientist. I do work with a couple now, but it's qualitative analysis, not quantitative, right? It's not just counting the things. I'm literally trying to put categories. Initial readout report, final report. This is example of that large financial institution I did last summer, you know, 300 to 50 assessment team meetings. It was actually about, it was more than 200 people. It was in the neighborhood of 350, 400 pages. In fact, this book, right, I'm getting better at creating systems that I don't have to have notebooks, but I'm just old school. If you look at, I hope it's color-coded and stuff, so let's become the categories. I literally had a DCIO at this bank at the end. So one of the things I don't do is I write down everything everybody says, but it's part of the qualitative analysis. The fancy way to say it, I aggregate the stuff. Nobody's name gets bubbled up. It's all like, I've heard this thing, you know, 15 times. I'm pretty sure this is the one of the most important things that we should probably address. And then I use it for a quote wall if I get called on by the CAO. But I'll never call anybody out for what I wrote down as a quote. But I had a DCIO offering me $10,000 for this book after they were already paying me a big money for the engagement, right? This was a personal, and, you know, the answer was no. You know, sorry, that's my promise to the people I interview. This is the thing. I actually got this from Kevin Bear. You know, if I haven't said I love working with my DTO team, let me say it again. I love working with my DTO team. The Kevin Bear, and he says it's from Eli Gorat, which, you know, that's great, right? Even better is this idea I figured out and I don't do this all the time. It just depends on the circumstances. But when I get to interview leaders, I don't want to ask questions in a different way. So one of the things that this technique is really works well is you walk in the room and you're in the office and they're about to tell you their resume and what they did. And they're like, oh, hold on a second, before you start, I don't want to ask you a question. And you say, what are the five things that XYZ, your corp, is not doing, it should do. And then they're like, oh, it's like you just threw a whole water in your face. And then the next thing you know, they just start rattling stuff off. And then to get up, sometimes you got to stop them in 10 or 15, and I'm going to ask for five. And I've had comments like, wow, this was therapeutic. Or I can't believe I just told you all that stuff, right? And it really sets the foundation. In fact, I was forced to do this because I had to prove that this would work to one CIO. So they wanted to start off with a smaller engagement. And I typically would say no to that, but it was doing it for a friend, a real friend that brought me in. And he needed something to change there. And when I went back to say, oh, this is your leadership. You're number one problem is communication. And everybody in the organization told her that it was capacity. And she knew it wasn't capacity. Even when the big four told it was capacity. They told them they had to consolidate offices and like all this stuff. And their number one problem for the leadership team was communication, right? And like she knew, she didn't know what it was, but she knew there was something had a capacity, right? And that's what got the rest of the engagement going. And the obvious findings that you see everywhere is high waste, high wait time, silos, obviously variation, low collaboration, low trust, low visibility, low automation. But the key is, again, you know, and I've done this and my friends do this and our industry does this. Companies come in and say, let us train you on this new technique. And then so you get this like training budget and you go in and you learn all this really cool stuff. And I didn't ask and you didn't know what the problem was first. Right, like, and the training probably will fit. You know, there are some great. I'm actually going to show some of the, the examples of roadmaps that I give from people who do training, including red ad, of course. But, but like the idea of just coming in and creating a training budget for like 1000 people on some new thing. So have you even asked the people who do the work? What's wrong? Maybe, maybe I'm crazy, you know, maybe I'm living on an island all by myself. I wish I was right now, but hey, the. So, but then we get into the sort of wrote like meetings and like virtual it's a little different, but you know, just the nature of virtual is, you know, normally what I do is try to have one meeting for a whole day and other meeting for all day. And then I'll do an hour and a half, two hour meetings. Just, just, you know, virtual and all that just makes sense. It's just, and actually I didn't think it would work. It's actually working better than I thought. And then I have to go through some process of qualitative analysis and, and actually again working with a guy like Jay Bloom, right? He's got a PhD in design transition. And like, we're going to work together. Sorry, Jay, but you're listening. I've already recruited you. But to make me a better scientist. Although I started John Allspar the other day who does very less stuff on incident. And he says that maybe one of my, the one of the things that might make this great is I'm not a not not a sort of academic based scientist. We'll figure it out. Top five, visibility, prioritization, toil, inconsistency risk, but here's the thing. I don't know. I'm unlikely these are the problems. If you're a hundred year old bank and you're sort of early on on your transformation and you've got sort of pockets of DevOpsisms, you know, probably three or four of these are going to hit and I could walk in as a high pay consultant and throw my devops handbook edge and say, I know how to fix this. Right. But like, I don't until I listen. Right. You know, and then, you know, so like, all right, so now it gets a little sort of easier. So now you're mapping all the analysis to the time. And here's the other thing too. Right. Not all parts of your organization move at the same speed. You can't just tell everybody, Hey, let's safe on Monday in the world will be awesome. But you have to meet people where they are like the legacy mainframe people. Like I started my career. The one thing that was just really cool for me is you can't stop me. Like you can start asking about cobalt on db2. I'd be a mainframe. I'm like, yeah, I wrote, I started my career as writing mainframe. I'd be a mainframe assembler for 10 years. Like last MQ, you know, J boss, of course, or, you know, rabbit MQ or you just go down the list, right, of all these different systems that, you know, but the point is this is just an example. The real magic is figuring out your capacity, the different speeds. How do you apply different techniques at different speeds in the organization? It's not like just, Hey, everybody dev ops. Well, wait a minute. Wait a minute. Some people are ready. Some people are not. So when I say this, you know, I do think there are some common themes. I kind of call the operators guide, right? You know, we want to create an operator's guide or, you know, if you want to be fancy, call it, you know, XYZ. XYZ corporation or, you know, or the shared agreement, right? It was talking to company of the day where they're the new CIO really understands what he's doing. And he has this idea how he's going to re factor the organization structure, ask me if it sounds, is it sound? I'm like, yes, that sound. But it will fail if you don't have that operator's guide across all those things. These common things that we all have to understand as the true knots, right? And so, of course, automation, but taxonomy. Like maturity, like, again, go back to the speeds. Like, you want to get everybody to the same place to north, but you figure, you know, some people and there's different maturity models, badging or different things that may or may not work. But the point is, you know, somebody might start off as yellow, somebody might be orange, somebody be like green, right? And like the point is, you're going to get them all in sort of directionally the same way. And then I find taxonomy might be one of the biggest problems in organizations is people use about 10 different terms and there's basically a thousand variations of those 10 different terms. So the people having meetings and they don't even know they're not talking about the same thing. It's just amazing how just simplifying a common taxonomy in an organization might actually be the most easiest thing to do. And solve such a large variety of problems. So learning, understand team, team turnover, how you organize teams, you know, you might say we're agile and we're doing, you know, we do sprints and scrum, and then I find out that what you're really doing is to whack them all on teams. You're putting a bunch of people together for like six sprints, then you're reallocating them to some other places. And I'll talk a little about cognition and load and learning of teams a little bit. And then depending on how old your bank is, you know, you might be bogged down in NFRs or, you know, service management, idle processing. Sometimes, you know, banter on the GRC, you might have groups that are leaving it incredibly slow paces. And it is amazing to me to walk into a top 15 bank today and still here in 2020 that it takes, you know, two to four weeks to get a compute instance. The one I heard recently will blow me away is, hey, John, it takes me about a minute and a half to two minutes to get an Amazon instance, but it takes me another two weeks to use it. What are we doing here, folks? Right? Right? Like, we have to figure this out. So if you keep thinking that, and I'm a big fan of cloud, I'm a big fan, if you know, know me of, you know, of containers, you know, OpenShift, I think the platform model is the right way for the future. But like, if you're building all this stuff on a platform and there are people out there that you're not talking to, they're saying that platform is great, but it still takes me two weeks to get a compute instance to run a test. Right? General visibility. I won't go through all these. I will make this deck available. Inconsistent road. This is the thing where you, it's not like what's on the screen. It's what's going on, right? Which is, you know, like there are these sort of notional beginning of year roadmaps. And then, you know, six or eight months of people that I talked to, like, they have no idea what we're doing. They think we're doing all this. But every three weeks, I'm told to change to do this. Too many practice, way more projects than our people. So having not even the visibility just show the chart that you are overcompact, you know, your allocation of what you believe is the capacity that you're running is 150 beyond. And that's not even counting the hidden work that doesn't get calculated in the early budgets and bottlenecks, too much work in progress. Like there's not even sort of a sense of whip going on, right? Or if it is, it's localized. So I did, you know, I'll run out of time, I'm sure, but sorry. You know, the thing I love like is, you know, and I'm not an Agile expert. And like, you know, I learned enough to be smart about from, I learned enough from the really smart people to be smart enough to be able to have the smart conversations, if that even makes sense. So, but when I walk in a room and I talk to a bunch of people and I talk about story points and all that, and I already know they're day driven. I mean, I know they're day driven, right? So like, I don't have an expert in all things Agile and Scrum and everything else. I just, you know, like simple math, I know they're day driven, and I want to hear them explain story points. Now, I actually have heard viable answer story points, but often or not, it's this fun game of, well, John, I'm like, okay, but isn't there a date on this project? Yeah, but you don't, you know, like, yeah, but I don't get to, you know, aren't you just reverse engineering the story points to meet date? Well, if you put it that way, John. Anyway, so I hope you're sort of laughing. I can't hear you when you're doing this virtual, but hopefully somebody just laughed a couple of times. Conflicting priorities, unknown dependencies, right? I don't tell this story really quickly. Like, so I wanted the stories I love in the fitness project, right? And I'm going to, I'm going to mangle it, but, but there's a story about where they're on the boardroom and somebody's saying, well, why does it take 63 hours to do a 15 minute task? You know, and, and then, and then it's explained to them, okay, let me explain to the very simplistic, you know, queuing theory and if people are 90% busy. And they're doing something that has a very simplistic, but everybody's 90% busy, which is not too far from a lot of organizations I visit. And everybody has, you know, seven downstream dependencies and everything they do. I got passed like, you know, algebra, I think, and that's not algebra, but like it's what, 62 hours, right? And here's the thing I do when I, when I go in and I start asking questions about how they capture work and I find out that 70% of all the work in that company from the IT perspective isn't captured. You know, and I have this great conversation with the CIO, like, how do we do it, John? I'm like, not, not really good, Bob. I'm like, what are you doing, John? I'm like, well, you know, let me put it this way. If you built airplanes, I wouldn't fly on them. I'm like, okay, Bob, as far as I can tell you have a $3 billion IT budget and you only capture about 30% of all the things that are happening in your IT. And I'm wondering what other part of your business would tolerate that finances. We reconcile the books every Wednesday if it's not raining. And then, you know, furthermore, when I'm talking to people about that sort of process, I say, why don't you write, well, how come you don't create a ticket to that? And I don't believe, you know, we have a whole discussion about like ticket dues and all that. That's terrible stuff. But why isn't there any, why aren't you keeping any electronic document on that work, this work you just told me about? Oh, I've been working with Sally for like 15 years. I know when Sally gives me something, it's only going to take me 15 minutes. Okay, let me ask you something. Does that thing you do for Sally need file space? Does it need to be dealt with like with LDAP or Active Directory? Of course it does. Of course it does. Like how long those things? Well, that's not my problem. But so the context of the view of how long it takes is already skewed because in their mind it's 15 minutes, but it's, you know, back to the Phoenix Project story, it's maybe 63 hours. Unplanned work, neglected work, right? Like, we've got some of that going on. Consistency, shared environments, right? You know, I'm again, like, if I knew how to answer all these questions, I wouldn't be here on this call right now. I'd be on like some ridiculously expensive fishing boat on the Gulf of Mexico, maybe calling people periodically to see how they were doing. But unfortunately, that's not the case. Shared service environments are terribly hard, right? Like, if you're running these very complex systems that have legacy code, you can't have four environments of certain kind, like TIPCO or, you know, large gateways and your MuleSoft gateways or whatever, right? Like, not every organization, and I can't walk and say, oh, you're a great problem is you need like, you know, eight of these for everybody. Like, you know, of course that's not going to be the answer, but it's still a problem, right? Because you've got this sort of yo-yo effect on shared environments. Somebody's moving up, you go to tests, you've got to move it back down to a release. Somebody left some artifacts. It's just a mess. Inconsistent environments, things like Ansible, you know, or Chaff or Puppet, you know, configuration is code or infrastructure is code, right? Like, again, when I walk into an organization in 2020 and it's, you know, it's a, you know, it's a plus $2 billion IT budget. And they're like, yeah, next year we're thinking to look in at infrastructure as code. So you just told them you were manually building stuff? Okay, sure. I mean, again, I'm being a little funny and sounding judgmental, but, and I don't do this when I'm doing this with clients, but sometimes you can't help but laugh among friends and y'all are my friends, right? So, unclear rows and responsibilities, you know, we could go through anti-patterns, you see ICD and just got to ping my bosses yelling at me. No, no, that's just not telling a kid. You know, there's tons of stuff written about anti-patterns. The cross-functional chaos, right? Make your space and, you know, in one team, there's team members that actually are cross-functional to somebody else. They're, they report to this one, but they're cross-functional. It's just like there's a lot of chaos in how you, and again, I'm not saying like product owners and product managers or technical leads or, you know, technical product owners and, and that's the taxonomy, right? Like getting all that straight. Not market oriented. We have a whole bunch of this stuff in the devil's handbook about that. Here's another area, right? Like strategy, right? Strategy is usually a mess. There's sort of common strategy or you might say compliance strategy. And then sometimes they are, sometimes they're not in sync with the architect's strategy. And almost always where companies are emerging on cloud native patterns or decoupling or, you know, sort of, you know, maybe microservice to really flesh it out or just sort of going all in on the cloud. A lot of those organizations, the architectural teams and the engineering teams are in complete different planets, right? And then, you know, I should add network here too, but security and network, right? Like a lot of those are sort of latent that you get through the process and the security comes in and says, you can't use that version TLS. Oh, that's going to be a problem, right? You know, so, you know, we're not, I mean, we're getting better, you know, and again, there's a lot sort of Lisa Red Hat, you know, just to be clear. I think lead hat has been doing too much work this week. It's a Friday. Red Hat has a lot of really good leadership starting with and the rest of the organization with GTO, but, you know, about how we are getting better. And, you know, we have something called the five elements and, you know, if you've been listening to this, the series, you know, you've had it already. Jave has, you know, we all, Jave is an inventor of the studio economy. So I mean, we're working really hard to solve these problems, right? So, but again, a lot of corporations, you know, this strategy is just different arrows pointing in different directions, general risk, you know, risk in general, right? I do a lot of work on automated governance. You can look it up. Maybe we'll get some links to some of the projects or DevOps automated governance, cloud automated governance. But, you know, most organizations is still primitive based, right? The mentality was, I can tell you, it was clear, you know, it called these counterfactuals when you go in and you read a postmortem of an organization and say, well, I know what they should have done. And so when I say this, I don't know what that should have done, because I don't know, but I do know that I got a sense that they were some myopic notion of perimeter based, right? And this is, like, if I spend a ton of money on IDSs and protect the perimeter, I mean, Martin Casado, who was the sort of the creator of social high networking, was pretty sincere, sold it to VMware. And now he's at, and he's at Harvard, so he's one of the leaders in network people in the world, brilliant guy. You know, he said, you know, a couple of years ago, I saw a presentation that our industry spends about 80% of its spend on perimeter based and less than 20% on inner perimeter, right? Subjective governance models, right? So a lot of what we do from audit and control is basically subjective in that, in that, you know, what does it order do? They come in and they look at the conversation in a change record for the evidence, or maybe screen prints, as opposed to possibly injecting what I would call objective governance into your pipeline, you know, maybe something like a blockchain and stuff like that. Low attestation efficacy, so that's back to, you know, a high attestation efficacy, that would be something like, you know, sort of like a blockchain evidence for audit. Data ops, interesting conversation starting, so attestations for how data moves, you know, most of the largest breach and the worst breaches are not about like the vulnerability and struts to Jakarta. It's about finding data that probably shouldn't have been sitting there. So if we had attestation models or evidence of how data gets transformed and placed in S3, the NSA breach, same thing, you know, stuff in S3 buckets. So the working model, typically, you know, again, not all the same. This is when I start to do, I've done with the analysis. I start thinking about what are these things and what order they should be put in, or there are other things that you'd add. But taxonomy models, understanding roles and responsibility, community practices, you know, open org stuff works really well if it hasn't been added. Really understanding how, you know, 2020 incident and problem management look, service transition, upskilling and outcomes. I'll go, again, a little faster. It's hard to do this faster because I love talking about this stuff and I think it's pretty good information. I would say you need to proportionalize your GRC, right? Like, you know, if there's a hundred things in your risk definitions, and there are people arguing that there should only be 10, you know, maybe you can compromise at 20 or 30. There's also patterns that, you know, I can talk about, or if you hit me up, you know, Jay Wilson read that, talk about how there's this interesting way that you can create sort of emergent GRC. So instead of sort of rewriting all the 400 column risk spreadsheets or, you know, 15 stacks of books of all the corporations, sort of risk definitions, you can actually start building through sort of evidence and emergence. It's pretty cool. Long live teams. You know, this idea of whack-a-moling teams, you know, taking a bunch of people and, okay, for next six weeks, we're going to put Sally Bob and Tom and Jim together. And then when that's over, I get, well, you know what, I need to pull Bob out of there early because he needs to start this new team. The teams are not getting learning how to function. There's a lot of research on like how long, I think it's three months before a team actually starts to bond. And if you're ripping them apart, you just, you're not getting, the whole reason why you might have wanted to go to build run teams or two pizza teams was for that synergy and bonding. Building trust in the pipeline, I think we understand that tax enemies and incident consistency. Invest in common automation, of course, team autonomy, trust, taxonomies are talked about. Again, you have to break that day-triven. And I'm not saying this is easy because it starts from the top, right? Build the bank, run the bank, right? Like, that is the, in most companies, that's how it starts. And so you're playing this like shell game at DevOps at the bottom. When at the top, it's already been decided sort of arbitrated on there's going to be a part of bank that's run the bank. And as a part of that, it's going to be changed to bank. And guess what, if you fall into run the bank, you're the furniture, you know, so we're not going to really invest aggressively in those new fancy picnic tables. So you really have to, it's been called agile budgeting. I don't, I'm not crazy about that term, but like you have to sort of break that. You get a budget at the beginning of year. You know, what happens? You know, I would say the first quarter, you're like, ah, we got the budget, it's great. Second quarter, like, we really should start working on that, you know, working out that budget stuff. Third quarter, like, oh my God, we're getting close to fourth quarter. What are we going to do in fourth quarter? So, you know, you know, Titanic organizational change, man. Again, you know, I think with everything, we have to move away from quantitative, you know, looking at like from the leadership perspective, like how many of these did you get done? How you like, you really have to sort of look at that and just sort of smash it to say, if this is not qualitative, you know, you can't expect somebody. This is a true story, right? Somebody comes in, they're on a project, and the first time everybody meets about the project, the whole project on the screen, put a schedule and status is green. And that person says, ah, yeah, you know, half of that screen shouldn't be green. And like, after meeting somebody comes up to them, you know, hey, you really shouldn't say that in a meeting. So the next time they come back, the next meeting, they say, oh, you know what, a quarter of that team shouldn't be green. Manager pulls them partner. Dude, didn't I tell you, like you really should not, you know, you're not a team player, you know, I'm going to ding you next year on your bonus. And what do they do about the fourth, fifth time they come in? Like, Bob, what do you think? Do you think that screen's all green? Yes, Bob's your uncle. You know, so like, you have to break it, agile funding, zero trust models, shift left security. Again, I've got a lot of presentations on this. We've done a couple in this forum. I'm sure I'll do more policies code. This is really interesting stuff. I'm about to work on a new working group here. I worked on a paper called DevOps Automated Governance. It's a creative commons on the itrevolution.com site. We're actually going to do a second version on that. We're going to really focus in on policy. So policy people writing human readable YAML that gets injected into attestations in the pipeline that become the evidence for audit. And if you can get that, you can actually start looking at something like policy error budgeting. I talked about data ops, you know, and then really understanding the new world of configuration. Like, we know the sort of Ansible, Chef and all that, but all the configuration that goes into containers and clusters and managers like Kubernetes, OpenShift, like there's a ton of vulnerabilities there. And it's really hard to keep up. So really understanding, you know, a switch that you turned on a container could be no-op by not turning a switch on an OpenShift, right? So common language, you know, this is from Jane Groh, who does a great job of sort of talking about DevOps, SRE, and EITL. She's an EITL expert, you know, for years, but just like it's kind of fun. If you look at some, we're going to have some funds like a CI or sort of DevOps SRE will continue its integration. It will be called CI configuration item in CMDB. Configuration management will be something like Chef or Puppet Ansible, and I don't speak, you'll be in CMB and you get the point, right? And then what, you know, and then you have this other thing that I think is important. We do a pretty good job in DevOps Handbook is understanding the roles of your organization. I think most organizations would agree, but not one-size-fits-all, that you want to move sort of to the right. You want to move away from I-shape where somebody is an expert in one topic to maybe T-shape where they're really good at, like, so for example, like an Oracle DBA might be an I-shape. Somebody who, an Oracle DBA that really becomes T-shape might actually learn Python or, and then really start exploring on having that same level expertise on MySQL or sort of other relational databases, or maybe even taking on some of the non-relational. And then I-shape, you know, I mean, it just depends on where you went. I think I detest the phrase full-stack engineer. There's a whole book on it about why you should, and they test it in the IT revolution. Foreign papers that I just talked about earlier. But I think I-shape does express somebody who is adaptable, you know, models, and I talked a little bit about models. You know, again, I'm giving you little snapshots. There's a, like, again, it's context-sensitive to the analysis. I'm not showing you everything that I put in a report. I'm just giving you little snippets here and there, things that I think are hopefully you'll find interesting. But I think this holds no sense of team boundaries, team work agreements, and then I think a lot of companies don't do this, but notionally a lot of people sort of in their agile coaching teams basically say they do, right? But I make fun of everybody, by the way, including myself. But the thing that, even if they're notionally doing or they are doing it, the thing I very rarely see is this notion of a team-tape API. And it comes from the book Team Topologies, which I highly recommend. And here's an example of it. Like, so each team-there's a problem you have is very rarely in an organization, is any one team know what other teams do, right? Or worse, what's the architectural design of their system? And in fact, they call this sort of architectural design anthropology, where people have to go find the original MRD, and usually it's at a date and not consistent. The requires document is not like anyone's here with the existing, but that's the best that they have. How about a world where the team sort of makes these promises that will always support two versions? Well, here's our wiki and documentation to the best of our abilities. Here's our practices and principles. Here's how you communicate with us. We have multiple Slack channels. We have a 20, ask us anything, which, and then by the way, Slack works when you have SLAs, right? We say, by the way, if you go into the ask me anything for our team, expect a 24-hour response. If you go into office hours, which will tell you when their prescriptive times are, we'll promise 15-minute responses, right? And then we'll make sure we show you our, you know, can band boards. So, getting near the end here, team complexity and cognitive nodes, a lot of this, some of this, not all of it comes from the team topology again. Just have any understanding. I mean, you could say we have nothing. We don't have build-run teams. We don't have two-piece teams. And next Monday at 3.30 in the afternoon, eastern time, we're going to have build-run teams. Or you can actually do some research and understand some of the models that work or not don't work. You know, again, there are some organizations. I think the Azure model is pretty good, which they use internally, which is they believe that you need, you know, like, I think there are some researchers that you need three months to bond and you won't get the effectiveness unless you're doing 12 to 18 months of keeping a team together. Or you're sort of losing a lot of the benefit of having those sort of build-run teams anyway. You know, Red Hat, we have some models. I'm not a great fan of horizon-based, but, you know, I worked out with one client how you could do a horizon one, you know, sort of a horizon, you know, create, like, if you had to have, like, 10 teams you could have, or nine teams you could break them up in horizon one, horizon, what's in horizon two and horizon three. I don't know, I always get confused, but, you know, some is the innovative, others is the sustainable. Here's some, we'll publish this. I'll go through this. This is some of the stuff where I got my information from, you know. One of my early things I got called on and said, John, where is the research from now? Okay, let me make sure I document it. And then let's end up with incidents. So, you know, I'm a big fan of John Allspar. If you haven't followed him, he works, he is actually working with some of the two premier resilience and safety, cognitive labs, people in the planet, Dr. Woods and Dr. Cook and John. And they really, they really spent a lot of time on incident analysis. And, you know, John says incidents are unplanned investments. This is actually a sort of a modified quote of John. I actually did a podcast with him yesterday. He said, you know, he talked about how, like, why incidents are so important, right? Incidents are signals that are the most effective directors of attention about an organization needs for recalibration. And one of these, John said, I think it's really clear in this. And again, we spent a whole hour, you know, maybe we'll get John on. I know we had John on last week. Hey, I forgot about that. I was on vacation. The one of the things that he says is the most interesting time of an incident is from the time the inferences, you know, sort of completed, right? Sometimes they're never really completed. And before you get into the big meeting, like the post-mortem, I think most people spend most of their money on the big meeting. And his point is, that's where you actually get to really understand how this thing could be written and exposed as a learning opportunity. And he actually says, you know, all this stuff in resolution, like a pilot is not great because they passed every test. A pilot, like Sully, right? If you watch a movie, Sully was great because Sully could tell stories and he listened to stories. In fact, he had a blog about aviation problems that were stories. So we need to make sure incidents are stories that we can, people want to listen to. And there's a lot more there, too. Goals of incident management, trying to get near the end. Okay, pretty close to the end. You want to reduce done plan hours. Just again, I think that's the point that it took me a while to really understand what John in adaptive capacity labs was talking about is, it's economics. Like if you can shift the economic opportunity into the analysis of incidents, what bigger part of our organization? The devil's enterprise summit recently. There was a presentation by a company had talked about, you know, literally last year. What was it, like an 18 hour spanning tree incident, right? You know, I mean, I asked my network friends, should we should be having spanning three incidents in 2019. He's like, yeah, John, unfortunately, yes, but but like 18 hour spending. I mean, this is billion. This is like ridiculous money loss, right? Like we need to figure out how to invest in instance, as opposed to just reporting them and throwing them into dustbin documents. Alright, so with the six minutes I have left incident management opportunities, you tell I know it's a Friday, right? Because I'm actually in a cynical funny mood. You want to learn from these investments to that point, right? Like, let's make sure that we're telling stories and we're not just filling out checklists. You know, if we think about the classic idol ceremony, we're just, we're running up to get reports into a system that nobody learns anything about those incidents. Like it's a bean counter. It's a quantitative dashboard on some executives, you know, screen. You know, if you listen to John and adapt best labs, like we should be taking a lot more investment in how we take those stories to learn from and there's a ton of great stuff there. Some things about service transition improvement. There's a great book on it. It's 2019 book. Just look for Scott Pru and CSG. He's one of the authors. This comes right out of that. I T revolution, foreign paper. This is where you start talking about localized authority. And it goes back to the T shaped individuals and you start building build run teams. Right. So you're, and what's interesting about this kind of investment, right? It's all about economics investment, right? Like, why would you do? Why would you replicate team skills and not have a centralized? Well, maybe one is that the test person becomes a developer or the product owner becomes part of an architect. Opt becomes a developer and tester because when you're working on a team, you start, you start learning and sharing the responsibilities and some at some point you have a whole organization of T shaped people. And so when you acquire another organization and everybody has to adapt to new things, the organization is the adaptive capacity of your organization. I think J. Brilliant J. Bloom where work brilliantly calls this. I mean, should I get it right? Wait, J. You're listening. The quit skills liquidity. Right. It's a it's a I think he's written some stuff on this. It's a brilliant way to think about a dojo. I'm a big fan of that was dojo, mercy of learning, creating repeatable patterns. It's not like an excellent center. It's a place where people come over and over to enhance their craft and their skill and learn new things. Making work visible. This is another really good book on it revolution, not book. It's a form paper about the sort of cycle of, you know, work management flow from handoffs to batch size to work in progress. Sustainable approaches. I do think, you know, people ask me a lot of times like, okay, John, when you leave, you know, what are going to do? I'm like, well, you need to find somebody that can. Like, so the question comes up a lot. Like, I've had engagements where because of the my schedule, their schedule budget, all those things. You start it like, and then you don't come back till six months later, which I don't recommend. But then you get back things are actually better. Like, there was some conversations initial that actually changed some things. There was some changes that they made. And, and then the question from the CIO and C level team is, are we done? You think we're better? I'm like, no, but like the way you find out is do this like organizational conversation thing over again and the people will tell you if you're better, worse, getting better. Lean coffee. If you haven't experimented slack internal dev ops days. If you haven't done this, this is brilliant. Again, ping me. Jay will set right out.com. I can tell you who has done it how they've done it internal hackathons to dojo. And then last but not least with three minutes. Man, I did this. Every Tuesday, we have we didn't have less two weeks, but we'll have it this Tuesday and every Tuesday I think we'll do it at two o'clock. We're going to see if that works. We're on a crowd chat and it's where a bunch of people all GTO and a bunch of people read at and then a bunch of people in the industry jump on. And we have these tweet storms. And if you haven't seen the crowd chat dialogue, it's pretty awesome. And we've had a blast and then we record those and we put it on our YouTube channel, the red hat global channel and we'll be adding more material to the red hat channel. And I am done. Thank you so much for spending this time for you. And like I said, easy to find Jay will set red hat.com botch glue on Twitter. I won't spell it out. If you don't know what that is, just look for me at Jay will set right out. Well, thank you. Thank you, Diane. Thank you. Awesome.