00:00:12

One of the most impactful learning moments for me was taking a workshop at MIT in 2014. So I went to this class because it was taught by Dr. Steven spear, who I mentioned earlier today in my opening remarks, since then he has become a mentor to me and I cannot overstate the extent to which he has influenced my thinking. So Dr. Spear is famous for many things, but he's probably most famous for writing the most widely downloaded Harvard business review paper of all time in 1999 called decoding the DNA of the Toyota Toyota production system. And this was based in part on his doctoral dissertation that he did at the Harvard business school. And in support of that work, uh, he worked on the manufacturing plant for, but tier one, tell you the supplier for six months. So since then he's extended his work beyond just high repetition manufacturer, work to engine design at Pratt and Whitney to the building and operating of the safety culture at Alcoa and how we can make truly safe healthcare systems.

00:01:06

More recently, he worked with Admiral John Richardson in supporting a us Navy initiative to create a high velocity learning dynamic across all aspects of that enterprise. And so for nearly a year and a half, uh, we've been talking nearly two to three times a week trying to see if we can codify what we've observed in our careers or on how to create these amazing dynamics that truly unleash human creativity and problem solving potential across so many domains with the goal of putting this into a book that we're working on to be released in 2023. So, uh, this time, uh, we will be presenting on how structure may be the best leading indicator of performance. Steve I'm so delighted that you were willing to help teach us to us, uh, today.

00:01:48

Uh, Jean, thank you so much. I consider one of the great fortunes in my life that we met those some years ago and that I've had opportunity to, uh, be part of the conversation of this community that you've helped, uh, nurture and foster for so long.

00:02:01

Thank you so much, Steve. So before you start, let me set the stage for talking about how structure may be one of the best leading indicators of performance. So we believe that there are structures required to enable the dynamics necessary to unleash the distributed and collective human creativity and potential to compete and win in age where we will does being tumultuous, disrupted by scientific and technological innovation market transformations and political and societal realignments. Uh, we believe that there are over the last 150 years, we've seen how some organizations have been able to generate and deliver ideas, uh, more quickly, uh, better ideas, faster and more reliably. And so the question is how do these amazing organizations, uh, unleash this magical dynamic that are, uh, able to help everyone better compete and win? Uh, and so again, the thesis is that structure might be the best leading indicator of performance.

00:02:52

And so if we look over the last 150 years, we see it does not just dev ops and agile is not just the Toyota production system, but, uh, we can see contrast of how amazing organizations have been able to do great things. For example, send a man safely to the moon and back as well as, uh, um, as well as be able to create COVID vaccines approved for emergency use as well as, uh, vaccinate them to a population who need them so badly. Uh, in previous presentations, we described how many organizations are trapped in a slower integrated problem solving style, where everyone's trapped in the functional silos, unable to do integrated problem solving, uh, with their peers. In other words, for anyone to do integrated problem solving, I'd have to escalate up eight levels and then down eight levels, uh, in contrast in high performers, uh, the majority of communications are not happening up and down the organization instead they're happening at, across the edges where the majority of communications are happening, uh, within teams or across teams across sanctioned interfaces.

00:03:51

And, uh, by doing that, uh, workflows more quickly and more knowledge is being created. And so as a leader, one of the top responsibilities is not only to set system level goals, but to design the organization, assign those roles and responsibilities and the relationships between them, and then also assess for performance. And in our thinking, we almost, uh, we can even simplify it further as saying, there are the job as a leader is to configure the system and then run it and also assess his performance. So Steve is going to talk about what are those properties required to enable a great performance and he's to answer questions like why isn't a hierarchy enough, why isn't culture enough and what are specifically are the characteristics of how a structure can enable great dynamics. So with that over

00:04:38

Steve Jean, I appreciate that very kind introduction that you gave me and even more so I appreciate the time we've spent together over the last many, many months, discussing how we can manage very, very complex enterprises to, uh, tap well into the innate potential of the people in that enterprise to deliver great value to society. And I think one of the things that's been most impactful for me is the realization that we mis-characterized w why we form organizations in the first place, you know, and there are a lot of reasons, you know, there's the legal reason of creating LLCs LTDs Incs, et cetera. Um, I think perhaps more distracting and misleading is the thought that the reason we're creating organizations is to get economies of scale around physical things, uh, machines, material, and that sort of thing, but really what's been most impactful. And focusing for me in our discussions is the realization that the reason we form organizations in the first place is to collectively and collaboratively solve problems, problems, which are much bigger, much harder than we can ever solve and hope to solve as individuals.

