Beyond Rebranding: Building Effective Platform Engineering Teams – The Platform Engineering Show EP5

Hi everyone. Welcome to the Platform Engineering Show. I'm your co-host Alan Hummel from Techstrong.

And let me introduce you to my co-host here on the show. org community. Um, first of all, hey Luca, welcome.

It looks like from the blurred background, you, you're home in Milan still? No, I'm back in the van. I'm in Madrid.

Back in Madrid. Okay. Yeah, man, you are the Globetrotter dude.

Good for you. Um, so what did happen last time we checked in on you, you were in Milan? Yes.

Did you go right from Milan to Madrid or what, what's been going on in your world? Yeah, London this morning. Landed this morning.

Oh, you just got in taking the van? Yeah. Yeah.

And I'm taking the van back to Milan, so that's why I'm here. Mostly. I'm, I'm, I was gonna go to Barcelona.

We have some workshops that we're doing. So apart from engineering workshops that we're doing tomorrow, no, on Friday in, in Barcelona. And I was just gonna fly there and back to Milan.

Um, but then I was like, well actually, you know, anyway, logistics, but we wanted to bring the, the van over to Italy. So I was like, like, okay, let me just land a day earlier, drive to Barcelona, and then drive from Barcelona after a work trip to Milan, which is gonna be a long ride, but hey, it's friends in between, so it's gonna be nice places to stop by. Good for you, man.

That sounds like a nice road trip. Good stuff. Yeah, Luca, so for this episode of Platform Eng, the platform engineering show, we're talking about steps to platform engineering.

org, right? Correct. And the article is actually to show notes.

Yeah, yeah. We'll, we'll put the notes in the article. There is actually nine steps.

I don't know if we'll go through all nine steps, but we're, we're gonna have steps, steps to platform engineering. Hell. But you know, it's kind of a funny premise, right?

'cause we're here trying to say platform engineering is a good thing. It's a way out, it's a way to scale. It's a habit scale.

Yeah. Right? Where, where does it all go wrong here?

That it, it could become a hell. Yeah. So yeah, this, this, again, this stems out of this like nine steps of, uh, er engineering had article, which actually stems through another article, which is the, I don't know how many steps to DevOps help that I had written prior to that.

And then it was interesting just to see, because to your point, right, like everybody was like, oh, you know, great, but I just moved to dev from DevOps platform engineering, all my problems are solved. Um, and then, you know, obviously you start seeing this like antipas merge within the platform engineering practice too, where well actually, if you don't do it right, you end up, you know, potentially even in a worse place than, than where you started. And so I think like, if we start from the top, like the first thing that I see a lot of people, a lot of teams, um, making as a mistake is, okay, let me take, you know, the sort of like hodgepodge of DevOps, cloud ops SE infrastructure teams and just rebrand them to the platform team.

Um, and it's actually interesting, you know, we start, uh, hosting these trainings or, um, organizations to go through from a, you know, to, to kinda like upskill their team. And one of the things that I see resonates the most with, um, with platform leaders is this, right? They say, you know, every, every time I say this, everybody knows.

They're like, oh my god, yes. So true. It's just like, I, I inherited this legacy of different teams now they all sit under me, they're all part of the platform engineering org.

But actually nobody has a clue as to what platform engineering even is, right? And so I think like the, the first mistake down to like, you know, um, sort of like slippery slope of, of the down platform engineering hell is this idea of like, okay, well let me just like rebrand whatever I have inhouse right now with no upskilling, no retraining, and just hope for the best, right? And it just doesn't work, right?

Because you have people that fundamentally approach infrastructure the way the, the, the, the relationship between developers and infrastructure as well in a very different way than, um, technically what a platform engineer should do. And so without retraining, without shifting the mindset, it becomes very, very problematic. And that leads right into the sort of second step, which is this product mindset, right?

Um, that we've talked about before. We had a full episode on platform as a product, as one of kind of the core principles of platform engineering. And that's really, uh, you know, also what's, what's missing a lot of times because there's no retraining, building a platform just gets treated as this kind of like one and done, um, sort of infrastructure project that's like six months or whatever.

