Welcome, everyone, to depression, to expression. I'd like to tell you a little secret. So come in close, because I don't want anyone else to know. Like, this is pretty nuts. Turn your volume down if you have headphones. That's cool. I don't want anyone else to hear. So come in close. You ready? Are you ready? OK. Come here. Come into the computer screen. Come close to my face. OK. Ready? We are on a rock flying through space. And if you tell anyone, now I know what you're thinking. Scott, I know we're on planet Earth.  I know we're flying through space. But I only think about these things when it's necessary, when I'm going through some kind of mid-life, quarter-life crisis, when I'm stoned out of my mind. This is only when I think of these things. Well, let me tell you, you don't have to be stoned to think of this. You don't. I swear. I swear. You don't need to be stoned. This perspective, this insane perspective, this reality that we live in, because that's the fact we're on this rock flying through space, this doesn't trip me out. This keeps me calm. I think this keeps me the happiest through it everyday life, because how can you complain?  How can that bother you when you look at the big picture of life, when you look at this mystery, this space that we're in, and we're just a bunch of organisms who evolved from fish? It is absolutely humbling and keeps me grounded. Now, the reason I'm bringing this up is Joe Rogan. His podcasts are really cool. His conspiracy theories are, and his agreement about those are a little out there, but his ideas in general are kind of in line with mine. And that's where I got this. I didn't get this perspective from him. I've been thinking about this since I was two years old, which is probably why I'm a little crazy. But he was talking about that people will travel to the Grand Canyon and want to experience all these things when in reality, if you can't afford those things or don't have the time, all you need to do is look up.  And you will experience something that is out of this world. And I don't know how. Like I want to go into work and I want to talk to people every day. I don't know how we don't talk about these things every day. Go into work and be like, yo, did you see the sun today?  There's a ball of hydrogen out there. That's actually what I want to talk about every day. I feel like you should just be able to go into a Dunkin' Donuts or Tim Hortons. Hi, could I get a large coffee, please? Yeah, that's fine. It'll be $2.50. Okay, there you go. Did you see the stars last night? Oh my God. She was like, oh my God, yes I did.  I just want to let you guys know that when I'm having a panic attack or when I'm feeling depressed or just an overwhelming sense of anxiety, that's the perspective I put in my mind. And when I'm thinking of smaller problems that I'm stressing about, I just think, oh yeah. That really doesn't matter. In the grand scheme of things, the restaurant that was out of maple syrup, I shouldn't be upset about that. I shouldn't be stressing that my Amazon order came two weeks late. I shouldn't be stressing that my flight was delayed two hours because after all, I'm going into a freaking plane and experiencing the miracle of flight. I think of the big picture. The rock in space picture. And that calms me down. It really does. Some people like to think of a God and think of religion and a God as your God is looking upon you and taking care of you and everything you do in life should be done through him and with purpose. And when you die, you're going to meet your friends and see all your relatives. And that comforts a lot of people. And sometimes it comforts me. And I'm like, yeah, maybe there is a God. Everything's going to be okay. But most of the time what comforts me is thinking that I'm so small and that I don't matter. It's really weird to say. But in the grand scheme of things, I don't matter. Yes, I matter to my immediate family and friends and what I do on YouTube and things like that. But what humbles me and keeps me sane and keeps me happy and keeps me, keeps existence relatively manageable. Because sometimes guys, it's existence alone.  Existing is hard. And this perspective just reminds me that I'm here. I didn't choose to be here. We evolved. I'm going to do the best I can. And when I die, whatever happens, happens. I have no control. There's a lot less pressure in that for me than thinking that I got a guardian angel and a God's looking over me.  Give me some privacy. I just wanted to share that perspective, the rock through space. Joe Rogan, thanks for reminding me of that. I think about this like every day, maybe once every couple of days. I'll look out the, can you see the reflection through the window?  If it were up to me, I wouldn't do anything all day and I'd just look at space. Should I become an astrophysicist or an astronaut? No, I couldn't be that because I'm not smart and I can't do math and stuff, yeah. Anyways, random video. If you're feeling stressed, if you're feeling overwhelmed, if you're feeling like existence is just a little too much, whoa, that became bright. If you're feeling existence is a little too much, just think, you're here, do the best you can because Earth is just gonna keep on flying through space. Don't forget to subscribe to the channel for more wacky ideas from yours truly, Scott, the Stoner YouTuber.


