PurePerformance - Platform Engineering Maturity Model: Reaching 10x Efficiency with Abby Bangser

Episode Date: June 17, 2024

"Meet your users where they are!" - For Platform Engineering Teams that means understanding the current way your engineers work, understand their pain, and provide a solution that doesnt force them to change their behavior but provides a 10x efficiency improvement. Thats not easy to achieve but is what we discussed with Abby Bangser in our latest episodeAbby is a Team Topologies Advocate, has spent years at Thoughtworks helping organizations transform through Delivery Platforms and is now a Lead at the CNCF Platform Working Group. Tune in and hear our discussions on Why Platform Engineering is nothing new, how to avoid Platform Engineering Teams to become your next bottleneck and silo, why Platforms need to have more than one interface and why the purpose of Platform Engineering should be to bring good Developer Experience to all engineersHere all the links we discussed during this episodePlatform Engineering Maturity Model: https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/CNCF Platform Working Group: https://tag-app-delivery.cncf.io/wgs/platforms/KubeCon 2024 Talk: https://colocatedeventseu2024.sched.com/event/1YFdf/sometimes-lipstick-is-exactly-what-a-pig-needs-abby-bangser-syntasso-whitney-lee-vmwareGitHub Issue for Questionnaire: https://github.com/cncf/tag-app-delivery/issues/635Kratix: https://www.kratix.io/Abbys LinkedIn: https://www.linkedin.com/in/abbybangser/Abbys Events: https://www.paintedwavelimited.com/events 

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and as always I have with me my darling co-host Andy Grabner. How are you my dear? I'm very good my dear. Since when do we call each other deers? Is it a deer or is it a deer?

Since you grew antlers. People don't know this but Andy's been traveling around the Black Forest and grew antlers. People don't know this, but Andy's been traveling around the Black Forest and grew antlers. And it's now going to get hunted by hunting season. Yeah, this was a terrible intro, Andy. Yeah, it's okay. I know there's good intros

and bad intros. The good news is for bad intros, it means the regular story that we tell or the conversation we have will just be so much better. Potentially, if we can pronounce things properly. Pronounce? Maybe we should talk about pronunciations today. Actually, the first thing I want to pronounce is the name of our guest today. Oh, novel idea. Say it again because I spoke over you.

Abby Bankser, the name of our guest today. Hopefully I pronounced it correctly. I actually want to hear her voice. Abby, are you there with us? Did I get your name kind of right? I am and you did. All the typical mispronunciations.

I even had my name misspelled at the wedding I went to last weekend. But no, you were spot on. Thank you for the intro, Andy. Perfect. Abby, would you mind quickly giving us an intro on who you are, background, things? I mean, I'm reading here a lot of cool things on your LinkedIn profile. By the way, folks, if you are interested in following up with Abby and connecting with her, the LinkedIn link will be part of the description of the podcast.

But team topologies, advocates, CNCF ambassador, what else does the world and our listeners need to know about you? There's probably a lot more to me. An American, as you can tell from my accent, living in London and working in platform engineering today at a company called Syntasso, helping to build products to help you build your platforms. And in specific, that product is Craddix. And we might touch on that. But more importantly, it's just basically a manifestation of all the things I wish I had as a platform engineer over the last five or six years at different companies and years even before that when I was a consultant and probably touching on platform engineering before we had the more formal definitions around it. So yeah, I've been involved in internal tooling and internal optimizations for a long time and really enjoy that side of things. Last time where we saw each other was in London. I think it was after a conference talk we did. I

happened to be in London at the same time. We met. Just a quick personal question. Everything good with the house, with the water? I know there was a lot of flooding going on back then. We are officially starting the rebuild rather than just the remediation uh as of next week so it's been a long journey since the first week of january but we are nearly at rebuilding the the flat so yeah water is amazing i'm just you know happened to be in germany uh and big flooding big floodings here in the south of germany i was really lucky actually to make it to Frankfurt with the train because many trains cannot make it in and out of Bavaria so yeah it's just

it's just you know sad to hear that these things take that long but I thank you so much for as I said you know making this podcast now looking at your LinkedIn I want to point out Andy though you said water is amazing and I thought that was an amazing statement because it was amazingly obvious.