Um, you know, I'm gonna teach developers something new, I'm gonna implement something new, and then I'm gonna move on to the next thing. And of course, that's also recipe for disaster because like we said before, previous app iss, really the point of building a platform is that it's an internal product. Um, and it has internal customers, the application developers or other users as well, security teams, architects, even the, the, the infrastructure teams themselves can be used of the platform.

So the point is, you have to ship it as a, as a product, um, implement product best practices, and really think of it as a product, not just from a technical perspective, but also from a business and go to market perspective, where your internal market is your, you know, internal tam, the total adjustable market is essentially the size of your engineer organization. Um, and so that, that mindset shift towards platform is a product is essential. It is part of the retraining, of course.

You know, it can also help obviously having, um, you know, a, a a pro product person or multiple product people within the platform engineer organization that lead this transformation. It helps if executives understand this and support this change. Um, but at the end of the day, that is another thing where if it doesn't happen, you know, you're, you're, you're setting yourself up for, um, failure, right?

Um, so maybe we can start from there, um, and then we can kinda like dive into, into, into other, uh, steps too. But I think that's really where we see in the community the first kind of roadblock and, and where, you know, the trainings and the courses that we've done resonate so much with the, with the market because, um, you know, everybody understands and this idea of like, okay, you know, platform engineering can solve all these problems, lemme go do it. But then if you don't do it right, if you don't upskill your people, it's very easy to, you know, to get stuck very, very quickly.

Yeah. You know, I, I, I think one of the things about that too, Luke, is something you said right, right off the bat, which is for a lot of organizations moving to a platform engineering model, we could call it that, right? Yeah.

Is almost like a lot of recycling instead of creating new, right? And mm-hmm. And granted that there's nothing a manner with that per se, right?

You, you, you do wanna Sure. Reuse these assets and you do wanna make it all work, you know, tightly, but you, you can't, you can't just put a fresh coat of paint and change the sign above the door and say, voila, you know, life of engineering. Yeah.

You know? Yeah. It, it, it takes more than, than just a fresh coat of paint and a new name on the door.

Um, and I, I think, you know, I'm guessing, right? You guys have the course. I don't, I haven't taken the course, but I would imagine it has to start off with, you know, preparation is, is the key to this, right?

Having a plan of, of, of instituting this platform engineering model across the, the organization and working with DevOps and SRE and, and ops and, and security and all right, everybody's gotta get buy-in. Everybody's gotta understand what it is. Everyone has to understand what they've gotta do differently or what they've gotta upskill on, or, or how this all fits in, like anything else, right?

Fools rush in where, where wise men dare to tread, right? You, you've gotta, you've gotta, it's all in the prep, I would imagine. Yeah, absolutely.

And, and, and I think like, um, few things that you said that I think are, are, are worth unpacking. One is this like fresh thing of paint, right? Which is so true.

Like this is one another huge, I think, um, you know, challenge that emerges when people are just like, okay, I have a, apart from engineering bandaid, because you know, my execs write on Garner that is cool and they should invest in it. Um, and so now I need to go do it and I need to show something for it, right? And so the first thing they do is they focus on, you know, the, you know, re re repainting the facade, really, right?

So it's like, hey, let's, let's, let's put like some, some ui, some portal, something right on top of the entire setup and call it a day, right? And it's like, we're down platform engineering. And of course, the problem with that is that actually, you know, I do think that that visualization is an essential component of platform engineering.

Um, but it needs to come with a layer of automation and ization underneath it. Otherwise, what you end up being is, um, you actually get the, the, the, the sort of like the second step of buy-in by executives because they're like, oh yeah, this, this looks great, right? Um, it, it's, it looks like we've, we've, you know, made a lot of progress and so on, but then actually there's no substance underneath.

And, and then you end up quickly in a place where you, um, you're sort of essentially misusing tooling that is meant to be front end tooling, um, to build, you know, to build the entire platform. And, you know, you can't, so you can like shoehorn your sort of like business logic into this, this front end modules and so on. And, and, and, you know, you end up creating massive tech debt down the line.

