 Uh, yes, yes, uh, yes, uh, open system. Oh, I have to, I have to go in my, this is a new max. Sorry. Got to go into preferences and allow this and then first it has to take a little bit of my blood. He's rolling the starting soon animation and once we tell him go, we'll, um, all right, I'm almost there. Harmon's bumper and we'll just rock and roll right into this. This is, this is my morning coffee talk. Oh crap. I have to quit it. I'll be right back. I have to, because I just made a settings change. I'll be right in second back here. There we go. Chris, hang tight. Why are we tasked? He had to come back in. He'll come right back in. I'm really annoyed at the new blue jeans changes, by the way. Like I can't get a good talking heads, like both of you view. Unless it's like the speaker view, which sucks because all these, like my login is always displaying. Like there's no hide non-video participants like there is in zoom. I know what I would say is that maybe, um, yeah, just change your name to being, um, producer or something. So it just, instead of Chris short, then it just makes it look like it's whomever is the producer or something, but not made. I don't mind if it shows. I edited it right out. So. Okay. Well, yeah, if you're in present presentation mode, it's not a big deal, but it's just when it's just people talking, it's a big deal. Yeah. And you are, are you, do I have you muted? I have you. Kevin is muted, unmuted. You have to unmute yourself. There you go. There's your beautiful face again. Do I have a screen? Or do I have a share? You have a screen. It's shared, but I'm seeing your side, um, tiles or. All right, everybody. Welcome back to another OpenShift Commons briefing. Today, as we like to do on Fridays, we're doing talks about organizational digital transformation with folks from the global transformation office. And today we have with us, Kevin Beer, with a great title, Rage Against the Siloes and Other Windmills. And he's going to introduce himself and his topic and we'll have live Q and A at the end and a conversation. So Kevin, take it away and self and what you do here at Red Hat. All right. Thanks, Diane. So today I'm going to talk a little bit about silos and Diane and I were talking before we were on and broadcasting here a little bit about how sometimes I like to use the space and maybe some other folks do too, which is to kind of work out some ideas and things that I'm noticing during the weeks that I'm talking to execs and different clients, but also a lot of folks that just have questions and we're trying to help out. So I kind of wanted to put these ideas together just because I'm hearing a lot of people say a lot of things and I'm hearing these conversations kind of die off after they say, you know, well, damn the silo, right? And so I want to make sure that, you know, as we kind of communicate out to folks that, you know, a lot of people are struggling with these problems. And I think there's been an echo chamber over a lot of years, Diane, like around just how, you know, do we actually start to address these problems? So I'm just going to kind of throw some ideas out there today and, you know, I definitely reserve the right to be more moderate in questioning than I'm going to be in presentation. And I do the goal here is to make us think and to maybe unstick some of the ideas that we've had and kind of been rattled in. So that's what I'm going to do. All right, so off on the off on the adventure. So I work in the Global Transformation Office at Red Hat with three other dudes and a bunch of hopefully a bunch of other folks that will be coming online here. But Andrew Clay Schaffer, somebody might know Andrew, you know, co-founder Puppet, worked at OpenStack Project. He's done a lot of stuff, built a lot of things, came from Pivotalast where he kicked a lot of rear building an organization there. John Willis is a gentleman I've known forever has done, gosh, I think most of the state of DevOps kind of reports at the DevOps Days conferences. Really, really brilliant guy with like 40 years of experience working in banking and, you know, going way back and yet still staying prescient and very, very relevant in conversations right now about automated governance and automated access stations and some really, really brilliant things that he's been working on in that space. Jay Bloom has been a partner of mine for years. We consulted together. We've also our friends, but Jay is finishing his PhD right now at Carnegie Mellon and he's actually working in the field of organizational planning design over long periods of time and transition. So, and Jay is one of the smartest people that I know I love to get to work with him. It's an honor. So, the DevOps methodology, I went on devops.com and did a query for silos and I think I want to say between seven and 800 results came up. I think it was like 745 results came up and I kind of scrolled through most of them. And to be honest with you, most of them were all the death of silos, you know, or every silo is bad or if you find one on the road, kill it, that kind of stuff. But what I really want to talk about is some of the things that people surround that phrase with just doesn't make any sense. And one of them is this notion of the DevOps methodology. There is not one. So, just want to say that. And when we talk about the DevOps methodology all the time in these articles that people write, and I know people mean well, this is not a thing that you can reference as a standard body of knowledge that everybody can go pick up and do. It's not the ITIL, right? It's not some sort of framework. So, we need to stop referring to it as that. It's really an adventure in sociotechnical thinking and systems thinking that really allows us to start to view things differently, right? And view our work environment completely different. We have, you know, and I looked through these presentations and there was all this talk about culture. So, they seem to be these touchstones, silos and culture. And like the echo chamber is strong. But the only thing that I found in all of these scenarios was that we thought we were solving something by just calling it out. So, in terms of our ability to kind of grok culture, I want us to think about it more in this slide. I'm not trying to define it exactly. But I do want to make sure that we understand some elements of culture. And one of the thing is, is it's inherently a rear view mirror. It is inherently what we've done in our organizational disposition. It's about how we have worked in the past and our propensity to do that again. And so, we got to remember that when we're talking about cultures, we might well say that I've been looking in the rear view mirror or when we look in the rear view mirror, what do we see that we've done, right? We have predisposed kinds of things that happen sometimes with triggers or stimulus. But then we kind of also could observe that we repeatedly act in ways. And sometimes we don't see that. And that can be the value of bringing a consultant in or somebody from the outside world to say, this is a little weird. So, people are saying that silos are bad, right? And there's just a lot of truisms that I hear at conferences that are wrong. But we're all titled to our opinions and we're all entitled to our experience, right? And so, what I want to make sure that I say here is that silos are not our problem, right? They're not our solution. Getting rid of them would not be necessary or sufficient to generate DevOps in an organization, to cause it to spawn, right? And to cause it to grow. Silo's don't stop this stuff. Matter of fact, it exists in spite of them in many cases, but it exists because of them in many cases. So, one of the reasons why I believe this is that what we start to see is that really what DevOps is, is it's more about cross-functional alignment than killing silos. And if we're having cross-functional alignment, usually that means functional stuff is contained in organizations and suborganizations, which we would call silos. So, if we think about having to actually work across those functions, then we actually are thinking more about how the DevOps kind of chain works, which is that we reach across boundaries, right? We've reached, we reached across development and operations boundaries. And a lot of people thought because we had to do that, the boundaries themselves are the thing that we have to attack. And they're not. And furthermore, you don't even have permission in most cases. If we're going to change an organizational chart in many orgs, it requires quite a bit of traversal upwards to get to somebody who actually could say, well, let's talk about that, right? But then there's all kinds of implications about changing organizational charts, like the rest of the organization and also the ideas that are inherent in HR about how your organization should be put together in terms of spans, layers, and reporting, those kinds of things. So, what I'm trying to say is when you see successful DevOps, it's not always because somebody flattened the org. And in many cases, I'm going to tell you that flat orgs are not a guarantee of any kind of success. So, what's really important is that if we do have organizational silos in our company, and they do exist for a reason, in many cases, they're like blinders on a horse, right? We think about just all the things going on around us extraneous to us that are not important. So, we kind of need to think about how we organize and what we do. But what's really important is how information and actually boundary spanning can happen across the silos. So, the notion that organizational structure is to serve strategy is an old one. And it's almost so old that we've forgotten it, right? Because if we change strategy as a company, then we could conceivably change organizational structure, which we see happen in some transformations, but often too many of those organizational structure scenarios, in my opinion, involve words like digital and where we actually reframe organizations that provide crucial functions in light of some new buzzword or whiz bank thing. And I'm not saying that we don't need to add capability and add organizational functions whenever we need to do different things. It just comes way too fast and way too cliche in my opinion in many cases. So, one of the basic things that I think is important is that when organizations announce strategy, board members, this is a message to you guys and gals, is that you need to start to ask and ask for demonstrable proof, not that you can say this is guaranteed to work, but ask for demonstrable language and some sort of conception of or concept of what the organization structure needs to be and how it needs to change to support this new strategy. Because one really interesting things, I've seen organizations do multi-variable type of experiments where they'll actually cut organizational functionality in one group while they're adding it in another group as two kind of separate movements, but one is used to pay for the other. And one of the things I often say is that you have no idea how your organization is going to respond when you add functionality. And so before you delete it, especially in operations or at the end of your value streams, you need to make sure that you have the throughput capability to draw that new capability's work and requirements and all of the needs that they have through that end system. So, I'm going to go back to this one other thing. This is that even though organizational structures often don't serve strategy by any means, because I can walk in and do one of the most simple tests, we can ask somebody why they're doing something in an organization, or we can even do a worse thing, which is asking what the organizational strategy is and then what it means to them. And most people can't tell you what it means to them other than if it's made them do a new project or something like that. So, one of the things I want to talk to you is to use a little bit of a tech networking example here, fairly shallow, so it shouldn't be hard. But back in the day, a lot of us remember the seven layers of the OSI model, right? And we think about like how we're connected in organizations. If you want to think of a flat organization, you want to think of it being like a layer two network, a really huge layer two network where everybody can hear everybody else's traffic, where everybody can hear everybody else's broadcasts that just say I'm here, right? So, in some ways, it could sound like you walked into a neighborhood or a huge stadium, depending on how big this network is of dogs barking. And really what that means in sense of dogs barking, not that we're dogs, but if you've ever heard dogs bark, you know, there was a great far side comic that actually showed that they were all just actually saying, hey, they had little captions above their names or their heads while they were barking. And if we actually have an organization full of people broadcasting their normal things that they do every day and it's all out in the open, we actually can saturate our organizational networks with meaningless communication, stuff that has nothing to do with us, right? And so it's really, really important when we actually decided to use this new technology called VLANs was created to allow us to segment network components, even inside the same switch, right? Create a virtual LAN that did not have connectivity to the rest of the LAN, except through either some sort of router or firewall or something that would actually direct the traffic back out to the norm or where everybody else is heading and the gateway. So the problem that we have is that in order to have traffic like that, it has to be very specific and routed and it has to have rules. Our organizations have rules and they have this kind of traffic routing in place, but it doesn't work right in many cases or it was designed for something else, obviously, because what's going on now just it's not being served by this. So it's important to think about it's silos are a really important way that we can segment communications traffic, focus, improvement, and all kinds of things that are specific to our function as it relates to other functions. But what we need to remember is that if our silo is completely permeable, it's not a silo. It does not help us focus. It does not help us work. So silos just kind of one of my general rules can serve us as long as they don't hinder the flow of work. So if all of my work comes from somebody else and all of my work goes to somebody else, I'm obviously in some sort of flow of work. Now how well that works across the different functional groups that add value back to the whole. That's something that we have to start to figure out. And I think DevOps in a lot of ways was an early answer to some of the problems that were there. But make no mistake DevOps is not an organizing scheme. It is not a routing scheme. It is not even a methodology, let alone some sort of organizational methodology. And so what we need to understand is that just like in our data centers and in the cloud, we can have workloads and some of those are completely persistent and they always go on. But other ones are ephemeral and come and go as they're needed. In organizations, it's really important to think that not everything that needs to be done needs to exist in a organizational caste structure. Something built in concrete, right? Like something that stays and really has durability. But rather a lot of the things, the things that we need to functionally do together can also be organized ephemerally to pop up, get the work done and then go away. So these are kind of called response options or what I'll call a response repertoire. Our organizations have very few response repertoires in their bank in terms of how do we solve this kind of a problem? How do we solve that kind of a problem? Great example is response repertoires first started to pop up in a lot of places around disaster recovery. There's not a full-time disaster recovery team. There's roles, right? We started to see it happen in information security with teams, right? Whenever we needed to run something involved a red team or a blue team, right? We were able to actually kind of form those ephemeral teams that we'll disband at some point. But the thing I think it's really important is that silos function as well as the way traffic and the ability for practices and relationships to permeate that silo that are relevant, right? So what's key is how that stuff's routed, how it's let in and out. I mentioned this a little bit before, but I'm a really big fan of moving to the idea of roles over job descriptions. And this is a very subtle thing for some people, but not for me. I think that the difference is, is that how hard is it to change your role in a company versus how hard is it to change your job description? So I think one of the key pieces we can start to move to in our job descriptions as we move forward is we can say that they are to play a variety of roles in that job description. And we can mention some of those roles, but not limited to those roles. In other words, in order to contribute to the value streams as we see fit, right? In other words, I think organizations are the most effective whenever they think about organizing around work instead of running work processes through organizations. And the reason for this is quite simple. One is purpose built. The other is a reaction that's going to have a lot of other rules and it's going to have a lot of other residue from the way the organization will originally work. And it might not even be good for that kind of situation. So I mentioned ephemeral things. Crews are huge things. Some of you have heard J.B. and myself or even David Snowden talk about these notion for crews. I really love this kind of concept, which is kind of based on the volunteer fire department notion. It's a great example of a crew in that the small town might not have enough fire activity to warrant having a full-time fire department or say a shopping mall that couldn't get underwritten insurance if there wasn't a professional fire department there. So what a lot of towns do that don't have that need. They use the form of volunteer because it's in everybody's interest obviously to put out fires, make sure there's fire safety. But since there's not enough demand for a full-time or budget for a full-time crew, the community will usually band together by the fire engines by the house, maybe even elect a chief that you know they'll be there full-time and a couple of full-time employees if they're a little bigger. But the volunteers that work somewhere else and already have a job make up the majority of that response mechanism. So what happens that I think we all know at some level is these people are doing their actual day jobs, but when an emergency happens a signal will go off, sometimes audible, sometimes vibrating, sometimes you know just a notification to get our attention. And when that signal happens it kicks off almost like a script of scripts, right? All sorts of people that know their role in this particular situation scramble, they leave their desk, they jump in their cars and they go to the firehouse. They know what they're going to do when they get there, what their role is because they've rehearsed it whenever there's not a fire. And this is a key thing that I don't think our organizations get a chance to do. We have to take the chances. They're never going to line up and we're never going to have an opportunity that just says, hey, you have enough time to rehearse something. But whenever we find particular situations in our organization where our response is really jagged and it's not smooth and we don't seem to meet the objective that we're uniting to do, then we need to practice it. And I think that any kind of response option that has some sort of a timing element and a criticality element to it needs to be rehearsed. So these folks rehearse assembling on a signal, but more than that they rehearse, hey, where are you going to sit in the fire truck and what is your role in fighting the fire? They learn all of those things when they arrive at the fire station, they know what to do. They know what they need to put on the truck or what they need to wear and they get in and they occupy their position in the truck ready to perform any function that's needed as they get there. So it's really, really important to understand that these are rehearsed roles. And what makes a crew so powerful is its ability to assemble no roles, not have to storm and norm and do all that junk. They already know what they're doing and then they go do their purpose and then when it's done, they bring their equipment back, they put everything away so that it's ready for next time. In other words, documenting, handing off knowledge to other folks and then they go back to their day job. There are so many things that we can do dev ops wise in terms of collaborations, in terms of incident responses, in terms of security design, all these kinds of things we can do together if we have response repertoires that include the ability to form dynamic crews and disassemble them. This is powerful and it's something you can work together with your managers and directors to even cross functionally because when you can call a play like this and people assemble and know what they need to do, all that matters is what they're going to do. And when you have an organization that has a bunch of these response repertoire type of situations, your staff can rotate in and out of these crews over time and actually start to spread the basics of what we need to understand together about how we solve these problems together. It's really, really powerful. So I want to say that outcomes can happen in spite of structure. I hear a lot of people speak at a lot of big conferences and they go in and they get to brag about all the stuff they've done and I've listened to a lot of executive presentations and some of them are amazing. Some of them are actually tier inspiring when you look at what they were able to do as a group and put together efforts to kind of offset or miss the kind of doom that they could have been headed for had they not banded together. But I think it's important to say that a lot of times the outcomes we hear about at these conferences or from people or in magazines or on the web, there's a lot of stuff missing from that, right? And one of the things I think that's important is to understand is that you can get a great outcome, but you can get there in a really crappy way. And sometimes it matters. Sometimes it doesn't. Sometimes you just need to get there. But my point is that organizational structures that are not optimized or that are even dysfunctional can still produce some pretty amazing results because people figure out how to do it. Now the thing I will say is that sometimes the toll on these people in these organizations can be extremely high and not sustainable. So just getting something done neither proves the organization nor proves the level of sustainability of the effort. And so the more convoluted and the more dysfunctional the organization, obviously the more heroism and over effort and, you know, kind of multi-effort becomes. And so that is kind of maybe not the trajectory we want to be heading on. We want to be on a repeatable, a sustainable trajectory, not that everything is the first time we do it, but long-term that's where we want to head. And so the ability to actually achieve outcomes through structure, in other words, with a structure that actually enables the strategy, allows you to have this degree of repeatability because you're not having to do the heroic play, right? You're not having to catch the uncatchable ball. You know, you're not having to write the unrightable report, right? You're actually able to do it because the structure allows all of these different functions to add value in a way that allows flow to happen. And when we have that, we have repeatability in many cases. And I think that that's really what we're after in the enterprise. Not only just results, but results that can be repeated by more people over time. So kind of what I want to talk about is that one of the signs that you are actually making some functional silos work for you would be to actually build these management cadences between the silos, right? The functional leaders. In other words, it's really important for them to actually understand how each of them contribute to the greater ability to achieve the strategy. And it's really important that the folks inside of those silos understand that as well and understand their agency to work outside of that structure and work across the boundaries and who they should be working with. This is a really, really important thing to understand is that these functional leaders literally don't own the teams. I mean, people might say that, but they don't. They don't own the projects. They don't own any of those things. What they really own is the performance of the team against those projects, against those goals or missions that the company has put together. And they own it in a way where they have to make it happen, but it also has to contribute correctly to the larger set of functional actual kind of output to create the overall enterprise goal or the enterprise strategy to be satisfied. So this kind of notion of orchestration is really, really important. Because if you think about it, you know, this is stuff that Jade and I talked about when we were really kind of building out some of the notions behind enterprise service design and orchestration and really starting to understand that each of these functional areas is providing output that's or actually modifying other output from other areas to create this organizational value. And so when you're talking about these leaders, directors, vice presidents, senior vice presidents, they are like orchestra conductors. And so every section in the orchestra or every function you could say has a first chair, a leader. This is who, in many cases, the conductor will communicate with. And this is something that I think is really important. There's constant eye contact. And so section leaders are really, really great like kind of motif for this. Now, what I don't want to hear is people turning this concept of the orchestra into some sort of organizational methodology where they basically have some sort of notion of breaking down every piece. That may work for you. And the concept works, but it's not meant to be carried out in total, you know, total literal sense, right? Because we don't actually have instruments and we're not playing in an actual orchestra, but the universal principle can work. And I think there is a reason why oboes still sit together. And the reason why I brought this up is there is a reason for partitioning and for functional siloing. Now, maybe not with the depth and with the lack of permeability that most silos have where they only open at the top and at the bottom. That's not really what we want. We want to see silos standing together, but literally the walls have permeability. What happens when one silo might even get isolated is that this kind of strange thing might happen, you know, the perforated equilibrium where essentially it's like the island effect. We have this here where I live where there's small islands and keys. And sometimes the wildlife on those islands and keys, depending on how far out it is from the mainland, they actually start to evolve differently. Sometimes faster. There's a smaller set of parameters that are moving very quickly. But sometimes you get bigger bugs. Sometimes you get strange things, right? And we've seen this all around the world. So some organizations in an effort to make innovation more sustainable and happen bigger, right? Start to actually allow all of that kind of perforation to happen. And or sometimes what they do is that they will separate a group off. And this is what happened early in DevOps. And it was, I think, a big anti-pattern. Create the DevOps team and isolate them. And in many cases, they got special rules. And when they got stuff done faster, because they were allowed to collaborate across organizational pieces, and they did it at a better quality, people wanted to repeat the silos. And what I always say is how you start it is how you're going to actually do it, in many cases, because inertia is powerful. So when you start these things, don't start them in a vacuum. Make them deal with organizational rules. Of course, people are going to get a lot less done if they don't have to deal with compliance the same way that everybody else does, right? We need to address the real organizational throughput issues and design issues and not create fake solutions that aren't sustainable, because we can't have everybody be using exceptions all the time. There's a reason why we have compliance, and there's a reason why we have to comply to certain things. So unless we're complying to things or over complying in ways that don't help us, we have to actually address the real issues in our system. And if we have a flow and a throughput problem because of that, DevOps collaborations are a great way, a crew can be a great way to figure out how to deal with a compliance issue or satisfy some sort of a control, right? But at the end of the day, we want to make sure that we're actually using rotation as a powerful way to create more response options. If I have two people that are my experts on something and they're not available, I don't have that expertise anymore or any part of that expertise. But if they've cross-trained with somebody over time and somebody's circulated through their groups, they will have picked up something. And I can tell you that when I have nothing, something sure beats it, right? And so I think one of the things that we can find is that over time, we can start to do pollination the way that I talked about in the coal miner talk that I did a long time ago, DevOps and coal mining, you can find it out there. But the idea was is that in the mine, people would learn the Pareto shape of each other's job. In other words, what is the 20% that I can learn from what you do that will give me some high degree of functionality in what it is you do? So if you got hurt, if you became disabled, or you couldn't show up for work, I could be able to pick up the slack and be able to do some things. Conversely, with safety, if the person who understood safety on that crew was killed or hurt, and nobody else knew how to cross-functionally perform those functions, there would be a big problem. So learning everybody's thing, part of the DevOps notion of us having these kind of Venn affinities with development operation security, but again, they don't all 100% aligned. There's a Venn affinity. In other words, a small part overlaps. That's when we're achieving the kind of organizational response options that we need to, because that adjacency of that Venn allows somebody with the smaller part of that to be more functional. And teams that have worked like that can actually be more functional too. If they all have a piece, you might get a hole. It's certainly better than nothing. And over time, you'll get many, many, many functional engineers and folks that can actually step in. It's so much better than just constantly reinforcing the knowledge that one or two people have at the expense of the rest of the organization. So yes, OBOs do need to sit together in the orchestra, because they contribute in a way where they actually need to do this. Same with strings, right? You don't see folks messing up the sections or playing with them a lot in orchestras. Now, in some new classical orchestras, you'll see some variations of this. But again, I think it's really important to understand that even if the orchestra adds a rock band to play with, which we see a lot of times, they'll actually, the rock band has its own set of conductor, right? It's singer, it's drummer, and they will oftentimes sit beside or in front of the orchestra. And then the conductor of the orchestra will then triage with the person in the band and then the rest of the orchestra itself. So in a sense, an orchestra can become a silo, right? And the band can become a silo, both playing on the same stage, both playing music that mixes together and produces a wonderful performance. So I hope that kind of some of this talk has maybe caused you to think a little bit. We don't need to rail against silos, right? But we actually have to work together and we've got to build organizational structures that actually accomplish or at least don't keep us from accomplishing our organization's goals, right? And it's a continuum. And there's not a lot of room for perfectionism here because humans are involved, human structure is involved, and human politics are involved. So when we've got those things, we've got our egos and we've got a lot of our feelings and we've got our aspirations in there too. So we need to be careful. But I can tell you this, we can make changes in roles, in response options, and in flow. And those are the areas we need to focus on. Those areas over time will allow us to say, listen, let's organize around the way we're doing work right now because we're not able to. Work can advance past the structure if it's careful and we're careful about it. It's subversive, but it's the right thing to do in many cases. So work inside your organization to find out how much of the structure can be changed, but be careful about changing it because it is an experiment. You don't always know what's going to happen. And remember, just because it's the opposite of what you have that doesn't work, doesn't mean it's going to work. So that's the thing I really want us to understand is, it's not that silos are good or silos are bad. It's that because you're having trouble with silos doesn't mean that no silos or the removal of all silos will help at all. You'll get a lot of broadcast traffic. You'll get a lot of chaos and a lot of people that need tiebreakers. And that is not something that's conducive to what I would call a matrix. And that's a topic for another time. But at the GTO, we're working on these things all the time with leaders. And if you're a CIO, CTO, or an organizational leader that wants to work on these things in your organization and make substantial change around transformation, this is something that we do when we work with, like I said, leaders that are doing this all the time. This is something that we are very interested in advancing our practice on and have been working in this space for quite some time. So my experience as a former CIO, CTO, an author and kind of researcher get peaked whenever I see organizations that are brave enough to admit where they're at and start a journey towards what they want to become. And so we're very much a part of that at the enterprise level. And if you're a leader doing that at a large level, we would love to talk to you. So that's all I have for today, Diane. Well, that was actually really interesting, especially coming off the heels of last week's talk with Jaybe on entanglements and all of the wonderful things about systems thinking and Donna Haraway. I love Jaybe on those topics. Yeah, it's quite fun. I think this is the year of systems thinking too. And I love the use of the word permeability around silos and the networking as a metaphor for that in layer two and layer three. I think, and before we started this call, I was chatting with you about how an organizational structure sometimes predestines what the outcomes are and the way that we work together. And I think I just wonder, like we have all these silos and I love the permeability thing and kind of I have, if anyone knows me, I have this fetish for jellyfish diagrams. They're amazing. The different open source projects and how they're all entangled with each other and connected and connecting. So it's a lot of what you're saying, I'm thinking in my head, oh my, having structures for fulfillment for contributors and maintainers. But on the organizational side, a lot of what you're talking about conceptually works fine. It's really, really amazing. But I'm wondering how much of these silos predestine how they're like concrete forms when you're building a house, sometimes breaking them down. What your experiences of helping people to break, not maybe break the forms because then the house might fall down. But get through them easier. What do you suggest around that? I mean, sure. So one of the reasons why I'm talking to folks, silos are not ideal unless they're kind of purpose built from a flow perspective. But one of the reasons why I talked about living with silos is because of where we have to be in the organization to get to change them in many cases, especially the larger, the enterprise. And so I think one of the things I often say to people is, can you actually, if you put on your positive intent hat and you turn it up to 10 or 11, because it takes that with some of this stuff when you're looking at it to block out all the other stuff, you turn it way up. What you're going to find or what you're going to want to do is look at what could be given that I have a positive intent, I want to get this work done. I want this mission to get met. Why would I put this here? And one of the things I think that we fail to grasp is we come up against the thing, the silo. And we're like, I trying to get this thing done. And now I feel like I've got to blow a hole in the side of this thing to get to the thing I need. And the person who should help me. And I can't because somebody's given me the hand, not the face. And so I'm trying to do this. How am I going to do this? And what a lot of times we do is like, this is a dumb silo. And it might be. But what we don't know is that when organizations, a lot of times, because they lack response repertoire in many cases, only have one option whenever a bad thing happens. And that's they make a rule. They make a bunch of rules. And they'll say, that can never happen again. So what we're going to do is we're going to make an insert silo here. We're going to protect this team. We're going to make sure that nobody can get them to do anything except for a thing. And so one of the things I found that Goldrad had said over and over again that's kind of bounce around in my head like a 22 bullet, is that I think because it shreds a lot of ideas that I have is this kind of idea that you're going to, first of all, the rules that people give you are often in the form of measurements. So one of the things I used to always say is tell me how I measured and I'm going to tell you how I behave. And also, if you want to get value from a new solution, you have to uncover the rules that allowed people to live with the scenario that existed without the solution. In other words, a lot of times silos are literally just the things that people do to be able to live with the situation. And so when you talk about removing it because of X, you may not address all the reasons that the silo was even created in the first place, albeit completely dysfunctional, but until we figure out what those rules were and how we could solve for those problems, that organization is not going to go away. We're not going to get to play with it because it's protective. And I think a lot of what we see in our enterprise that we're running into is this weird notion, I keep talking about this and I'm not sure if I'm lucid, but is the idea that for the enterprise to exist, it has to provide enterprise value. In other words, not an individual's name, you're buying because it's the brand, not because Ted works there, right? Because if that's the case, that's individual value. And so I think that many times we fail to understand that the way enterprises protect enterprise value is something strange, which means if one person can't become a brand in the enterprise, one or a few people probably aren't going to change it drastically. And that might not be a bad thing if for shareholders who are saying, I like depending on a check, I like knowing that this place is going to do what it says it's going to do, and now you're going to change that, that stinks. I don't like that. So what if you're going to be more happy? So I think one of the things that we have to understand is if we can address the rules that cause the dang thing, we have a chance, or at least we have a chance to say, could we try this? And I found a way a lot of times to get rid of a silo is just to act out the cross functional alignment as an experiment, right? How did that go? And by the way, this is kind of what DevOps feels like to me. We've got this network team and we've got this developer team. And the developer people are like, why do we have to know about firewalls? And the network people are like, because they're more important than anything, right? Of course, nobody says that anymore. But the point being, we actually have to really start to figure out how we could do these collaborations so that I can pick up a little bit of your peanut butter and you can pick up a little of the chocolate, right? And we can have a Reese's peanut butter cup. But the one thing that a Reese's peanut butter cup is, it's not all chocolate and not all peanut butter, and it's not the mix of both of them. They're separate. And it works because when they combine together, it's at that moment that we want to get the value, right? And so it's like, I think it's probably a pretty crappy analogy, but I think if we can address the problems and suggest a way to experiment around solving the functional issue, not the silo issue, if we can get the silo to be more permeable by allowing things to work across it, we can align with all the functions. And then directors and managers have a job, which is to kind of cadence that alignment across the silos. Hey, do you need to work with this team? Do you want to work with this group? Could we put a crew here? They're all talking because what they care about is the flow of work, the health of the system, which actually should help create the morale, right? And so that stuff to me is very idealistic, but at the same time, you've got to back up a little bit and figure out how the heck we got here. We've had this conversation too before. And we'll have it again, trust me. Oh, I know. The repeatability thing too. And what I really like is the concept of the crews. And Andrew's talked about it. You've talked about it and everything. And one of the problems we have in software, whether it's open source or not or anything like that is the release process. And right now, I am a proponent of everybody on an engineering team should have to sit on the release team at some point. Absolutely. They should have to feel my pain of getting that release out the door. It doesn't matter. They don't have to be there permanently, but they need to know what it takes to build the whole thing, get it out, get it through the CICD pipeline. But everyone should have a seat at that table at some point so that they could be in an emergency part of that crew. And I'm speaking from experience with OKD and other projects that open source projects. But that kind of rotation of duties so that there's an awareness of what the risks are and the responsibilities are of each of the other teams and how to actually maybe not to do it perfectly, but at least an awareness of that. And we I gave an example, a few talks back with you about I worked at Fujitsu back in in the mid 80s. Yeah, they would rotate. And we've had this conversation about Japanese management styles. And there's a title for it where they rotate the managers. So it would be that, you know, people would fly in. I was in Hillsborough or and they would fly in from Japan and from head office and sit in, you know, operations for, you know, two months, even though they knew nothing about it. Exactly. Or put the operation guy in finance for, you know, two months or whatever it is, and they would just rotate management seats through it. And, you know, some of them, you know, at the time, those of us who were in the IT departments and the working on the stuff were like a little doubtful of the value of this. But in hindsight, it was huge, you know, the awareness of what goes on in the other silos. And the thing that was really cool about it is we made those connections. You know, when you talk about the permeability, we then knew who was that dude in operations saying, hey, you're way over budget or, you know, that workflow is just not going to work. And a lot of having and we were joking about this before the talk, all of us at Red Hat are now just finishing up our compliance ethics training for last year, you know, always has to be done by the end of this month. And so everybody's scurrying to do the little courses. But I think the other issue is a lot of those rules are there not for efficiency, but for protection. Yes. To protect the enterprise. And so the and the reason that sometimes those individual DevOps groups that got instantiated were successful because they didn't have to pay attention to all those rules. And it's really the integration of the compliance and risk officers and the operations and the finance with the IT and the software development folks, that when you have people who have at least a notional understanding of what these other roles are and who these players are, the communication is really the key, I think. Absolutely. For being successful. And you're never going to get re-assilos. I mean, it's maybe in five generations. I don't know. I mean, I have this visual of driving through Alberta because I'm up in Canada and the old silos that are up there now that are like the grain silos. And those are what the postcards are. We love them. They're memories and stuff like that. But there's still some of them functioning out there. Oh, I know. I know. Every once in a while, one of them blows up. Yeah, it's pretty crazy. Yeah, or some kid falls in. Never mind. That's what that's like. But it's, you know, bad metaphor. But I think the the key, I think, is and that's why I think I'm caught on that permeability thing. I have. Yeah, just as a concept that, you know, like Cruz and a lot of these kind of biological concepts, you know, Dave Snowden kind of many, many years ago kind of really peaked me with some ideas around this. And, and, you know, I think if there's one piece of piece that I've picked up from a lot of interactions and conversations we've had over the years, this is that if we treat organizations more biological than mechanical, we're going to have a better, better set of expectations about what's possible about what really is complex. What things just are not repeatable and sustainable. Maybe we can start to drop words like drive and roll out and, you know, those kinds of mechanical terms to refer to what we're going to do to people. And, and also the way the relationship will be, I will drive it to you. I will roll this out on you. Like it's being done to you, right, instead of with you. And so I think really, really healthy organizations have an understanding that they're managing a complex adaptive system of human beings versus cogs, widgets, and machine terms. And so when we do this, and like you were saying, the rotations, it's really hard to have empathy for what you can't even imagine, right? And, and I can't tell you how many times I've worked with execs and rotations or, you know, like you were talking about the release, this is one of my isms. Bring the executives to the release, but first you have to do a bunch of work to make sure that the people doing the release don't think it's because they stink, right? So there's a really, really important setup that has to happen there from the exec who comes to the developers who are doing and engineers doing this release. Hey, I'm just here to learn. I'm clueless. I want to know what you guys have to go through to get this done, right? Get, I want some empathy. Like I need to be able to talk to people about this other than with all the oversimplifications everybody uses, right? And I don't like it when people think a release failed when we had, when we learned to something. I want to learn something today about making this easier together, what you guys think, what this team thinks will make this easier, right? And when you go to that, I'll remember the first release party I ever went to, right? And I just walked out of there and I was like, Oh my gosh, what am I doing to these folks? Why haven't I been warring every day to make this easier to make this, because it would make everything better if we worked backwards through this problem, right? And so we started to, right? And in almost every case where you do this, you have some single person that gets on the hook for fixing all the problems. Oh, boy, come to the OKD working group next week, you know, talk about this last release process. Yeah, it's, it is, you know, you just make a bunch of brints, right? That like constrained folks that want to help and they're doing their best, but it might not be sustainable, the level of effort these folks have to do, plus the distribution of knowledge, empathy, all that stuff is so huge. So I think sometimes we think that we have a knowledge economy in tech, like we were hired for what we know. And there's a certain amount of that's true. But if we haven't figured out right now, it's, we're hired for what we can obtain, learn, and use, right? Every day we're having to do that, which means we're having to unlearn things and take them out of our brains when we have better information. This is exhausting, right? And it's maybe even not something from an evolutionary standpoint that we're used to, right? We are subconscious, you know, jokes people make is that it knows more than we do. But what I look at it as is like a pre, a pre compiled bunch of dynamic link libraries, right? We could just go out and pull that code as we need it, right? But the problem is that sometimes that code's old. And we don't know it. And we execute the same pattern that's not right. And, and so for that situation where it no longer serves us, right? And so I think that when we talk about, you know, actually going and seeing the problem, you know, like, oh, no, and many other people have said for yourself, it's not to fix it. It's not to meddle. It's not to should on people, right? It's literally so that you can develop empathy and you can start to enable people solutions, permeability across silos, all of those things are how you get those things unfrozen, right? And I just think that because we're taught as engineers, and even CEOs are taught all about finance, they're taught about sales, they're taught about procurement, but they don't ever learn about humans. And I think that's a problem. The biological thing is, you know, again, riffing off all of the stuff that we've been doing in past briefings, you can go back to listen the last weeks as well. Yeah, I think that's really the humanizing of the silos. I did really like also your oboe metaphor because yeah, not because I know anything about orchestras or the organizational structure of orchestras, but and I love the idea that the oboe guys and gals get to sit together. But it's like, you can hear the music through the walls, I think. And a lot of what we're talking about is it's almost the human thing is to be able to share the stories. Yes, storytelling and to allow other people to hear and see and maybe be part of those stories as well. And I think that's one of the when we talk about it in a mechanical way, like you will do this. I mean, how many times have we've been out on a factory floor and see someone who's been doing the same job for 30 years? You know, it's funny because those rich stories kind of form a tapestry, right? And I often think that those stories become the clothing that we wear while we're performing the work. And so sometimes, if it's beautiful, that clothing gives us room to move and do what we need to do. But other times it's like a straight jacket. And when you hear that story over and over again, some people just put on a straight jacket. They don't even want to try to do anything. What's the point, right? And so I think you're right. It's the permeability, the flow and the air of the story, the strategy becomes a part of the story, it becomes the missions. And if the story is we can do what we need to do and we're going to, we have confidence we're going to be able to help with this mission versus I can't drive this tank. I can't drive, I can't use this oboe. I can't, it's broken, right? And so like I think how do we understand, you know, as leaders how to listen to those stories and make sure that we're hearing stories from other places like you're talking about the oboe sounding and blending together. So, you know, I think I listened to culture, you know, and I talked about that like that kind of reflection echo, right, of what we just did, you know, an orchestra plays and if they play in a right hall, it has a really great ratio of direct to reflected sound. You get 80%, 85% of direct sound and then the hall is the blending and the echoes and the reverberations that just make it larger than life, right? And that brings that performance together because it bounces all over, literally like you were talking about, we can all hear it. We can hear it and it's definite and it's like the crisp clear direct and then we can hear it in the angelic echoes behind us and around us and we feel it in our spirits and our souls, right? It's multiple levels of energy. And so I think it's really, really amazing as an analogy for organizations because if we couldn't, even if we could all hear each other but somebody pointed their chairs facing the wrong way, it's not the same. And so I think that, you know, we have to take what we have and I think, you know, from a pragmatic standpoint, what can we do to make it sound better, hear better? But we can't hear all the voices at all the times because in the orchestra, not every voice plays all the time and when it does, everybody notices. Like it's a big deal, right? And so in a system, one of the key pieces is, I believe that nobody talks about is, is that we don't always use all of our potential and all of our skills all the time. It's part of being in a system. We subordinate. If I'm a trumpet and I just play and I riff and the sax player plays like Coltrane the whole way through the classical piece, that may feel cool to those people. That's indulgent, but nobody else is going to appreciate that unless they think it's funny, right? But like, I think that the, you know, the notion of this is that sometimes it requires us to just not do, to be, to learn, to rotate, to be out of our expertise. And to listen. Yeah. I think a lot of the key part of being in an orchestra or on any team is the listening to, you know, there's a lot of value in the silences and there's a lot of value in the listening in these things. And the other phrase that I really liked is about the leadership and the management role in the use of the word cadence. And that's where I think good leadership, good management, they're always listening for the cadence and helping to make sure that, you know, the timpani's come in when they're supposed to. Exactly. There is a timpani. Exactly, right, cue the timpani, right, exactly. Yeah. That is a big deal. And I think just creating that expectation. And cadence is also a really important thing. And like Goldratt, Ellie Goldratt talked a lot about a solution that he used to solve the Herbie problem, which was, you know, in the goal, which was the, he had one person that was slower hiking than all the other Boy Scouts, right. And, but he had to show them what they all got there at the same time regardless of who ran out ahead. And so he would put the slowest person in front of the group. And he would establish a drum beat, gave people a rope to separate themselves with, and show them how to use a buffer to not run into each other. And so drum rope buffer became the cadence idea of how we put our constraints in front of us and all play with them together versus all rush them. And I just think that, you know, we don't like to subordinate, I get that as humans, but in a system, it calls for us to do that. So as long as we're subordinating in ways that are useful to the purpose and sustainable for us as humans, I think that's awesome. Right. And that's how we grow. But, you know, the other stuff, we know it because it feels wrong and it hurts us and it drains our energy. Yeah. So, but yeah, this is a lot of fun stuff to talk about. And there's a lot of metaphors here. But the end of the day, this is a management problem. Right. And I think that the interaction between management and staff needs to be, you know, a lot more transparent managers need to create this opening for their people to talk. I think so. Yeah. Oh, yeah. Oh, you've given me a lot to think about and a lot to use. And I, oh boy, I'm just, my brain is buzzing here, especially because I'm stuck in release mode right now. And when someone gets ahead and someone's behind, it's like, you know, no, this all has to come online and be ready to be built. I mean, it's just marching in cadence here is so important, especially in software development. So, yeah, that, that, that's strange kind of notion that there's freedom. And then there's responsibility. And that means like the cadence is part of our responsibility, you know, it's kind of a, you know, that opposites thing that we have to deal with. All right. Well, we're at the end of our hour. I want to thank you again for another wonderful engaging session. It really well, thank you for having me and letting me ramble, you know, ramble like this. That's great. You think it's rambling. I just think it's just wonderful. And it's a great conversation. So thanks very much. I think a lot of people are going to enjoy this one. So I hope so. And any kind of, if anyone wants to continue that conversation, they should just hit me on Twitter. I'm just at Kevin Bear. And we can, we can talk this stuff out even more. I'd love to collaborate with a lot of you folks. All right. Well, I think there's, there's definitely interest in the topic. And you've made my Friday. So thanks again. Awesome. Thank you. Take care.