I was like, oh, water. I just have to do a side note, because it's a meme that keeps on giving. I was just looking up magnets, how do they work, the great awesome miracle song by Insane Clown Posse, which is one of the most ridiculous songs. It's like, magnets, how do they work? It's like, water, it's amazing. Yeah, anyhow, just can't forget about that.

Feel free to make a meme. I guess I was a little distracted because somebody just walked into my room, but they left again. But looking at your work history, one of the things I wanted to highlight is you had six years and a half at ThoughtWorks. Yes, that was my actual first official foray

into the technology industry, which I think is, I continue to feel is a blessing that I was able to be surrounded by so many amazing people. And I find that I can't throw a stone without hitting a current or past ThoughtWorker that I respect and that I learned a lot from. So I'm really grateful to be part of that community and have had that experience. One of the things that I, and I'm just looking

it up here because I just did a talk on platform engineering. And one of the slides I use is a quote from one of the ThoughtWorks blogs. And it says, platforms are a mean of centralizing expertise while decentralizing innovation to the customer or the user of that platform. And I really love that quote because for me, it really perfectly describes what at least the way I see platform engineering in my bubble that I live really is all about, what platform engineering is all about. It's taking the expertise of many people

and then providing an internal centralized product that people, other teams can use to make it easier for them to then have more time for innovation. Do you have a different definition of platform engineering or is this still spot on? I think there's a ton of definitions that float out there, but I think this one is possibly one of the most philosophically aligned with where I stand. I think one of the things that I really like about it is the decentralization of innovation

that speaks to the access of users to this platform to be able to enable their own innovation along their side. The one thing that maybe that quote doesn't explicitly call out that I would maybe add, but I don't think it dissuades either, is that there should also be some level of enablement of bringing together those expertise in a scalable way. when the platform building team or teams or organization is owning all the features and all the offerings of that platform and any new offering on that platform goes through a backlog for that one platform, again, group, team, or set of teams, versus the platform being something that enables experts

to plug their expertise in and be able to decentralize also those offerings, even if they're then built into a centralized location for innovation. So, yeah, just to add that. Ryan, I think we just have our perfect audio snippet for the promotion of this because I think that's really awesome. So basically, how can you scale platform engineering without having to put all the strain on the platform engineering team so that they don't become the bottleneck, but they can become the enabler to expand the platform? Yeah, I think we talk about, there's been some great examples put out by people in different places.

And just recently there was one talked about using a library as an example. With a library, there's authors of books, and there are readers, and there are librarians who manage the collection of those library books in a way that is accessible and discoverable by the readers, right? And a way to be able to accept new books as they come aboard and that kind of thing. Bringing into technology, you look at something like an Etsy and the engineers at Etsy aren't knitting things for you. And they're also, they probably are buying lots of awesome stuff off Etsy because let's be honest, it's addictive. But that's not their main job. Their main job is to figure out how to connect the makers and the buyers, right? They are a true platform where they are generating value outside of themselves.

And I don't want to discount the value and quality of the makers on that Etsy platform or the book authors in the library example. Or in our platform's example, the infrastructure as code writers and the security experts and the performance experts and all those, but they are providing the capabilities. They aren't the ones curating the platform experience. And that is something that I think we have to invest in just as independently as we do all those capabilities that need to be exposed. So we need to give a shout out to the Dewey Decimal System. Exactly. I was there with my little paper cards learning how to move around the library. I don't miss it, I have to say, but I do know it. You just brought up a new term, platform experience.

So if I get this right, you basically say that if I want to use the platform or expand the platform, I want to have a good experience. Similar to what in general we want to do is improve developer experience, right? With platforms. Because I always keep referring to the State of DevOps report from last year, who were saying that I think only 40% of developer time is productive and 36% of developers say they're leaving an organization because of bad developer experience. So this, and if I get you right, and please confirm, is platform experience really like you are designing the platform so that you provide a great experience on all aspects of the platform, not just how you use it, but also how you extend it? I think that's part of it.

I think I've been talking about the fact that platform engineering is more than just building platforms. It's about bringing developer experience to all engineers. And the application developers are a much larger percentage often of a company's engineering base, right? I mean, if it's not, we're in trouble, right? You should have a lot more engineers spending their time and energy on business value generating software. And they would be maybe described as application engineers at your organization.