And that's one of the, uh, it's already one of the, I would say, another huge kind like mistake. And then kind like step to Hal is this idea of like, okay, start from the front end first, but also, you know, um, and so really not following, uh, architectural best practice, right? Like, yeah, I think it's very important to understand that building a platform is just like building any, our application.

Again, it's just an internal product. You need to start from the backend and then figure out, okay, what pretty facade? What door do I add to my door, to my, to my house, right?

Um, you don't wanna start, as we said before, from like the house and the win from the, from, so like the doors and the windows, and then kind of like add, you know, the walls and the foundation, uh, after, right? Um, so, um, so, so I think that's, um, that's like a very, very important thing, um, to avoid. And then to your point, right?

It's about planning. So, um, this is where I think one of the, um, one of the most significant standards that, that have emerged, the commute in the last couple of years have been this reference architectures or enterprise grade platforms. Why?

I mean, I don't know if you're, you know, if you remember like two, three years ago when people started talking a lot about platform engineering, um, you know, like in places, like, so I remember, you know, three, four years ago, I had to explain to virtually everybody I met, okay, what is platform engineering? You know, what do we mean by this? What do we mean by that?

Um, and then, you know, a couple years ago there was this clear inflection point where you could, first of all, everybody was talking about it and everybody was interested, but then also you could finally have a real conversation about it because there was this visualization, which again, it's why I think it's so important to visualize thing. There was this visualization of what a platform, uh, target architecture can look like, right? And all of a sudden people had a common ground to have that conversation and to think about, you know, backend front end, okay, what do we mean by this?

You know, how do this security tools interact with our platform? How do observability tools interact with our platform and everything else, right? However, I also think it's important to mention that, um, and, and so, you know, like the lack of a plan is certainly another step to hell, right?

But then I think there is a subtle step right after that, which is, okay, I have this beautiful target architecture that I want to build against. Great, let's go build it. And then the mistake that people make is, okay, let me try and do everything all at once, right?

Um, and, and build this like, amazing platform layer that is super secure that has all observability built in, that is making everyone happy, right? And that's, that's I think, a, one of the, the, the big problems here is because platform engineering initiatives touch so many different stakeholders, it's very easy to fall into the trap of trying to please everybody. Um, and that is a, a sure recipe for a failure in my opinion, because I think the way we should approach it is, you know, we've talked before about this idea of minimum viable platforms really taking, again, this like product management best practices of starting small and iterate from there.

Um, but what starting small means is it both from a technical estate perspective, right? So selecting one, maximum two representative applications and their respective dependencies, and start from there. But then also start with like one team, and especially one set of stakeholders, right?

If you're trying to, you know, make the application developers, the infrastructure people, the security people, the architects, the executives, try to make everyone happy at the same time, it's very, very, very hard to keep momentum and traction for your platform initiative. Whereas I think, I don't know if you spoke, if we've spoken about this before, I know you and I have offline, but you know, we've, we've, um, I think it was actually part of the, um, the predict 20 20 25, um, predictions, right? This, this idea of, um, the, um, the Pareto, Pareto, um, PA efficiency, right?

Um, which is similar to the 80 20, the Pareto principle. Um, but there is a subtle difference, which is interesting, I think, which is essentially is, you know, in, in, in layman's terms, like, don't p**s anyone off, right? So, um, um, which, which is like, okay, you need to make live better for some people, right?

And, you know, in the case of developers, that's, that's side of the conversation. The DevOp cell is easy, right? Like right now they're waiting for like two weeks to get an a database provision by their ops colleagues.

Like to make that 10 x better, it's easy. You just cut it into minutes. It's like cell service.

Um, uh, so, so that is a 10 x, but then it's important that that doesn't count at the expense of, you know, getting your security folks mad because now you're making things less secure or, you know, um, whoever else, right? Like infrastructure people now, um, are mad because, you know, you built, you didn't build your platform, right? So it actually, now self service means developers can just like click a button a hundred times and create a hundred different resources that then the, you know, infrastructure people need to deal with.

