How to Avoid Platform Engineering Anti-Patterns ![rw-book-cover](https://img.youtube.com/vi/2uvcglflDi8/maxresdefault.jpg) Hi everyone. Thank you for joining us today on our panel discussion on how to avoid platform engineering anti-atterns. This is a lead dev panel discussion created in partnership with Postman. We have 45 minutes today after which myself and our lovely panelists will join you all in the lead dev slack group. So make sure you join there and ask and answer and talk to us in the panel Q&A channel. That's where we'll go to hang out with you after this live webinar. We'll also answer a couple questions live on air. So, please submit your questions through the Q&A function on Zoom and we'll get to them as we have um you know our our panel discussion today. Um again that channel for lead dev is panel slash nope panel-q- a. Um all right so let's get started with some introductions. My name is Tiffany Jaka and I'll be joining uh you all today as moderator. I am a senior engineering manager at Yahoo. And we also have our panelists who will each introduce themselves and give a short summary of who they are and why they're excited on the pan to be on the panel today. Let's start with Aerys. >> Hi, I'm Aris Viel. Um I'm staff engineer here at Postman. I've been here about a year and a half now. Um previous to this uh I worked at a bunch of big places um Oracle and Amazon AWS and in all those places we have platform teams and they're all they all work very differently. I'm excited to hear uh and learn from uh the panelists today about the the other side of platform engineering. I can jump in and go next. Hey everyone, I'm Molly. I'm a site reliability engineer at Netflix. I've been at Netflix for about four and a half years and prior to that I was at various startups. I am particularly passionate about understanding human factors uh when it comes to software and often when I review incidents to extract lessons learned I'm going to be studying engineers and how they interact with central platform tools and then learning how we can actually improve that tooling to make it a safer environment for all engineers. So I'm really excited to be a part of today's discussion and share kind of that S sur vantage point. >> Hi, I'm Chris Plank. Uh I work for Nat West Bank in the UK. Uh I'm a platform as a product product owner uh lead architect for an initiative that's kind of looking at how we use modern platform engineering practices across the bank to provide managed hosting platforms and services to our internal customers. I've been building platforms for over 30 years. Um, I'm also uh one of the community leaders, community group leaders for the CNCF platform engineering community group. So, I talk a lot about platform engineering. >> Awesome. Well, yes, our panelists today will talk a lot about their experiences and their knowledge and their wisdom and it'll be an insightful conversation on all things platform engineering efforts. I know a lot of them start with good intentions to help other teams and users um you know gain consistency, repeatable patterns, reduce cognitive load and sometimes between all of the enterprise scale and evolution um platforms can be hard to use and easy to bypass and quietly resented. So this group of uh panelists will be talking about that today. I'd love to center the conversation around anti-atterns since that is the webinar title. Um I'd love to hear from each of you like when platform when platforms start doing the opposite of what they're meant to do, what can that look like in practice and sort of in your day-to-day as well. >> Who wants to go first? Hey, Chris. >> I I'll I'll bite you on this one. Um, so I came back to the bank probably 2023. Uh, I'd left about 2016, just when the bank was starting its kind of public cloud journey. And in that time when I came back, the first thing I found was that they they went down the patterns approach, you know, the golden path route that a lot of people talk about in platform engineering. Uh, and I came back and found hundreds of patterns. We've talked about this publicly before, right? I think I've said back then it was about 135 or more patterns. Found an awful lot of those patterns were actually duplicates. You know, they had originally started with one pattern, one way of doing things, standardizing. That's the golden path. And then for whatever reason, applications weren't changing. And so they started to have -123. You end up having lots of patterns that are doing roughly the same thing but with slight subtle changes. And that customization becomes the enemy, right? And I think what what you find is those golden paths that that fast path through governance, that fast approach to getting things done. It maybe started off like that, but over time they get stuffed full of everyone's requirements, processes, hoops and hurdles that you've got to go through and eventually they're no longer the fast path. And then you start getting these other little variants popping in. Right? So there's there's some antiatterns there. You know, don't stuff your your golden paths with all these processes from all these different teams. Don't create kind of subtle sub patterns for all the different applications. Try and find a way that you can actually work on that and make them not as rigid, you know, open enough to change, but still do that in a managed way or you'll end up with lots and lots of different things that you've got to maintain. And that's really difficult, right? We all know how hard that can be. >> I love Chris, one of the things you mentioned is like these little variances. And in my experience, one of the things I've seen is when teams work with a platform, a lot of times they'll accept little bits of friction and they will just work around that friction. Yeah. But it's it's so little for them that they won't say anything. But if you go and all of a sudden you talk to, you know, four, five, six different teams and you realize all of these teams are doing the same workound and now you've got a friction that's been multiplied and amplified, right? So, I think it's it's super important and something I work um diligently to do is to tell teams, hey, when you're doing little workarounds and frictions, share those, communicate those back to the platform teams because other folks might be experiencing them and if you don't speak up, then that snowballs effects, you know, into something where the platform is being used in in a way it's it's not intended. So, I love that call out of things start with just little variances. um and they get worse >> and one or two can just keep on getting compounded, right? You keep on adding them up and suddenly if you're trying to maintain that thing, you can end up being spending more time maintaining those variances than the actual product that you actually really care about, right? So, lots of different techniques can help with that. I mean, Molly, you mentioned, you know, getting them to talk. That's probably one of the greatest things you can do. a center practice, community practice, special interest group, whatever it is. If you can get these people together and talking about why they need the variances and actually work through it, in a lot of cases, you can actually get rid of the need for that because you can get them to come to the conclusion that they do need to standardize. Uh yeah I I I want to add uh a view from the side of um the customer of the platform from product engineering uh what I've seen uh when platforms are not working so well is that velocity will drop you'll see that um you'll hear about okay this project is blocked because we're waiting on permissions we're not following the golden path we have some slight you know deviation for our use case we're looking for approvals or we have CI issues And if you hear these often enough and becomes a pattern, then then you know you have you have to do something because the platform isn't making things e easier in in fact it's making things harder. >> Right. Right. And finding those common things that people are saying this is a problem. Those are actually what we want to go after as platform engineers anyway. Right. We want to solve those problems for them in a kind of managed platform way rather than them having to do it themselves. Yeah. And as product engineers, we should be reporting these instead of just quietly working around them as Molly was saying. >> Yes. Thanks panelists for sharing um some thoughts around when workarounds can become a sign of failure versus a sign of flexibility. Um y'all chatted a little bit about cognitive load as well and some of the antiatterns. So that's really helpful. Uh, I I want to remind the p the attendees here that if you all have any follow-up questions, just ask them in the Q&A, we'll we'll pick them up as we continue on the conversation. I'd love to pivot a little bit more now that we've named some of the anti-atterns and what they can look like in practice. And I'd love to chat a little bit more about what happens to platforms when things start to scale. Um, so I I have two questions around this. Uh let's let's first talk about um platforms as approval gates at scale. Platforms can often become approval gates instead of enablers. How does that happen and how do leaders accidentally enforce that? >> I can kick us off with this one. Um, I think especially with uh with platforms, you're always looking to strive to find a balance between, I like to say, their guard rails. You want guardrails on your platform that encourage folks to do the right thing, but at the same time also allow that flexibility. So when you need to do the workaround, maybe you're in a an incident or something, you've got that emergency situation, you want to have that flexibility to be able to do what you need to do. And that's it is a hard um balance to find, but I I think there's there's definitely a a balance there. I think one of the things um that I have seen is sometimes platforms go too much towards too many guard rails and then they become inflexible and then that's when you know as Chris mentioned those workarounds then those workarounds start to show up and so I think keeping a pulse on are people doing these workarounds and using that as a signal determine okay where are we falling in this balance of guard rails versus inflexibility I love how you mentioned scale because scale is the thing that seems to be my word and my trigger in in the platform engineering community. I talk about scale. You know, I work for a a very old bank, one of the top four in the UK and we're massive, right? We've got over uh I think it's over 66,000 staff now uh in the organization. I think of India alone. I just did a quick kind of AI chat there to see how what it comes up with as a number rather than logging in and checking it. It says it's over 17,000 just in our engineering division alone. I mean Molly, how how many engineers are in uh Netflix as an example? Right. >> Few thousand couple thousand. >> Yeah. >> Right. So our scale and our challenge is very different and the complexity is very different as well as an established regulated organization. You know, we've got lots of systems, lots of processes that you've got to follow for regulation purposes. That means you've got lots of divisions and lots of teams in the organization all trying to do things all for their part of the organization that contributes to the whole. And so the size and scale of dealing with platform engineering is is very very difficult and and the challenges are very different from an org that maybe has one platform and does things one ways. We've got many platforms used by hundreds of thousands of people and so yes it's a very very different model and you know that the whole question about cognitive load and you mentioned that earlier as well I think when the cloud came along public cloud we started to see the requirement for a lot of these teams to stand up their own platform engineering teams we gave them their tools we gave them knowledge we gave them terform libraries and things like that we gave them processes to follow that gave them AWS accounts and they went off and did wonderful work, right? But that cognitive load just grew and grew and grew. There's a great graph in um Max Kobeer's platform uh architecture for plat platform is it platform architecture I think it's called I've got it sitting over there. It's a brilliant book and a good draft that just shows over the rise of the 90s into the kind of 2000s and into the 201s. It really hits a peak that we're asking people who previously were maybe Java developers to suddenly know about Terraform, AWS, Google, Azure, um all these other things on top of what they need to know for their subject matter expert. Right? And we've seen the we've seen a lot of the the kind of shift to trying either to shift things more things left. I don't really like that. That's just adding more cognitive load. So some people then start talking about shift it down onto the platform team. In a small org, you probably got one platform team. In a big org, you might have dozens or hundreds of platform teams. And so you're you're you end these anti patterns start coming in about well does one team do that? Do you spread that across all the teams? You know, it's it's quite a different challenge. We would say it's at scale. >> Yeah. Um, that's a really good point and something that's a really good segue into one of the Q&A questions that we got here, which is around how platform engineers and platforms can evolve as engineering orgs grow. So, I'd love uh to answer this one live. Um, someone had had asked how do you see a platform engineer fitting into an organization as an individual in embedded in teams or some kind of combination? I can take this one. So I think as you mentioned as as an or as a company grows how they're going to do platform engineering maybe they never did it and now they start to do it. I think one of the keys is, you know, when you're big enough, you you want that central platform team, someone who can deeply understand um and help build that platform, but they always have to be connected to the product teams that are going to be using the platform. And so I don't think you need that kind of embedded model. Um that that is hard to scale. You know, when we're talking about scale and growing, that can be very hard when you have individuals that are off on all these teams. But I I do think there is a lot of benefit for those central platform engineers to go out and spend time with the product teams. I will say I'm part of an SRE team and we do a embedded like a a fluid embedded model where we go we spend time with teams we start to understand their challenges and then we bring that information back to to our centralized tooling. And so I think there's a huge benefit um for platform engineers to stay close to the the folks that are going to be using using their tooling and understanding them. >> Totally. >> I really like that uh Molly. Um yeah, that makes a lot of sense. Uh one thing I I feel like uh platform engineers uh should gain empathy for uh what uh uh product engineers are experiencing and being doing this uh type of work with them makes a lot of sense. And one other alternative is to dog food uh the the platform, right? Build things on top of the platform so you you feel what other engineers are feeling and then you can see the problems where it need needs more attention. We call that drinking your own champagne in Europe rather than dog food. But give me >> I support that more than dog food. >> It's nicer, right? Um I I mean in our or we we have the scale challenge, right? And we've got lots of different platform teams. So the model that we've started moving to and I talk a lot about is having those existing teams contribute uh their components, right? They're component platforms really and then we create products that are composite of many different teams components. Um we've started calling it multiplayer mode. If you think in the past platform teams I'll just choose a random platform open shift. You probably had an open shift team that did everything to do with that platform, right? They built it, they ran it, they supported it, they did updates, they had to release new features. They had to work with the customer on all customer requirements. They did everything. And if that was just one of your platforms and you had 100 teams, 100 different teams pretty much doing similar things, right? Similar processes and things that they to do. So in the model, we've kind of decomposed that. We get those teams to do the engineering, whether it's an onboarding to their platform or stand up an instance of their platform. There's many different types of products, right? But they comp they create their component other teams have got components and we've got reusable components and then we build a product out of that that we expose to the customers and so you've got more scale more people able to help you right it's one of the ways of reducing the cognitive load on one team and scaling it out you get everyone to contribute and the best thing about that model is these other business unit teams I think you used a different term for them Molly I think you used product teams uh because that's your internal customers, right? But you can actually get them to inner source contribute to that model as well. You know, if there's something that they've been doing in their area, they've been self-managing, self-engineering that, they can actually turn that into part of the managed product as well. So, you get a good way that different whether it's product engineering teams, whether it's consumers can actually use inner sourcing to contribute quite a lot to that model. I love it. I love the insight on how you can approach building platforms in an iterative man manner. We did get a um question in the Slack channel and I see it in the Q&A and I want to get to it. I will get to everybody's questions as well. I I think there's a particular order here that we can go and approach them, but there was a question on how to um and you all can read it. It's the last one. How do we avoid the big bang migration anti-atterns for for more mature apps or mature organizations? Specifically, are there strategies that allow teams to adopt certain platform capabilities alakart versus doing like a full painful replatforming or make this big push to platform engineering. >> Don't don't run multi-tenant platforms, right? We've we've had a lot of conversations about that uh in in the community, you know, and um we've heard from some of the hyperscalers as well where they've seen people who run like Kubernetes platforms. Originally, people might have started with one Kubernetes platform, they spent all their time making a multi-tenant and they end up having kind of this situation where all eggs are in one basket and what happens if one, you know, you got one egg that breaks, right? It goes over all of them. It's kind of the noisy noisy neighbor type approach, right? that you you end up having a problem and it affects everyone. So they've they've talked before about you know seeing people move away from that one big platform to lots of smaller platforms and managing the creation of the platforms the onboarding to those but it it it separates out your kind of blast radius into much smaller chunks and then you think about how you manage that as a product and how you start updating things as a fleet. So instead of managing like snowflakes or one particular thing, you've now got into this kind of fleet managed approach where you can manage your product and the roll out of those features to the entire fleet in a controlled way. Um it's an evolving field. I'll be honest, we're tipping our toes in that is that's our our uh new model. We still have lots of traditional multi-tenant platforms where we do on boarding type products onto those. Um and I think you'll always get that mix, right? I mean some some products like a paz platform by their nature they're meant to be a multi-tenant platform right and you just have techniques of how you've got multiple nodes and multiple instances and dual deployments and cut across and all these good techniques but yeah there's no one one sizefits-all in our industry right that's what keeps us in the job for uh 30 years >> awesome uh and Maybe uh Molly Eris, you you all have more to share on this one, but um there was a question about how much platform product comes from platform engineers versus technical product managers or more the inerial side. That's a great question. I you know I can't help but think that um if your you know your TPMS or your your product managers um are doing their jobs I would I would assume that they are very in tune with the needs of the customers of the platform um and and being able to help set that direction alongside um engineer So at at Netflix, you know, we're we have a very collaborative environment where you've got engineers, you've got product managers, program managers, everyone's really working together to understand the customer needs for a platform and then create that ideal vision and and path forward. So I think it's it's in the ideal world it's a collaboration of all those folks coming together using their different vantage points um using that as input to then you know come up with um the ideal uh evolution for for a platform. >> Thank you. Um, we also had uh we have a lingering question here um around evaluating platforms. Eris, uh maybe you have some more to add to this one, but are there obvious symptoms, signals uh that can maybe be a big part of noticing that maybe something's wrong with a platform or something's maybe not quite meeting expectations? uh I if I see that it's a lot of check boxes and gates um rather than guidelines of that explain the why of why we do things a certain way that kind of worries me because then uh if people don't know why something is important they'll just want to check the box as easily as possible rather than trying to do the right thing. So if uh if if I see that this is the kind of platform like that doesn't explain then I I I I get worried. >> That's a good point and is a good segue into um moving on from scale and talking more about governance and access and how do we onboard folks onto platforms. Uh we had a question in the Q&A here around um you know you all suggestions are there ways to make platform uh to make a platform open to experimentation and discovery without it becoming um open or prone to shadow IT. >> So I think I can kind of segue into this one. I wanted to build on um what Aris is saying about GES and stuff. I think one of the biggest kind of anti-atterns that I have seen on a platform is when it tries to abstract away too much. So you try to take as much of that load off of those product those those customers using it. But in my experience what I've seen is that you create then too much of a black box. So those customers the service owners using the platform can no longer reason about their systems what it's doing. And I have seen that, you know, cause so many problems um in and issues for teams. So I think being able to give that insight into what the platform is doing and kind of building on to that last question about like how do you kind of encourage that experimentation if you have a platform that yes it can manage a lot for the users but at the same time gives detailed visibility into okay this is what I'm doing these are the steps I'm taking that's going to allow users to understand what's going on and that's going to I think open up those doors and and make it a more inviting experience to maybe they want to try something new, maybe they want to experiment, maybe they want to make a suggestion. So, I think really keeping that platform visibility even as you're abstracting things away, always making sure those abstractions are visible um and understandable to the the users of the platform. that depending on how big you are and the number of platforms you've got, you don't you don't necessarily need to mandate the platform. You can let the market decide kind of the approach you're going to take. You know, we we're again because we've been at this a long time. We've got lots of different platforms. We've kind of got three types of consumer. We have the teams that want to do self-manage and self-engineer predominantly in public cloud. They can do what they they really want to do inside guide rails, right? And the guide rails are regulatory. They're safety security, but they're not, you know, they're not kind of constraining their creativity, right? They can literally pick up some terform and do what they like. Not every team's got that money. Not every team's got the the skills and the people to do that, right? So, you also have teams that are really good at just orchestrating things via requests, what we used to call ticket ops, right? where some other team provides those things for them or some other platform does it. You know, like give me two VMs, give me a load balancer, here's the firewall rules for that and I need a database, right? And that's predominantly the pattern. Their creativity isn't so much in writing Terraform or or doing that stuff. It's more in the patterns and the way they wire things together. And then you've got this new world, kind of the self-service world that a lot of us talk about now in platform engineering where we're kind of trying to reimagine all of that stuff, trying to look at what's most used and say, "Hang on a second. We've got x amount of groups doing this. Let's turn that into a managed product. We've got x amount of people doing that. Let's turn that into a managed product. And let's encourage them to use that so they can do other innovative innovative stuff. So don't stop them having the access to do the innovation but look at what they're doing cherrypick the best things and then make those common products for them right that you can then you essentially you've reduced that cognitive load you've reduced the time to delivery and the cost and the need for lots of people to look at that separately and you've centralized it in some way right um that's where I think we certainly talk about you know getting the benefits from doing that uh so you've got the kind of the best of all these worlds right people can still have the access to do what they need to do in their own time scales, but it takes time to take things and turn them into products. So, it gives you a good balance, I think. And the market can decide, right? They can choose whether they want to use that or just do it themselves. >> I love how you've divided your customers and you you you deal with them in different ways. What you know, what's appropriate like how much level of management you want to provide for them at SC. Yeah, it's it's it's it's not a like a division. It's more a recognition that you've got these these different types of consumers. I think that's I think that's that's life, right? Not everyone wants things done by someone. They they they've got the real creative that they want to go off and do it themselves. And we should foster that, right? We should encourage that. Um because those sparks of creativity, you know, never know what's going to be there that might suddenly be a game changer, right? Where did the I come from, right? Was it just Azimov thinking about that and writing about that way back when? Right. That was a spark of creativity. >> Yes. And I appreciate the insight into like how you all um help guide you know like what standards, what concerns should belong to certain things in the platform, what goes around the platform. Um, we had a question that was very in in the lines of what Chris you were sharing. Um, it comes from an anonymous attendee. Do you still centrally orchestrate the deployment of infrastructure and hand it off to like an ops subplatform team or do you have a central platform kind of building blocks team that's more focused on like building your platform in each of your areas? So, I guess you all can chime in. >> Yeah, I'm sure that's someone in my or right. I probably know who it is the way they've asked that question. Um, yes, we have we have a my team platforms of products is is a central team in in technology. Um, where we're trying to build those those hosting platforms and we act as that product management type capability. We create the products and we release the products. We work with the customers on their requirements. We then work on the other side with enablement teams and with uh component teams to create their components and we bring all that together and release it and then after that uh the you know the the an S sur and we call them C function would then support those running instances and the component teams would then continue with the engineering of new features big updates but you know the the actual day-to-day updates would get done by kind of the S sur team uh they would deal with kind customer problems, right? And it would also then have that feedback loop with the customers as well that if these incidents happen, they can then go in and then they can fix those, but they can contribute back to the code as well. And the ultimate aim that I've talked about a lot in the community is, you know, it's probably a 5year journey to get to a real true inner sourcing model. You have to have some products there first that people can touch, they can consume, they can build up trust on those before they start contributing to those. And so it t it actually takes longer than you think to get business units to contribute. Um at the moment most of our uh uh early adoption customers and consumers, they're they're providing requirements and feedback and testing and ideas. um not so much contributing the code yet. I think that that code contribution for them will come later. We have all the other platform engineering teams contributing code and doing it for their components, but I've yet to see that kind of ignition with the business units starting to lean in. Um we do have some not saying it doesn't happen. You know, we've got a business unit that went off, took uh a lot of Terraform, standardized that, made it available for other business units to consume, and we've pulled elements of that back into the central thing. That's what I was talking about where, you know, you can see these good things that people have done creatively, and you can pull that into a product, right? It takes time to do that, to take it from one area and bring it into another because you have different opinions about how things are done when it's a a managed product versus when it's just for kind of one vertical, right? You've got lots of other things to consider. I'm sure that was Alistister that asked that question. Find out tomorrow. Molly, Eris, anything to share on on your side? >> I think Chris uh really covered it. I I will say um I think one of the things you do have to be careful of when you're kind of building a platform and then maybe handing off operations um is keeping those two functions as close as possible. Um so that the people who are operating it aren't necessarily the only ones feeling the pain. And so I think that's something to to watch out for. And if you are kind of handing off those operations um and then you know the building like making sure those functions are very close um so you've got those great feedback loops in order to improve. Greg Gregor hope covers that very well in his book about platform engineering you know in his architecture elevator series he uses analogy of a kind of car manufacturer. If you ever read his books, it's always about cars, right? Um, and it's kind of, you know, car manufacturers create the car, they sell the car, people then use the car, but they never take it back to the manufacturer to get it fixed. You take it to a dealership or an independent garage. And you've got that kind of recall feedback, right? If there's something commonly wrong, it does go back to engineering, you know, back to the factory, right? To make factory level changes. But once it's out there in the in the wild really, it's, you know, it's it's another division that's dealing with the the updates and and and dealing with the consumers, right? It's a really really powerful analogy. I think that kind of talks about the model that we were trying to implement. That's how they've scaled and that's how you scale these things out. Um, so it's yeah, it's definitely a pattern. It's not the only pattern, right? But it's it's it's a I find it a good pattern. >> Yeah. Thank you. Um, I know we talked a lot about patterns and themes. Um, I'd love to double down on some of the conversations that we've had around pioneering and creativity. Um, you know, with a lot more AI in the mix in our uh, organizations and enterprises and in our platforms, I'd love to hear from you all like what role do AI agents play in the platforms that you're working on and how should leaders really be thinking about this? I can get us started. Um I think because of AI today, right, we want we have all these agents that can do stuff for us. We should be building in a way that um not only humans can use our tools but also a agents can use our tools. So that means um we have to get our interfaces right. We have to get our APIs very clear, our documentation very clear. um so that not only humans but people can use their agents to automate things and uh it's just very powerful time we are in today. On top of that like documentation should used to be the the most difficult thing to keep updated right but now we have AI it can do it for us and we should should take advantage of that. I think with AI you've got kind of another user base if you will right so you've got your human who are interacting with platform and now as RS mentioned you have a you know agents interacting with your platform and sometimes doing so quite autonomously and so again when you go back to thinking about or you know architecting a safe platform you want to make sure those guardrails those gates are kind of in place. So depending on what kind of user is coming into your platform, um they're set up to succeed and and not gonna flip the wrong switch that you didn't want them to to flip. And so I think when you think AI, that's like agents are another, you know, new user base that we've got to consider with platforms. >> I I think 2026 is the year that platform engineering teams start leaning into AI. you know, in in certainly in big orgs um for the last few years, the teams that have been innovating and delving into AI have predominantly been um you know, they've been a dedicated team, right? They've been mandated, you're the AI experts for the orgs. You're going to go off and investigate this. You're going to come up with AI gateways. You're going to come up with standards. You're going to come up with patterns, products, all that sort of stuff. I mean, I think I'm right in saying our Kora AI uh agent has a little chatbot. Um it's probably 10 years old now and it's evolved over time, right? That was probably our first foray in AI. We've got an entire division that looks after AI, but my platform stuff doesn't yet do much in the AI space. We've got business units hugely successful, right? The one the different types I talked about. Um we're not yet using it in the platform space. And we've talked about this, we actually talked yesterday in the community about some of this stuff. Um, we put it up as one of the optional questions for people to have a chat about and they weren't too interested in AI. There's still other priorities in the platform engineering space that people want to focus on. It's not part of the CNCF platform maturity model, for example, that came out two years ago, and AI isn't isn't mentioned in it in any of the levels, right? It's one of the one of the many updates we want to start working on on that model this year. But we do we do feel that it's that's kind of the direction that a lot of again I've got to watch what I say. I'm talking about hosting platforms. There will be teams who do AI platforms already probably in those business units right that look after AI that are doing this. But in general when we've talked about in the community it's not it's not the thing that people are doing yet like you know using MCPs to uh build platforms right but that we think that's inevitable. We've seen some really powerful stuff over the last 6 months. Go back to CubeCon. Some fantastic demos from people of what they've been doing. And I think that's now seeping into all the team's plans for 2026. I'm normally called John Connor, you know, because I'm just totally anti-AII and I'm an old guy, right? Uh 80s reference there for anyone who doesn't know the film. And um I'm starting to embrace AI in a big way and start using it and get involved and you know start thinking about how we apply that to platforms. So if the John Connor of the world's doing that then you know guaranteed the younger people are going to be doing that for sure. >> Yeah. It's one of the things that we're doing as well at Yahoo. We have like two new backend we call them squads but they're really like teams. Um and they kind of go hand inand right like the plat with the platform play. We have one that's centrally like for AI and one that's also centrally for all things content. U which is pretty interesting. Um but yeah, some of the things that we've seen here uh as well. >> I I've got one of my customers who's in in that organization that's that's you know responsible for AI now leaning in and co-creating with us and and talking about kind of the the AI platform enablement. They've done stuff. Now, how do we bring that into we provide that as a managed platform, right? Which is really exciting. It's a completely new language for a lot of us platform people, you know, that are coming from a kind of CISAM type background. And then you look and see some of the chat prompts, it's all like, you know, oh, it's a command line. That's our world. >> Yeah. >> Good, good, good. I know we are almost at time. I'd love to just ask I'd like to just sneak in one more thing and then we'll do closing statements. Um uh and if we didn't get to any Q&A questions, we we will in the Slack channel. Um I'd love to just chat more about getting back on track. So, you know, we we've everybody on the panel here has shared so many um wonderful wisdom and insights, but like let's say you're in a position where you have a platform that's already lost trust. What are what are some ways that you can win engineers back or your users back uh to that platform? maybe share a story or two on on how you know you could like a true comeback story. >> I um I'm happy to share on this one. I think uh you know I' I've had an experience in my past where working with a platform team that had lost a lot of trust um from its users and they actually decided they were going to lean into more visibility when the plat platform broke. So they started leaning into incidents and incidents in the open. So every time something broke within the platform, they made an incident for it and out in the open they were triaging, they were working on it and people started seeing that and they're like, "Wow, they they really care." So that started building trust. Um, then this team was able to use all of this data in order to advocate for a six-month feature freeze so that they could just focus on the platform and stability. And in that time, they completely 180ied and turned the platform around. So, I think when you have a platform that's struggling, um, one, work out in the open with your stakeholders. Um, that's going to build trust. They're going to see. Don't fail in private. Fail out in the open. So then people, ah, okay, they're on it. And as soon as people see you're on it, it's amazing. They just, they back off because they're like, we're going to let them do their work. And then use the data. Use the data for the the toil it's causing um, in order to advocate to your leaders uh, when you need space um, and take that space to do it. Otherwise, you're just going to be in reactive mode for the rest of the life of the platform. and and that's no one as an engineer wants to be in purely reactive mode. So I think um yeah that's a a tidbit from my experience I wanted to share. >> Uh I know we have a few minutes left. Um so in closing I'd love for uh all the panelists to to share some closing statements. Um primarily to fill out this sentence. A successful platform is one that and we can start with Chris. >> Oh, I was just writing that down there. Okay. Um, I'll follow on from what we're saying about losing trust. I think takes a long time. Sorry. A successful platform is one which uh works with the uh consumers of that platform and builds that trust. Um, takes a long time to build trust. Uh, it takes only a second to lose it. Right. So just just following on from what we were discussing there, you know, you really need to uh work with your consumers, work hard, uh co-create, be responsive, um keep some capacity in reserve for when they come along with requirements, and you know, they need things in a hurry, and you're you're able to demonstrate that you're responsive. I think that responsiveness in a platform team breaks all of those kind of um visions that people have about platform teams not being responsive, right? If you can actually take a requirement and turn it around really quickly, that's what's going to build the trust with the consumers, right? >> I love that. I can go next. So a successful platform is one that is safe to operate because it makes it easy for engineers to do the right thing. So again like investing in those UIs, making destructive actions, they've got warnings, they got big red buttons, you know, you're doing something that is, you know, is is going to alter things. So I think safe platforms um that make engineers jobs easier. Uh and on on my side, a successful platform is one that just fades into the background. It just works except for the big big banners that that Molly said that hey, you're doing something scary. Um but if it just works, that's that's the successful platform. >> Wonderful. Well, thank you so much for the good insights in today's panel. We will now be heading over to the lead dev Slack in the panel dash Q-N- A channel. So, please sign us there. Our wonderful panelists will answer the remaining Q&A questions that we didn't quite get to today. And if you know there's anything that they said that really inspired you, put it in the channel. We'd love to see it. Uh thank you all so much for joining and we hope to see you next time. Thanks all. >> Awesome. Punch. Uh-huh., How to Avoid Platform Engineering Anti-Patterns, YouTube, 01km5zgyhj0hsqrn86hvma4ttb.