But there's going to be not insignificant amounts that are allocated towards data engineering or towards infrastructure engineering or towards security engineering or performance engineering, quality engineering, and all these other kind of aspects of engineering that are in pursuit of the value drivers for software. And I think that platform engineering is around realizing that pulling these pieces together and actually having developer experience for those that write infrastructure as code and those that are building platforms and those that are testing and all those things is just as important as those that are writing applications. And so, yeah, I think that's why it's called, in my opinion, why I like that it's called platform engineering rather than just focusing on platforms as the outcome, right?

We're talking about the practice of engineering as well and engineering those platforms and what it looks like. One more thought on the whole term of experience, developer experience, platform experience. One of the things I recently heard was to explain developer experience as one of the kind of attributes that you obviously want to focus on in building a platform. But really, the slogan was develop experience about creating the desire for your users to actually use your platform. Because I think that's also very important. It's a desire. It's like, because in the end, platforms, the way I see it,

you're building kind of an internal product. And like with any product, you want people to use it. And if you actually get it to an effect where people don't just have to use it, but they want to use it, creating a desire is a much stronger attachment to something. And I think it creates much more momentum. And I guess in the end also leads to more success.

So I really like the whole, you know, getting people so excited that they have a desire to use it, to expand it, to extend it. And yeah. That's super interesting because that's bringing into kind of the conversation, the adoption of a platform and how to drive that adoption. And the fact that you're pointing at developer experience there as being applied to people's experience using the platform over and above their developer experience of just writing software and i think we often talk about developer experience from hey i need to write this web application and i need it to authenticate and i need it to have a great

end user impact and all those things. But you're talking about the developer experience of getting the dependencies that you need and using that platform can have a big impact on adoption things. And it's a subtle difference, but it's a really interesting one. So I'm glad you shared it. I was curious too, we've been talking about platform engineering a lot more lately, and it goes into this experience. I'm glad we're on this topic. Do you see any hurdles to adoption?

If you use the Etsy model, people really didn't have a way to successfully sell online before then. So when something like Etsy comes up, it's going to be embraced to do that. Meanwhile, developers have been for years doing things without platforms, and someone like you or your teams come in and develop this platform and tell developers this is the way you need to do it now. Is there a lot more of an open arms, like, oh my gosh, finally, this is so much easier, or is there a lot of resistance of, why do I got to do that? Can I do it this old way? That probably is terrible.

So I think that last sentence is the thing I'm most interested by, because you said, can I just do it this old way, even though it's terrible? In my opinion, that is your existing platform. I'm a big advocate of the fact that platform engineering is not new. Platform as a product has been around for 20 years and even in conversation using those words, let alone being more formalized of recent and over the last maybe five to 10 years. So these aren't new concepts per se. They are gaining a new breath of life, which I'm really excited about. And so I never try and shoot people down when they talk excitedly about this as being new, because I'm just glad that it's getting more visibility and more insight. And I think

that's because of a lot of improvements in the industry that have helped get us here, right? Infrastructure as code has gotten better. Testing has gotten better. DevOps has driven a realization of combining operations and development of software together into a shared responsibility for the team. Those things have all led us to cloud computing, APIs as our interfaces. Those have led us to this place, right? But when you ask, like, can we get people

into this world of wanting to use this platform when they already have a platform? The big question is, are you providing them something that is 10 times better than what they had? Because if you're not, the cost of changing

is going to put into question the return on investment. Now, what is 10 times better could be developer experience, but it could also be removing their fear of whether or not they're secure. It could be removing their responsibility for the cost of their software because it is now being something that is more going to get elevated to them through the platform with alerts and things like that. So they no longer have to go in every quarter,

figure out how much money they spent, and is that within budget and all those things. So the value you're providing doesn't have to be developer experience, even if that's what we're talking about a lot these days. But it has to be 10 times better, at least, else it's going to be really hard to gather people's attentions because even in etsy like we had ebay before etsy you could sell stuff online it just

wasn't very nice it was 10 times better to go on to etsy and do it and so people switched and started using it and at least 10 times better so they thanks for the reminder of the 10x because I remember when I initially started talking about platform engineering, I talked about, I brought up the example that we cannot hire 10x engineers because they simply don't grow on trees and they're as scarce as ethical creatures like unicorns. But what we can do is we can put our efforts together to create a 10x organization by making it easier for every engineer

to have a 10x better experience. And I think that's, thank you so much for that. That's a really good thought again. And I like the eBay Etsy. There's your next platform engineering definition right there. That sentence. I have a talk next platform engineering definition right there. Yeah, I need to.