So like, those are the type of of things where it's like, make sure that your platform really makes life easy for somebody, but doesn't, you know, is at, at worst a net neutral for everyone else. A best in net positive, but it's never a net negative because the moment, even if it's like a 10 x better for some, for, for for few people, for few stakeholder groups, but even just like a minus 10% for somebody else, you can bat that somebody else is gonna, you know, like, uh, uh, like put up a crazy fight to stop this thing. Um, and, and it's a tragedy of the commons, right?

That this like large enterprise or transformation run into because, you know, it is better for the organization anyway, but that person doesn't care because that person is now 10%, uh, worse off. And you bet they're gonna fight, you know, you know, they're gonna give up their life, uh, to block this, this platform initiative. And that's kind of just the reality that we live in, right?

You're dealing with humans and, and, and so just to kind of like put a ball on that, I think that's the, that's the last thing I would say is, you know, another huge mistake is just like looking at this as a technical problem to solve, which is very natural for engineers as opposed to this like multi-stakeholder complex cultural problem, which is really human problem that we've talked about many, many times. And, um, and, you know, and that's the sure way to, to sail it, in my opinion. That was a lot.

You, I'm sitting here laughing. No, no, but I'm sitting here laughing. 'cause I, you know, we were talking before the show today about the Google migration going on here, uh, with tax showing f your, and, and that's kind where I'm at, right?

It's just, it's more than a minus 10% for me. It really kind of Yeah. Sounded like it grips at me.

Yeah. But, um, I don't care how good it is. It's not, it's just not, you know, I'm going to not accept it so quickly and it's gonna, they better gotta make it right.

I, and I, I, but I think that that's a good lesson. And, and this, and, and quite frankly, there's a DevOps lesson too, is it's not just about the technology. It's not just about the technology.

It never is, first and foremost is people culture, right? Because you can, it's a lot. It's pushing rope uphill to get people to accept technology or a process that they don't buy into if they don't buy into it.

I, and look, I this is 30 plus years in business, right? 35 years in business. Yeah.

I, I've run into this, not just in it, but in general, if, if your team doesn't buy into what you're selling, right, what you want them to do, it is, it's pushing rope uphill. You don't want, it's shoveling sand against the tide. You're just not gonna win.

Yes. Right? You gotta win 'em over who is pushing back, um, on, on DevOps, right?

Because to your point, it's a similar, like, it's like a cultural change, right? And, you know, I feel like looking back, it feels like everybody was agreeing, but I'm sure like not everybody was agreeing, right? So up here, everyone was agreeing, sitting around the campfire singing kumbaya, right?

Right. But the fact of the matter is, it's the same people, you know, and I'm not dissing anyone, but a lot of engineers and, and folks say, yeah, that, that culture stuff is all fine and dandy. What CIC detour I might using here are, we gotta get ups from Jenkins.

Jenkins, you know, Jenkins, Jenkins Jenkins, and what's my plugin and what's that? And, and that's what it's about. It's about moving, you know, shifting security left.

I don't care. But you know, where the, the testers, we don't need no testers. I'm using this new testing product, right?

Yeah. That's automated. And, and so like, they give their mouth moves when they talk about people and culture, but at the end of the day, they don't mean it.

Yeah. It was about the tools, all about the tools. Mm-hmm.

And, and it can't just be all about the tools. I mean, I, you know, I'm sorry, but tools are important, don't get me wrong, but I don't even know if they're the most important. Right?

Right. I still think people is is where it's at. But let's, so, so Luke, let's assume we, we get off to a good start.

We do the right things from the start and, and we're up and moving, right? We're, we're progressing mm-hmm. Down this platform, engineering on the road to heaven, stairway to heaven.

What could go wrong that makes the U-turn, you know, after we, like, after the train left the station, right? What else? Where else can we go wrong here?

Yeah. Well, I think it's the same things, you know, um, it's just like at a later stage, right? So that, I do think that that getting off the ground is the hardest thing.