My name is Kevin Jones. I am an Invitia product manager. Today I want to walk through with you the GPU and network operator. Just a quick news flash, 15 minutes on the current state of affairs, where they are today, how they're constructed, and how you can utilize those on top of your Kubernetes platforms to take advantage of the hardware acceleration of GPUs and SmartNix. First, before we get to the GPU and network operator, I want to talk to you about the platform I specifically work on, which is EGX. And EGX is a cloud-native platform for scale-out acceleration. And you can see in the visualization here that this goes from the certified systems of hardware at the bottom layer through to the EGX stack itself, which is a common application platform built on Linux and Kubernetes. And you can also notice there that the network operator and GPU operator at this layer, and those are the ones we're going to specifically walk through today. You have the CUDA libraries, drivers, and SDKs that are available. And then you also see that NVIDIA is working on different frameworks to make smart systems more available and more easy to develop applications for. So we have things like Metropolis for smart cities and retail. We have Clara for healthcare, Isaac for robotics, and 5G Aerial for the telco work that is being done on 5G today. You may also have noticed that there are different lines at NVIDIA with the GX moniker at the end. And I'll explain those really quickly. The EGX line is really about small-scale, system-on-ship, embedded, manufacturing robotics-type systems. The DGX line is about scale-up. So remember I said EGX is about scale-out. DGX is about scale-up systems. So a lot of our work in the supercomputers lately with the DGX super pods, that's what those systems are being built for. The HGX line is about cloud service providers, so allowing cloud service providers to provide instances to their end users with NVIDIA GPUs in them. And then EGX is our scale-out platform that I've been discussing here today. Now I'd like to switch gears and start talking about the operators. But before we dig into each of our NVIDIA operators, I really want to touch on the operator framework. So a while back, Red Hat acquired a company named CoreOS. CoreOS had many contributions to the Kubernetes ecosystem. One of the major contributions that they gave was the operator framework, and Red Hat has continued to work on this really beautiful and capable framework for deploying Kubernetes native applications. It's a pattern for how you accomplish this, and you can use different ways to write your operators as well. They can be helm-based operators, they can be ansible ways, they can even be go-based if you get really complex. And each of those different layers have either simplicity in the approach of how you build them all the way up to very complex application capabilities. And the operator framework allows you to do deployment, it allows you to do updates and upgrades of your software stack, complex tying together of different components, and it also allows you to tie in monitoring to your applications as well. And so NVIDIA chose this as a great mechanism to distribute and deploy software that enables their both their GPU accelerators and SmartNX on Kubernetes platforms. And when they're deployed together, they actually automatically enable things like GPU Direct RDMA. And if you have ever configured any of these things mainly in the past with GPUs and SmartNX, you know that there is quite a bit of work and almost black magic to get all the things in the way that you need them. And by also doing this inside of the operator framework, we have made it so that we are able to deploy these capabilities onto many of our partners, Kubernetes offerings. With all that foundational knowledge out of the way, let's dig into the GPU operator. We approached this in three parts. The first was to have our container runtime and driver installed on the host and then plugged into Kubernetes. And then we containerized the device plugin and the data center GPU manager monitor and capability called DCGM exporter. And with this set, we had the core functionality we needed. But the next piece is to actually containerize the runtime and the driver, NVIDIA drivers themselves, so that all of our component tree is running as pods on top of Kubernetes. And this makes the GPU node look like a CPU node. And then the last was to wrap this with the operator so that we can manage lifecycle of all these components. And this enables you to not have to worry about all the different variations of configuration and versioning that goes on. This is the NVIDIA GPU operator. With each of these components, we'll talk in depth about each one. So first is our container toolkit which enables GPU support for various container runtimes. This includes Docker, Cryo, Podman, LXC, Singularity and others. And this we integrated specifically with Linux container internals rather than wrapping to specific runtimes. And we can expose the GPUs and the drivers to containers via this toolkit. The next is the drivers themselves. This is the component most administrators are aware of whether they have done containerization with NVIDIA GPU drivers or on standard hosts. And the driver is really the most critical component to exposing all the capabilities of your underlying GPU to your application layer. And the goal here is to simplify provisioning of the NVIDIA driver with our operator. The next is the device plugin. This is a really important part because it allows the applications to make requests for GPUs as resources via pod specs. And so in our example here, you can actually see this GPU example application is making a request for one NVIDIA GPU and that's what Kubernetes will expose to the application. And I mentioned our data center GPU manager, DCGM Explorer, which enables us to take the telemetry that's being fed back from the GPUs and expose that into Prometheus which gives the administrators of the cluster themselves visibility into their GPUs telemetry much the same way they're getting visibility into their CPUs that are running in the cluster. So this is a really great way to take advantage of the native tooling that's been selected in Kubernetes and feed that with our GPU telemetry. So with all of these core components put together and simplified in the operator, we have a great way to expose and get the best out of our GPUs and our Kubernetes clusters. So next let's talk about the roadmap for the GPU operator. We're working on a number of things, new features that have listed on the side here. So things like upgrade management where we handle driver and kernel updates, handle node reboots if we need to. Those things are improving with each release of the GPU operator. We're also working on disconnected and air gap installations where whether you're restricted via a proxy to get out to certain resources or you have no internet connection at all and you have to pull things from custom registries. Those type of environments are very difficult to work in and we're trying to make it easier to utilize the GPU operator in those environments. We're also working on security capabilities like more granular RBAC controls via roles and bindings for the GPU operator. Nvidia is very conscious of security capabilities within our hardware and our software stack and we wanna make sure that the customers are getting the best and most secure capabilities they can. If you haven't seen yet, the A100 is a beautiful piece of hardware that is the most impressive leap in GPU capabilities thus far. It uses the ampere architecture, micro architecture and there's a capability in the A100 that doesn't exist on any other GPU which is called multi-instance GPU and the A100 is physically capable of being sliced up into seven unique slices of the physical hardware which means you could actually have seven parallel processes running on the A100 card. And so we wanna expose those mid capabilities up via the GPU and take advantage of that capability to share this outstanding piece of hardware. And the last worry we continue to work on is further integration with all the Kubernetes distributions that are out on the market. And we have great integration with those like Red Hat OpenShift but we wanna continue to expand our capabilities to integrate with others. I put up some useful links for you to go and follow up with on the GPU operator. The code is open source, it's available on GitHub at nvidia slash GPU dash operator. There is a getting started document that I've linked to here and you can also reach out to us with any of the questions you have. Now I wanna switch gears and start talking about our network operator. If you were not aware, NVIDIA acquired a company named Melanox. At super computing, Melanox has obviously made a very good name for themselves and we wanna continue that trend with Melanox as NVIDIA's networking business unit. And so with the network operator we've taken a very similar approach that we did with the GPU operator. The idea is that we can simplify for system administrators that are running Kubernetes environments with Melanox SmartNix underneath of them. And we wanna simplify the configuration and expose all the capabilities that make those pieces of hardware everything that they are up to your applications in your Kubernetes clusters. So we chose the operator framework to leverage that again. We use custom resources to define what we need from a componentry standpoint. And the operator framework takes care of reconciling the system itself versus the hardware and the software that's configured. And it automates things like fast networking configuration, RDMA, GPU direct. So we did all of this for the benefit of our end customers. We wanted to simplify the deployment experience so that complex network deployment tasks are taken care of for you by the network operator. They're portable across different Kubernetes platforms and it's a consistent deployment across those platforms. We also wanted to give you some operational efficiency gains because we are now managing the network at a cluster level rather than individual system levels. So the operator itself starts to look at this as a cluster capability rather than individual system units that have to be configured. And we want to put the network automation administration on autopilot. Last, we want to take advantage of the architecture itself. So making the operator aware of the architecture. So we did this when we started, you had this legacy where the Melanoxa OFED driver and the NVIDIA peer memory driver were configured on a Linux system by hand or by automation scripting. And then we containerized in the same way that we did the device plugin for GPUs. We have this Kubernetes RDMA shared device plugin that's containerized. Maltis is what really gives us the capability. Maltis allows for multiple network interfaces on a given pod. And the OFED driver and NVIDIA peer memory driver were exposed as plugins into Kubernetes. And the last piece that we did was containerize both the Melanoxa OFED driver and the NVIDIA peer memory driver and we wrapped that with an operator for lifecycle management. And what you get is the NVIDIA network operator. So let's talk about the individual pieces themselves. The OFED driver container is what loads the Melanoxa OFED driver into the kernel. So you have it prebuilt for the distribution and the kernel that's running on the host, deploy it onto the nodes based on node labels. So in both the GPU operator and the network operator, there are these node feature discovery capabilities that go out and label each of the hosts with the hardware that they have. We expose the container root FS to the host to allow kernel module compilation against updated headers. And then we load the kernel RDMA stack and the Melanox driver stack on container start and we unload it on container stop. The RDMA shared device plugin is how you can run RDMA workloads in Kubernetes. And the shared device plugin is the way that we let pods perform RDMA, exposing RDMA device files to the container in a shared manner. And you can see in our example here that it is requesting a single RDMA device and it's limiting itself to that one RDMA device through its pod spec. The next is the NVIDIA peer memory driver container which compiles and loads our peer memory client driver into the kernel itself. So it loads in VP or mem module into the kernel and unloads it when the container exits. This is a really great capability for us to be able to do this. All for the administrators and all automated via the operator lifecycle manager. So where are we at today? So in December, we're looking at helm deployment. We're using node feature discovery. That's what you see NFT there to label RDMA nodes. And we're also working on secondary network deployment. So you actually have a secondary network that is RDMA configured that we can take advantage of in the cluster itself. So that's our 15 minute quick newsflash on both the GPU and network operator coming from NVIDIA. I really appreciate your time today. I hope this information finds usefulness for you that you explore the GPU operator and the network operator. Feel free to let us know if you have any issues or you have any feature requests that you want to add to this. You can find us in the upstream community working on these operator code bases. We really look forward to hearing from you.