I have a talk next week in KCD Munich, KCD Zurich. So maybe I'll use that, yeah. Platform engineering, making your organization 10 times better. It's funny because I actually have the same thing like two years ago. Maybe I just need to resurrect the slides.

You know, as you go and you're doing a lot of talks, you are coming up with new ways and you update your slides. Sometimes it's also good to go back to some of these. But thanks for the reminder. That was really cool. Abby, I got another question for you. So one of the things you're very active in is the Platform Engineering Working Group and the CNCF.

For those listeners that are not aware of it, can you give us a quick overview of what this working group is all about? What you've been doing? What's happening right now? Where things are going? Absolutely. So working groups within the CNCF are sort of the most detailed and focused community groups in the CNCF. So they are a subset of what's called a tag or technical advisory group, which tends to have a more durable and long lasting topic. And so our tag is app delivery. So app delivery will exist forever. Platforms may or may not be something that requires deep investigation and help forevermore, right? But it does now.

And we've been around for a couple of years, about two years now. And in that time, we've put out a white paper to help describe what platforms and platform engineering can be. And a maturity model to help people map themselves from common patterns within the industry through to that white paper. And we're a group of about 20 or 30 pretty active people and another 20 to 30 people that pop in and out and help review our papers

and propose new ideas of things to work on. So it's a pretty active and exciting group. And you should come join our Slack channel in the CNCF. Yeah, folks, check out the links in the podcast description. I always, always in my presentation, I have a QR code. So hopefully more people join. I'm actually part of the 20 to 30 that only occasionally pop in. I would love to contribute more.

I'll do my best to get a little more. We welcome that as well. Don't feel like you have to be there every day. We just love to get different opinions in. So, yes. Maturity model. That's very interesting because a lot of organizations, they like maturity models because you can see where you are

and you have a prescriptive way in how to get better or have a way to measure yourself and how you get better. I know in the preparation of this call, when I asked you what are some of the things we can talk about, you mentioned that some interviews are coming up in terms of the

measurement framework for the maturity model. Can you maybe go a little bit deeper on that, on the maturity model, how people will be able to bit deeper on that, on the maturity model, how people will be able to use it to measure themselves, what that interview is all about? Absolutely. So the maturity model is a table, just like you'd see in most models, that I think does have some unique characteristics. And so, first of all, the table has four levels and five aspects. So when talking about what you might want to measure about your platform engineering efforts at your organization, you may want to think about adoption, the interfaces you provide, the operational overhead that you do, the way you measure your platform and platform engineering experience,

and I'm missing one. Oh, on how you invest in that platform and platform engineering. I did that one off the top of my head. Normally I have it up on the screen. See, I do know my stuff. Yeah. So those are the things you might want to think about. And then you need to think about what level of investment you want to give. And this is where I think this model is really unique. And I'm really proud of the outcome from this group. Because most models tell you that if you're at level one or zero, you're no good. And you've got to improve because there is three more levels that you need to get through before you get your certificate for succeeding in this model. And that is not how this is set up. So we have very intentionally laid out the four levels of this model around the requirements that you and your organization may need. So instead of telling

you that level zero is beginner and level four is expert, we say level zero is provisional level. And that might be not super easy to tie in. So I'm going to go to the next level and say the next level is operational and then scalable and then optimizing. So some things you'll notice is that not every organization needs to be scaling. If you are at a stable scale, if you have a set of engineers and you don't expect to hire a ton more and you have a pretty stable user base and don't see that sort of multiplying the load on your platform, scalable might not be where you need to be. Or if you're an early stage product, early stage company, you may not even need to be operational. You might still be sussing out the value you're providing and the expectations in your org. And so provisional

is just right for you. And finally, the last one, which is optimizing, there's a slight turn of phrase there because instead of saying optimized, like you have succeeded, you are at the top level, and now you get your certificate, we went with the phrase optimizing to indicate that this is something that is perpetually improving, that all the aspects that are at that level are telling you that this is how you get feedback into your system and improve as you go. So that's where the model sort of lives and comes from. And there's 12 pages of document behind this model. And it's not to scare you away. It's actually quite a quick read. There's lots of headers and things that you can kind of scan to the thing that brings you value and means that you should be reading through it.