And what's also interesting is, you know, I think it's important to understand like platform engineering is mostly a enterprise thing, right? Uh, or at least like mid-size sort of like engineer organization and up, right? Because that's where the problems that platform engineering solves are most badly felt.

Um, and so, you know, um, and so it's important to, I think mention like you basically in this situations, in this companies, you never start greenfield. Like there's always an existing legacy brownfield complex enterprise thing that you need to deal with. Um, and so it's not like you're kind of starting this platform engineering initiative in a vacuum anyway, right?

So even if you're starting new, you need to start wherever you are. And, and, and then if you already are on track, it's actually, you know, because I'm seeing it where I go in and I do these trainings with like large enterprise, and some of them are really at the early stages of their platform journey. Some already have like a platform team of like two, 300 people.

And granted, some of them are just rebranded, right? And they need training. But some of these people are proper platform engineers that have been building platforms for years.

Like they know what they're doing. Um, but they're, the challenges are very similar, which is like, how do I get adoption? How do I get buy in from different, um, you know, uh, uh, stakeholders, whether it's executives or others.

And so you're just at different stages of it, right? Which is why, like, the way I think of platform engineer initiatives is, you know, you have this like MVP phase. If you're at the very beginning, um, then you have this kinda like production readiness, right?

When you want to go from like, okay, you've proven the, the proof concept all the way to, okay, let's go to production with the first set of applications and the first one or two teams. And then once you're there, you go from production readiness to all, you know, all the way to full-scale adoption, right? Just like, okay, we're gonna go to the entire organization.

And every step of the way across that journey, you have, you know, basically just like a permutation of the same set of challenges, right? Which is like, how do I convince people? Um, right?

And, and maybe like the first time is like, well, how do I convince the first team? And the first team is like, you know, you probably wanna start with like a, you know, pioneering team, how we call it in the community that is like, um, you know, the team that is, that are like more comfortable with like, new technologies, new setups, you know, maybe the first one that implemented Kubernetes and containers back in the days, or infrastructures code and terraform and stuff like that, right? The one that you use to, you know, effectively like stress test new paradigms.

Um, and, you know, but so the set of challenges that you need to solve for them is radically different than the set of challenges that you need to solve for the nth team, which is, you know, the laggards effectively within your market, within your organization. And they, you know, they're just, they're not so with the firm, or maybe you need to figure out, okay, what is the right way of, you know, obstructing this underlying complexity while still giving them control? Because obviously they're the people that like control.

They're the people that like, you know, their infrastructure, uh, you know, to like being able to get their hands dirty, they like their arm charts, whatever. And then the, the, the latter, the, the last group that can just be like, well, we don't care. You know, we're very happy to click around, but it's like, it needs to meet us exactly where we're at because we're super lazy and I, I don't wanna, you know, you know, jump into another interface or anything else, right?

Which anyways is best practice. Like you should always meet developers where they at, the users in general, but, you know, so, um, and, and, and it is the same thing for executives. It's a very different thing that, you know, at the beginning you're asking for, you know, like half a million, 2 million or whatever, depending on the size of your org, when then you're asking for like, you know, 30 million because you're, you're scaling this up, you're, you know, now you're like, you're no longer 10 platform, 10 people platform team, or like a hundred people platform team, right?

So, and so it's like, how do I, how do I keep realigning my platform engineering initiative to their priorities as their priorities change as well, right? Because it might be that last year their priority was employee retention this year is, you know, my, you know, I need to cut my bottom line or increase my bottom line, right? Like, whatever, right?

So, so it's like it's, and again, and, and it's always this like constant cultural play of like, you know, as the organization evolves as this like complex organism, how, you know, does the platform evolve with it as it grows within it? Luca, let's step back for a second though, right? I, I was reading an article the other day and it was like a crazy number.

Like 70% of it initiatives are not successful. They don't necessarily fail and maybe end up in hell, right? But they're not, you know, if this is the bar for success, they don't make the bar, right?