00:05:45

So when we started thinking about this issue of creating organizations for the explicit purpose of collaborative problem solving, then we start thinking about the ways in which we organize as conducive or corrosive towards meaningful conversation. And so what I'd like to share with our colleagues and friends here is the idea that four things we can do. So first is simplify the flow of ideas through an organization to make them less confusing. Our second is create standards and third is to create stabilization mechanisms and finally is create synchronization amongst those doing the collaborative work, the creative work together. So many. Let me just sort of quick a cartoonish explanation of what I mean by these terms of a simplification standardization, stabilization and synchronization. So first, why bother simplify? You know, when we think about creating the flow of ideas of the flow of work more generally through an organization too often, we think about, um, minimizing the wait time for the thing, and that kind of leads us in the direction, um, when we're using those, um, industrial metaphors about inanimate unthinking, unresponsive objects to just put things in cues and have things go, uh, queue up and go to the first available.

00:07:07

So it's kind of like when you're, um, checking in, in an airport and would go to the first available, uh, ticket agent, you know, and then your next to the next next, and why is that? The idea is to move things through the system as quickly as possible. But when we start realizing that at each of these steps in a process moving left to right across the screen, that at each step, we have a person and that person, if they're connected to everything, every possible station or source of input before them, and they're connected to every station or source of output or destination of output after them, you have this real problem of just so many relationships having to be considered so many relationships having to be managed, um, all at once that the person who's sitting in the center of this very complex, highly intertwined network of relationships, they can be spending so much time and just be so distracted on terms of on whom do I depend, who is dependent on me.

00:08:05

So, anyway, what is step one in sort of liberating people's brain space to do something useful is, um, simplify the flow of work so that I have fewer upstream dependencies and downstream. There are fewer, um, people and individuals dependent on me so that the architecture is simple. The architecture is less confusing. We're spending less time, time, and energy and effort and creativity thinking about the architecture of the system in which we're embedded. I frame this from the perspective of the person who is in the system and having always to look upstream downstream for all these flows, things in and flow things out. But imagine the person who's responsible for the system as a whole running a program, trying to manage the contribution of many, many people on the enter in the enterprise. Well, when they're looking down on a system and they've got all this interconnect that hyper, um, convoluted, intertwined circuitry over which ideas get created and flowed, how do you even possibly manage that sort of thing?

00:09:08

However, when we give that person an opportunity to look down on a system, which has much cleaner circuitry, much key, cleaner flows, um, much cleaner relationships, they can be more prospective in terms of designing the system, supporting the system. So regardless of whether you're looking from the inside out or looking from the, uh, the top-down simple as much more easy conceptually to liberate brain space for doing useful work anyway. So that's 0.1 0.2. Why half standards? Well, here's the thing. Just imagine trying to do anything without a recipe, try to play any piece of music without a score, or, you know, imagine, um, a ballet troupe trying to dance without choreography. You just predict the mess, right. And the other thing about the absence standards, you think about what a standard is, a standard is the capture of our best known approach, our collective best known approach.

00:10:04

So why would you ever give someone a situation where you asked them to do something absent the void, not informed by, without the benefit of our already captured best known approach? So why have a standard? Cause it takes the wisdom of the ages as it were and puts it in the hands of the person. Who's doing something perhaps for them for the first time. But there's another thing about having a standard. If you have a standard, you can see an aberration. And that becomes really critical because anytime we're doing, um, complex work through a complex system where the pieces are moving, so we've got complexity and, uh, we've got, uh, dynamic behavior. Things are going to glitch. That's just the nature of complex systems, biological systems, glitch, um, technological systems glitch, and certainly social systems they glitch too. So the reason when the reason that those complex and dynamic systems behave well is not because they're glitch free is because they can respond quickly.

00:11:05

When glitches are seen, when problems are seen, those problems can be swarmed and solved in the presence of standards. It's much easier to see problems so they can be swarmed, contained and solved in the absence of standards. It's hard to even have an agreement as to whether we have a problem or not. So anyway, in terms of liberating, their brain space literally liberating their creative potential towards good purposeful use. Um, simplification helps. So they're spending less time thinking about the architecture of the whole system. Standardization helps because then they're equipped with the wisdom of their predecessors. And it's much quicker, easier to see a problem when an end where it occurs, so it can be contained. And that's actually a natural setup for our third normative, uh, design principle, which is when we have these complex systems of collaboration and collaboration to be creative in the generation of something new and useful.