But it is a lot. And people often aren't really great at self-grading themselves when there's just a lot of text to read. And that's why there's an effort being proposed by Corbin from AWS and a few others from there that we're going to try and create a sort of questionnaire that can help people identify what they need. So is their organization needing scalable or optimized or what level of investment and where are they? And therefore identifying where their hotspots might be. Hey, you said that you need these types of things given the shape of your organization, but you're only investing up to this level. Here's a bit of a risk area for you. You're

potentially under investing here and you may find that you might have some challenges. And go read this part of the model paper to understand more what the impacts would be. So really early days on this piece of work, the thing we're not going to do is we're not going to give people a score of like, you are a 76 maturity level platform. We're not going to do that.

But what we do want to do is just give people the ability to introspect more effectively. I'm just looking at the the talk, the pages on the tag at delivery

CNC FIO slash white paper slash platform engineering maturity models. So folks, all of this that Emma has been talking about, it's already extremely well documented. And as I said, I will link to all these pages

where people can also find when your group is meeting, how people can contribute and things like that. One more question, because maybe I got this wrong or didn't fully understand. The questionnaire, is this something that people can already find? This is something you're still working on? It's something we're working on, but there is a GitHub issue. And so I can get that to you and we can put it in the show notes if you'd like.

And we're going to be going through the kind of format that we're initially thinking and trying to put that through the ringer a bit with the group to see if it fits people's mental models and we think it would be effective and useful over the next probably month to month and a half. And then we're going to go from there to some of the more specifics of like what questions should we be asking to drive out these answers. So, yeah, we're really early days. I expect this to be a good couple of months of back and forth and debate and conversation within the group. So if this is your kind of thing, come join us for sure.

I would love to switch gears a little bit and talk about something because I've just been sitting here in a workshop about platform engineering. And the first thing I want to confirm, I wanted to say this earlier, when you said platform engineering has been around forever, but maybe people have called it something differently. When I explained platform engineering, one of the guys said in a room,

we've been doing this for a while, but we just call it differently. And I said, yeah, exactly. So that's just perfectly spot on. Typically, though, a lot of people are asking, what are the tools in there and what do we need to use? Now, I know there's a lot of tools in the platform engineering space. It seems every week, every month, there's a new project coming up. If you go to KubeCon and you walk the expo hall,

it feels like every second booth has something to do with platform engineering. And just on top of my head, obviously, a lot of people are assuming that, let's say Backstage is already an IDP, but Backstage is just a little piece of the whole puzzle, right? There's different tools

out there. Now, you are working for Sinteso and Kretix? Kretix? Got it. Kretix. tools out there. Now you are working for Sinteso and, uh, credit critic, critics, critics, critics. Got it. Perfect. All right. This was with the, with the German pronunciation. It sounds a little bit different, but it's almost there. Uh, critics.io tell me why does the world need yet another tool? And what is it? What is it that you do differently why should people look into this because i want a little bit understand more on what the stuff is that you're doing with critics it's a very fair question so the first thing i would say is that platforms and platform

engineering has i'd say lots of things to do they have to manage the infrastructure of things like clouds and SaaS products that they're running and on-prem servers and things. They also have to provide business processes. So things like manual approvals and security scanning and reporting and GDPR and all these things built into their systems. And they also need to actually interface with the users of these underlying technologies. So the applications and the application engineers. And you could choose to have a platform that does all of these things, or you could choose to break them apart. The key is, is you need to have all three layers of application orchestration, so management of your application depending on aspects of infrastructure, or visibility into that infrastructure and what your application depends

on. You need platform orchestration where you're dealing with business processes and the flow through that system and how to connect these things all together into being bespoke to your business requirements. And you need infrastructure orchestration. You need the management of those APIs and those SaaS products and those clouds. And again, do them all together, do them all separate, do two of them together, whatever. There's lots of different patterns and they can all be successful. The reason why I think Craddix is unique in this space is because we come from a history

of building platforms that try and put all three of these things together. So a lot of our team has a really storied history of both implementing and writing Cloud Foundry that came out of Pivotal Labs, which is still renowned as one of the best user experiences for application developers

who are able to do CF push, right? It's a great experience. But there are only so many applications that can run CF push. You have to be a 12-factor app. You have to be running in a certain way. And that's just not realistic for large parts of organizations,