Right. Hell maybe is down here. Is this, is there a similar thing in platform engineering adoption curves where maybe we don't quite get to hell, but maybe we're in purgatory, right?

For for a time where, you know, we didn't get to heaven per se, and we're not in hell, but we're somewhere in between. Yeah. Yeah.

A hundred percent. I think it, I think that's the na you know, I think that's the na the natural state of, of most, um, of most things in the enterprises, this kind of like stuck in the middle, right? Of like, you know, because it's just so hard.

It's, it's, you know, you have, you have, you know, at the beginning it's easy because maybe it's easy, right? Because you have this like, set of pioneers that are like driving change. They're really passionate about it, right?

And then it's like, okay, you know, and you see that's, that's why I think it's very, very important to think about it through the lens of a product. 'cause you see the same thing with any product that goes into any market, right? Where it's like, okay, you know, it, it requires, it's a different thing to get your first million revenue than, you know, the, your first a hundred million of revenue and then your billion of revenue after that.

And it's like, how do you evolve across all those things? And so, and, and it's so easy for, you know, and, and, and, and so how many unicorns do you get? Very few, right?

Um, and the reality is that most people, you know, end up on some, like tens of millions of revenue. And that's, that's kind of like where everybody's happy, right? And, and so I think that's also the thing is, is like, you know, do you, you also need to keep dr like have an intrinsic and extrinsic motivation to keep driving this forward where, you know, maybe the had of platform who's so passionate about your platform engineer initiative is content now with having onboarded like your first like 10, 20% of estate, 20% of teams, um, you know, out of like 10,000 developers, that's already like a huge success, you know, and, and, um, and kind of like happy days and they moved on to the new better paid role or the next company.

And, and, and so like it, and then there's no driving force. So I think this stuff is normal, happens all the time. Um, and this is also why I think, um, at the end of the day, the, the more successful platform engineer initiatives that I see are, you know, are, are prioritized across the, you know, throughout the, the, the Israeli chain of command all the way, especially to the, to the executives.

Um, because you know, when it is, like, it's something that really, yes, you need to consider developer adoption. Yes, you need to consider like all the different user preferences. But at the end of the day, I can tell you there are, and is where I think it also becomes a, not just like a cultural, interesting cultural conversation within the organization, but, but especially like also across like actual culture cultures.

Like we traditionally define them, right? So like across different countries and different regions in the world and so on, where, you know, I think we said this before, but they're clearly like platform initiatives and, you know, more top-down cultures are more successful, um, because they're just top down imposed. And, and that's it.

You know, that's what we do, period. Like, there's no conversation. It's not a discussion, it's just what we do because we're a regulated bank and, um, and the developer doesn't have much of a say.

Right? Um, now I'm not saying that that's, that's the ideal state, you know, because every organization is sort of different, although not as different as they think they are. You know, everybody thinks they're like a special snowflake.

Um, but, um, but at the end of the day, um, you know, having that, uh, if you can have that top down thing, that's where I think you can really drive and sort of like, you know, hit escape velocity and, and, and, and kind of like get to the entire company. Otherwise, it's just, you're gonna be relying on how good that particular leader is within the organization, um, and how motivated they stay throughout the, the hassle of it, right? And then it's just like a founder, like, is a founder happy with like a 10 million valuation or a hundred million valuation, or are they one that kinda like shoots for the stars, right?

So, um, it's, it's a little bit of that. It, it, I think even more complex because, you know, you just add an entire politics layer within these organizations that I, I think you don't have actually, if you think about like, you know, I mean, you've done a lot of startups. I'm doing my, my first one, but, but it's like the, the, um, the, you know, you, you actually have a cleaner discovery mechanism with the market, um, because I'm selling something.

If they like it, great. If they don't like it, I need to change, right? Like, um, whereas in, within an organization, it, you know, when you're building an internal product, the, the, the feedback is not that direct is not that instant.

And you have all this sort of like derailing, CIO says like, actually, we need to do AI now, right? So like, that's actually what happens. And so like, I think it's, it's even easier to, to, to get lost in all of this and, and just go like, look, we're, you know, we're 30, 40% of the, you get, get, you don't get clear signal, right?

