 Okay, so we're gonna get started next session from Kubernetes in the past or what's next. My name is Daniel. I'm more than happy to be here as a moderator this track chair and track host. And here's another Daniel Bryant from the Ambassador Lab, right? And then he is head of the DevRel. So I believe he got a lot of the bunch of interesting stuff to talk about today. So please welcome to Daniel. Thank you, Daniel. I appreciate the intro. I can hear myself loud and clear. This is good. Right, so welcome to from Kubernetes, to PaaS, to uh, what's next? Now I like to always do a TLDR to kick off my talk. So key takeaways, right? This one is really a spoiler alert. Now I've asked from Kubernetes to PaaS, platform as a service, to what's next? I'm gonna pitch its golden paths, aka paved roads, paved paths, paved platforms. The Mercedes-Benz folks queued up perfectly in the keynote this morning, right? They mentioned about golden paths, which I thought was great. The real questions I think we need to be asking is how much of this are you wanting to build yourself? And how should you assemble the control plane, particularly with developed developers in mind? And I'll break down to my previous development career because I think there's a tendency in the Kubernetes space, in the cloud native space to focus a lot on the ops side, which is great. I get it, but developers are really important. After we sort of looked at some of that developer focus, I am gonna say something that I'm, we're kind of hearing being called platform engineering is key to this going forward, right? Platform engineering, and I'll break down some of this as well. That's my spoiler alert, you know, you can go and get coffee now, right? But we'll dive into this in much more detail. Very briefly at Daniel Bryant UK on most of the interwebs, Twitter, LinkedIn, GitHub, all the good places, right? I am head of DevRelate Ambassador Labs. My background is Java developer, moved into solution architecture, ended ops, built a bunch of platforms on Maysos, on Kubernetes, made a bunch of mistakes, had a few successes, would love to share that today. And I love sharing my knowledge. I love writing, a few books to my name with some friends of mine, and I'm on InfoQ and the Newstack a lot as well. Let's begin our journey. So we're hearing shift left all the things, right? That's what I'm hearing a lot from community folks I'm chatting to, to customers. We're being told, particularly as developers, we need to shift left. It kind of makes sense, right? Even in my career, early on, like 2000s, we were taught to think about the illities early. Reliability, you know, the security, all these good things, the extensibility, right? But you need abstractions, APIs, and tooling to help this, right? The danger of you don't have these things, you're just shifting left, more responsibility on to developers. And the joke of Charity Majors says it perfectly, right? You can't call yourself a full stack engineer, unless you can do React all the way through to chip design. That's full stack, right? Bit of Terraform in the mix, bit of Bash there as well. It's not gonna work. Even the smartest of us in the room can't hold that many abstractions in our brain. Now, when I started my career, 2000s, kind of pre-DevOps, right? Dinosaur Age, the tooling, the abstractions was not there. I wasn't doing much security stuff because it was basically hardware stuff and a different team did that when I worked at the UK government as an example. Now, I think we've almost come full circle. You know, tool sprawl is pretty much an issue in the cloud native space. And it's mandatory at this point to put this meme up, right? We love poking fun at the Cloud Native Community Foundation map, right? I'm gonna say sorry, not sorry on that one because it is a sign of a healthy ecosystem. But as a developer, I'm confused when I see all these options. And KubeCon doesn't always make it easy, right? More tools come along, you know, but it really is that sign of that healthy foundation, the healthy ecosystem. That's why we're seeing all this flourishing of interesting ideas. Kubernetes is just a fantastic platform for platforms, right? Let's take a pause a minute and look at core requirements for an app development platform. Now, we'll build this slide up as we go along through the talk, but I think, and chat with me in afterwards at the booth if you think I'm wrong, but I think every developer needs to think about coding, shipping, running, living in my IDE. These days we separate deploy and release, right? There are two different things, deploy into Kubernetes, releasing maybe using Argo, Flux, something like that, right? And then running is all about observability, getting that feedback, that resilience. Continuous delivery does not stop when you deploy something, it only just begins, right? You get the feedback going on. You need to code as a developer, you need to ship, you need to run, but you need those abstractions because you can't do it all yourself. You need the abstractions for the platform team to kind of communicate with you. Now, Kubernetes, I've chatted many people over the last, I was pre-1.10, I was involved in Kubernetes, and I've chatted many folks and some folks literally look at Kubernetes and think it's a Paz. They think it's a Heroku, they think it's a Cloud Foundry, and they're disappointed when it's, it doesn't do all the code ship run things, right? But other folks look at Kubernetes and see it as that foundational platform as a component. And I was at DevOps UK last week doing a talk, and Josh Long, I'm sure if you're in the Java space, you know Josh Long, he types some codes faster on stage than I do normally, and he's just an epic kind of person, like lots of great jokes. But he did this great joke, I love Kubernetes. It's my favorite YAML database, right? And I looked, I tweeted, I got a bit of traction, I was like, well, Josh, that's great. But then I kind of got a bit more surreal, right? As in Emmanuel jumped in the mix, who's a database specialist, he works on Hibernate, an ORM, right? And he was like, yeah, I think this is kind of true, Kuba's an API database that happens to be in YAML. And then Brian Grant, co-creator of Kubernetes got involved, like, yeah, by design. Kubernetes is the API database, right? It's one of your core foundational pieces of your platform. But when you think about it this way, it kind of changes things up a little bit. Let's take a step now back to the future through my development career, my sort of ops career as well. I'm gonna brain dump this table, we'll walk through it together, don't worry. But what I want to do is the years go down through here, yeah, my career, roughly 20 years or so career. And I wanna overlay my cognitive load on this, the kind of the challenges I was having as a developer as I was going through this time period. And spoiler alert, stuff to the right means it was more painful, right? So I started in 2000s, Java monoliths, in-house TIN, as a developer I lived in my IDE. Oracle JDev, it was CVS at the time, it wasn't a thing back then, right? And I pushed to that and then the ops team deployed it and dealt with all security, they raised the ticket if there was a problem. Kind of happy days, I was learning, I had some amazing mentors, it was all good stuff, right? It got a bit more tricky, 2005 time, I was doing a lot of classic SOA at the time. And the promise was the workflows are standardized, the interoperability is there, XML all the things, right? And anyone who's lived through that era will recognize like the promise was there, the delivery was not quite there. I had to think more about shipping and running now as a developer, because my code wasn't just running on an app server, it was running in an enterprise service bus, it was running in a message queue, it was running in some other enterprise middleware. It was a lot trickier as I stepped through that in my career. I did a bunch of work on Ruby on Rails and also later Java on Clifandry. Classic paths, CF push at the command line, Heroku push, the stuff went wrong when it was running, we used to use New Relic quite a lot, right? New Relic dashboard popped up, I'd look at it, figure out what's going on, do some coding, test locally, push. Super, super easy, the developer experience, the UX of Heroku and the UX of New Relic had clearly been thought about as products. They worked really, really well. Step through a little bit now to where we're at now, right? So I went to work for a boutique consultancy called Open Credo in London in 2015 time, I think it was, and we know as consultants you only get brought in when stuff's going wrong anyway, that's part of the job, right? But I saw a lot of real challenges with customers, with clients, developers, ops, the whole gamut of just having too much to load into their mind as they adopted Cloud Native. They're like, right, so I write some stuff in Terraform, right, I'm going to be a bash to bootstrap that, then I'm going to have to docker, and I love containers, love docker, not trying to sort of say anything bad about all this stuff, but there's just so many layers, right? And most developers that I was interacting with, particularly at that time, just wanted to write code, just wanted to ship some value and go home. And I respected that, right? I love learning, playing with the new stuff, I'm sure many of you do, because that's why you're at this conference, right? But a good chunk of developers just want to write the code, ship it, run it, done. And adding these new layers made it more and more complicated. So what did I learn? Hopefully you picked out a few things as I went through. The real good platforms were treated as a product. Heroku, even some platforms that I worked on, we would really treat them as a product. I learned you can't have good developer experience without good user experience. And I mean proper user experience, not UI, because when I'm a backend engineer, right, when Twitter Bootstrap was released, I thought that was UX, but that's just like a web framework, right? So I'm talking about proper user experience. And focus on the workflows and the interop. So many times we had these promises on workflows and interop, we've not quite delivered as an industry, we get distracted sometimes. But I'll walk through these three things now and give you a bit more of a deeper dive into each one. So platform as a product. This is not new, right? The golden paths, like, we've heard Netflix talk about them. I know they've been working on them many years. I first bumped into it in Qcon, New York, 2017 timeframe. They talked about freedom and responsibility. You could build your app as you wanted to, you could ship it, you could run it, but you were on your own if you deviated from the paved path. They had an approved, sort of like, not necessarily approved, but they'd come together and agreed on, this is the command line tool set we use, we use Jenkins or Spinnaker to deploy, and this is the platform we're running on. You can step away from that, but it's on you to maintain it, right? They talked a lot about these, making it easy to do the right thing. That's the golden path. I also saw Spotify, of course, we went golden paths, they had like golden paths for ML services, golden paths for microservices, golden paths for their desktop app. Again, it's making it easy for the engineer to quickly spin up a project, a developer, get everything ready, have it all plugged into CI and CD, and just get coding and delivering value. I worked on a bunch of stuff in 2015 for Not on the High Street. That was my first proper platform as a product. We used MaceSauce at the time and containers, and we really thought about the developer experience and it paid dividends. I've checked, a GoSpot check, they did a great keynote. Dave's studio did a great keynote and we had him on the podcast a while back. If you look back a couple of years at KubeCon, Dave talks about how he thought about properly designing and treating the platform as a product. Now it's gotta be product-led, right? And Gairdly, if you don't follow him on Twitter, fantastic, and sorry, Nicky, I've learned a lot from Nicky over the years. Nicky worked at Financial Times, he worked at Skyscanner, and all these companies, right, these big, you know, not even like unicorns necessarily, Financial Times, Skyscanner, other companies, they are really talking about you need to invest in the platform as a product. Staff it appropriately, resource it appropriately, think of it as a product. And if you haven't bumped into team topologies yet, like this is my single, like biggest recommendation as a book from this conference, right? It talks about once you've got your platform as the product, how do you offer it as a service to your dev teams? And it talks about stream-aligned teams, sprint teams, scrum teams, that kind of thing, how they interact with the platform, best practices, all these kind of good things. It is a fantastic book. I'm lucky enough to know Matthew and Manuel quite well. I've learned a bunch from them over the years. This is a great book for thinking about how to put your platform as a product into service. My case study here is Ambassador Labs, right? We drink our own champagne, or as Yen said, I was chatting to him earlier, it's like eating your own dog food. There's another thing, right? But I like cats too much. I'm not going to eat dog food. So we drink our own champagne, drink our own water at Ambassador Labs. And blog posts you can check out. We use our own tools. We donated the CNCF emissary ingress, used to be Ambassador API Gateway. We donated telepresence to the CNCF. But we use these things day in, day out in our normal dev workflows for offering our SaaS product. Staffed appropriately. We have dedicated platform teams. We look at it as a product. We do interviews, retros, when things go wrong, when things go right as well. And we just, we really learn and think about that. This is a product as much as the products we sell to everyone else. Onboarding and training, so, so important, right? You can have the most amazing platform in the world, amazing product. You like think about all the good products you use, like the documentation's good, or the product's so intuitive, you don't need docs, right? But you've got to get people on boarded really, really effectively. And we really focus on that. We're not perfect, we're trying our best. So you can't have good developer experience without UX. So there is, you know, good UX is the next one. A good UX for platforms. Now, any designers in the room will totally be rolling their eyes again. These are classic books, right? But I read them a few years ago and they really helped me understand about building for specific people in mind. Because it's very tempting as platform builders, we're actually not building for ourselves. We're building for other folks, right? You really need to think about personas. Platform experts, the hipster engineer. I'm sorry, but that's pretty much all of you, right? If you come to a conference, you're pretty much a hipster, right? You're learning new stuff. But there is, as Gene Yang calls it in a fantastic blog post, the 99% developer. These are the folks I mentioned earlier on. These are, most of the work, 99% of the work is done by these folks, right? They're not at conferences. They're either too busy, can't convince their boss to come along, not so interested, whatever. But these folks are doing the real work, right? And designing for them is very different than designing for the hipsters us at KubeCon. User research is really, really key. So go out into your, like, if you're a platform engineer, if you're an ops person, building a Kubernetes platform, go out into your teams and ask what the biggest problem is. Honestly, as a consultant, we got brought into so many platform builds that were going wrong. I won't mention any names, but in London. And straight away, we learned to ask, have you chatted to the development teams? And nine times out of 10, folks like the ops team are like, why would I do that? I'm just copying Amazon. Or I know what developers want. But if you don't chat to your customers, the developers, how are you gonna solve their problems? How are you gonna build the thing for them? And do watch, use researchers, keep it watch users in their daily tasks. I've been shocked, right? I've done a lot of interviews on Zoom over the last few years with users using telepresence. And there's some very standard users of telepresence for fast feedback, hot reload, remote local to do debugging on Kubernetes. But then I've seen some folks use telepresence in ways I could never imagine, right? And because it's open source project, they've modified it in different ways. And I was horrified a few times, right? But I learned a bunch of stuff. I assumed people were using it as we intended, as the community intended, but people do their own thing. And I learned just as much from those situations as I did from where I saw the telepresence being used as we thought it would be. So do actually spend time with developers watching your platform, using your platform, sorry. Now I'm from my use case of this, I'm gonna shout out the Argo project. The folks haven't bumped into Argo, I mean, other CI CD or other CD platforms do exist, but Argo really put a lot of thought into the UX, right? There's a fantastic UI in Argo CD. I do a lot of training, a lot of teaching, and they see a lot of Argo rollouts. It's just fantastic, right? It's really been thought about from a user experience perspective. I've heard like the folks that into it who use Argo and contribute a lot, some of their developers just use the UI to understand what's going on in the cluster at a service, at a deployment, at a pod level, right? Because you imagine a Kube cut will get pods or whatever, it's not super intuitive for folks that don't like the CLI. That's much more intuitive, right? And for us, I love the CLI, I'm sure many of you do. That's fantastic, there's a constant refreshing CLI. Argo really thought about their target persona, developers versus ops, I think there. Workflow and interop. Now this is a really important sort of section if you like. Now I've learned a bunch from the Netflix folks, I'm very lucky with Qcon conference, I've checked many of them, and they talk about full cycle developers quite a lot. Now this is a developer that is empowered from idea to delivering value and getting that feedback. Now I mentioned earlier full stack, you're doing potentially all the things, right? Now full cycle developers, they're responsible all the way, but they have clear integration points, clear platform components available to them to make their job easy. This great blog post, the standout quote for me is the centralized platform teams act as force multipliers by turning their specialized knowledge of the workflows into reusable building blocks. I've seen this right in a couple of companies and it's fantastic, right? You get a nice handoff between, or a nice abstraction there between dev and ops. And there's still a lot of collaboration there, but you know sort of who's responsible for what. Equally awesome blog post by Galen Navarro talked about how to build a PaaS for 1500 engineers. And this is good focus on getting the balance between standardization and autonomy. And I saw this in a couple of projects I worked at, like you don't wanna have 10 plus database styles in your architecture if at all possible, right? You don't also don't wanna have a mandate of just one database style. You want some kind of compromise there probably, right? But getting that balance between the standardization and autonomy is really, really hard. Great thinking points there with these blog posts. My use case here is an intro of example between two CNCF projects, Emissary Ingress and Linker D. Myself and Jason got a, yeah, myself and Jason from Boyant and we were looking to put together a CNCF webinar. Atai joined us. Anyone's on Twitter. Atai's famous on Twitter. He very kindly offered to host us. And Jason and I were playing with these two CNCF projects, right? My Emissary Ingress I was working on is the North-South Gateway, Linker D, East-West Service Mesh. We were like, how am I going to mash these up to get an end-to-end TLS story, end-to-end transport encryption? Now, both use the Kubernetes resource model, right? So they use CRDs, controllers, all the best practices baked into Kubernetes. And we looked at, like, how they'd interrupt and actually turned out to be a one-line bit of config. And I can tell you, I'm not picking on any other service meshes, but when we've integrated Emissary Ingress with other service meshes, there's a few more lines of config involved, shall I say, right? And this is really interesting. It was literally that line of code to get up and running, right? And actually, my colleague Flynn and Jason are presenting tomorrow on a very similar talk if you want to learn more about how to use these two CNCF projects to get your cloud-native comms going on. But that's the example, because Emissary Ingress just routes the services in Kubernetes, Linker D augments services. It just worked. Was when you start doing too much magic in the mix, different abstraction level, layers, too many IP tables in the mix, right? It all gets a bit complicated. This is one example I thought was really nice of that interrupt being thought about. We both, you know, both projects designed it separately, but we both came to the same conclusion, which I thought was kind of cool. So I think there's some kind of need for a platform control plane emerging, right? You know, as we've gone through, you know, we're pretty much agreeing, like, even the big sort of category sections on the CNCF landscape. We've got, you know, our Dev environment, continuous deployment, Kubernetes run time observability, and they map pretty much the code to ship and to run when I think about these things, right? As we're building up this slide. But what's up here? This is the important thing, right? The abstractions, the APIs, particularly how, you know, how do we engage with this platform, right? Fantastic quote by Kelsey. Like any Kubernetes talk, you've got to do a Kelsey-like quote, right? Because he's on point so much at the time. And when I first read this tweet, it kind of stung a little bit because I was building platforms at the time, and I kind of thought my constraints were unique or my requirements were unique, right? And Kelsey, like, I'm convinced that the majority of people managing infrastructure just want to pass platform as a service. The only requirement, it has to be built by them. And that's a little subtle dig, right? And I'm like, yeah, I see you, Kelsey. Like, yeah, you're kind of right there. That's kind of hitting me a little bit. But this is 2017, right? Two years later, Kelsey came and said the delta between Kubernetes and a developer-friendly pass is where the next layer of value is and where things tend to get opinionated. A requirement for reliable end-to-end workflows. This, I think, is the golden path, golden paths, right? Reliable end-to-end workflows, but it's the delta between Kubernetes and what we need to get stuff done. And again, Kelsey's so on point with these things. Naming's hard. I'm not saying this is a perfect name, but I think this is where we're going through as an industry now, right? We're going for these golden paths. So building the golden paths. I had it, like, I sort of put together this thread. I've been reading about platform engineering. I was like, how do we, what do we call it? Is it DevOps? Is it SRE? Like, how do we build these golden paths? I put this tweet out there. I assembled a bunch of research, right? As I was learning, my team and I. And it just blew up. Like, that is my most famous tweet, I think, right? I was like, wow, people like this stuff. Great conversations. The reply is just, as you can see now, full of companies of all sizes replying going, oh, I'm doing that. I didn't know it was called platform engineering. Oh, I'm doing that. And I just found this fascinating, right? And I started doing more and more on the podcast. Chatting to people are Alan Barr, Bo Daly, Crystal Hirshhorn, Alan's from Veterans United Home Loans, a US government organization. Bo's from Zipcar, and then Crystal's from Sneak, real range of companies, right? And they were just sharing with me all the things they'd learned along their journey about building their platform. And most of them were on Kubernetes. Interestingly with Alan, he was on Kubernetes, but the requirement was they couldn't use the cloud. So we actually built a platform with Kubernetes, not in the cloud, which I thought was super interesting as well. I want to give you now that the quick highlights of the podcast, and you can check out the podcast later on, but these will give some thinking points about that slide I put up with the platform control plane. I see anecdotally, right, but successful orgs are investing in golden paths and the platform teams. They're staffing this stuff, this project, sorry, accordingly. The successful orgs are starting small and then getting big. It's developer-led, right? Bottom-up motion, as we call it. Again, the projects I went in when they were failing, very much top-down. The CTO, the CEO had mandated a platform, bought a platform sometimes, or the ops team thought they knew best and were mandating top-down. Honestly, didn't work. The ones which did sort of, we managed to recover, they were a middle ground and we got the developers involved and that's when we actually rescued the platform. But I think if you're starting, go bottom-up. Listen to your engineers, developers, what are they using, what do they need? There's also a bit of internal dev rel, right? So my career has gone from engineer to dev rel, a bit of marketing involved, right? Because I realized when I was doing entrepreneurial stuff, I was always selling. Whether I was an architect, whether I was a programmer, I was always selling something and I thought, ah, I want to learn about this marketing thing. And you have to communicate the long-term vision to developers to get them to buy in. Why should I learn this thing you're creating? Oh, another command line tool. Oh, another platform you're rolling out, right? You've got to sell the long-term vision. You really got to recognize the socio-technical aspect of the system. We all love our tech, myself included, right? I was like docker, docker, docker when it came out. I love docker, right? It's a fantastic bit of tech. Love Kubernetes, love Istia, all the things, right? But you must not forget the human aspect. We've got to adopt this, and I learned this from Alan Barr, but adjusting a hospitality focus to get folks on board. A good UI paints 1,000 CLIs. I've learned this more from my career. I was a Linux user, loved the CLI, migrated eventually to Mac. Now I do recognize, particularly in bigger organizations, UIs can really open doors. Some developers do not feel comfortable with the CLI, don't want to learn the CLI. I respect that, right? They're just doing their job. If we can give them tools to help them do their job, they're going to use them. I do like the CLI, though, right? The key thing with developers, we need to help them eliminate toil. Sometimes when you say, oh, how do we fix this? Or a bit more Kubernetes? How do we fix that? Or a bit more Istio? How do we fix that a bit more? And the poor developers are like, my God, this is all these technologies coming on top. We should kind of hide that from folks, right? They just want to get their job done. So automate and create to remove friction. That's the key thinking point for these platforms. And the standards, for me, I'm seeing some standards emerge. API is like open telemetry is a good example in the API space, right? If you adopt open telemetry, you can swap out your metrics back end as you scale. It's a good investment. CNC effort and great work in this space. Love some GitOps, not for everyone, but I really like that standard is the best practice how to deliver software on Kubernetes and the Kubernetes resource model. If you're building tools, look at what's out there in Kubernetes land. Look at operators, look at kubectl plugins. Don't fight against the grain. I saw this all throughout my career where folks would fight against the grain of where a platform was going. Adopt the Kubernetes resource model. You get the biggest interop there for your developers. Now, I might be dating myself with the next meme a little bit, but you've hopefully spotted, as I'm going through here and throughout the presentation, I'm talking a lot about developers, yeah? Hardcore old-school meme. It's because I've been coming to Kupon. I was literally the first one that ran in London I helped out at. I've come into Kupon for so long and I'm seeing the pivot towards developers, but it's been very much an ops conference, I think, up until recently. But we've really got to think about our target users, our target customers. You may be developers, that's great. Work with the ops folks to help them understand where you're coming from. But this focus on developers is really, really important. We are building a platform, shiny technology. The goal is to help developers code, ship, and run. So we come back to this slide, right? That we need for the platform control plane. Now, I'm actually thinking it's really a developer control plane. That's the most important thing, right? We can do our platform thing down here, but the developer control plane is where we need to spend some time. It's not easy, right? It's not easy, but we are seeing a lot of great stuff. And I think the CNCF ecosystem is the foundation. I poked fun a little bit at the start, but I genuinely love the CNCF. That's a fantastic collection of folks, of technologies. And what I think is, we're gonna see a lot of work in this space, right? We're seeing things like backstage, right, as a custom UI. We're seeing lots of interaction, the integrations in the API space. Many vendors emerging, which is always a good side. Ambassador Labs, Humanitech, other folks, right? There's lots of interesting stuff going on here, but you'll notice it's the UI, it's the integration points, and it touches in to the actual tooling for the code, the ship, and the run. This is where I think if you're getting into platform engineering, getting into ops, spend some time investing in this space. This is where we're struggling at the moment, you know? I would recommend having a look at this space. Cool. So wrapping up, I'm pretty much on to time there, I think. So from Kubernetes to past golden paths, right? When creating a golden path, how much should you build yourself and how should you assemble the control plane for effective use by developers are really the key questions, I think, asking. Should be asking. Treat your platform as a product. Realize you can't have good developer experience without good user experience and focus on the workflows and the tooling interop, right? And this has got to be developer led, the developer led control plane. I wouldn't mandate top down. These are my key takeaways, right? And just a final tweet I'll leave you with. I was at, whoop, whoop, I almost read it. I was at DockerCon last week. Fantastic, Docker doing amazing work at the moment. Docker extensions rolling out, lots of great stuff. But the really great conversation for me was between Scott Johnson, CEO there, and Kelsey Hightower, mentioned before, and Kelsey, my drop moment, right? He was like, you don't want a 10x developer. We're talking about 10x developers. What you want is someone that can come in and make 10 other developers more productive. And I was like, ooh, that, yeah, that kind of hit, right? And that is the role of a platform engineer. It's not actually another developer necessarily, right? It's the role of a platform engineer making 10 of the folks picking number more productive. Because we were all sort of seeing the 10x engineer is a bit toxic, right? You don't really want that going on. But I thought this was a really, really good point. I'll leave you with that to think with. Do feel free to connect with me, right? I'm on Twitter, on LinkedIn, and hit me up on the Ambassador Lab Slack. We've got a booth. We are not a pizza vendor. This morning, everyone's come up to me saying we've got too many big graphics of pizzas. We're not a pizza vendor. We do help Cuban FD Solutions. Come and chat to me and the team there. There's a bunch of resources I put up for you there. Our Golden Path Pizza Party, platform engineering guide. We are, of course, hiring. So come and chat to me afterwards if you're interested. But I'll say at that point, thank you for your time and take some questions. So if you have any question, we have a mic. And just please hand it off. And then we are more than happy to address. All right? Thanks. Seeing as you've done some consultancy work and you've come into companies to try and help them fix this, you didn't obviously just have to convince engineers about what to do. You also had to convince management, right? Yeah. What strategies do you have for convincing maybe non-tech savvy managers about why Golden Paths are important? Great question. And that's a talk in itself, I think. And definitely keep chatting a bit more later. But my key advice is find out what that person you're trying to influence, what matters to them. Sometimes it's very much not what we think as engineers. Some companies, you're rewarded for growing your organization. You're rewarded for growing your fiefdom, shall we call it, right? And therefore if I say, I'm going to help you with dev productivity, they're like, that's not good for me, right? I lose my engineers or I can't get my hiring wreck for next year. I'm not going to get promoted. Bad luck. You have to really, like, it's the five-wise thing, right? Really dive into what's your motivation? Why, why, why, why? And then you usually get the actual motivation. Once you've got that, then it's start trying to adapt to that motivation. And so I'm on camera, gotta be careful what I say, guys. But it's a bit tricky. Sometimes the folks that hire you in to fix stuff are actually the problem, right? They think it's just developers need to go faster, ops need to produce a different platform, and actually it's how you're leading the organization. It's how you're defining the incentives, how you're setting the mission, the strategy, right? So it's a can of worms. It's a great question. The Team Topology's book does go into it some more as well. It's a fantastic book, that book. Thank you.