00:12:00

Not only do we want to have, uh, the simplification and the standardization, but that when we see a problem, we want to have stabilization mechanisms in place. Now, why is that? Imagine you're sitting in that system and a problem occurs and you have no recourse. What happens? Well, one, you add a locality or suffering this disruption, um, for longer and with an amplitude greater than you might otherwise have. And there's something else. The problem you're having may escape and start impacting downstream and downstream and downstream from there. Maybe it escapes just because you can't deliver. Maybe it escapes because what you're delivering is less and less adequate, but whatever it is in escapes. And so the local aberration, now it becomes a systemic aberration and may eventually to assist them collapse. So however, we have stabilization mechanisms, which when a problem occurs, it's seen remember the benefit of having standards.

00:12:58

And when it's seen it draws attention where someone can come over and say, Hey, what's the problem? How can I be helpful? What we do is we decrease the duration of the problem. So it's less aggravating locally, and we reduce the chance that the problem escapes to be disruptive systemically, right? So now we've got three tactics to increase the chance that people can collaboratively and creatively create value together. All right. So, um, we've got our simplification, we've got our standardization stabilization, and one more piece synchronization. Now you think about how often we find situations, whether it's in the industrial setting with parts, moving through machines, machines managed by people or ideas, working their way through programs or projects, uh, maybe never anything tangible, other than code and ideas and drawings and diagrams and designs, but that always who does what, when, on behalf of whom, um, in what form and what format, all of that stuff has to go up to some central authority, a control, production control, whatever it is, a project manager.

00:14:06

And that that person now has to think about the next steps in terms of where everything is at, right in this moment, who does what next for who, when, how dah, dah, dah. And he said, and he started thinking about the problem here. You have the base plate of activity, whether you call it shop floor, deck plate, or studio level or bedside or bench or whatever it is, you've got this base plate of activity, which has its own natural frequency. It has its own natural speed. It has its own natural level of detail, all of which are fat, fast and fine grain. And you have the central authority. Who's trying to draw inputs to understand the situation and is getting overwhelmed by the frequency, the speed, the granularity, the level of detail. And you have all this signal coming up to the top, coming up to the control level and why I like this because there's so much signal that's for them, nothing but noise.

00:14:57

And so what ends up happening their conceptual space, right? And their conceptual space is really kind of a slow thinking, deliberative, uh, assessment kind of thinking. And they're trying to apply that onto something, which is a very, very fast moving. So what do you see? They get overloaded. And so you have the consequence either the system itself has to slow down for the central control to process, or if the base plate system won't slow down, our canceled downers told not to slow down, but you end up as getting these pockets of chaos, which builds more chaos and more chaos and more chaos. And then you may get system failure. Um, so what's the alternative to that. The alternative to that is having the base plate elements, the individual designers, the individual programs, the individual workers, the individual creative elements have ways to synchronize the work based on the immediate dependencies they have with someone upstream and the immediate dependencies that have someone downstream.

00:15:54

And what does that mean? Now we're preserving that bandwidth. We're preserving that bandwidth, that cognitive space to look down and not look down and try to handle a signal in and process that insight generate a signal down and another signal up in process and another signal down it's like, they can now observe. They can monitor. They can assess they can support. They can improve. They can design, they can redesign. They can stay in this slow thinking. Creative deliberative assessment type of thinking while the base plate layer is self synchronizing at its own natural frequencies, its own natural speeds, its own natural granularity and level of detail. Anyway, Jean, um, what's coming out of our discussions over the last many, many months is that we organize for a very important purpose, which is to harness the intellectual horsepower of the enterprise towards common purpose. And because of that, we should think in terms of an objective function of how we design, how we operate, how we manage that an objective function should be to liberate all that intellectual horsepower towards actually creating things of value and not being consumed, consumed by understanding the collaborative systems into which we insert people.

00:17:17

And in order to do that in order to have that objective function switched towards attention on the thing we're trying to create a way from the system itself, simplifying the system, standardizing the system, stabilizing the system and synchronizing the system. Those four tactics are huge towards achieving that objective function.

00:17:38