Hello everybody and welcome to the OpenShift Commons today. As we like to do on Fridays, we're going to talk about transformational topics as in Transformation Friday. And I have with me my cohort, Jay Blum from the Office of Global Transformation here at Red Hat. And we have a special guest today, Gregory Vignoux. I'm sure I'm killing it wrong, but he is going to talk with us today about risk vulnerability and the precarity of identity, which I think is going to be really interesting. And then we're going to have live Q&A and a conversation afterwards. So I'm going to let Greg pronounce his name correctly, hopefully, and introduce himself and take it away for probably 30, 40 minutes. So come on the ride for us, because I think this is going to be a really interesting topic. So, Gregory, take it away. Thank you so much, Diane. My name is Gregory Vignoux. It's a really hard last name. I am coming to you live today from Boulder, Colorado. I thought it would be good to give a little bit of background here to maybe show you a little bit of where I'm coming from. Some of my practical background, the most formative parts of it, are in wildland firefighting. I worked for the United States Forest Service and National Park Service, primarily on what are known as hotshot crews, which are highly trained, highly cohesive, highly self-sufficient units of about 20 to 22 people that respond to high-priority fires all over the country. And they hike into traditionally remote parts of fires and spend anywhere from just a couple to 14 days working on the perimeter of the fire with chainsaws and hand tools to prevent the fire from spreading any further. It was probably the best job I've had. It was a very formative experience, being able to work every day to eat, sleep with the same bunch of men and women and work for about six to seven months together, doing the same thing day in and day out. So we've got a lot of experience working in units. It's a hotshot crew or a wildfire crew. I think you could also call it a team, and we go all over the country. So a lot of diverse experience there. So when I think about organizations, I think I tend to think about it in those terms, a unit that is functioning in a really dynamic environment over an extended period of time. So that's one of the lenses that I apply to thinking about organizations and today, organizational identity, sort of maintaining that in a very, very dynamic, turbulent environment. So I did a bachelor's degree in wildfire management and a master's degree in emergency management, and I've been fortunate to work on a few different emergency management, disaster management, research projects here and in New Zealand, including co-founding the Adapt Institute with two great colleagues. The Adapt Institute is its purpose is to help progress emergency management, practice and education through a core competency approach. So my background is in natural hazards and emergency management. And I think that when I see this community and interact with you online, I think we have a lot of things in common. I think we're just coming to sort of the same things from different angles. And I'm really excited about that. I'm particularly excited about things like the incident command system, making its way over to your neck of the woods, which is an artifact of the wildfire management system. So I think that there is a lot of similarities, a lot of things we share and we can have a lot of really interesting discussions around incident management and hazards, risk and vulnerability just coming out of from two very different angles. So I'm hoping to be able to continue this discussion with you after the talk and hopefully online through Twitter and email and whatever else. So what I'm hoping to do today in this talk is really elevate the organizational identity and the work. So framing the work as the processes that reproduce this identity as two elements that we can use to evaluate and analyze hazards and risk. So I want to put those central to discussion about vulnerability. So in doing so, I want to first start out with a bit of a metaphor and then dive into some of the theory where we get identity from this theory of self-individuation that comes from Ezekiel DiPaolo and then add in some hang some sociotechnical systems, ideas on top of that. And then finally, I want to move into a hazard analysis look at organizational identity and reproduction. And I think that will give us plenty of stuff to talk about. So this is a general overview of where I'm trying to go with this. I mean, I really like what Korsgaard is saying here. I think it's I think it's really captures where I'm trying to go.  A giraffe is always making herself into a giraffe. So right off the bat, you have something that has an identity. The giraffes giraffe Ness is its identity and it needs to continuously reproduce this identity to continue being a giraffe. So right off the bat, identity is precarious to the degree that you always need to reproduce it. So the metaphor here is you organizations and organizational identity. And I think it is generally easiest to think about organizational identity in terms of what the function of the organization is. But there's obviously more to it to that. I think a lot of stuff sticks to that and hangs together. Some in conflict, some in agreement, some tacit, some explicit. And if we're talking about sociotechnical systems, there are theories of technology and what technology is capable of and how technology should be used and what its role is that that hang to that. And then on the social side, there's how the social and technological systems should interact, what Trist and others call the goodness of fit between these two systems. And there's ideas about how tasks should be designed and how work should be managed and how teams should act. So all of this, I think, kind of maybe coalesces is the word into an identity. So being an organization is already doing something and that an organization has to continuously make itself into the kind of organization that it is. And that is a very precarious thing for reasons that spend quite a few slides getting into is you have to keep the ball rolling to continue having that identity and this becomes particularly difficult when we talk about what is in the environment, what is in ulteriority. So that becomes increasingly difficult. So course guard goes on to say that a giraffe is trying to keep a particular instance of giraffeness going. And one of the ways that the giraffe does this is through nutrition. So giraffes to keep going have to consume plant life. I don't know if you could call them vegans because they chew on bones, but they're definitely vegetarians. So giraffes have to consume plant life to keep going. It drives metabolism. So one of the things that I think she's bringing up here that we should pay attention to is this emergence of identity and environment that are alongside one another. So to part of the giraffe's identity is that it is a vegetarian. So to that giraffe, what appears as food depends on that identity of being a vegetarian. So I do identity plant life equals food. And for identity to continue is contingent upon the inflow of food. So there's this sort of always co emergence that's going on between identity and environment to the degree that if you no longer had any plant life, you wouldn't necessarily have a giraffe. And one of the drive this metaphor a little bit further as an organization. What we need to reproduce our identity depends on what our identity is. And that identity is contingent upon receiving some sort of flows from the environment. So there is this coupling that is taking place that is also very precarious. So not only do you have to continue reproducing this identity, which is hard enough in a vacuum, but you also have to do this now with being dependent on something from the environment entering into the system. And lastly, course guard says that to regenerate, which I think she's talking about the lineage of the giraffe. She needs to reproduce. And I think we can connect this to sort of an organizational in an organizational way by saying that to continue being the kind of organization we are, we need to produce technologies in the form of products and services that will reproduce our identity. I definitely want to get into that further because it's I think it's a very core piece of being a socio technical system. So I want to dive down a little bit here and talk about where some of this idea of having an identity is from and being a entity comes from. There are a number of places that I think you can get this from. I like to use the organismic metaphors that come from an active cognition in the work of Evan Thompson, Francisco Varela, and now Ezekiel de Paulo, which is where I think the work of Humberto Maturana and Francisco Varela kind of exists in its final form for the time being. So the first thing they address is this idea of self production. The giraffe is a self producing unit. But of course, they provide in the second half of this quote, the very important condition that, yes, self producing, but also dependent on environment to perpetuate these self producing processes. So the key to self production here is this idea of operational closure, where there is a network of processes and that network of processes produces some sort of components that organize back into that network of processes. So another way of saying this is that all possible states of activity must always lead to or generate further activity. So there's this kind of self perpetuating, self referential cycle, and this is where you get identity from a few different few different people to include Evan Thompson or an agreement that operational closure is where identity first emerges from. So then you get the condition of self distinction, which is where there is something that differentiates inside from outside of this operationally closed network. They say that it provides, this provides the possibility of a boundary, but it doesn't necessarily need to be a boundary, some kind of processes, some kind of something is taking place that is saying this is the inside, this is the outside, this is part of the system, and this is not part of the system. So those are two conditions that you get in part of having an identity and a thing that is separate in some way from its and its environment. So I think that this is the minimum sort of graphical representation that you can have of what it is they're talking about, right? So I've drawn this with a boundary, because I think that it is the easiest way to imagine it. And then you have on the inside here, you have the top of the feedback loop, which is consist of processes, which I'm calling here work cycles. And you get that from some of the earliest work on socio-technical systems from Trist and Trist and Bamforth, as you get this notion of work cycles that were down in the coal mine, and these work cycles produce outcomes, components that sort of act as the foundation for or organize into subsequent work processes. So maybe one of the ways to think about this is work begets more work, I think is probably the simplest way to put it, but this work that begets more work is always producing the identity of this of this organization as a coal mining organization. As long as these things keep happening, as long as this cycle keeps moving around, you are reproducing the identity of the coal mine as the coal mine. Now there's a couple of interesting things to maybe draw attention to here that are interesting for discussions of risk and vulnerability. A lot of, I think, what I tend to be focused on are external threats and things that are outside of us, even the things that are somehow tied to us because of our dependency. I'll think about things being very external and from my natural hazards background, I think that's definitely part of it, but Trist in a few different papers with a couple of different co-authors brings up some interesting, interesting points about work cycles and how they can or cannot produce vulnerabilities. And again, this was down in coal mines sort of around the age before and then after the age of mechanization. And I think it's important to talk about how before mechanization coal mining consisted of very small teams who were multi-skilled, they had boundary tasks, meaning they could work across functions and the sort of the complete work cycle was their responsibility and they were in the entire team was responsible for that work cycle through what is what they call responsible autonomy. Now, after the age of mechanization, what happened was is you had what's called long wall teams and they were working instead of small groups. They're working to like 40 to 50 person groups and these groups were highly fragmented. The work design was highly fragmented and they were working over very large areas instead of in small groups really near each other. So one of the things that they found was by sort of fragmenting the work and breaking up these like multi-skilled teams was that they had created very interdependent tasks and that was where that work cycle was becoming vulnerable because if everyone needed to be at 100% performance all the time and because people were dissatisfied with the way of the conditions in the mine, rightly so, there was high absenteeism and people weren't getting along. So you had this situation where people who shouldn't have been in the mine were having to come down and provide reinforcements. So you get this vulnerability in the top half of the work in the work cycles processes that is not producing the outcomes you need to perpetuate work cycles. And I think this is interesting because you have vulnerability in this local area, yes, but it also scales to a vulnerability in the ability of the organization to reproduce its identity. So it scales in that way. So keeping in mind self-distinction and self-production, Dipalo wants to talk about flows and he first says that autopoiesis, which is closely related to operational closure, doesn't adequately account for exchanges of matter sort of across the boundary of the cell or whatever the autopoietic unit has to be, it's generally a cell. So they think that they haven't appropriately accounted for this primordial tension that is involved in self-individuation and they provide two sort of extremes. And the first one is total openness. And I say that as state of total openness, there is no self-distinction. So there is no delimited unity. Every environmental flow, everything in the environment contributes to your identity. They say it continues to contributes to self-production. I have a bit of an issue with that. I think that if you are accepting every environmental flow into your system, you are sustaining the system in some way, but you're not producing an identity because you haven't really selected anything. You're not holding on to anything. Falsilias, in a paper on a certain slowness, would write that you are being as, there's no difference between you and your environment because you're moving too fast. So in this extreme, you don't really get into an identity. And the bottom one, where you're totally delimited, you have a very strong sense of identity. You're protecting that. There is a impenetrable boundary around your organization, around the organization. Totally robust. Nothing can come in. No environmental flows. But at the same time, you can't reproduce your identity because you're not letting anything in. So these are the two extremes he says we need to overcome. And the way that he does that is through talking about agency, which is a really interesting way to go with this, he's saying that as agents, through regulating our agency, and it's the collective agency of the organization, or maybe some people in the organization, you are accepting flows that contribute to self production, and you are rejecting flows that would harm your ability to be self distinct, to be delimited from your boundary. So we come back here to this idea of the emergence of identity and environment kind of alongside one another. So as this agent, they are selecting an inflows that will reproduce their identity. And what inflows they select is also based upon their identity. But once that decision has been made, there is a further degree of precarity that is sort of instituted there, because you at some point might need to change these flows. You might need to switch to another flow. I'm going to get into that a little bit later with the hazard analysis section. I think it's just that's where your adaptive capacity sort of comes from. I think one of the areas is your ability to select different flows and still produce the same identity. So it's this idea of moving around in a basin of attraction and being multi-stable. In the earlier example, the giraffe is multi-stable in the sense that it can eat anything, essentially any plant matter, and it does pretty well. It has specific routines in flood and drought. It's multi-stable, but it's not multi-identity in that you can't make a giraffe a carnivore. So we have, we sort of confronting this issue now of how much can you sort of move? How much can you sort of change the flows and transform those flows into outputs before you need to fundamentally change who you are? There's a threshold there. OK, so when we talk about coherence, I think that what we are referring to is the coherence of ongoing processes of identity reproduction. So the work within the organization to what degree is that producing that identity? So if in cases where we are completely incoherent, I would say that we are not producing any kind of identity whatsoever, whereas we can maybe picture it as some kind of graded boundary where we're somewhere along this gradient. And when we're completely coherent, we are driving towards that identity and somewhere in the middle, we stop being able to reproduce that identity. Coherence is at risk much in the same way identity is and that it is something that can be lost. We have an identity we have established and we want to hang on to that identity. And it is precisely for that reason that identity as first at risk and everything else, every other degree of precarity is fundamentally second to that. It is this thing that we don't want to lose and that places it at risk just by itself. And coherence is all at risk because we're trying to manage and lead organizations and maybe transform them in a coherent way. We don't want to lose coherence. And if we do, we sort of lose that capacity to reproduce that identity. I was there's a story that comes to mind. I'll just briefly share with you. I was hiking into a fire in California some years ago. And when you do this and you're always in a highly structured line, every wildfire is a highly ordered system. And we were hiking in along this road and we were hiking along some power poles and they'd are fired already come through there. And I was walking along and every all of a sudden, everyone realized that the utility lines were coming down on top of us, which is never a good thing. And everybody from we went from this moment of total coherence, totally driving the identity to completely incoherent, not producing any identity. And that's what I think about when I think about coherence and the production of identity. That moment had the complexity of that moment had outstripped our adaptive capacity and by consequence, the co are coherence, the coherence of our ability to reproduce our identity. So I want to start here by putting some of these concepts together. I think we've got an understanding of identity as this ongoing kind of this process of self individuation where it is delimited and there's operational closure. There is a network that is continuing to reproduce that identity. And then underneath that, we have identity reproduction. We have these this operationally closed network that can be described as coherent or incoherent to some degree. I've chosen to draw identity like this because I think that identity can be thick or thin, long or or maybe even or wide. I think we can have a very large and very detailed ideas of who it is that we are very large understandings of who we are as an organization. And I think the larger these get, the more they sort of preclude change to a certain degree or the harder they are to change to a certain degree. So if it gets really big, and I think part of that bigness is there are specific versions of the past and detailed stories about the future. They all sort of make it kind of hard to move in any direction. I think you become very focused on robustness and not focused on multi stability and certainly not focused on transformation. So what we place at risk is all of this, this idea of who we are that we continually reproduce with some degree of coherence exacerbated by the fact that there are flows we can and cannot use to produce our identity. I like Sillier's paper is really is really great here. He's saying that you have to invest some sort of resources in the reproduction of this identity.  And I think that that's exactly right. The larger your identity is, I tend to think or have a thicker that it is. I think you're going to tend to invest more resources and reproducing that than you would if it was, let's say smaller to some degree and you were maybe a little bit more sort of ready for or open to change within this idea, this understanding of who you are. So they're at the bottom. There is this inflow that is coming in to the operationally closed network. There's also an outflow. Now in DiPallo's work, he refers to the inflow as an enabling condition. So something is entering into these reproducing processes that perpetuates them. But in our case, when we're talking about a socio technical system, there's also something that's coming out that is part of that identity reproduction. And I want to draw attention to that now. This is a bit of an expansion on DiPallo's work in the sense that we're looking at that output in a very material way. But I think it I think it applies. So if you are, let's say, a bridge company, you need an input of materials to make that bridge. So that's the inflow. Of course, you need other things, but at the bare minimum, you need something to make a bridge. You take these materials and transform them into the output of the bridge's construction. Then you need to sustain the use of the bridge, which I think is where the part of the difficulty lies. Once we have built that bridge, our identity is embedded in that bridge to a certain degree. One of the ways to think about this is at least our reputation as being a bridge company that is helping to reproduce us as this kind of company is embedded in that bridge. So there's a certain degree vulnerability out there that if we were to lose that bridge, our capacity to reproduce our identity as a bridge company would in some way be threatened. But I think the picture actually gets much wider than that, because once we have put the bridge out into the world, we also need to sustain what the bridge makes possible. And this could be really, I think any technology, I like the concept of the bridge, because it connects to Anne Marie Willis's paper on ontological design, but the bridge, let's say, connects to socio technical communities, so to social technical systems that are communities and makes possible commerce that wasn't possible before, let's say. So that also needs to be sustained. That is part of what you are sustaining through maintaining the bridge. I think there is also a certain amount of risk that is generated that needs to be faced by the bridge company. By putting up a bridge, a certain amount has been introduced, I think folk in a paper called Resilience Thinking does the best version of this where he comments on how resilient international European travel had become, and then goes on to say that yes, super resilient, but when the Icelandic volcano sort of took place in, I think, 2008 and made air travel impossible, that showed how a focus of resilience over here had actually made a pretty big gap over here. So by way of putting a bridge out into the world that connects to people and making the choice that is going to be our outflow and not something else, a little bit of risk has also been generated. I think that we also, from a natural hazard standard, that bridge becomes vulnerable to a lot of different malice and floods and mass land movements. It's all tied up in this, but it's this output that we need to continue not only being used but maintained. I know bridge companies don't generally maintain bridges, but for the sake of the metaphor, we need to keep this technology in use to continue reproducing our identity. So I want to come back up now. I think after being in a little bit of a, being in an abstract space and simplify this a little bit more using the work of Maturana. So Maturana talks about systems as having structure and organization. And I think the easiest way to talk about this is through his example of using a table. So a table can be made of plastic or steel or wood. It can have a glass table that can be a top that can be glass. It can be oval. It can be really any, any number of configurations, but that is its structure, its organization. What's it also also refers to as its class identity is its hableness. So its organization is its identity. It's how you know it's a table. So for us, for our purpose this year, the structure of the system is what reproduces the system as the kind of system that it is and its organization is that system's identity. So one of the things that he's getting at here is he's saying, OK, so systems have organization, that's their identity, and they have structure that realizes that identity. He's saying they're also structurally determined in a world where there's no structural determinism, we would have a King Midas situation where you could put your hand on something and turn that thing into gold. That's what he refers to as instructive interaction. But he's saying that's not the case. He's saying that whatever happens in a system is because of the structure of that system. So all you can do is provide a perturbation that can trigger a change, but you don't actually cause that change by what you did to the system. For Job Capra gives an example. He's like, you could, you can kick a dog, but whatever that dog is going to do is based upon its structure, its history, and how it exists at that moment. So we get systems that are acting based on their own internal dynamics. So this is fundamental to the next slide, which is my own version of this. I think Maturana, Maturana writes that you can classify any system by using these four domains of structural determinism. And in the first one he writes that you have interactions that can trigger changes of state, which is just a mildly changing the system, whereas then you can have a domain of changes of state where you have changes in structure without loss of class identity. The example that Maturana gives is he gave his son a saw and a little toolkit and his son cut off the end of his table and that table was still recognizable as a table, even though it had lost some of his structure. He goes on to say that in the domain of possible disintegrations, you can have structural changes with loss of class identity. He then gives the example that his son went on to actually cut the table in half and it lost its table-ness. So it was no longer identifiable as a table, but it was identifiable as something else. Then you have the domain of possible destructive interactions, so interactions that can disintegrate the system. What Maturana is trying to get at here is how things can change and still remain the same. I think he's getting at, he doesn't write about this specifically, I think he's also getting at how systems can change qualitatively, which I'm going to carry on in my own version of this. I was talking about this with Jave a couple of weeks ago and had a lot of fun going over the ways that we can kind of bring in Maturana's idea of organization, structure and structural determinism and sort of tangle them up with robustness, adaptive capacity and lay into that these ideas of identity and reproduction. So I think that the first thing you get that was Maturana's domain of perturbations are possible interactions that trigger no changes or changes in daily in operations. So I think there's subtle changes. They don't really require too much. It's a variation in input that doesn't change anything in output. We can think back to DePaul's sort of ideal self distinct state where there is a strong enough boundary and we have to have provide the condition that some flows are getting in, but other external flows that we don't want aren't able to affect what it is that we're doing. So then I think you get into the domain of resilience where we think about all the interactions that can trigger, not produce but trigger changes in how we produce our identity while our identity maintains. Nothing has changed in our identity. And I think you get kind of a few different versions of this. I think the first one is that if you are a bridge company and that is your identity and you are making bridges out of stone and that's your thing and stone is no longer in vogue. Let's just say you have the possibility to change your inflows from stone to iron. Part of that equation is that you need to also change how you transform inflows into outflows and to borrow from the socio-technical systems literature. We start talking about multi-skilling in there, of training people or having people who are able to work with more than one material and still transfer transform that into an output that sustains your identity as a bridge company. So flows can change in sort of any number of degrees and still produce the same identity.  That precludes this sort of possibility of being able to change flows and make something different. I think what that sets you up for is I think all these domains in a certain degree to do this, but especially this one, can fall into the domain of dissolution where there is a disintegration in our identity as well as how it is produced. So we have this capacity for multi-skilling, multi-stability in the domain of resilience where we're sort of moving around in a basin of attraction. We're changing flows, but we're keeping that identity constant. I think that's the idea of resilience. I think in the earliest paper that I've seen from Hollings in 73 is you get this idea of persistence. So identity persists, but the way that it is reproduced, change. So this brings us down to transforming giraffes into tigers. You have all possible interactions that can trigger changes in our identity as well as how we produce it. So we're not talking about really basins of attraction at first. We're talking about changing what they are so that we can move into a new one and change our identity and its reproduction. Boke writes about that this can be deliberate. We can change from being a bridge company to possibly being an airplane company. We can change who it is that we are. I think the Forest Service is going through or is presented with a domain of transformation right now or are approaching it and that they have to move from a seasonal workforce to a full-time workforce that will definitely change the culture of that organization and that could be something that could be deliberate on their part. It is also written about that these things can be forced. There are changes in what Gundersen and Holling would call the panarchy that surrounds you. There could be changes in that and any number of those layers that force you to transform who you are and how you produce that identity and I think in that case you end up in this domain of dissolution before moving back into the domain of transformation. There is something that you go through and then move back into that. But there is this period where you maybe don't know who you are and how you are producing that. One of the examples that comes to mind from my background is Hurricane Katrina where the federal policy, emergency management policy landscape had just changed drastically and I don't think people really knew how things were supposed to go and identity was unclear. So Matrona writes that if you go fall into the domain of dissolution, a new system of a new class appears. So you don't have whatever you went in there with, you're not going to have after you leave. So I think this is maybe a place where if you fall into it from another domain and I was definitely influenced by Kenevan when thinking about this, you could move, you enter there and a new system might emerge and bring you back into one of the other domains. So when putting this together, my goal was to create something that would help me and maybe others to think about what hazards are we vulnerable to as it relates on this very, I would say an almost core scale of our identity and who we are. I think that's a big part of what we're looking at, these sort of grand large scale questions. What is out there that could stop us from being ourselves? What are the opportunities to change how we reproduce ourselves? How can we change from the kind of animal that we are and what lies out there that could cause us to really be in a lot of trouble? And I think the follow up question to that is what is beyond our transformative and adaptive capacity? So although the concepts are different, I think this definitely stays consistent with Maturana's original purpose of figuring out how much change is possible before we no longer remain the same. And what we're looking at I think is more in terms of hazards than maybe in terms of what Harvard is writing about with risk management. But I think it's definitely a hazard analysis that it is asking how much can we withstand and what can we do about it in these course categories of what is our identity and how do we reproduce it? Thank you. This this was awesome. And if we can get there you go here you're back there. This was just awesome and it makes you think about organizations on so many, so many levels. And I can't tell you how much thing how many things good things you've triggered in my head. And there are a lot of questions and comments too. So if folks have questions, ask them in the chat. If you want to turn your video on go for that. Jay, why don't you take it away to start with because I bet you can lead this discussion quite nicely. Sure. Great. Thanks so much. I loved the presentation. One of the things I was I was thinking while I was watching it like you and I share some vocabulary that maybe not everybody else does. When I think about like identity and the reproduction of identity, one of the ways I might map it into the community that we're talking to right now is kind of like operations, like literally kind of the reproduction of the operating conditions of a company or of a system. There's some interesting things when you look at your last slide about thinking about kind of the way in which a system coheres, both kind of at a physical, mechanical level, but also the way in which that mechanical coherence is kind of reproduced by social coherences, right? Like by multiple mental models and the ability to kind of share just enough information to kind of keep a conversation going, keep the social network together and stuff like that. I don't know. When you think about like, you know, some of the conversations we've had in the past about kind of the differences between, you know, your firefighting experiences and kind of software engineering, what type of stuff do you think is important for people to kind of think through there? I think we deal with a lot of the same ideas, a lot of the same dynamic aspects of our work environment. I think sometimes I'm a little bit not having the software experience. I'm a little bit outside of that. I think what we are all trying to do is create and manage coherent holes. And that is one of the things that we are trying to reproduce. I think that from what I understand reading reading about agile and different sort of management methodologies, you're trying to do that differently than we are. We're trying to do that, I think primarily in a way that is World War One centered. And I think that other people have are post that in the way that they are reproducing coherence within their organization. I have sort of I have on that slide and I thought different of it before presenting this morning, but I the how coherence is reproduced socially. And I think we do that in very different ways. Yeah, I think part of our I think part of our art, it's not it's not coercive coercive at all. It's just very forcefully reproduced. And I think that I ideally comes from a different kind of understanding of safety. Yeah. Yeah, I think one of the things I was thinking about like when I talked to you about this stuff before in the past is like, so your story like firefighting is kind of like in incident storytelling, right? Like it's about what's happening in an incident where when I look at like a lot of people who are working like in resilience engineering or agility or you know, some of these other, it's much more focused on kind of postmortem reflective practice after events, trying to figure out how to improve going into the next event. If that makes any sense. And it feels something like, you know, the sense of urgency around the kind of physical danger maybe is what brings the firefighting community back to the in incident version as opposed to the post incident version or maybe I'm wrong. I don't know. I think that you are so a particular typical day in the life of a firefighter is, you know, you're on a 16 hour shift and you're going to work 14 days in a row and then take two days off and then have another 14 day roll. That's the goal is to is to stay out for 14 days because that's the sweetest deal around. So I think that drawing the distinction of not being on an incident versus being on an incident is actually pretty hard. So what we're doing is there is a running narrative lasting the entire year, the entire six months, seven months, whatever it is, that it is continuing to build on itself. And we're doing a lot of what we call tailgate sessions, which are quick AARs sort of before we load up in the trucks and head back somewhere else. So there is a lot of I wouldn't call it learning, but there is a lot of constructing this running narrative of what we did and how it what went well and what didn't. And there's definitely people who are in charge of that narrative. And there are people who are not in charge of that narrative, just because there's, you know, positions and varying degrees of social capital. So I think that I agree with you that it is in incident that we're thinking about this all the time. And a lot of the shaping in a lot of the learning is taking place while you're out fighting fire. Yeah, interesting. I mean, I think like, you know, just to again, reflect a little bit on on what you're saying and try to like your tailgate sessions remind me of like in kind of agile and slow thinking, there's these two different ways of thinking about like how to do an after action review or incident review or however you want to describe those things. And one of them is that you set up time boundaries of time boxes. So every two weeks, you stop the development of the software, you deploy it and then you reflect on what went good or bad, right? And that's every two weeks you do that. It's called the retrospective. But in flow based thinking, one of the things that we differentiate is that you should that kind of information rots. So if there's an incident, you should actually do the do the reflection as close to the incident as possible. And so it's not a time thing. It's actually an event based thing that happens. And that that feels more like what's happening inside of like the resilience engineering community and stuff like that. I think it's something interesting there. I'm also thinking like, you know, so much of like clients early work is so, you know, based in kind of analysis of firefighting. So I think it's interesting to have someone who's actually done the firefighting, trying to think through some of this stuff. And, you know, applying it to actual practice, I think it's kind of an interesting thing. When I agree, I'm sorry, I cut somebody off. I'm just going to ask Gregory if I can ask a question of you. Real quick, I wanted to know how perhaps you had a way to move that incident management into like a life cycle. So it's more part of the cyber and IT risk register so that it doesn't become a one off thing. You're constantly chasing and you're going after incident incident. I mean, typical banquet, 22,000 employees in 13, 14 countries will have what, a thousand incidents a day. You know, how do you move that into a regular life cycle, a risk life cycle? Okay, so are you talking here? Are you talking about how to tie all these incidents together? Time together and make them more something that you can handle on a regular day to day basis. So your team isn't doing what you described earlier, constantly putting out fires and running around you know. So have you I'm interested about that and I'm interested to maybe what degree have you heard of the incident command system? Has that come your way at all? A little bit. Tell me more. Yeah, so the incident command system is a product of wildfire. It was made after some really bad what we thought at the time were bad wildfires in the 1970s. And it seems every time we think a fire was bad, the next year is worse. So there needed to be a way to organize things better. There was lack of communication, lack of coordination. It was pretty incoherent. So they developed over the course of the few years what's called the incident command system, which is effectively a command and control system where you have, you know, essentially one person in charge, the IC, and you have people who are operation section chief, logistics, finance, it would have to be it has to be adapted, right? And it is practiced as some sort of command and control model, fierce hierarchy. But I think that has a lot of potential to be more of a complex adaptive system just because it scales pretty well. So when I think about what you said, and this might be off board, what we have are people in called incident management teams who will staff the incident command structure. So you have instead of setting it up like an ad hoc incident every time, you have people whose tasks it is to fill out and manage the incident. And then on top of that, you can have area command, which is running multiple instances of the incident command system at what are called incident command posts. So it sounds like if you have a bunch of incidents that are going on always, having sort of the same people who are managing those incidents is probably the quickest way to learn. And also the quickest way as to have point contacts, and you can aggregate those off into area commands. And that sort of might bring some degree of coherence to what's happening. But it depends, you could actually have a multiple incident within an incident run by one instance of incident command system. Yeah, thank you. When you build your oris, you're right, you have so many instances, the result of it that it needs to be routine. Thank you, Gregory. Absolutely. Thanks. I would suggest you think about a little bit is kind of like in SRE, we talked about a concept called toil and there's all sorts of different definitions of toil. But my definition is really simple. Toil is doing the same thing over and over again, where the thing the incident isn't surprising. So it's like, oh, that happened again, right? Yep, that's the thing that happens all the time around here. Still an incident. One of the keys, Jay, Jay, Terry. Yep. Yeah, one of the things too is that where people look for the reports of the incidents is stays the same. So like if you think about Linux and Red Hat and we communicating out when there's a security breach and how to get that patch, how to apply that patch, the communication channel and having that repeatability is really very important for it to scale to something like what James is talking at a bank is like everybody knows to come to that. And somebody does have to tag Amy here because Amy had a good point and she was chicken to talk about it.  Well, I heard two things there, right? Like you mentioned like a deluge of incidents. And so as was suggested, some kind of coordination in the incidents will help you deal with those as they come up. But the other thing we really work hard on in SRE and I talk about a lot is that's that's one time scale, right? You can handle the incidents in the event and there's it's usually like in security in SRE it's very, very fast paced. You know, it's it's in the matter of hours or minutes usually. And so that coordination is super key to like bringing order to those but that but you also need and Greg talked about this earlier, right? Is we can't just have the incident as the feedback cycle. There are bigger, longer cycles that we need that help us control the whole socio technical system or regulated or government or whatever fancy words are popular right now. You know, and so in SRE, we talk about SLOs, right? In security, there are other controls that people tend to use, but ways of helping teams understand their out how their outputs are contributing to risks into incidents before that stuff hits production. And then you have both of these cycles, right? You have the incident review cycle that's feeding back into your engineering and product organizations and security needs this too. And then when you have these longer cycles like SLOs and security reviews and things like that, those also need to be back into your product and engineering organizations. And that's kind of that. I forget what the terms Greg was using earlier where but I think of it as part of the whole homeostasis, right? Like we have these different time scales of processes that that we have as people or as living organisms, and our organizations have those too. This is John. Really quickly there, James, is to think that people talk about feedback and they think of it almost always as information, but in ecological system, part of feedback is back pressure.  The way to implement that in a security system is to use something like error budgeting. So you can keep on putting out more and more features until you hit a certain amount of error and then you have to switch from feature production to security production, right? And that's the back pressure of a feedback loop as opposed to just saying, oh, the feedback loop is closed because we have the number of incidents that is now being reported to the development team. So back pressure is pretty negotiating. You know, Greg, John, sorry. Yeah, no, I posted a couple of things there now. The discussion, a couple of things. There's a great presentation by Erica Morrison at the Devo Center for Summit where they talked about one of their largest instance and they actually used the incident command center stuff from Forestry. So it's an amazing presentation of how they board a consulting company and particularly it's a really good analysis. It was like the worst outage they've ever had. Also on the dynamic nature of some of the things we do on ops, again, I think if you look at Dr. Woods, Ponegal and that stuff, they talk about sort of this sort of dynamic thrashing. Probably an easy thing to pick up. A beautiful overlap is either John Aspar's master's degree or and I think I posted that and then Jeff Susner has written a really good book about design delivery. But I think John does capture because you had mentioned at one point about maybe there's a difference between sort of how we do more post-mortem work and that is most of the oxygen in the discussion. But I think some of the work that John Aspar with Dr. Woods and Richard Cook are doing are more about the sort of the cognition that you do in a dynamic scenario of things that thrown at you change the dynamics. And I just want to say I was I'm going to have to watch your presentation a couple of times. But I thought it was fascinating. Honestly. Thank you for saying that. You know, as I'm sitting here thinking about what everything, everything everyone is saying, one of the disadvantages that the tech community has in this whole idea of incidents and learning is that we live together. The seasonal workforce, the people who are driving the train all all live together. So we're never not processing what has happened and not learning. Even though even though the fires are over, it's just something that's taking place all the time. And I don't I don't think you can discount that. That's one of the ways that the processing over is difficult. We're always together really. And even like I've been out of it for a while and we're still processing some of it. So it's it's an ongoing process. And I think that is an advantage in our favor. There is if you're interested. And this is maybe more of a stretch. There's also the cluster approach, which the humanitarian organizations use, which is much more of an innately complex adaptive systems way of managing responses. And one of the it goes by sections, food, shelter, agriculture. It's set up that way. And people that operations become part of that. And one of the things that's neat about it is that there's this notion of last protocol is if someone isn't providing the service, I think you got you might call it swarming. You need to then swarm over to that direction and help fill that cluster out. So there are some tested frameworks that might be interested to think through more about handling and managing incidents in in your areas. There's also. Jay, there's another application of this. We're talking about risk and that. But also when we're trying to create a corporate identity like red hats, culture and that the creating a cohesiveness for the entire how many 16,000 people there are to a lot of what you're talking about really applies to everything from corporate culture to creating a brand around an organization to how we as organizations are become resilience and do transformation. But how do we change to and create something that all of us all 16,000 people who are being succumbed into IBM? And that's another three hundred and sixty. I'm sure I got the numbers wrong. Three hundred and sixty thousand people. So how do we sustain that identity in a way that's healthy and still moves the organization forward? And I think that's something every organization, not just red hat that of that size struggles with. You know, my my brain while you're doing this may not have been worried so much about Linux security patches. It was more thinking about the bigger organizational issues that we have to create a coherent organization that lives in breeze and dynamically does it in a healthy, inclusive way. And that's thought you gave us so much food for thought. But I was just wondering how you think about it in a bigger picture way, like large organization stuff rather than a risk. So we're talking about reproducing an inclusive safe, healthy identity. Is that sort of where this is going? So I think Gabe has two terms that he uses that I seem to not be able to recall here. I think we have to be able to settle first on what makes an identity and decide to which degree can we allow that to be conflicting? So I think I think function is the easiest way to think about identity, especially when you're thinking about its reproduction is IT companies need to be able to reproduce themselves as IT companies. I sort of think about that as like the central pillar and it's the easiest thing to talk about. And I think that's where I focused a lot of my time today. And I did acknowledge but didn't really get into all the stuff that sticks to that. And I think that's where the of where you're talking about is where the trouble lies is getting like a cohesive, coherent, positive identity because you get and is the term fragmentation? Is that what or is it delamination? I use two different ideas. One is called delamination, which is the high level identity of the organization. You could say like the strategy of the organization and the tactical layer of the organization come apart. So like the people at the top and the people with the bottom don't know what they're doing anymore. That's delaminating. And then and coherence is part of that, right? Like the link between strategy and tactics when they're linked, you're coherent and you're not delaminating. And the other version of this is disintegrating, which is when teams don't know what they're doing more at a peer level. But like one of the things I'd say in response to Diane based on our conversations is your four over four right starts talking about this stuff. If you start thinking about it as not as four different ways in which the organization could be, but four different the interactions between these different ways of being the dynamics between them as being what enables change. Right. So like the critical ones for me and that four or four are things like the relationship between the way that Greg has defined resilience and the way Greg's defined resilience is the ability to kind of reproduce a certain identity. And then in the lower left hand corner, he talks more about transformation. And so there's actually a way in which you have to think about there's a minimum amount of resilience required to go through transformation. Otherwise you get chaos, you get these delaminations, these disintegrations, right? So focusing on resilience, being able to reproduce stuff and then going into a transformation where your identity is changing, but it is not changing at such a rapid pace that you disintegrate, that you that you can't stay together. And in socio technical systems theory, this is called the difference between, you know, the fourth level theory of environments, which are complex systems theories and what are called vortical environments, where the organization tries to ingest so much complexity that it just spins apart, it breaks apart. So the resilience part of it is really important. And that Sillier's paper where he talks about the idea, you know, like in software engineering in particular, we have a habit of talking about options, we always want more options, make more options. And this is a big thing in cybernetics too, right? It's called the ethical imperative, always act to increase the number of options, right? But Sillier in particular wants to point out that if you have infinite options, you have no identity, you have no commitments. And in fact, to have an identity, to have a ongoing nature is to have certain commitments. And so the question ends up being like, which commitments do you need to be resiliently engaged in order to kind of go through a transformation? And I think that's the large scale question of kind of organizational change in relationship to kind of Greg's explanation. I ran it. Sorry. That's good. That's good. All right. Well, we are sort of at the end of our hour. Actually, we're 10 minutes over the end of our hour. And I know we can have you back again and have another conversation and get James and Amy and Ben and everybody else who's been chiming in and Barbara on the side here in the chat and John back to have another conversation about this. I think this is one of the most thought provoking and interesting talks. And it really gave me a lens through which to look at this and think about it much more deeply for tech and for other aspects of the universe that we all live in. So thank you, Gregory, for coming today. And yeah, Barbara is asking the question that I was just going to ask. You quoted so many things. And this is becoming the thing on Fridays is how do we get a bibliography of every one of those references? So I think that'd be good. I'm going to capture what's in the chat here now, but and attend that. But yeah, we'll get Greg's slides and make this happen. So thank you again. Yeah, I have a references slide so I can send this off to you and you can share it with everybody else. And if you want to just pop the reference slide up right now on the screen. You can show that and then we'll end on that. And and Jabe, we have to have him back. Absolutely. I love talking with Greg. He's one of my favorites. We're going through the giraffe and tiger stuff. And when you framed it in resilience, all I could think of was how the National Park Service brought up their Twitter handle during the Trump era so that they could get out.  And I'm sorry to bring up politics in the middle of this.  And then hopefully they can come back and re bloom. Well, thank you so much for having me to this was a lot of fun to put together a talk. Don't get to do it enough. Yeah, well, and James, if you have a talk up your sleeve and want to go in there, just I've dropped my email and the address here. See, now you're talking. I just do my fourth cyberwire interview. So maybe I could go I could do your your forum. I don't know. James laughing because he knows I like that stuff. Well, no, we've got a whole whack of Fridays in January to fill. So I'm totally thrilled to have more of these conversations. And this is exactly what I want to happen on.


Hi everyone, Joe for jazzy's casewrakes.com with a quick random number block randomizer for these three teams right here that unlocks Picker Team 18 which will be in a separate video. Here are the instructions on how these number blocks work in case you're not familiar with it but I think this group is familiar with it, thank you. There are the numbers right here, let's roll it in randomize names and numbers. Snake eyes, two times, one, the left eye and the right eye, easy, Clint, down to Clint. And then Snake eyes, two times for the numbers, one and two, remember zero, as you saw in the description it gets any and all redemptions including one of one redemptions, a rare occurrence but something we like to remind people about in case that sneaks up on us. Alright, Clint with eight, Diana with four, Griffin with three, Gale with one, Adam with seven, Steven with five, Adam with nine, Diana with zero, so you'll get any and all redemptions for those three teams down there including known one of one redemptions, Griffin with two and Clint with six, let's order these numerically and coming up in a separate video will be that spectra break, we'll see you for that, jaskiescasebreaks.com.