Hello, I'm Rob Hirschfeld CEO and co founder of RackN in your host for the cloud 2030 podcast. In this episode, we talk about platform teams and the challenge of building effective, productive platform teams, how to form them, what their mission should be, what type of tools and dangers they have, in putting them together, we really start by questioning if there are such things as platform teams and what roles they have and how they can go awry in modern organizations. But at the end, we recognize that they do and can provide a very important role. And in the conversation, we will discuss and you will learn the right ways to form a platform.
I can't decide if it's a hot buzzword at topic if it's a necessary thing I was on the platform teams bandwagon a year ago, and then it felt like nobody wanted to talk about it. And now it feels like people want to talk about again. So
can you define friction? Since since I can guess what?
Well, there's there is an element of confusion because some people consider platform teams, teams that are focused on building and maintaining platforms like Kubernetes seat. So in some people's definition of platform teams, it would be a separation between the ops team, the dev teams, and then there's a team that's running Kubernetes for them. Which is not the way I typically think of it. But although I've heard that as a definition that what I hear platform teams is a re not exactly reconstitution. But it's it's this idea of systems administration, DevOps, infrastructure teams, turning into a more service, Bureau oriented focus, and then becoming a you know, your ops and automation teams for an organization. And so it's I like it's it from the 80s.
Yeah, I was gonna say that sounds like what I used to do, it was an IT manager.
Well, I think part of what we're trying to do, and what I've seen, because I've been reading about this is, is platform teams, unlike it in the 80s, or 90s, doesn't get to become a choke point. And they can't control things. So part of what the platform teams are doing is they're trying to create consistency and governance and repeatability and offload infrastructure ops from their dev teams. Without becoming, you know, central it again, I think that's what people are using platform teams describe. So sometimes I see Center of Excellence mentioned, and it's a center of practice or sent out of excellence. Sometimes they're trying to do tools and consolidate things, companies, it's all over the map, which is why it's
so I think a friend of mine worked at Target for a while I think Target has something like that, which has turned into the the old problem of the old it and that they own the platform, what all the applications go on and whatnot, they phoned the hardware, up to certain levels of infrastructures code. And the problem my friend had at Target is that they, they own the opinionated platform, so you had to do the opinionated version of stuff, which is fine. But they still weren't responsive, like a new team. They weren't particularly agile. And they decided they weren't going to rewrite OpenStack because I could do it.
Yeah, yeah, we had we had a team and Verizon who did that they the the leader John Constantine is now working for IBM.
One of the trend lines I see and I hear in our customers is they are in a lot of cases trying to build a centralized platform team or a centralized platform product or self service portal. And I've definitely seen some of our customers doing exactly that and building stage like they call it Gaia or Pangea or Uber or whatever, right? There's always some where they think They're going to create the super
portal? Well, I can I can address that because Verizon is struggling with that right now, right? Because, you know, we don't write software, particularly, I mean, we have certain tools that we create, but they usually wrappers around other tools. And we're struggling with, you know, customers want these portals. And like the big buzzy customer that we're getting, you know, our sales team is always comparing and saying, Well, hey, you know, our customers are saying Kaitos fan fabulous. And they have this great portal, and you can do all this nasty stuff. If you go in to Cato. Yep. And so, you know, we're trying to say, okay, what can we build that? Does better than Cato, because we know what Cato does. So kind of smoke and mirrors. That, that allows us to try, you know, uh, give the customers the tools to be able to, you know, make changes to their networks without like, totally screwing things up.
You just, I think you just hit the key. Right, the horses left the barn on self service. So whatever people are doing, it has to enable teams to have cell service, you can't overcome her. Right. And yet, the I think the balance is you have to provide governance so that you can go. And you also have to reduce toil, because there's a lot of teams out there that are TerraForm, to me is the classic classic one. They're writing their own TerraForm scripts and being like, Whew, that was easy until it all of a sudden wasn't. And now I need somebody who has real expertise here. Yeah, and that's right. Part of the platform teams, I think it's been missing in market is that you actually have to have a recognition that there's expertise in the ops side.
Absolutely. There's expertise in the outside. I mean, we have, you know, a couple 100 Or a couple 1000 people who, that's what they do. They're experts. Right? I guess you want to say something?
I don't know. Yeah. I'm thinking that again, like, I'm thinking very much along the same lines of care, Rob, like with but with a with a TerraForm. equivalency is that. I think platform teams are a necessity of scale. But startups don't necessarily need a platform team. And that's also why you I think you'll see that divide in discussion is that there's there's two clear demographics, one that doesn't need a platform team, and one that finds themselves suddenly needing a platform. And the, the main, the main thing I got here, going back to analogy with TerraForm, is that the platform team provides opinion that abstraction that is tailored to their to their dev teams. So the the, in essence, the platform team is a solution architect, type of team in that they did take us the the requirements from from their internal clients so that they match them to what they can provide long term solutions, and provide the minimum viable solution for that. So it's a it's a matter of reducing complexity for the for their, their internal clients, while maintaining reasonable flexibility.
So you just opened up a ton of questions for me. Does does the platform team need to run it? Like, does the platform team responsible for running the infrastructure you're describing something that's almost the Center of Excellence? It's like, here's the tools, here's what we think. And then are they did they get out of the way or do they they keep operational control?
That's a question of governance. I like it could go either way, depending on the the requirements of the company. Like I myself consider great but
I was gonna say different comp I mean, you know, Verizon is a very, very operationally oriented company, for obvious reasons.
Yeah. Like it, it depends on whether you need. So what like what like what level of auditability, you need, for example, like if everything needs to be bedded by a, by a committee, then of course, the platform team is going to be contributed one, maintaining the infrastructure, because don't want developers going, going and making changes. If you're in a more flexible environment where everything's more, it was allowed to be more self serve, certainly, you're going to gravitate towards that. But ultimately, the platform team is it doesn't have to maintain that infrastructure. It can if they want, but they maintain the knowledge there. They're the equivalent of the of the traveling sages that go from town to town, sharing what they've learned.
But and I think that that's, to me, that's the Center of Excellence model, which makes a ton of sense, right? You're no team is going to want something forced on them, they you need to have somebody's who's bringing value in with their with their recommended ways. Doesn't hurt to have a corporate behind you that says, you know, I think you should follow this advice. And if if you don't agree, then you're it's you're going to have to explain why you don't want to do it. But with fin ops and stuff like that, I I think that it goes more than following their advice that this is sort of where I'm, I'm trying to reason out what the right balance is with this, because you telling people they have to use tools or platforms is is not very good. But at the same time, your sage advice isn't useful if you have to learn somebody's bespoke choices when you show up at the team. So there's an element of, hey, we've got this platform team, they're really good at ops, they really understand TerraForm or Ansible, or networking or DNS or certificates, or, you know, right, you actually want to be able to hire somebody who can do that secrets management. But if every team they walk into is doing whatever they want it to do, without any standard, then the sage is not very safe, like
every team is doing what they want to do on hand, there is no governance to tie them together, then you don't need a platform team that like that, that my favorite team allows you to homogenize your, your tasks. If you if you're if your teams have no intention of homogenizing, then there's no point.
So can they I mean, the there's a resistance to homogenizing. And then there's I think there's an anti heterogeneity and accidental heterogeneity, which is where I think most I think most teams right now are not at war with each other intentionally. Like, you know, creating a non homogeneous homogeneous system, they're doing it because they don't know. And that's right, where you're going with the sage, listen, it's like, you know what, there's two choices here. If you had chosen B instead of a, then we'd have three teams doing the instead of right, and that that actually I think is a hugely valuable thing for companies especially.
And this is also why I'm I described it as providing opinionated solutions, as opposed to prescriptive solutions. It's basically like you want to use Kubernetes. Great, here is a solution for that. Go ahead and use it if if you follow these steps, we do 90% of the work for you. We're not going to tell you that you have to do it, because there might be some cases where there's an exception, in which case we will try to tailor the solution to fit that case. But again, it's it's opinionated,
and Huawei, what as a huge company was trying to do that. The last group I was in was a group that was not part of any of the product silos. And what its task was was to find the best and breed and the best practices and whatnot, and document them and roll out those documents and other collateral to the rest of the company. So the rest of the company could take advantage of it and use the same processes. Now how successful they were not all that successful. But if anyone was willing to actually step up and use that stuff, they had a pretty decent roadmap. So I don't know if they've gotten more successful. The issue is that they had lots of empire builders and Huawei very militaristic empire builders in Huawei.
Well, Huawei had some other problems too.
But, but they actually did have a department that specifically was out there, to find the best and braids and document them and provide them as a roadmap to the rest of the company.
I mean, it's also important to consider that whatever solution a platform team comes up with, it doesn't need to be set in stone. And I think that's where a lot of companies falter. And they'll say, like, Okay, we have this no solution. Everybody switch over to that, no, it's not gonna work like that. I mean, even if you don't completely switch to the new solution, like even if it's just adopt some some of the principles, you're still very far ahead of where you were performed. So you
challenge that is now you have two solutions that you have to care and feed for.
They just don't care feed for your solution, they only care and feed for the best of breed solutions.
But a lot of a lot of times when people build this stuff, they don't. They, they assume they're going to force homogeneity in things, which is impossible. And so they don't account for the fact that even if you have, even if you can fork coerce people to using the same platform, their use cases can be different enough. Yeah, that, that the platform team ends up maintaining variations within the system that that, ultimately, to Martez point create multiple versions.
Right. And the problem with a lot of these platform teams is you need the feedback loops. You need to be able to identify when somebody, one of the groups comes up with some something that works better, listen to them, and feed it back to everybody else. And that's where a lot of it falls down, the feedback loop doesn't exist. Once you get that centralized team.
They have strong disincentives to tolerate the the n plus one. This is this is the challenge, right? If you're building a platform team, you better be ready for the fact that the thing that you picked for your platform team will may not be the long term solution, right? You have to actually be working to sustain and optimize and obsolete some of the stuff you're doing.
Absolutely. And that's also why I think that like going back to Windows his comment about well having to support more than one solution. I don't think that's necessarily bad. It should be a sliding scale. One solution may be like maybe becoming more popular, another one that may be getting sunset. But it also means that you don't have all of your all of your eggs in one basket. Right?
In theory, I love that, in practicality, for any enterprises are facing it right now. More so from a skill standpoint, enterprise organizations are everybody's Kubernetes Kubernetes containerization. But you still got a quote unquote, Legacy environment that is composed of bare metal composed of VMware OpenStack Nutanix. And it's, in many cases, a wildly different skill set. So now do I have to keep a full staff for my visualization and my bare metal? And now try and hire and chase the startups to try and compete for top tier Kubernetes talent in eight tickets becoming untenable for many large organizations?
To Great point. Wouldn't the platform team allow them to consolidate some of that knowledge? So instead of having to have each to me, this is this to me, it's my fault, right? Wouldn't the platform teams, you'd hire one great Kubernetes person and then they would hopefully be able to train and service a whole bunch of all your other Kubernetes work? I guess it could get frustrating for them. If you're
I think the problem is, I think we in many cases think it's a very easy jump to just go from so I'll take VMware as an example. All of their events are talking about Kubernetes and tanzu. All of the all of the traditional virtual ever Structure admins, just you should just learn tanzu And Kubernetes. Why aren't you running Kubernetes fast enough. And it's it's a different paradigm and different really interest in many cases from those that are in Kubernetes. And so we start to get into while they're both in operations as we would typically think of it as, but it's as almost as wildly different as you're not going to ask a database administrator to to handle your firewalls or your networks. And I think we think it's so interrelated, that I think we just think people should naturally be able to make that transition.
But another issue that I think with platform teams, is I don't know how much your backgrounds are, I have both an operational and a development background. And you know, people who are operations people have just very different mindsets. They're not developers, and they just don't think that way. You know, they use tools. Don't Don't get me wrong, but they don't consider, you know, and they write tools too. But what they don't they don't consider writing tools to be development, they just think, Oh, I'm just trying to make my life easier by by automating some of my boring tasks,
right? The mindsets very different and most more of the operational filter system, folks. So they have a systems perspective, which is also hard to translate across. And they're not going to understand the developers particularly much because the developers are just so laser focused. And they don't care about anything, but their stuff, and how it works. So yeah, it's, there's that aspect of
platforms, as far as this, sorry, Rocky, go ahead.
Well, one of the things I was gonna say about, you're hiring the Kubernetes, tech expert, and then training up everybody is that if you only hire one Kubernetes expert, that person will never have time to train because always be in firefighting mode.
Well, and that gets back to my earlier comment, the Kubernetes expert now is going to be a developer. We went into this in OpenStack. In the early days of OpenStack. Rob, you probably remember this the early OpenStack. People were all bunch of developers. That's true. Oh, yeah. And there were no operations people I remember being in San Francisco and sitting in a, you know, weird, you know, somebody was going on and on about, you know, how great this new OpenStack thing was, and I got up and said, I'm an operations person, how the hell are you going to support this thing?
So, no, that's there's an element in what you're all talking about is where my question was gonna go is like, because we went through this with Site Reliability Engineering, also. And it's funny, Klaus was talking about startups and startups definitely have SRE teams in some way. And maybe SRE teams or prototype platform teams, were prototype platform teams, but you know, are we just talking about companies saying, I need an you know, I need better Operations Control? The developers don't certainly don't want to do it. And I, you know, I need my ops pros to have authority to demonstrate that knowledge.
Yeah. Well, when, when net DevOps started becoming popular, and people start talking about it, I can't tell you how many of my old buddies who were, you know, sis admins back in the 1990s, all of a sudden found they were very popular. Because so sad man is from that period, which I was one of them. You got to do everything, because you know, there was nobody else out there, do it. And so, you know, so those are the people that have the skills now. Now, most of them are retired. But you know, developers still have cysts that system sysadmin skills, they're not interested in sysadmin skills,
although they keep trying to make the developers get sysadmin skills. And so that's part of the issue, you get this weird kinda hack together stuff, because they learn just enough to write a piece of code that does stuff they don't want to do.
Well, that's that's one of the interesting to me fallacies on Infrastructure as Code is that developers hear about infrastructures code, they think they're going to develop the infrastructure stuff, put it enough polyphony crepe Lumi or TerraForm scripts and you know, that's, that's the end of the day when, you know, it's helpful, but I don't think it's actually operational.
No, it's not.
It's part of the operational aspect. But it's not the full journey. But it's basically like it's basically one operations.
Yeah. And this goes back to what Beth was saying about OpenStack. I pushed through for years at take a developer to Work program for OpenStack, where you would invite some developer from OpenStack, to come and spend a day with your operations team. Yeah. And the developers weren't interested in it. The operators love the idea the developers weren't interested.
Right? It's it's the feedback loop is very slow and hard. And this is part of the challenge with ops work is that the time the effort it takes to create good process? And this is one of my challenges, platform teams. I mean, just for the record, I think companies should be investing heavily in platform teams, if they can find the people in the leadership and executive buy in to do it. Because I think it would help them in process and governance tremendously. Right? Well, there's a huge butt, which is, you know, you, if it slows down development teams, they're gonna get end run, if it's not providing, right, it's like, there's I don't know how to help that team become successful.
Let me add some perspective rises perspective, because we I mean, so we're heavily operational. And we do have on our operations side of the house, I mean, we don't write code, right. So we don't have to deal with the development as much. But I'm on the operations side of the house, we have a whole team that does nothing but process improvements related to operational aspects. And that includes some writing of code, some, some, you know, just looking at the processes and making sure that they are efficient and hold us. And the people that they use are generally senior operational people who've been in the trenches in the NOC for, you know, X number of years, and then they get promoted into this team. And they do these kinds of operational improvement types of things. We don't hire people from outside to do any of this stuff. Because you need intimate knowledge of all those OSs and BSS systems to even think that you can do it. For our environments. Yeah. It's extremely difficult environments. And in many ways, I think those are actually platform teams, we don't call them that, I think
they are Martez, you were gonna make a comment. I don't want to take the thunder fun, you
know, it was just a along the lines of the same classic challenges that the in particularly the enterprise is dealing with are going to continue to crop up as it relates to the operation side, the manner in which it's going to be viewed, plus also the facts of being viewed or constantly as a cost center, which I'm strongly opposed to that term. And that wording, both from a classification standpoint, but also human aspect of getting to the point of in essence, when you really boil it down to basically saying, people, these people are costing the company money. Not so much actually providing value to the organization. But in the case where there's always going to be more developers or more in consumers, then the operations team is always going to be behind. And effectively, I think more and more is going to be run run around so
to speak. Could some of this be addressed by having, like, repeatable patterns and practice? Like? Because one of the things that strikes me is what you're saying, is those teams if they're not, if they're if everybody has to make it up? And there's no like, yeah, okay, we know how to do this. You should do it this way. Hey, then you're the scenario you're describing is where we are. But what if we started having standardized process? Or at least cuz like, like,
this practices, like I tell, well, more.
The consumer, the consumer has to be willing to adapt adopt it. So I literally thought about this the other day, is typically an enterprise organizations or a lot of organizations, they'll get something that's off the shelf. And so you know, this doesn't quite fit the way in which I want to do it. And so then they do something custom and we end up in this, everybody's doing their own thing. Everybody's a snowflake versus looking at Link by various managed services and things in which you don't have the control. Are you willing to just accept what comes out of the box and say, You know what? We're good with this.
I think that's where people are development teams. This is this, to me is part of the, the, because actually a nice segue because right now, development teams have a lot of power. They don't want to mess with learning how to operate and process it. And so they've outsourced a lot of things to services, but not consistently to the same services or in a consistent way. And now companies are like, whoa, wait a second, I'm relying on this thing to, you know, run. And I don't have billing control, I don't have operational control. I don't have network, I don't have like, there's all these issues. And so they're trying to figure out how to fix that operational challenge. So it sort of feels to me, but they need to come back to, you know, we're not going to have you got here with like VMware and Oracle, no, no, VMware, but like databases, like, there's teams that run databases, because they know how to run databases, nobody's nobody's like, Oh, I'm gonna figure all this stuff out myself. They say, alright, here, we have a team of people who are pros at it, they're really important service systems, we're going to let them do it.
Yeah. But it took a long time to get there. I mean, I think, I think there was two things related to databases that got us there. First of all, you know, big, big honkin, databases are, are very costly to move, put it to gravity. So there's a lot of data gravity, you know, I'll use an example from Verizon, Verizon has a database that probably dates and thank you for the mid 1980s that we use, that's our customer database, and it has a lot of information about our customers. And its base, you know, and, and there's a ton of stuff that's around it, but the core database is never going to get moved, because it would cost millions of dollars to move it for no good. Benefit, right. But it's, but we're also stuck with sort of the 1980s way of thinking about things and, and, you know, we have a bunch of like weird three letter codes, because at the time, you know, we couldn't fit more data in to the record. And so there's all sorts of weird nuances about it. But, but nobody's talking about moving. On the other hand, I worked for another company that had some guy who built a database based on FoxPro. Back in the, I don't know, must have been in the mid 90s. Sometime, maybe it was earlier than that. And, you know, it was it was sort of one guy did it and in, you know, the company is sort of stuck with this incredibly awful thing. And it's not a big database, it's got, you know, maybe a couple 1000 records in it, but you know, they, they don't want to take the time or effort to like, move it, because it's not millions of dollars. But,
and a lot of the space program is is like that, in that at the time these, especially databases, but all sorts of information bases got created. They were stuck with whatever was available at the time. And if you didn't, if Oracle wasn't agile enough, there are lots of little PC databases. So the legacy and the space program, you know, databases from 3040 years ago, and they're still there, and they have to run. But this platform they want you guys are making me think about is that there are what Rob was saying ways to standardize and whatnot. And poor standard stuff that people standardize on within the company, you can consider that legacy. What you need is your platform team to be able to maintain the legacy, but also work with teams that are working outside of the like, you need some Greenfield advisors for the Greenfield, folks.
This is why the platform team can't be the office of No, it has to be resilient.
I wouldn't. It has to be an Agile team, one of which actually maintains the legacy stuff, but also advises best of breed for the Greenfield.
I would be hesitant to call to use the legacy label. I would I would think that established will be a better choice. Legacy has implication that that it's on the way out, which might not be the case. Yeah, I
going anywhere. No, I
can see. I mean, let's take Kubernetes as an example, though, I could see companies, a company coming back doesn't even have to be a big company say, alright, we're using Kubernetes, in six or seven different ways. You know, it's not benefiting anybody for us to have so much variation around Kubernetes. It's, it's a, it needs to be a centralized skill set. So let's build this, take the platform team, let's have them, you know, establish a Kubernetes Center of Excellence and then start saying, Alright, let's look at these six different ways were using Kubernetes. And then standardize them so that we can support all six of them. It sounds
like it's not necessarily that python three platform team will come and look at you and say, Oh, you're using VMs, using containers. Everybody pick up on we're shifting to coordinates. And it's not that it's that you find yourself having five teams that don't talk to each other, each of them have independently implemented their coordinate solution. And now you, you're starting to look at the big picture and say, we could standardize this because there's sufficient demand.
This, this is this is the chicken. There's, there's, there's not this is not a chicken or the egg problem. What we're saying I think, is that the platform team follows the pattern that the organization is using, it doesn't impose the pattern,
exactly. If it's gonna work wider solutions architects, like they need to do Requirements Specification first. If they don't do that, then the default.
question I have is, is that sustainable? In a scenario where you've got, yes, we're going Kubernetes. But Kubernetes for us, means some rancher sometimes do some OpenShift, and some public cloud managed Kubernetes platform to figure out how to normalize that across all of those.
But this is no more test. That's no different than, you know, as companies are moving their stuff to the cloud. I mean, I remember working with a client who, who their IT team hired us to kind of review their cloud use. And we came back and said, you know, you have 41 instances of Salesforce, do you know that? And they were like, No, we have no clue.
Yet my concern is, Rick, we're simply inserting new buzzwords for the same problems that we're going to continue to run into. Yep, that
that was where my starting point. That's where I was starting from with this platform, sort of this platform? I don't think so. I actually think that there's that there is a consolidation in it coming not from the, like, we're gonna force everything to consolidate. But I think we're learning how to use this stuff. And and we're going to cut down the number of patterns. I think from that perspective, platform teams are
practical. It's an evolutionary change, not a revolutionary change. In a sense, you can look at the platform team has something that has been done anyway, throughout the history of the companies, it just now we've put a label on it. And we formalize the responsibilities.
Yeah,
yes. But I think what that's causing us as an industry do is to chase that team title. And whereas previously, folks organically grew into that, I think now more often than not, there's the desire to shortcut right to that, where I may not have the years of development experience or the years of operations experience. And now instead of evolving to that, after 1015 20 years of experience, I'm jumping right into that, after two years of practical experience that might not have a lot of depth or breadth.
Yes, although that is an endemic problem with industry anyway, like, yeah, no matter what, whether you're talking about platform teams, or you're talking about agile or object oriented programming it anytime there's this new buzzword that there's going to be a bandwagon following it.
You have the opposite. And then you have the the contract, you know, the headhunters going, Oh, well, you need you know, you need this specific version of Linux, otherwise, we're not even going to talk to an ex. Are you kidding? Linux is Linux, you know? Oh, but you need gen two.
The challenge is what we keep we keep jumping back To the platform teams need to have a degree of expertise and flexibility that is rare, more rarefied talent.
Right? Ideally, your platform team would be constructed out of will construct that internally all of your existing subject matter experts, right? Because they already know what the teams need and what. And then you might complement it with new with new hires and build on top of it. But But you wouldn't hire externally for a platform team. At least you shouldn't hire external Yep.
That's how you end up with the problem of them platform human causing a pattern rather than pulling, like imposing versus exposing.
Oh, that's why we do that. I mean, we don't hire I mean, those people that do the operational excellence are never from outside. The people that are the tier three solutions. Architects are never from outside. You can't.
Yeah, the issue is, is that right now, like Kubernetes expertise is in really high demand. And most of these companies that have their, their excellence teams don't have the Kubernetes. And it takes a long time to learn it up. But these companies are creating platform teams, because the expertise is rare. So they don't have the luxury of having multiple teams with that expertise.
This is particularly interesting, because it is relatively young technology. Compared to things like with witness it, it makes sense to seek external expertise if you don't have it internally. Because you likely don't don't have an established coroner's platform that you're looking to, to optimize, you're growing into coordinators. And you're in you're saying like, Okay, I need expertise to help me with the transition. So that is not the same as saying us, for example. Let's say you have Nagios configured for your monitoring solution. And it's working fine. Do you want to build a platform team for your monitoring? You wouldn't hire someone who? Who doesn't know that? Yes, but only those images? And then who comes to tells you Well, everybody? Abandon ship with badges? Let's go to Prometheus. It might be fee. It might be technologically better, but it's not necessarily the right solution.
And on that we are over time. So like, like where we got I have more questions. So maybe I'll put this back on the agenda and deeper company get more. This is already a deep conversation. It's cool. Thank you all. Done. This is good. Thank you. Good thank
you. Wow, really powerful conversation. Because all of us have our battle scars from the past around IT teams that over corrected became the Department of No. Whereas modern platform teams to be effective, really our center of excellence, but more really helping organizations to reduce toil, improve governance, and have a much more consistent it experience, which I would expect everybody in the company should care about. If this conversation is interesting, we will go back to platform teams. And we have amazing conversations like this all the time. Please join us at the 2030 dot cloud, and have your voice in the conversation to that thank you for listening to the cloud 2030 podcast. It is sponsored by rockin where we are 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 laying out your thoughts and how you see the future unfolding. All part of building A better infrastructure operations community thank you