Just to reiterate, you're talking about simplification to extent are the value streams, linear and explicit, which allows for partitioning nesting standardization, that everyone has. Everything has a strong declaration of how things should be working. Um, and what happens when those conditions fail stabilization is that, uh, there is some mechanism so that local effects can stay local, uh, when things go wrong, I suppose it causing global disruption and synchronization, uh, coordination can be done locally that doesn't involve the need for a centralized mothership. Uh, that knows all did I get that about right? Absolutely.

00:18:11

Absolutely.

00:18:12

So I thought it would be fun for us to, uh, use that lens to take a look at some of these, uh, better and worst organizations. So, uh, to be specific, to be high performing the assertion is that we need all four characteristics to be present and, uh, for an organization to be low, we're performing, uh, we need only to be missing one of them. So the first one that I love is the operations of the famous Netflix, um, and chaos monkey during the first AWS outage. Um, that's, Phil's famously took down so many cloud services and we were all amazed at when AWS east went down, almost everyone down except for Netflix. And it was due to, um, uh, what they described as a Rambo architecture. So they, uh, they wind on the simple characteristics because they specifically talked about how they design systems so that they are partitioned and modularized and that services should stay running.

00:19:01

Even if dependent systems go down. So wonderfully exhibited and exemplified during that outage things were standardized. There was absolutely a very strong declaration of what constitutes a properly performing system in terms of correctness, latency, availability, so forth. And then when it didn't meet that standard, uh, then it triggered it, uh, that VM to be killed stabilized. Uh, uh, when failures happen locally, it stays local. So it can put CONUS could go down and they would rely on fail overs, uh, to another VM. And they were actually relying on AWS to manage that fail over. And it was all done locally. How that last test, uh, there was no centralized production control system telling each node what to do. So I think, uh, Steve, I think this is just a wonderful example of the miracles that was pulled off, uh, through the Simian army and chaos monkey. Does that resonate with you?

00:19:51

Oh, Jean a hundred percent. Look, our, our assertion here is that you have the way you design systems, uh, has a direct consequence in terms of how well you can, um, engage people's, uh, problem solving ability. And you know, what you've explained what this Netflix example is taking a system, which is very complex in its entirety and being able to partition it into pieces, which can be self-contained relatively simple. So that, uh, if there's a problem in an element, it doesn't become a systemic problem. It can be addressed and so on and so forth. It's a really fantastic lesson here. Okay.

00:20:26

Wonderful fact, let's take a look at the opposite pole. Um, you know, when you have very problematic services, uh, uh, in the simplicity test, we can fail that Scott havens at Walmart talked about when we have item availability, it looks up look, ups that might require 23 deeply nested API calls and the before stage, all of which must be up in order for the consumer, know whether an item is available, a standardize, we can imagine situations where as Christina Yacktman from Vanguard talked about when we have only alerting when things go wrong, but no telemetry does actually tell us when things are going, right. Uh, stabilized as Scott havens talked about when any one of those dependent services go down, suddenly everything goes down and we can't sell something to the customer and synchronized. Um, I think it's, it's so interesting. Scott said because all 23 services were required to operate correctly. Um, and any deployments to any one of those 23 could go wrong. Suddenly all 23 services had to communicate, coordinate and plan deployments together and deploy one at a time so that when something goes wrong, we can identify and isolate what went wrong. Steve does that resonate with you?

00:21:30

Oh yeah. Fantastic. Look, the, the Walmart example resonates so strongly because basically what it's saying is that if you don't have a S a system which has been simplified and consequently, it can't be partitioned, there is no difference between a local problem and systemic problem because the local problem will spread, um, and becomes a systemic problem quickly. And even if it's identified as a local problem, and in order to fix it, you still have to shut down the entire system because everything is connected to everything or many things that connected to so many other things that when you work locally, you're really working on the entire system simultaneously, which is sort of the exact opposite of what was, uh, your explanation for Netflix being able to handle this major disruption, the, um, the unavailability of, uh, Amazon web services yet they could still function.

00:22:21

