 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 Beard 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&A at the end and a conversation. So Kevin take it away and what you do here at Red Hat. Alright, 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 this 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 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 some of you might know Andrew you know co-founder Puppet worked at OpenStack project it's done a lot of stuff built a lot of things came from pivotal last 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 Carnegie Mellon and he's actually working in the field of organizational planning design over long periods of time and transition so and James 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 comm and did a query for silos and I think I want to say between seven and eight hundred 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 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 right 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 I till 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 look 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 is 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 light 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 entitled 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 silos 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 sub organizations 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 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 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 was bang 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 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 prove not that you can say this is guaranteed to work but ask for demonstrable language and 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 I one one really interesting things I've seen organizations do 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 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 capabilities 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 is is that even though organizational structures often don't serve strategy by any means because I you know I can walk in and do one of the most simple tests right 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 you know a lot of us remember the the seven layers of the OSI model right and and you know 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 farside 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 land that did not have connectivity to the rest of the land 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 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 dev ops in a lot of ways was an early answer to the some of the problems that were there but make no mistake dev ops 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 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 cast structure something built in concrete right like something that stays and really has durability but rather a lot of the things the the things that we need to functionally do together can also be organized ephemeraly 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 we were able to actually you know kind of form those ephemeral teams that will disband at some point but the the thing i think it's really important is 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 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 to 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 it'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 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 jay by myself or even david snowden talk about these notion for crews i i really love this um this kind of concept right which is kind of based on the volunteer fire department notion right it's a great example of a crew and that you know 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 formal 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 you know by the fire engines by the house maybe even elect a chief that you know they'll 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 desks 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 jagging and it's not smooth and we don't seem to meet the objective of that work you know we're uniting to do then we need to practice it and you know i 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 they 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 repertoire 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 right 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 right 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 you know offset or 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 it's there's a lot of stuff missing from that right and 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 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 and you know kind of multi-effort becomes and 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 un-catchable 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 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 folks inside of those silos understand that a 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 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 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 with when you're talking about these leaders directors vice presidents senior vice presidents they are like orchestra conductors right and so every section in the orchestra or every function you could say has a first chair a leader right 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 you know 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 you know 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 oboe 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 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 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 a I think a big anti-pattern create the DevOps team and 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 a better quality people wanted to repeat the silos and what I always saying is is how you start it is how you're going to actually do it in many cases because I'm 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 we have there's a reasons 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 is that over time we can start to do pollination the way that I talked about in the coal miner talk that I did 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 you know 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 right of us having these these kind of then affinities with development operation security but again they don't all 100% align there's a then 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 then 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 functional engineers and folks that can actually step in right 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 oboes 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 are playing with them a lot in orchestras now in some new classical orchestra 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 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 you know kind of some of this talk has maybe caused you to think a little bit we don't need to rail against silo right but we actually have to work together and we've got to build organizational structures right 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 and you know 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 us 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 really interesting especially coming off the heels of last week's talk with jade um on entanglements and all of the wonderful things about systems thinking and donna harrah harroway yes um so i i love jade on those topics yeah it's quite it's quite fun this i think this is the year of systems thinking too and yes i love the the use of the word permeability around silos and the networking um that networking as a metaphor for that and layer two and layer three because the i think and before we were we started this call i was um chatting with you about you know how an organizational structure sometimes um predestines what the outcomes are and the way that we work together and and i think i like i just wonder um 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 um 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 you know having structures for fulfillment for contributors and maintainers but on the organizational side and stuff i'm a lot of what you're talking about um conceptually works fine you know it's and and really really amazing but i'm wondering um like how much of these silos predestined how organ you know they're like concrete forms when you're building a house sometimes breaking them down what what your experiences of helping people to break you know not maybe break the forms because then the house might fall down but right right right but get through them easier what do you suggest around that i mean sure so one of the reasons why i i'm talking to folks um you know silos are not ideal unless they're kind of purpose built um you know from a flow perspective but one of the things i think 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 um and so i think one of the things i often say to people is can you actually if you if you put on your positive intent hat and you turn it up to 10 right or 11 um because it takes that with some of this stuff when you're looking at it to blank out all the other stuff um and you turn it way up what you're gonna find or what you're gonna want to do is look at what could be given that i have a positive intent i want to get this worked on 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'm 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 you know hand not the face right and so i'm 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 gonna do is we're gonna make a you know an insert silo here right we're gonna protect this team we're gonna make sure that nobody can get them to do anything except for you know a thing and so one of the things i found that you know gold rat has said over had said over and over again that's kind of bounce around my head like a 22 bullet right is this that like i think because it shreds a lot of ideas that i have is is this kind of idea that you know you're going to first of all the rules that um people give you are often in the form of measurements right so one of the things ellie used to always say is tell me how i measured and i'm going to tell you how i behave right and 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 right 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 failed 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 you know 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 like that's not you know 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 um of course nobody says that anymore but the the point being like 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 because but the one thing that a Reese's peanut butter cup is 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 get 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 that 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 you know 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 you know we've had this conversation too before um and we'll have it again trust me um oh i know the repeatability thing um too and the and what i really like is the concept of the crews and andrew's talked about you talked about it and everything and one of the 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 um i i am a proponent of everybody on an engineering team should have to sit on the release team at some point absolutely 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 and that they may be you know but everyone should have a seat at that table at some point so that they could be in an emergency part of that crew um and that would you know and and i'm speaking from experience with you know okd and other projects that um open source projects but yeah that kind of rotation of duties so that there's an awareness of what the risk you know 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 um 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 i there's a title for it where they rotate the managers so it would be they 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 um those of us who were in the the it departments and the the you know working on the this the stuff were like a little doubtful of um 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 yes that workflow is just not going to work and a lot of um and having and we were joking about this before the talk all of us at redhead are now just finishing up our compliance and ethics training for the year for last year you know always has to be done by the end of this month and so everybody's scarring to do the little courses but i think the other issue is a lot of those rules are there um not for efficiency but for protection yes to protect the enterprise and so the end and the reason that sometimes those individual devoc groups that got instantiated were successful because they didn't have to pay attention to 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 being successful this and you're never going to get rid of silos you know i mean it's maybe in five generations we can do it but i don't know 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 yeah yeah the grain silos and those are what the postcards are we we love them their 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 they it's pretty crazy yeah some kid falls in their mind that's what yeah exactly um but it's you know there's a metaphor 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 crews and a lot of these kind of biological concepts um 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 um 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 um 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 and so when we do this and like you were saying the rotations we 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 in 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 something i want to learn something today about making this easier together what you guys think but 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 and 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 right it's very talk about this last release process yeah it's it is you know that 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 um 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 it's like a pre a precompile a bunch of dynamic link libraries right and we could just go out and pull that code as we need it right but the problem is is 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 and many other people have said for yourself it's not to fix it it's not to metal 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 um because we are been 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 you get you the the biological thing is um you know again riffing off all of the stuff that we've been doing and past briefings you can go back to listen the last weeks as well yeah i think that's really the humanizing of the silos um 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 and i love the idea that the oboe guys and gals get to sit together but it's like there's camaraderie right you can hear the music through the walls i think and a lot of what we're talking about is it's almost um the human thing is to be able to share the stories yes storytelling and take to allow other people to hear and see and maybe be part of those stories as well and i think that's um one of the the when we talk about it in a mechanical way like you will do this i mean how many times have like we've been out on a factory floor and see someone who's been doing the same job for 30 years you know yes it's the you know it's funny because you know those rich stories kind of form a tapestry right and and and and i often um think that those stories um become the clothing that we wear while we're performing the work and 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 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 in the air of the story the the strategy becomes a part of the story it becomes the missions and and if the story is we can do what we need to do and we're gonna 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 um this oboe i can't it's broken right um 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'd listen 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 percent 85 percent 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 in its definite in its like the the crisp clear direct and then we can hear it in the angelic echoes behind us and around we feel it in our spirits and our souls right it's multiple levels of energy and so i um i think it's really really amazing as an analogy for our 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 i think that um 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 um but like i i think that the you know the notion of 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 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 and the other phrase that i really liked is about the leadership and the management role in using the use the word cadence um and and that's where i think good leadership good management are they're always listening for in the cadence and helping to um make sure that you know the timpani's come in when they're supposed to and exactly there is a timpani um exactly right cue the timpani right exactly yeah that is a big deal and and i think just creating that expectation and cadence is also a really important thing and like uh goldratt ellie goldratt talked a lot about a solution that he used to solve the herby problem which was you know the 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 drumbeat 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 and i 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 i you've given me a lot to think about and a lot to use and i i oh boy i'm just my my brain is buzzing here especially because i'm stuck in release mode right now and uh yes when someone gets ahead and someone's behind it's like you know nope this all has to come online and be ready to be built i mean it's just marching in cadence here is is so important especially in software development so yeah that that's strange kind of uh notion that um 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 um 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 um i hope so and um any kind of uh 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 um there's definitely interest in the topic and um you've made my friday so thanks again awesome thank you take care take care diane