Yeah. When, when you're selling to consumer or even a B2B, you as a start of your small organization, customers tell you, yes, no, maybe I don't like this. I like that when you are going internally, there's the politics and the, there's just no clear signal.

I'll, I'll leave it at that. Yeah. You know, but it's an important thing that you mention here.

And, and I've seen this over and over in enterprises through my career, call it the orphaned project or the orphaned, you know, movement where Right. You know, charismatic guy, high guy or gal high up the food chain, this is their baby, they're gonna push it through and then either they lose their mojo, right? They don't have that kinda juice to put it through, or they leave the company, or, you know, something else happens.

And now all of a sudden without that top down push, all the naysayers come out. You know, all the people who said, I always, I never liked that. I never wanted to do it.

They made me do it. I'm not on it. I'm not on board.

You know, you, you get that a lot. And you know, this was an interesting thing. You know, you got paralleling the DevOps journey.

This was a huge discussion in dev in DevOps, is can you do bottom up DevOps? Can the developers and ops people say, Hey, this is, this works for us, right? Yeah.

And, and the, you know, the long and short of it was, yeah, you can get some bottom up, but you always need air cover, right? If you are just gonna do one little team over here, you know, off on the side, yeah. You don't need necessarily a, an exec buy-in.

But if you are going to do it at an enterprise scale, try to do it organization wide without air cover. You know, I have a good friend Gary Groover, he, he, uh mm-hmm. He used to do, he used to run software for HP printer division and then for Macy's mm-hmm.

The retail company. Yeah. And he's written a few books on this right.

On why you need top down air covering Yes. You need, you need executive sponsorship for anything like this. Yes.

I mean, it's just, yeah. And all and all the way through, right? It, it's like, um, you know, it's like a lot of people, like when they talk about, you know, if you zoom out politics to the macro, to the macro level, right?

Where it's like, oh, you know, China has this like multi five year plans, right? And like, we're stuck, you know? And, and, and it's a little bit like that where it's like, yes.

You know, like I, you know, capitalism is a great discovery mechanism, right? But, um, but then it, it, you know, then you have this like mutations of it where it's like chronic capitalism and all these things, right? Where it's like politics gets me with politics and then it actually becomes a, a less good discovery mechanism or, you know, progression engine actually than if somebody just says what, what we do.

Right? Um, uh, you know, so it's, uh, yeah, I, I, I, I think about this, um, a lot 'cause it's, it's, it's very interesting and at the end of the day, you know, organizations are not democracies either. Like they're not, they're not meant to be, right?

There's like somebody that just decides and then they just like, and, and, and, and that side works. This is why, you know, when you have like nimble teams, it works to somebody that just takes a cult. It's what it is.

Peer, you know, and it might be right, they might be wrong, but at least you're moving, right? And then, you know, as you grow, you lose all of that, right? Yeah.

You know what they say, democracy is the most in the best of the worst form of government because it's so inefficient like that. And yeah. And there is times when, you know, a more structured, kinda, this is what we're going do past, does work the Navy, the other work is in the Navy.

Yeah. There is not. Anyway.

Hey Luca, we're about outta time, man. I wanna thank you for joining us today. Thank you.

We, we have the, uh, the URL for this article. You can go check it out. Uh, we'll be back on with some more people.

We're working here on the platform. We're very excited. And, uh, you are, you're headed in the van on the way.

Well, you're gonna Barcelona, then Milan, with a lot of stops in the way. Yes. W we'll catch you on the road for the next episode.

Will do. Thanks Alan. Thanks everybody.

Hey, you bet. Thank you. Thank you all for watching.

I hope you've enjoyed this. This is the platform engineering show. Do check it out, uh, on your favorite platform, uh, platform, not Plat platform platform, your favorite podcast platform, apple, Spotify, whatever.

You can get it on Text Drunk TV or any number of places online. Until next time, that is Alan Shimmel and Luca Gallente for Platform Engineering Show. We're out.