 I'd like to ask each of you to introduce yourselves, what you do at Red Hat, and if you've just joined Red Hat, what you did before you joined Red Hat. So, Chris, if you'd like to go off first. Sure. Thanks, Diane. Hi, I'm Chris Pinella. I run the Open Innovation Labs program for North America. Perfect. Hi, I'm Jay Blume. I'm a member of the Global Transformation Office. Prior to joining Red Hat three weeks ago, I ran a company called Praxis Flow with Kevin Baer. We did large transformations for global 20s, and I was getting my PhD at Carnegie Mellon. A PhD in what? I'm getting a PhD in design at Carnegie Mellon. Is it like furniture design, or engineering design, or what am I getting out of this jewelry design? So, I define design as the purposeful creation of intentional systems. That sounds not like furniture. Furniture can be intentional in this system. Designing how organizations change their behavior. There you go. Great. Great. And John? John Willis, sometimes known as Botch Gloop, just done a number of things. I am the co-author of the DevOps Handbook. I'm working on the DevSecOps Handbook, a couple of publications. Sold a company to Docker, the company formerly known as Docker, sorry. And anyway, yeah, so that's about it. And I work for Andrew. He wrote a book. He did, like, some DevOps. A couple of things. Founder of DevOps. So I just want to say what a privilege it is to be here, first of all. Not just a privilege to be at OpenShift Commons and work for Red Hat, but also just the fact that we can come to this beautiful city and spend a few days, like, in the realm of the spectrum of, like, human experience, like, we're very privileged people to be here, everyone in this room. And then my journey here is, you know, way back in the day, 2002 or so, I was a Sun-certified Java programmer, ended up working at some startups, I ended up working on a startup called Puppet, made some tools to help people manage servers. Then I went from that to a startup focus on OpenStack that was sold to, as VP of Engineering for Cloud Scaling, was sold to EMC. And then the last five years I've been focused on Cloud Foundry and Spring and then more and more focused on Kubernetes and Pivotal. And along the way, and really the thing that made me kind of interested in some of the stuff we're going to get to do together at Red Hat, is this struggle that is the great limiting factor for organizations to get better. They all want to get better, but you can't just give them a tool and then expect them to do better. If you don't work through that social technical system that has its own inertia and attachment to the way it does things, then the technology won't solve the problem by itself. So, your new office has a grand title, Global Transformation Office. I love that, almost the first time I read it, I thought it was Game of Thrones. And I thought that is perfect. You're old like me, it's a GTO. Yeah, it's gonna be good. Cool car. Yeah, oh, GTO is you can all drive some, that'd be wonderful. I was proposing Global Transformation Field Office, but people don't like the, yeah, yeah, yeah. Yeah, also along the way, I left out the same sort of stuff, like I've been organizing DevOps days globally since 2009, and like been involved in a bunch of kind of communities around these open source projects and trying to help people do better with tools and processes. Yeah, Andrew and I ran the first DevOps day with Damian Edwards, the first US DevOps day ever in US, yeah. So back to your question, I mean, on some level, we're an experiment, right? So I was in conversation with Jim Weihers and the person who kind of funded this experiment. And there's this insurmountable opportunity to help people do better with their technology investments. And the other thing that I think that Red Hat is in a position to evolve, especially with the relationship with IBM, where you have this story about open source infrastructure and open source infrastructure was a great story, you know, Linux, open source till now. But now literally every single, every single company at this conference is trying to frame themselves as the open source infrastructure company kind of for the next version of this story. So what is the, what is the opportunity to differentiate yourself in that market where everyone's gonna try to tell you that they're the open source infrastructure company? Well, it's also, we talk a lot about, and I'll say it again, digital transformation or DevOps transformation or moving to microservices and being agile and all of that. And so I kind of would like to ask each of you to tell me what transformation means to you, because it means a lot of things to a lot of people. It's kind of a nebulous word, but it's one we use a lot, so maybe. Christina first. Christine. Okay. Yeah, and how you do that in innovation labs, I think. So transformation really in my opinion is more around your cultural change. And really kind of what you as an organization are striving for. You know, we see so often that folks will, you know, assume a tool will fix their organizational problems. We'll just lay it down and then great, we'll start using it and be done. There's so much more to that around, you know, getting folks excited about new ways of working. Understanding what it is and why they're being asked to go through this type of change and really like what the organizational is willing to undertake as part of the journey because it really is a journey and it's a series of experimentations to learn from to figure out what's right with your organization. And that's a lot of what the Open Innovation Labs program is focused around is looking at those experiments to prove it out before you scale it out. You know, for me, you know, one of the things we do a lot of, we waste so much time in this industry arguing over terms. And a lot of it is, why do we bother? So digital transformation annoys a lot of us, right? Because we've heard it before. But you know, Cloud and, you know, like how much, you know, Dev Ops had made me, yeah. Dev SecOps. In fact, when I give a presentation on security, I say everybody who wants to argue about the name, go to that side of the room. And meet me on that side of the room so we can talk about how to fix things. So digital transformation can mean something for us. And we need to stop worrying about it, is it a good name, is it a bad name, is it, let's just focus on the things that actually will work and make things better and people's lives better. So I get in trouble with Andrew right now because I say, I think transformation is an interesting word, but I'm more interested in transitions. I'm more interested about the in between than I am about the end state. And by looking at it that way, there's a couple of kind of critiques that you can immediately bring up. Most of digital transformations that I see have some end state goal in mind. They want to be more like Google. They want to be more like somebody who they aren't. And the reason they're not those people is because you don't have the context that those people operate in. They need to understand their own context and transition through to become more capable of operating in their own environment. So the technologies that we offer open up possibilities. They only offer possibilities. Is the humans that make decisions about how to apply those possibilities to the context that they're in, that is what a transformation becomes. It's a double enablement. Enablement to use the technology and enablement of the social system to use the technology effectively in context. And I think those are the two really important criteria. So we can argue about the semantics later. Going to that side of the room then. So mathematically I think transform has some interesting properties. But the feeling that everyone has and everyone knows when you work in these enterprises that were born kind of in the past. Like there's a lot of work that I've done over the last decade that's been in companies, some of them over 100 years old. Certainly decades old. And all the people working there have access to internet. And all the people working there carry a cell phone in their pocket that's essentially faster than any computer on the planet when I was born. And they know what it's like to use Facebook. They know what it's like to use Gmail. They know what it's like to use Twitter. And then they go into these enterprise IT working conditions where it feels like the software they're using is designed to be actively hostile. So you know what's possible. You see the spectrum of what's possible as a human embedded in those organizations. And so you know kind of being in your bones that is possible to do this better because you see other people doing it better. And so then the question to me, like I'm not that interested in like oh like the vague titles of whatever, like I want people to have good outcomes because I like living in a world where more and more things are possible on the supercomputer that I carry in my pocket. And so the more that I could help organizations get better at that, then the better I'm going to feel. But it's really about the fact that we know, I mean you're seeing like these, there's just an article about some massive failures with this massive investment in digital transformation. So everyone is motivated. That's why everyone wants to kind of jump on that digital transformation train, but no one really knows exactly how to get from where they are to where they want to go without a little bit of, frankly, love. Like you just need to, people do things for two reasons, love or fear. And a lot of places have like this fear and they're not attaching themselves to like what they could actually become because they're too busy with the internal politics of their own thing to get out of their own way. So for me, three weeks ago I hired on Red Hat, right? Prior to that I spent about two and a half years just visiting banks. And what I found is in every bank, my joke is the sixth floor, the people were talking about idle and service management. The seventh floor they're talking about cloud native. And the eighth floor they're talking about DevOps. And they all use different elevators. They never talked to each other. They overloaded terms. And if it's digital transformation or whatever word we use to fix that, see I'm a meat and potatoes person, right? It's let's fix that problem in a large institutional bank that has these problems where little you have cloud native and GRC risk are just separating at a gulf rate that's just maybe there's no digital transformation without people transforming their behaviors. So you bring up a really interesting point and I think Andrew and you've said this before and I think all of us have probably said it in some form is that what we're trying to build are learning organizations. And it's not just the technology and it's not just the DevOps people or the IT people. It's the compliance, the risk spoke. When you go into a bank there's a huge organization there that wants to change for the most part, wants to get to be Google if that's a goal. But how are you going to go about helping to enable people to become those learning organizations? I think the immediate thing that I always think of when I hear learning organization is shouldn't you also be a teaching organization? Like literally the importance of these individual communities teaching other communities inside of their own organization. This is what I do and this is why it's important for you to understand what I do. And I think there's a set of shared practices, it's like a Pareto practice, right? 20% of what I do is really important to what you do and that's all I actually need you to understand. I just need you to understand about 20% of what I do on a day to day basis. And if a digital transformation, that's what we want to call it, is going to work, that conversation has to be with finance, with procurement, with HR. It can't, we can't be successful doing these transformations inside IT. It's about optimizing the whole system holistically instead of just how many times you deploy today or whatever. I think Innovation Labs has some techniques that I've seen used to break down those barriers. So we, as part of what we do when we come in at a customer is we really look around how do we actually create that virility within the teams? How do we break down those communication barriers and get collaboration going? And don't cringe at me when I say this. It's really, there's a concept called Hebb's Law and it's about, loosely, it's neurons that fire together, wire together and it's about getting to that 20% alignment that organizations, it starts to click, even grassroots wise, just to get things piloted and get folks excited to start building these inner networks within their organization. So my last company was called Praxis Flow and so the word praxis means theory-informed practice. It's a basic theory that says, you can't just give people theory and you can't just ask people to practice. You have to combine the two together in some sort of thing like a lab that people actually can learn to exercise the theories that they're hearing and that's the only way to get those things to really hook. So we also talk a lot about microservices and agility and teaching that to folks who have legacy or enterprise systems. What are some of the techniques that you use to get people on board with moving to Agile and moving to DevOps? I like to give people the choice not to, for one. So I think that it goes back to this notion of context and to me, if you need to explore, or you want to explore some new opportunities to create revenue or whatever, change your organization, then by all means get that to an architecture that we can continue to deliver and explore those features. If it needs to scale, like we're having problems with operations or there's some other reason why it's expensive to operate, then let's get that to it. But if it doesn't need to change, it doesn't need to scale, it's not expensive. Just leave it there. It's not broken, let's not fix it. So, because you can spend all the time and money you don't have refactoring things to microservices with little or no benefits. So to me, it's always not just, oh, what's the optimal architecture? It's like, what's the optimal solution for your context? There's some, in a DevOps world, there are some phenomenal monolith success stories. Etsy, Facebook is a monolith, right? So it doesn't mean that you're wrong in the context of DevOps or whatever you want to call it because you have a monolith. Now, for me, again, this is where I feel like an imposter between this thing. It's sort of debatable though because both those examples are PHP and you basically deploy by changing one file in a folder. Tell them you have to run microservice and you get into a fight, right? But I think the strangler pattern, right? Like, that to me seems like the way you think about it. Like, don't just rip apart and decouple because company X is doing it and you sort of then present it. Also, there's billions of dollars running through the monolith sometimes. Yeah, yeah, yeah. I mean, trillions, and you know, I mean banks, you know, I mean, top 100 banks in the world run. They're system of record on IBM mainframe DB2 databases, right? And by the way, pull out your phone and talk to your bank. Go ahead and go onto Delta and go ahead and do a transition. Everyone is gonna go back through like some type of MuleSoft to WebSphere to MQ back to a system of record running on a mainframe, right? You don't just decouple that, right? And so the reality check of our industry is that we need to figure out how to strangle pattern things. You can strangle pattern. There's some brilliant stories out there about mainframe strangle patterns. Anyway, change data capture. I think there's like three things that I usually like to kind of start with the conversation around. The first one is really understanding cost of change. It's not technical debt, it's actual cost of change per component. So like understanding all the components, what's the components in here that cost the most for me to change if I want to swap this component out? How much it would cost me to change that? Now the question ends up being, do I want to pay that cost or not? So that's a similar conversation that these guys are having. Do I need to replace this? Or do I need to just lower the cost of change? Do I need to focus on interfaces? Do I need to replace those things? Adding to that conversation just a cost of delay analysis of those types of things trying to figure out which ones come first, which ones come second. So I think getting those two things to work in parallel together. And then finally, I like to kind of frame all of this stuff up in a wordly map just to actually see what components we're talking about and how we might think about decomposing it. Now we can explain wordly. Thank you. Good job. We all said through that seminar. Why don't you explain what a wordly map is? So a wordly map just says, so you can take a classic kind of architecture diagram and get a stack, right? A wordly map just says, hey, some of the stuff in the stack is important to your customers. They see it and touch it. Some of the stuff in your stack is less important to the customers. It may be important for the function of the system, but it's not touched directly by the customer. And then there's stuff that's new to the market and stuff that's commoditized in the market. And so by laying your architectural stacks out on these graphs, you can kind of get an idea of things over here high up in this corner would be highly commoditized and touched by your customers. Things down here would be brand new and not touched by your customers, not cared by. As a simplification, it helps you decide what to build versus buy. That's right. And then it allows you to see those connections between things and do an analysis saying, is this connection have a high cost of change or not? Is this component have a high cost of change? And that, I think, again, takes kind of the broad brush argument of microservices and contextualizes it to your situation. I was gonna just say, I was reading on the flight in last night that the GDP of California is like 2.5 trillion or something like that. Top five banks in the world, their asset holdings are around 2.5 trillion. So when we talk about changing a bank, we're basically saying we'd be better off changing the state government and the revenue system of California to change the bank. Just put that in perspective. Wow, that's a good one. Thanks. I got the other one. Yeah, that's okay. I said, well, I won't go into mass globalization or a conversation about politics now. Sorry. I just meant the revenue. Mine blown there for a second. That was good. So it is a lot, though, about change and a lot of it is cultural change within organizations. And so we do, did the boat just do that? Did the boat, that wasn't me? That wasn't me. Okay, so I promise you we're not leaving the dock and we're gonna stay here. I can see the weight coming from the big ship out the side. Yeah, here it comes again. So a lot of this is about cultural change and how do you sustain that in an organization? We do a workshop with Open Innovation Labs. You might create a wonderful thing, but what are the techniques and things that we are going to be preaching or we do in order for folks to continue to building that learning organization? Well, one of the techniques we employ is around building communities of practice around both technical and cultural agility adoption. Because you're right, it is important. First, take a look at what you are trying to do based off of a set of goals and initiatives. Then how do you take that to scale? How does that propagate out? And I think when you start small and you learn and take a look at what works and doesn't work for your organization, you're able to kind of course correct and pivot as needed, take those successes, pull them forward and just keep building on it. It's a continuous improvement journey that you're going on. So no one likes to hear that what they do is bad. And humans tend to attach their identity to their task. And as a consequence of this, then a lot of times what you're dealing with in organizations is actually people hearing that what you're about to do is erase their identity. And so they'll start to create immune response and resistance. So to me, this is like system thinking, but basically like you could try to push change harder or you could try to remove the resistance to change. And so the more that you can make people see themselves as heroes in the new version of the story, then the more receptive they are to building these bridges and doing that new kind of work. I think that's a lot of what we try and do in the commons too. It's not like we're trying to, you're all heroes to me, but is to share the podium, is to get people to share their stories, their war stories, what the good, the bad, the ugly is, but to give everybody a voice and to try and bring out those stories. I think that's a lot about why the commons has had the success that it has, is it's encouraging people to share their stories, to learn from each other and connect. And I think that's a lot of what you're bringing to Red Hat. Everyone wants to be a hero in their own story. Yeah, we're gonna get a new T-shirt made. Everybody wants to be a hero. So yeah. I think like in particular, in my experience, the it's pretty easy to identify how you're a hero as a developer. Like it's actually a pretty common story. You can pick up books anywhere, talk about being a hero as a developer. It's pretty easy to figure out how to be a hero as a CEO. At least you can go to any airport and go in and then there's like a dozen books on how to be a hero as a CEO. Middle managers though. Middle management is completely devoid of stories about heroes as middle managers. If you go to the most organizations to ask them what do the middle management do? Like everybody kind of goes, I don't know, they get in the way. I grow my head count and my budget. That's what I try to do. So like I like the, one of the things I like to say is the number one indicator that your transformation is being successful is the increase in peer-wise communications in middle management. So, and it's partially about creating a stage like you're describing. Some place where they can talk to each other and practice telling their stories to each other. They'll humanize each other. That's right, exactly. And that way the leader can actually go into another part of the organization and have a conversation where he can be seen as being a human being as opposed to an other from someplace else. A functional unit from some other tribe that we don't really talk to. Exactly. And the other one that I really like, it's subtly different than what I see in a lot of organizations, is it's called a boundary spanning role. And a boundary spanning role is kind of like, you can think about it like, most agile coaches are in teams. What if you had a coach that sat in between teams? That literally their only job was to make sure the teams understood that 20% of their shared practices and that was their entire specialty was to accelerate that conversation. So I was gonna try to shut up, but I can't. No, because I want to say something. We were at a client site the other day, right? And he was telling the client, this guy, crazy, smart. He was telling the client, don't think about roles. Think about skills. And one of the phrases that he uses, I thought was so brilliant, was the liquidity of your skill set. Chris Matz. It was just beautiful, right? And the idea that we tend to get focused on our roles and how do our roles overlap and what does our tree look like? And he was telling this group of like 30, 40 leaders, coaches, they rented out Stojo. It was all the coaches in the dojo and they couldn't stop taking notes when he was describing this notion of its skills and liquidity, I just thought it was, I mean, I was taking notes, you know, so. Well, I hope you all are taking notes and taking names and numbers because these guys are gonna be around for some time. Do you have any final words as we wrap down here that you'd like to add going forward where you see yourselves going next with Red Hat? Well, we're still figuring out what we do here, but we have been meeting customers and we have been meeting the product team and the sales team and we're just, I think we're gonna partner with Christine pretty much going forward every day we're gonna work on something. So we're just trying to get in the mix of it. But to add to your point, Andrew Clay Schaefer, LinkedIn, reach out if you wanna have more conversations like this. I'm also a little idea if you wanna see random comments about tacos right now. Jay Wilson, Red Hat, Botch Group, for those of you who know me. I'm gonna focus, you know, Andrew's giving me so this green light. I've been blessed two years, really focusing on what is cloud native and governance risk compliance really mean? How do we deal with this? How do we get kinda grab it back? DevSecOps, automated governance. I wrote a publication with a couple of large banks about how do we start changing subjective attestation if that makes sense into objective attestation. I don't wanna say blockchain, but no. But the point is, that's, I'm really, so if you're interested in that, Jay Wilson at redhat.com. Merkle trees, what? Merkle trees. I wanna have a sit at that. Merkle trees. Merkle trees. It disguises a blockchain, yeah. It doesn't need to be distributed. You can make blockchain, just don't call it blockchain. Merkle trees. Merkle trees. I'm super excited to explore kind of a very particular thing. It seems like it's likely that agility is necessary but not sufficient for a lot of the things that enterprises are dealing with. On the other hand, kind of like open source software development, large distributed platform development? Like, hey, maybe that has something to offer that these scaled frameworks that have been inflicted, can I use that word, on organizations. Maybe this way of working with openness is something that we can really help organizations really understand how redhat has been successful developing a platform and how they can use those same ideas to develop their own platforms. I think that's the thing that I get asked the most is you're doing all that stuff out in the open source land. How do we apply that internally? There's a whole inner source movement. 100%. There's a whole lot of folks that are trying to bring these models and these connectivities and collaboration techniques into the enterprise. I think there's a big opportunity there. I think it's a huge opportunity. I'm super excited about it. So just to add to that point, I don't think any of us would have been here if I didn't have such a kind of resonance with the way Jim Whitehurst talks about open organizations and some of the discussions we had before we got offered jobs, basically. He watched a video I made of a talk I did called There Is No Talent Shortage and then we just had this super deep mind-meld conversation about how to take kind of like the grounds up version of organizational learning and openness and transparency and accountability and this kind of CEO level framing of that and just the opportunity to try to make that real in the world with the platform that Red Hat has was, I don't know, I feel like we have a once-in-a-lifetime special opportunity to try to do something. And Chris? Well, as you can see, I'm in for a lot of entertainment. Good, yeah, exactly. And in the spirit of continuous improvement and working, striving to make our own customers successful, really having these guys be thought leaders and input into the program that we're working on is looking forward to. Yeah, I'm really looking forward to it because it's what we've been doing with Open Innovation Lab for the past, how many years have we been doing this, too? A little over three. Three years now. I mean, it's been really impressive for me. I'm not in sales or anything, so don't get that way. But the people who have come out of it have just raved about it. And how do we scale that? How do we get that to the next level and bring that to all of the enterprises and all of our customers and enable them? I'm really looking forward to working with you all. So thank you for coming aboard. The good ship, Red Hat. And we'll have them back for the AMA session, so save your questions. And thank you very much, guys. This was great. It was a privilege. Thank you. It's awesome. Thank you for providing us.