In fact, and Scott spoke so brilliant in 2019 about how he's supplied those systems. 23 lookups went down to two, which is amazing. All right, in the coding space, we have continuous integration and delivery. So I would pass all four things. Simple. We have integrations build test deployments that are happening all the time that are well-defined and automated. Ideally with only one way to get into production standardized, we have all our assertions and tests defined and automatically run upon every change commit in diversion control. Uh, and when something breaks, we kick in stabilization, if anything fails, the test fails, we stop the CICB pipeline. And, uh, that engineer supported by the team, or, uh, maybe even the entire organization will help swarm the problem to get back to that releasable safe state and all this is happening at the local level, without this need for some centralized production control system. I tell every person what to do, Scott. Uh, Steve, does that resonate with you? Yeah.

00:23:12

Again, the only way this happens is if the system is originally designed with an architecture, both the technical system and the organizational system, as an overlay in which you can create partitions where it's clear, what's within my partition, what do I have to, um, coordinate with the person on the other side of a partition? And if all of that is clear, and I know where I have latitude locally and where I have to have coordination, um, with my upstream and downstream dependencies, then the folks at the top aren't being sucked down into the base plate operations, and they can continue to do the things they're well-suited to do while we do the things we're well suited to do.

00:23:53

So the opposite pole to this is, um, the large complex deployments spending hundreds of people that we only do twice a year with almost no memory of how we did it last time. So we failed the simple test three, we might have scores of teams, hundreds of dependencies often only discovered in the middle of the deployment that we have to wake people up in the middle of night, uh, standardization. We feel that because we're lucky if we have good documentations, um, on all the steps required hundreds, or maybe even thousands of steps, um, stabilization, um, when things go wrong, uh, the entire production is jeopardized Phoenix project. I love the fact that there was no turning back. You can only go forward. Uh can't can't, um, abort or, uh, call off the deployment. And again, synchronized everything is, uh, as the worst of all worlds, tightly, coupled and loosely controlled, uh, not so good. Uh, Steve.

00:24:43

Yeah. So without, without going to the four specifics, but you realize, um, how condemning such an architecture for a complex system would be in a contemporaneously, right? Because not even if, even if you could get to something that, um, functions well, what it will lack is, uh, resilience, and it will lack agility. And we live in an environment where so much is changing all the time that, uh, the absence of agility, even in the presence of functionality is a condemning,

00:25:19

Uh, not so good. That's something that we're all too familiar with. Okay. One of our favorite examples of that, uh, is the Toyota production system. So simple, I think for me, one of the key insights of that, uh, decoding the DNA of the production system is a notion of explicit relationships between each work center that those pathways are explicitly identified almost like an API. In fact, even use the language of, um, Dr. Carlos Baldwin, uh, similar to how we think about software systems, standardized judoka are those built-in tests and standards at each work center. More importantly, the Andon cord pulls a signal that helps us needed, which is takes us to the stabilized point. So we have 4,500 and on-court poles per day. Um, not only that we have 60 lines, side store changes happening in a given day, all part of daily work. Um, and all of this is done without a centralized production control system must know all Steve, does that resonate with you?

00:26:08

It sure does. And I'll tell you why I'm going to channel what I learned from Taiichi Ohno through the Toyota production system book, and other things that he's written. And the stories I've heard about him is that from his perspective, the reason to create this type of management system and the beauty of it is I'm not so much about creating explicit relationships between work centers, but creating explicit relationships between the people who are using those work centers as a way to express their inherent creativity as human and, uh, when one reads on, oh, and then read, reads them and reread them, and finally come to some sort of motor come of understanding. You realize he's talking about a system for managing people who happen to be using very complex, complex machinery to express their creativity. He's not talking about the control of the movement of inanimate material through inanimate objects to create other inanimate material. So this, this rings very true.

00:27:16

So we can't talk about Toyota without talking about the emperors, the 1990s, big three auto plant where things were not simple, uh, things were not connected point to point within work centers instead, they were connected through a centralized MRP system. Uh, I think the best evidence of lack of a standardized, um, property is that, uh, came from the NPR, this American life, new me episode. Uh, there are documented case of cars missing steering wheels or tires engines being put in backwards, showing that, um, maybe the problems may or may not have been detected, but certainly weren't acted upon which takes us to stabilization. I think in an interesting property of, uh, the lack of stabilization capabilities, is that a big three automotive executives that you quoted in the ideal cast saying that they tried six line side store changes in a given day. And, uh, they ended up having to shut the plant down for three days because everything was in the wrong place. And this is because that everything was routed through a centralized MRP system that could not keep up pace with the real world.

00:28:14