even organizations that see huge value in Cloud Foundry. So we have that experience of trying to build the most perfect platform that incorporates all three of these layers and just hands it off to people. But we also have a lot of experience within our team of building from the ground up. I, for one, have been building up from Kubernetes for years and years now, throwing in things like GitOps agents, using Argo CD extensively, using reconciliation infrastructure as code. I used Crossplane. I've used the AWS-specific reconciler for that.

I've used Terraform, all these things. trying to build to the point where an application developer is happy, but actually often falling short where I'm handing them like HCL Terraform modules and being like, just make a pull request, it'll be fine. Or I'm handing them, you know, Helm charts that they have to be able to read the YAML. What Craddix does is a framework for actually enabling you to build your bespoke platform experience that feels like the experience of a cloud provider where everything's done by an API. There's different interfaces for different use cases, and everything's built in, but it's bespoke to your business. So it has all those requirements like when you need a manual sign-off, when you need to do GDPR compliance, when you need to do reporting, all those things built into it. So it's a framework rather than an all-in-one solution.

And that framework lets you build on top of those primitives a lot faster than if you start from scratch. Well, thanks for that. And I told you earlier on email that I wanted to really talk about the whole concept that I saw. If you go to Kratix.io and if you scroll down a little bit, you basically see the architecture I guess, and then the concept of promises comes up and workflows and fleet management. But I was also intrigued by kind of the that promise layer and i looked a little bit into it but i guess i didn't have enough time to really work

with it and experience it but is that promise layer exactly what you just told about that you can actually define and kind of customize your experience as you like it because every organization is different and then you can define your platform experience through promises is this the concept that i got right exactly craddocks in short allows you to provide anything as a service in your organization bespoke to your organization and a promise is the definition of something as a service. That's our domain object, right? So a promise provides, let's say, a test environment as a service. That would be your implementation of that promise would be a test environment. your API, set your business rules and workflows associated with when people make requests for these test environments, and also set how to manage deployment of the infrastructure

behind that test environment across your entire organization. So whether that be mainframes or Kubernetes or network devices or cloud providers, we can schedule that infrastructure anywhere that you need it to go. So packaging all that up together as a service is the real magic of the maintainability of providing these services internally in your organization. Cool. What else do we need to know about critics but like I don't want to give you a free stage now to basically do a commercial for like the next 15 minutes at the time we still have left but

other things where you say and besides the pro I really like love the promise concept because you're basically making a promise to your end users that certain things get done so I love that and that's why I also wanted you to talk about it. Anything else that I missed maybe as I quickly glanced over the other website? Stepping away from the product particularly or the implementation or the tech or whatever, I think the thing that I'm most proud

to be working on Craddix for is the fact that you introduced me and you said, oh, team topologies advocate and CNCF ambassador. I think that showcases my kind of focus on the socio-technical challenges, right? I don't like just talking about tech. You can always solve something with code eventually, right?

You'll figure it out. But often the hardest problems are the people side. And I think that Craddix is exciting because it's focusing on that socio-technical challenge. And whether or not we're 100% there yet, who knows? But what I can say is that we view ourselves as providing the technical requirements to enable that team topologies evolution. And so the more we work with people who have a mindset around organizing their teams effectively and creating team APIs and driving out an efficient organization through that kind of method, the more power they see in working with Craddix technically, right? So yeah, so I think it's that socio-technical challenge that I think Craddix is really well suited to support. And I think

that's where platform engineering needs to be because it is a people problem. We talked about adoption earlier. It's always a people problem at the end of the day. And so if you're not thinking about that, I think you're going to find yourself in a little bit of a challenge trying to get that platform engineering effort off the ground and long-term successful. Thank you so much. There's always so many thoughts that come to mind when I listen to our guests. So to recap some of the things I learned already, I really love going back to the very beginning, the 10x. So if you're building something, it has to have a 10x impact because otherwise, why would you move, right?

What's the real benefit for all the investment? The people problem, and we've been talking about this for many years, a lot of things are people problem, and the technology is then just the easy part. I just lost my train of thought. How often does this happen? I wanted to say something very smart now, but I completely lost my train of thought.

I was waiting for you to pop in there, Brad. I actually now remember. It's too tempting. No, I just made you lose it again. There you go. Yeah. No, I remember. So one of the things, you talk about adoption, right?

