Hello, I'm Rob Hirschfeld CEO and co founder of rockin and your host for the cloud 2030 podcast. In this episode, we come back to an important topic, which is understanding, agility and adaptability. And in this discussion, we get very concrete about the differences between agility and adaptability and why that's important for you as you go on your own innovation journey. looking for places where standards can be applied and accelerate your team are where it's too early, and learning iterations that we would call agile process are more appropriate, and how teams get caught in the middle between standardization and agility. It's a really fantastic discussion and part of a longer journey for us. In these topics. I know you'll enjoy the discussion
there are some townhouses around the corner from here that are literally 13 feet wide, three story, and they're selling for over a million. Yeah. Which is an insane amount of money for such a small physical space. I mean, like, you're buying a home with bedrooms, that you can't even put a king sized bed in half the time
on some of those homes even have a sub basement. Yeah, like the basement is still like, like an ensuite. And under that you have the sub basement with a laundry room. So imagine, they're just that they're narrowly stack, like those stairs, do your laundry?
Yeah, they're stacked side by side with a certain amount of recess, you know, like, you know, staggered front doors. But then they have these like tunnels that you have to go through to get to the front door on some of them. And I'm saying, Why would I pay 1,000,003? For something that looks like I've walking into a prison?
Oh, I mean, high rise condos, but like it's the same? The same floor the sign that just more flows on top and below?
Yeah, it's so it's crazy.
It's actually funny that so this is an actually good segue for the topic of the day. So because the topic is adapting versus agility, perspective, and right, I mean, some of what we're describing this is this comes back to it, we were talking about century home, we were talking about a boy, I could bring up my compliance, death curve, work that I've been doing. You know, I think that I, we keep coming back to this interesting idea of fitting within the space you have, which is where I was thinking about what those houses are. And the benefits of of being able to do that be adaptive, and whether or not that's agile, whether people feel like that's agility, riches Rich has given me the look of because here's, and I'll frame it a little bit more, if you don't mind. The work I've been doing on this component, the compliance death curve starts around the assumption that people assume that standardization means slower agility, which is a completely mistaken assumption. But I but when you walk into a shop and say, Hey, we're going to have more standardization, more patterns and practices you're going to conform to, right, our corporate standard. People throw up their hands and say, We can't do that. We'll never be agile, we you know, we're going to give up, we're not going to be able to move fast, everything's going to be stuck and slow. And that mythology keeps breaking people, but I don't. I don't think we have the language well down to explain how it's not true.
Well, it's not Oh, go ahead. Rich. Sorry. Yeah,
I was just gonna say, I mean, a standard. Two things. There's a presupposition if you're, if you put in standards, and your assumption is that you're going to build absolutely everything in house, you're going to everything is going to be DIY. Then there might be a little bit of a of a rationality behind saying, well, we won't have full flexibility but let's put that aside for a second interest in you, when you put in standards standard, can be terribly constraining. And then really very, I mean, if you can overdo it, let's put it that way, the same time, you can put in standards that are better than guidelines, they are standards. But they actually encourage and, and actually improve longevity. And I point to the a lot of the RFCs. And a lot of a lot of the Internet protocol standards, which were designed to be not overly restrictive, have some lifetime, and compare them to a lot of what came out of, you know, OSI and the and the, the, the original seven layer standards that CCITT and itu were were putting in place, which were incredibly overweight, and yeah, you know, over over overly constraining, so, you know, their standards and then their standards.
And making me think about soap versus rest from that perspective.
I actually talked about on Tuesday.
Sorry, I missed that one. I'm looking forward to going back and listening to it. Well, but that's yeah, go ahead.
Sorry, I, having written standards for many years, or contributed to them, I would say that those that are really Picayune in the detail, are so are written that way. For two reasons, one, because the technologies around them have not evolved significantly enough. Think about EDI, right, or can be or are adaptive in the sense that they can be reused as the same standard across several segments or industries. And to the point of agility versus adaptability. And they are two very different concepts, even though they're used by most of us interchangeably, the idea of the standard is usually adaptable. And so the argument that I would make is standards do not make you inflexible, or in Agile, they make you adaptable to a point. In other words, you have the flexibility, you can take something that's very black and white, and you can still turn it into a shade of gray. And those notions of how gray is gray depends on the industry for which the standard is being used. So in the case of compliance, like ixbrl, is a perfect example. It came about years after XML was already in place. And you know, HTML had evolved and whatever whatever. And somebody got the bright idea within the stock exchange community that NASDAQ and s&p and Dow should all start taking the front edge financial statements in under SPRL as the standard for reporting purposes to speed up the process. So it had a purpose, it was mindful. Now, I don't know about you, but every single financial statement of a major corporation is never going to look exactly the same to your AI power they do the calculations is never going to be exactly the same. Up to date is not a standard calculation. It is a calculation period, how you put those figures together to create the MTA. That's another story for accountants. But these are all things that are far more adaptive and adaptable than they are constraining. And so one of the things that I like to say from a compliance perspective is agile is a reactive state. Adaptive or adaptable is a proactive state. You are adapting to change. You are not reacting to change. You're foresighted you're not hindsight it and if you actually left
the last conversation, and I want to dig into that because it feels right, but also not a
simple Yeah, I'm not I'm not sure I agree with the word agile being classified as reactive. I mean, if all you do is using agile, agile to react, yes, that would be right if but agile, the way I see it implemented, which may just be me being lucky. But it's, it felt more proactive than reactive in that instead of sticking to our course, that has gone astray, you proactively adjust the course of your work to meet new, the new data, it shows that instead, so as opposed to, let's say, say a CT for six months, and then adjust and then do a strong adjustment, and then another six month you reduce the length of potential your Sprint's to do micro adjustments. So as a culture that's proactive, in that, you know, that you will need to make these adjustments, let's do them earlier, rather than later.
But in, in what I've, I like what you're saying, and it's really making me think, here, because by design, agile process is a learning process, which I think is reactive to Julian's point. But you're the whole point is saying, I don't know enough, I need to keep I need to learn and go. And what makes what's interesting here is that if you if somebody showed up with a standard, and you were agile in this case, do you would you would actually say I can't follow that standard? I don't know enough. And so right there, this is this is potentially a place where people are saying, add, if I come in with standards, I'm counter agile, because I haven't learned that I need them yet.
Well, maybe I'm
trying to figure it for trying to figure out why people are so resistant. I mean, it's stuck.
They're resistant to standards, they're not really they're not. I don't are they? Are you getting a pushback on agile or pushback on being adaptable? Or,
well, what standard what? The stamp so what I'm what I'm seeing, right, and this is the joke I was making to my team earlier today was right, it's 2020 for the year of the year of compliance and governance. Because Because most organizations have to have have said, I'm gonna get out my I'm gonna get my standardization and governance, I'm going to undo that get out of the way, because we need to move quickly, which is not the same as being agile, but that they're often flooded. And now they're coming back and saying, wait a second, I've I can't secure this. I can't support it. Each team is doing all bunch of toil where they didn't they didn't. They haven't collaborated. So you can't offload toil from that team into an Operations Group. Right? Most of the organizations that we're talking to have created a mass for themselves, because they've they haven't imposed guidance, guidance and standards and patterns in the work they're doing. And most of them, if you come in and say, Hey, we're going to impose standards, there is technical that they have to burn down. But they they the teams really resist the idea that they're going to give up. And they'll say, Well, I don't want to give up autonomy, or I don't want to give up agility to use a standard or to conform to a standard.
My experience has been the opposite, actually. Okay. And the team's drive. Adoption offers standard because, like, for example, one recent use case has been like observability. Like, there's been so many teams and lots of companies that are like, okay, like, we want to get on top of the observability bandwagon, like we, we see the benefit of it. But up until fairly recently, I would say last year. It has been a non standardized landscape, in the sense that the libraries and protocols have been right, pretty much all over the place. What research to because it had this has been But like an explosion of new ideas, new technologies that needed to be put through the fire and tested battle test, now that the winners are coming out standardization, standardization is happening with open telemetry, leading the pack there was essentially like, if you want to adopt open up the relative standard, you pick up open telemetry, because it gives you a lot it gives you treaters, it gives you metrics, it gives you a standard way of producing them. And it is pluggable into all of the existing systems. So, so now, this is a good time to adopt the standard, because you want to use it, or in many cases, you do use it anyway. And now you are reducing the toil from having to use this train systems by standardizing on one method,
so would you would it be worth saying that the using the term standards is possibly a mistake. And that me and that is you'd have to you have to qualify? At what point you're putting standards in place in the in the kind of the lifecycle just as as Klaus has been saying, you have, you know, you have a, you have some de facto standards, you have absolutely different different places. The other thing that you have to think about not just the timing, but the the intent of putting standards in place. Sometimes it's for uniformity and and inter inter working interconnectivity, sometimes it's to kind of extend the lifetime, but sometimes it's safety. It's, you know, I'm putting I'm putting guardrails in place, and I'm putting them in early, because I actually don't know, all of the different troubles I'm going to get into if I leave the straight and narrow path that that's been defined. PTT IDs are notorious for putting in standards way too early, putting in something that they believe is the right thing and doing it for the purposes of safety.
Yeah, all right. Can you refresh my acronym? No, let's itu
PTTs. The the National Post and telegraph. You know, the the national telecommunication telecommunications authorities have that are governmental. They establish the standards for their country. And that's, that was what I was referring referring to.
Okay, so there's Sorry, sorry, Robert, I didn't mean to cut you up. There's another, there's a way to look at standards as well. And that's from the industries that they're being put into, as well as technology across the board. And so there's issues of democratization, cohesion, uniformity of transfer of data and information. There's looking at the standard from the point of view of, is this got a human touch to it? Is it going to benefit or be purposeful, from a societal perspective? All of those factors actually go into how I so decides whether it's going to bless a standard or not, I triple E can bless the standard and say, Yes, it's good in the in this very specific domain, which is to Rich's point where it can be very restrictive, and to Rob's point as well, but from the compliance perspective of a standard, it's everybody must provide X or Y.
And that gets to my safety argument. You know, if safety is the is the driving principle, great, that's what's going to happen. And it's going to be often too early with the stated idea that yeah, we're putting we're, you know, we're putting training wheels on you. Here. We are, we're going to create a fairly narrow range in which you have degrees of freedom but we're doing it for everybody's safety for for a number of beneficial reasons. And we're going to, we're going to put in place validation and certification and compliance in order to reinforce the message that, you know, this is for the greater good the safety of the community that's involved here.
I don't know if I agree that these are premature? No, not at all. I would, I would say, at least safety standards are in some cases misguided. Like, for example, the password competition rules that we're now trying to do. The other side, but apart from security, I think is and this perhaps applies more to the fact of standards rather than written standards is reduction of toil. Because a standard gives you replaceable parts.
Supply supply chain supply chain is another. Yeah,
well, which is a combination of reduction of toil and security. Exactly. So
one of the things that's interesting that coming up here is right at Agile is important as a learning process. And adapting is important as you want as you've as you come into a place where there's more repeatable patterns, where we can actually say, because the standards don't work I've been I've been hearing this consistently with the discussion. They're not going to work if you don't, if you don't know what the pattern, if there's not something repeatable patterns, you're imposing standards too early, and you've missed your learning cycle. But one of the things Joanne said early was that we can over define standards, and those, right, and those are creating too much. Oh, oil to oil well, and then what was what was interesting is that you can actually break based on what I'm hearing, we can sort of break things down into sort of layers of standardization and objectives. Yeah. So there's standardization to collaborate through with other people. There's cloud, there's things to transfer knowledge, like liquid get became a standard, right? There's toil reduction, I have security, people and skills, being able to reuse people's skills, and then supply chain so that you actually have interchange, tangible vendors. There's all of these different sort of rationales for having standards, but they have different levels, like what you were saying with interchanging financial statements, you know, over specifying that is going to eliminate people's participating in the standard. And so get creating high adoption rate on a standard is also part of the objective with this.
Right. But that adoption rate, like in the case of SPRL, I forget whether it was the Dow or NASDAQ, one of the majors and their cohorts around the world that are owned by the same basic entity, all said, by x date. Government will require you to do this, there is law behind it, and they had a three year window, to then take the standard, develop it out as best practices and use case and, you know, download this to get that kind of thing. Where everybody was in conformance. And the reason that they did this, by the way, was for the public good so that you could get the financial statements out to the public, both the shareholders who were majorly going to be impacted one way or another, within a very short period of time from the end of a quarter or from the end of a year end or whatever. And so it took about three and a half years for them to do that, that to the two points to your point rather than the variation about what is the intent of the standard. From I triple E 's point of view from ISOs point of view, it is about repeatable process, and everybody always does the same process, everybody should have the same results. That's the foundation of it. How you then portend or play that out. Longer term is in the version one version two version, you know, whatever, but agile, just to muddy the waters a little bit and take it back to the beginning. Agile is you know a synonym for nimble, how fast can I do it? How easily can I do it how fast facile Unlike as a corporation, to adopt something new or to dapped to change, adaptable and
changing direction, and
yes, right based on a trigger, it's kind of like event driven architecture, which I'm a huge fan of something happens, you then react. But my point of view is, if you can anticipate that something is going to happen, based on the predictions made previously, or the, you know, harbingers and bellwethers that come out in your industry, then you should be an adaptable organization, and start the processes of how you're going to deal with that eventuality in something as simple as if this then what else, right, you can do that. So being adaptable and being adapt and looking at a standard says, I can doped that standard and adapted to my specific use cases and business scenarios, because I know, I'm not going to be the only corporation. In this same scenario, the variability of the scenarios will change, like a gauge might change by a degree or more. But generally, I'm going down the same course as my cooperator. I'm going to face the same issues, the standard allows me to bring forward my view of adaptability, because I have the the Rosetta stones in place, I have the cornerstones in place to be able to adopt, adapt and be agile all at the same time. It's
interesting, because I'm thinking through, like how USB has adapted from that perspective as a standard, because there's two, right, there's the communication and bus power supply, and then there's the physical adapter. Right, one of the things that has made that standard work really well is that the standard has adapted over time to different use cases. Right, it didn't, we had, you know, we've em, we still have USB keys that you know, still work there, you know, the A plugs are still compatible with the C adapters you have to buy an adapter but we have USB has been a standard. And, and it's adapted from dots,
I think we are seeing a little bit of a regression now with USB C because uh, so I'm particularly with the cables, because not every cable is to say, so, one USBC cable might only be able to provide like USB two type speeds, another one USB 3.1 on that one might be able to do power delivery. There is no standard yet another
yet another one, you know, you can use for you know, very, not just differences in speed, but differences in protocol and basically in low level protocols. So yeah, I'm there, where this is where they lose the plot. There we pull out, pull up that
little drawer and you plug it in and Damn, it does not work.
Because there's no labeling station you like you have to guess or you like in some cases it might even be that the vendor claims to be compatible on justice or not.
And, and you know, it's funny that you're talking about USPS because this week that's been the bane of my existence. I have micros I have C's A's, and I have ports on my new little tiny computer and a bunch of cables and I cannot see well enough because they're so tiny to you know, I keep plugging the wrong hand into the port going where the hell is this not fitting and then I look like a magnifying glass and look and I go well duck, you know, micro is not going to fit into c and now I'm looking for a single package which I cannot find on Amazon by the way, have multiple ends male and female ends that I can just buy as a package of C to micro to B to A to you know whatever. As one package. I now have to buy six packages of adapters to get one mix.
I've been funny like we have I've slowly we're down to very few but I have some older devices that have the the micros yeah and and but the squid stuff People are giving out now only have Matt, you know, a Mac and C. And the micros are, right, I'm gonna have to bring specific micro cables
or adapters, or adapters. So yes, yeah. That
turn on the number.
The good thing about adapters now is that they're the compact enough. And they're sturdy enough that you can just toss them in your bag, and not worry about them being damaged. To the point of being unusable. Yeah,
that's true. But but this is, this is the perfect example of agile will not help you here. Yeah. Why not? Because no matter how you react, no matter how quickly react, you, you, your reaction is not going to yield you the results if you don't have the right plug.
It's this is a story about what Apple did, where Apple went off on their own or the information for the standards or
no Apple went off on their own and took the headphone jack away because they wanted to boost their beacon business. And everybody else said from a manufacturing perspective, that's a sweet idea. I'm gonna copy it. And then they eventually disappeared. And then you have people like me who do not want to be trolled. While we're in particular locations and don't want those beacons going, Hello, do you want a discount on this or, you know, buy from me or whatever, whatever. It's like, you know, being in Marrakech at this point. But that's the reason that they did it. Not for production quality, or cost reduction, simply to boast the ancillary business called beacons, which they pretty much on the market for.
Now society is suffering from it because it turns out that many of the current most popular Bluetooth implementations have an unfixable vulnerability
that Bluetooth implementations
Yeah, the the it's possible to man in the middle Bluetooth communications. And essentially, as long as you are as your device is paired with a with a with another Bluetooth device, man in the middle, kind of intercept that and change the device type to a keyboard, or any kind of HDD input device, start interacting with, with your system.
And you know, where it's most prevalent. Cars big especially taxis and Ubers and Lyfts. And those kinds of folks, because it's very simple to do. Everybody has Bluetooth on Bluetooth is on in your car, even if you haven't paired your device. Right? And I where it came out and I asked someone who was at CES, one of the people from one of the vendors to I shall not name but let's say that there are is Honda and I said so how do you prevent this from happening in your now you know, new cars that you're saying are so they're going to be level four autonomous, they're going to be super safe. All of the edutainment infotainment, blah, blah, blah, blah, you're listening to as you're driving, how are you going to keep that safe and secure? And their answer was, we don't know.
There were may not it it doesn't have to answer for this like you do network segmentation. It was just about VLANs were made for in the first place.
Yeah, yeah. But but you know, how big it was me like can you know knows how to put knows how to, to put in place and then manage the lands and you know, no one's made that a you know, dead simple, kind of easy thing to do. It's just, it's, it's it's still a mess. Rob, you talked about the the conformance. What do you say he's called the plastic implant stuff curve, compliant sector. Tell me what you mean by that.
The I've been at this a series of talks I'm working on putting together the, the idea is that at companies are really struggling to. And I think we've described it really well reduce toil and prove security, right, accelerate their teams, because right now a lot of their teams are not moving very fast, they're not agile, the way they think they should be. I think Closs is a good example, right? They, we, you know, having them converge to an observability standard would actually make all the teams more effective, because then you could say, We're gonna build a observability platform, and have a team govern that specialize in it, now you've offloaded something from other teams. But moving at a current time, most companies that I'm talking to have not tried their been agile. So they've been in these learning curves, they've built a whole bunch of stacks where they have not, they're missing the standardization, the benefits of standardization that we've articulated. But when somebody shows up and says, we're going to help you standardize these processes and operations, the teams rebel against that standardization, motion. And I think, by Steph Curry, because because they look at it, that what they look at is two things. One is they don't want to be told what to do. But they also and they look at the toil the work, it's going to take to comply with the standard because now they have to uproot work they've done to move to that standard. And so when they the compliance death curve, actually wait, I think I could actually show you the curve. If you'll bear with me for a second. That's the last time I tried to do this my computer crash packet here, I got it, I'll share it. And you can see what I'm talking about. Okay. Jump in here. So what what you what, what I've been talking through in this is I'm not going to zoom in any bigger, that's great is is this idea of, of standardization that we've been talking about, but there's a bringing controls during this phase, and people feel agility is dropping during the standardization phase. And what they don't have a feel for is the bottom of that curve. So they're very worried about this time, where they've lost agility, putting in standardization, and they're not getting the benefit yet from the standards. So this, I've been finding, right the this resistance of standardization in organizations because they perceive that they're only going to lose agility. And what we've been talking about here is right, and this is that. So there's still a lot of frustration at this point, there's very little benefit to the, to the state to the work that companies have to do. And frankly, they're all goldfish. So most teams, most companies don't have enough longevity to think that they're going to work through this process, fortunately, but what we're talking about, and I think we're really clear out is once you put in the standards, we have all these benefits, right? The toil reduction, security compliance, you know, improved portability as skills. So there's a huge innovation phase that comes after the standardization lube. But so,
yeah, that makes a suggestion. Sorry to interrupt you.
What were you up to envision?
Where you have the innovation phase in your up arrow next to it? I would call that adaptability.
I like it, okay.
Because that gets you. And there's another part of this, which I had a question, which is why I interrupted you. Where's adoption? I know you're gonna be a straight line.
You're You're right. And I think that one of the things that I get, as this is what's fun, I'm trying to this is this sort of concept where and in this before it, there's some this week where I started in the today was this myth of standardization and agility are at odds with each other. And autonomy and standardization are at odds with each other. So right away, I'm building up the mathematical, there's a mathematical part to this, that that goes into, you know, why companies resist why actually it's why teams resist what the company needs to do from a standardization perspective. And some of its Go ahead.
If you can't go back to the previous slide. You might as well, sorry, yeah, I'm not sure I agree that TinyMe on standardization, or using the same units? I don't think you can.
I was gonna ask the same question.
Like in like, as, like from your chart, like, standardization is complementary to autonomy. But that is a Venn diagram we're talking about. So decision overlap, yes. But when, again, like they're not conflicting, and that they're also not multiplying. Ideas, the apply to different business aspects or tasks, I suppose, because it doesn't need to be a business. How
standardization
sorry, there's, there's another there's another force that needs to be added to your, your graph. Okay, that's a downfall. It's, it's the gravity. It's, it's the thing that that actually creates a larger area between the two curves during that.
Like to call depth.
Yeah, or
this is actually the technical debt. This is the technical. It's
technical. Yeah. And, and, yeah, there's something else that there's missing. And, and the other thing that may also mediate this is
back to Klauss. point about the point in the process, there's a there's a time, there's a kind of in the whole adoption curve, there's a there's an optimal time to introduce standards. Oh, I like that. Yeah. And, and that, that's probably one of the areas that you need to address. And that in itself, you know, the choice of where in time you you need to implement a standard or put one in place has to do with going back even further in the conversation, the intent? Why am I putting something in in place? If it's safety, it might have to go in early. It's a it's a cost, it's more costly, but it is your costly in this term, but it's you're putting it in earlier? Because you're you're trying to protect the community, the end user, what have you. So I think, I think adding a couple of things there
is direct feedback
is is really important. The incorporation of you know, what causes more gravity and you know, basically bringing that minimum benefit line down even further. That would be important.
The way I would actually visualize that is that so is that I will start with autonomy by itself, with arrows going in all directions. And then when you ask standardization, you clean into a ver autonomous teams our direction, so that the war in unison, as opposed to potentially against each other.
I like like a visual, I need to
think about it. So So I have a question. Yeah, because I it's a premise question. Can you the slide that you have that says agility equals autonomy and standard time standardization? Explain, please.
We're at a time ah, ah, yeah. Yeah. No,
yeah. When you haven't downloaded I lost.
Yeah. And here's what I'm, I'll explain what I'm trying to do. And then if you're if it's sorry, we'll bring this up as next week's topic. Sure. And then we'll put we'll put the book we'll put the book discussion the week after that. If y'all haven't read it, it's the it's the negotiation one, which is, which has been doing the rounds. never split the difference. But the what I'm trying to do here is I'm trying to match up a little bit. And I don't I don't, I'm not claiming to get it right. I, I had an opportunity to put this together sort of as a as a preview of it. And so I'm trying to pull in these mathematical concepts, because I think it helps build the graph, but they're not all connected yet. So next week, I'll go into what my thinking is with this a lot more. And I would love to get some feedback, I think I've got this core concept that we're all we're all nodding to, which is something is scaring people away from a what should be a beneficial operation for the team at a multi team level. And they're there, you know, what I'm trying to do is get it very concrete as to what what's going on for these companies so they can overcome it.
One of the things that would be really helpful is if you had a graphic that said, optimally, you'd like to minimize the minimize the the air, the shaded area,
there may be another dimension in there. There may be both in X, Y and Z.
I like what Yeah, because what this is what I've been trying to sort of go between is, there is this graph has this perception problem, and then we get into what, what, which, which we're acknowledging is true. And then and then we're acknowledging there's a benefit and shepherding people through it. But I agree with you, there's there's we should, should be some Pat was what would
an optimal, you know, kind of kind of best best case look like, and what would a pathological
This is, I think, I think this is what you're describing to me, is the vendor versus the consumer very, like the vendor walks in with the optimal path, which which basically, start up eliminates the whole bottom part of this curve. And the user looks at, you know, looks at it, and just says, We're never going to this breakeven point is never going to is not practical. And so we've got these overly optimistic and overly pessimistic viewpoints. And that's where the death, people just think it's what I'm seeing, broadly in industry, and what we'll talk about next week is, is they just get stuck, because they, they're so afraid of the downside for this curve, they never can get to the, they have trouble getting to the other side. But
I also want to charge is agility without standardization. So for example, like an initial strike, because you have the freedom to do the things that are plateau, and then a significant drop, your tech debt accrues on that line, we know the second graph that did include there. And then essentially drags you down, because you'd have not standardized. And
then I would demand
for connectivity. In other words, multiple multiple players coming into the market and into whatever this universe of discourse is,
and you say,
great, you know, as long as it was within their own their own backyard rate they had they had a wonderful time. They, they got to do whatever it was they wanted. When it came time to deal with interworking interconnection.
That's when, you know, Reality Bites. I
like yeah, I need to do a little bit more framing how enterprises have operated so far. And what
what's run before you drop off, if I can just throw in a comment, that that one line that you have where if you can show this slide adaptability. Yeah, you know, the one that I'm talking about?
This one, or this? No.
The one I think it was the one before No, no. 11
Okay. This one? Yeah.
flip this around in your brain before you change it on your slide. And say standardization equals agility. be plus autonomy to the power of event. Because that's really what you're, I think you may be true.
So, okay, you're here, you're being more mathy than I was. I was I was thinking, um, let me let me take let me digest that. And I hadn't thought about putting adaptability into this either. Yes.
Which what is it? What is in in this? Is that in to be
exponential? Yeah, the flywheel the network effect.
This is I've been trying to work into some exponential effect, because of the graph actually is exponential. I know. And so I was trying to make this mathy. And then I got, I only got so far. And then I wrote things down and committed to putting ideas out there. And I love the feedback because, right, I this is six months away from being where I needed to be. But it's, it's directionally correct. So
Well, that's good. I have a chart that I'm gonna send you that you might want to model off that, by the way, please,
I'd love to see it. Cool. Yeah, no problem. I did not expect to create so much excitement. At the end of the meeting, we will definitely pick it back up next time. And we'll we'll do some some some mapping.
Wow, I really enjoy when this group can get concrete, with examples and specific action items, to help you think through a course of action in when to adopt standardization. And as a bonus, we spent some time preparing for a more detailed review of my compliance, death curve. discussion ahead, that conversation will be ongoing, we're going to pick it up next week. And then working to make that a formal talk, which means that we'll come back as I get the actual topics locked in and perfected. Come in, join us be part of those discussions. We are also going to be talking through the club 2030 Book Club, which will involve never split the difference by Chris Voss an excellent book about negotiation. You can find out all of our details and schedule at the 23 dot cloud. I'll see you there. Thank you for listening to the cloud 2030 podcast. It is sponsored by rackin, where we're really working to build a community of people who are using and thinking about infrastructure differently. Because that's what rec end does. We write software that helps put operators back in control of distributed infrastructure, really thinking about how things should be run, and building software that makes that possible. If this is interesting to you, please try out the software. We would love to get your opinion and hear how you think this could transform infrastructure more broadly, or just keep enjoying the podcast and coming to the discussions and, you know, laying out your thoughts and how you see the future unfolding. All part of building a better infrastructure operations community. Thank you