Yeah, yeah. And Gina is, you know, as you're reciting this, it just strikes me the perversion. That is the characteristic of such management systems that, uh, they fail or to refuse to recognize that their systems for managing human beings who are seeking meaningful collaboration with each other. And once they, um, missed that key point, everything is about managing, uh, material and machines. And anyway, you get these situations where, um, by ignoring the potential on the base plate to actually solve problems, you don't engage it. And by, um, overloading those at the top, you cripple their ability to do anything useful. It it's just disrespectful and, and perverse all around

00:29:08

Our favorite example, a team of teams in the, before state, we fail the simplicity test where missions required experts from a vast numbers of functional silos, military service intelligence agencies with no direct connections between them. Uh, we fail the standardized tests because the dependencies between each silo was not explicit. Uh, so as you said, there was no equivalent of an API or a service level agreement or what the value exchange was. Uh, we feel the stabilized test because no organized mechanisms for teams to quickly get help from each other, especially in the absence of those defined SLS, or even at the level of prioritizing resources, uh, was only happening at the global, uh, region scale. And the synchronization, uh, teams were working against their local priorities versus the global global system, a low goals, which was to dismantle the terrorist networks interact,

00:29:58

Uh, which gets us to the after state. Uh, they ended up with a far simpler system because these functional specialists were put into short and medium term mission oriented teams, uh, standardized, uh, yes, because the roles and responsibilities were defined again within the context of these mission oriented teams. And they could depend on help from each other and even we're not, they invested in these relationships, uh, to create these relationships where they didn't exist. And maybe the best evidence was that difficulties, uh, were identified and remedied opportunities, uh, could be taken, uh, as evidenced by the fact that they went from sighting of a terrorist leader by a 22 year old drone operator resulting in capture 45 minutes later. Again, this is, uh, not done by the production control, centralized mothership, but by people at the edges and, uh, synchronization, everyone knows what the goals are. So mid-level leaders could, uh, among other things, horse trade, scarce resources, such as helicopter, transport, and space on, um, intelligence gathering platforms across this vast network, again, without the intervention of eight levels up. And April's down, Steve does that resonate with you

00:31:00

100%? You know, Jamie, you know, we've had the good advantage of I'm learning a ton from David Silverman who was writing sort of autobiographically as co-author of team of teams. And he started thinking about what David has explained in the ideal cast and in this forum and elsewhere to us is that, um, the start state was, you had talked about high-speed, high-frequency a very fine detail operations. You had people at his level, you know, young man, young officers sort of, uh, you know, operational manager, if we want to bring it into the industrial design parlance, um, who kept having to wait for instruction from his higher ups and then, um, constantly give them updates. So they can then decide what David and his colleagues and those in adjacent teams were supposed to be doing when and where, and, um, not surprisingly the experience they were having was exactly what one would predict from that kind of setup.

00:31:54

Right. Which was the top seemingly unable to make, um, meaningful timely decisions because of getting flooded with so much information, those on the bottom, um, either idle or, um, misdirected, but the whole system, um, ineffective. And then when, you know, David has explained to us so eloquently and so well is that, um, by giving the base plate operational level, the, a ability to talk, uh, directly in terms of the horizontal flow of ideas in the horizontal flow of work and, um, self synchronized and stabilize and all of that, it meant that they could operate and retune with great alacrity while their seniors were able to observe the system as a whole on how the system was performing as a whole on how the system was directed in terms of its purposefulness as a whole. So the, um, more senior people who should have been thinking about policy and thinking about strategy and not at the micro tactical level, they were actually liberated to do that. And the people operating at the micro tactical level, not only were they able to operate at that level, they're able to modify and adapt at that level to

00:33:09

Wonderful. And we heard from Admiral Richardson on day one saying the job of the top leaders is to study the problem, right, and, uh, spend 55 minutes and an hour, uh, understanding the problem so they could best understand how to craft as a solution. Wonderful. So I think this does in my mind, uh, motivate why structure is so important and why it is maybe one of the best leading indicators we have in terms of what the resulting dynamics will be in terms of, and whether to what extent we can actually achieve the mission. So help we're looking for validation or reputation of these ideas. So much of this, it's been so gratifying, Steve, to be able to piece this together over the last a year and a half plus. And again, if you are interested in mapping flows of works, Steve has some amazing technologies to help enable that. Uh, just reach out to him on slack. Steve, thank you so much,

00:33:58

Gene.