So one thing is if you have a 10x solution, awesome. The other thing we talked about in the preparation of this call is the way people are interacting with the platform. And one of the notes that I have taken from your, it was the conference talk that you recently did at CNC. It was at KubeCon, I believe, right? Platform Engineering Day at KubeCon, yeah. Yeah, exactly. So it was called, the talk title itself is awesome. Sometimes lipstick is exactly what the pig needs.

And you did this talk with Whitney Lee from VMware. And one of the things you mentioned in the description is, the saying goes, meet your customers where they are. So you need to understand where your developers are, your users to your potential platform that you're building because sometimes you need a nice fancy UI. Sometimes all you need is a CLI, an API, whatever it is. What I always try to explain people when I talk about platform engineering

is exactly that kind of first step, which is understand who your users are, understand what their pain is, and understand in which environment they live. Because a shiny web UI might not go well with engineers that are expecting a YAML file that they put into Git and that's all they care about. On the other side, you may work in an organization where you scare people away with Git, with YAML, and you need the shiny UI.

Do you have any experience on what it actually is? Is there any good model to understand what is the best use experience that you need to deliver in order to increase that level of adoption? Any approaches to better understand your real user or, as you put it, meet the customers where they are? Well, this is very much a reinforcement that Whitney and I should get our website up. So that talk introduced a framework to think about how to choose what interface is best suited to the capability that you're offering. Because first of all, the case we made is that a platform is not a

single interface. You cannot just make one interface for your entire platform. You instead need to think about the different users. And often you'll have different interfaces for different capabilities within your platform. But even more often, you'll have more than one interface for a given capability. So think about cloud providers we've mentioned. They don't just give you an API or just a CLI or just a UI. They give you all three because different use cases require one or the other, but your experience is still the same in that what you can configure and how you can get what you need and the speed you get it and all that. So yeah, the framework that we

talked about there in the talk that you can listen to for the talk, we are going to be putting up a website to make it a little bit more accessible and faster for people to consume. Because we think thinking about your user needs and your capability styles, that combination of the two is how you pick the right interface. So is your capability something that is going to be aimed at more power users in general or more beginner users in general? Is it going to be something that requires a lot of configuration or actually sensible defaults works most of the time? Things like that will change what interface you need just as much as is that user someone who uses a command line

day-to-day or not. But the only other thing I was just going to add is when you talk about a shiny UI, I think one of the things we really often run right past when we talk about meeting our users where they are is acknowledging that a lot of them are already using UIs. You just might not find them fun. So a lot of our users are using ServiceNow or Jira or Wiki or something else that they're doing, GitHub, right? Or some other kind of ticketing system. If you want them to go off to a different UI, so this isn't about

that they don't want a UI anymore. You're asking them to change the bookmarks on their website, on their web browsers. You're asking them to change their muscle memory. You're asking them to possibly have to keep checking multiple locations, depending on if they can truly shut down that original way of working, which if you're using one of those ticketing systems, most likely the organization is still going to require it to a certain extent for reporting and all those things. Why not make those our interfaces? They're not shiny. They're not as exciting as the new portals and things like that.

But someone opens a ticket and it sets off a set of automation that results in comments being made on that ticket to the point where the user has what they need and can close that ticket. That doesn't require any user behavior change, but provides a huge step forward in user experience, right? Yeah. User behavior change is expensive. Ask people to change their bookmarks. It's expensive. So I think every time we introduce a new interface, we have to be really cautious about it.

Yeah, I love it. And this also goes, yeah. I also always, you know, try to tell people, because, you know, we've been doing a lot of education on the role of observability in the life of platform engineering. And the message that I always try to make is don't force your developers to go into the observability tool to get the data, get the relevant data for them and push them into the tools where they live. Because with this, you give them additional value without forcing them to change. And the example that I, each year is one example where I say, you know, maybe you want to, if a developer is working on a Jira ticket to implement a new feature, once this feature

gets released, once this feature is adopted, why not figure out a way how to push back a comment on the Jira ticket saying, hey, this feature has not been released. And if you want to see a detailed dashboard, click here. That's awesome. Or another thing that I really like, for instance, I always, it seems every day now, you know, we're using Microsoft Office 365. So I get like daily digest emails or whatever they're called.

You get an email saying, hey, here are some things you may have missed. I live in Outlook anyway, but I get some really nice assistance. And so the same would be true from an observability perspective. If developers, let's say, they live in Slack, why not get in the morning an 8 o'clock or 9 o'clock Slack message from your observability capability

of a platform that says, hey, Andy, we noticed that you have made three deployments yesterday and here are three new error logs that we've seen. Is this something you want to look into? Then click here. But that's a completely different way

as saying you need to go into this new tool and now you need to change your behavior. I love it. This is why we need to learn more across domains as well, right? There's so much of that type of conversation happening in the platform engineering echo chambers and silos and things.

But observability is not a million miles away and yet you're having those same conversations how can we amplify each other's messaging here because that is a fantastic set of examples i think it's really good yeah and they it yeah and they also resonated really well with all the people and i really like that whole a bit we talk about how ai is making our life easier because it you it becomes an assistant. We don't necessarily need very sophisticated AI for that. It's just about we want to make our life easier by, as you said, not changing our behavior,

not having to change our behavior yet, getting better information so that we can become more efficient or can do things that we otherwise would not be able to do because we would never look into these tools and i think that's yeah and only pay that chip of behavior change when you need it and when it's valuable enough right because that is an expensive chip to play exactly yeah it reminds me a lot of the um virtual instruments you know virtual synths and stuff like that for on the computer, you know, most of them are set up like a traditional synth or something like that so that you can just pop it in and explore the sounds and

make it work. But every once in a while either a virtual even a hardware synth will come out that is completely different, right? Completely different interface. And when you read the reviews, it's always about, yes, this is not something you're going to be comfortable on. They made these changes to force you to not work in the way you were working so that you're going to try to use this in a completely different way. So I think, you know, just taking that from my own world, if you're not giving people an interface they're expecting, you better be giving them something completely new or different as a result. Otherwise, keep it familiar.

It's an amazing example as well. Now, we talked about this cognitive distance, or contextual distance, I'm sorry, contextual distance, and that certain interfaces pull you away in distance from where you had that aha moment that you needed help. And some tools keep you right in the moment. So think about like chat GPT in your IDE. Keeps you in the moment, keeps you there. You don't have to go very far. But to your point, Andy, of like an observability tool, it's a whole new interface that you maybe don't log into very often. Could be quite a far contextual distance. That's not a bad thing.

So inherently people think, oh, low distance, always low distance. The lower the distance, the better. But actually, if you think about, for example, wanting to think about an architectural diagram instead of looking at a log line, you might be right in your log lines thinking, why am I getting this error? What's happening? And actually pulling yourself up to look at the map of microservices and how things are interacting with each other will fundamentally change how you're thinking and possibly open your mind to a new idea. So just to be clear, there isn't right and wrong about this. Like, it's that when you do, what are you encouraging in the behavior and what value is the user getting for paying the tax of contextual distance or learning a new behavior or whatever? Are they getting that value that they need?

Yeah. Excellent. Sorry, that was my rant. No, it's awesome. It hits home, you know. Hey, Abby, I remember before we hit the record button uh and we said you know we have about an hour you said uh who would who would ever listen to us for an hour and guess what you know the hour is almost over and that's the crazy the crazy part of this right but we don't know if

anyone's listened yet so we're gonna have to put like an easter egg for some swag or something you know if anyone actually finishes this. That's true. If you listen to that part, you will get lifetime licenses for tool E. I've got some decent stickers and some other things. If you ping us that you've gotten here, you let us know. We'll figure something out. Exactly. No, thank you so much, Abby.

I'm very happy that, A, our paths crossed, not only in London when we saw each other, I think the first time where we had time to sit together, but also prior because we've been on some virtual conference or a panel discussion and then this kind of led to this and uh i'm sure there will be more we do together because we're both very passionate about platform engineering um yeah we will post all the links that you gave us also to your website with the upcoming talks and I hope that some people, some listeners are,

you know, at least looking into what the critics is doing. And yeah, so keep up the great work folks. Please also join the working group because there are more people that help, even if it's just, you know, from time to time joining in.

Everybody helps. Bring us your problems as well. That'll tell us what we should be working on and focusing on. So yeah. Thank you. Bring us your problems as well. That'll tell us what we should be working on and focusing on. So yeah. Thank you so much for having me as well. This has been absolutely brilliant. I've learned a lot from you two as well.

And I just, I love having these conversations because I learn something every time. So I really appreciate it. So do we. Thank you. And this definitely did not feel as long as it ran. So it's very entertaining.

Thanks a lot. Really appreciate it. Thanks to everyone who's listening and um we'll see you on the next episode thank you bye bye thank you