PurePerformance - Organizational Sustainability through Platform Engineering with Lesley Cordero

Episode Date: May 12, 2025

As a leader that wants to optimize an organization you are bound to fail if you isolate social (culture and people) and technical (tools and process) changes. When we ask Lesley Cordero, Staff Engineer at The New York Times how to solve this dilemma she answers: "Platform Engineering, it can drive organizational sustainability by practicing sociotechnical principles that provide a community driven support system for application developers using our standardized shared platform architecture"Tune in to our latest episode and learn more about the importance of leadership to continuously keep up and balance the tension between "Developers" and "Operations", between "End User Experience" and "Developer Experience" and ultimately between "Culture and People and "Tools and Processes"Links we discussedLesley's LinkedIn: https://www.linkedin.com/in/lesleycordero/GOTO Conference Talk => https://www.youtube.com/watch?v=Jx-XrUONJ-o QCon 2025 Talk Details: https://qconlondon.com/presentation/apr2025/platform-engineering-practice-sociotechnical-excellence DevOpsCon 2024 Talk Details: https://devopscon.io/business-company-culture/platform-engineering-devops/

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 wonderful co-host Andy Grabner. How are you doing today Andy? I'm very good but Brian I was expecting a little more enthusiasm. Normally you are full of energy for today which is like... Yeah well I was up late. I was up late. I had to pick my daughter up from a concert.

So I'm a little tired this morning, but if you want, I go like, Hey, Andy! See, here's the dumb joke. So everyone, Andy prepped our guest saying we make some dumb jokes beforehand. And this is the dumb joke. I don't even know if you can consider it a joke if it's not even like close to making you laugh. So instead of me continuing my failed stand-up career that I never had, Andy, why don't you do some sort of, let's see if you can segue from this mess to, let's see if you can swing us back to the topic at hand.

Yeah, you mean like a pendulum swinging from something that wasn't that exciting and energetic to something that is extremely exciting and will bring a lot of energy to our listeners. Today's podcast guest is Leslie Cuadero. I hope I pronounced the last name correctly. Perfect. I got the thumbs up. Leslie and I, we happened to meet each other last year in London at dinner with our mutual friend, Abby Bankser. She was at the conference DevOpsCon, I believe in London.

I was there for another event and then Abby said, hey, I want to bring a friend to your mind as a tour. And so we got to talk. And Leslie, here we are a year later. Thank you so much for being a guest on our show today. Awesome. Yeah, super glad to be here. Yeah, thank you for the patience and really excited to talk about platform engineering. Yeah, exactly.

That's the topic because I have thanks for sharing the slides with me. You did a couple of talks last year was DevOpsCon. I think just recently you were speaking also at QCon. Is this correct? Did I remember this correctly? Yeah. The topics were around and I just highlight the titles because there's a lot of stuff in there. Driving organizational sustainability with platform engineering was

one of your talks and the other one was called platform engineering as a practice of socio-technical excellence. I looked through your slides. I also had a couple of notes and the whole kind of not joke, but the transition that we tried to play earlier with the pendulum. There was one thing you talked about the pendulum of tension. And I think you can probably explain this much better, but just folks, if you have a chance, we will put all of the links to any presentations of your recordings that are out there on YouTube or on these conference pages. We'll put this into the description of the podcast.

Check it out. Also, I'm not sure if we are allowed, can we share the slides as well? Yeah, some of them are definitely open up for, I'll let you know which ones are. Perfect, perfect. We will also add these links. And I just wanna highlight one thing.

There's a lot of different things you talk about. You talk about how the importance of bringing organizational change together with technical change in organizations. So don't see them in separation, but do them jointly together. You also talk about leadership. You had an interesting quote from David Yeh. He, you told me how to pronounce it correctly. Well, he said, it's our jobs as leaders to hold things in tension.

And when we talk about tension, you brought up the pendulum of tension and the pendulum, really you try not to hold the pendulum in the middle, but you always try to make sure as it moves, let's say between culture and people versus tools and processes, or from a platform engineering side, where you try to make sure as it moves, let's say between culture and people versus tools and processes or from a platform engineering side where you try to find the balance between developer and operations or end-use experience and developer experience that you are steering it correctly so that I guess it doesn't flip all the way too far in one side. I know I talked a lot, but this is a really exciting topic, Leslie. For those people that have never heard about the socio-technical excellence that you talked

about in platform engineering, what are the couple things that you're highlighting in your presentation? What do people need to know and that also hopefully encourages them to watch some of your presentations? Yeah, so socio-technical is definitely a complex topic. It has origins from decades and decades of go from industry research that actually happened in the UK, which is where I gave the talk, funny enough.

But it's basically this idea that you can't look at social and technical systems completely separate, right? Like that they inevitably interact and impact the other, right? And so it's this, it relies, so socio-technical theory basically relies on this idea of like joint optimization, where you're trying to, when you're trying to change the system, you have to think about both together, right? And like that process of like optimizing for the overall system by looking at the sessions at how the social and technical components

interact with each other, that's called joint optimization. And to me, that joint optimization like that, that's the hard part of like being a leader. Like that's where all the tension to use David's term comes from. So I really think of leadership as a practice of optimizing that. And especially because there's not as many playbooks

on how to do that because every single system has its own context and whatnot. So socio-technical theory basically has, it comes with the framework of how to think about those things. It has four components that are part of, that interact together in the social and technical context. And then there's the organizational part that are,

it can be more external. So there's a lot of external factors, right? Like for example, you know, in my talk, I speak to the impact of, you know, the overall like economic situation that we're in right now, right? Like that is why we had to do a lot of mass layoffs, right? Like that's why there's been a pressure to be lean and, you know, more than even before.

And so those are the things that are more out of our control. But socio-technical theory is basically talking about how do you go about making internal change in light of your external and internal constraints. And so I basically talk about how platform engineering is that practice of sociotechnical, of navigating sociotechnical tensions. Do you see one thing that came to mind? We see a lot of organizations that say, hey, we need to replace this particular tool with the next generation tool because then everything will be better. Then they do it and

then they realize after three years when the contract is up for renewal, wait, actually, you know, they didn't get the value out of it. Because I guess to your point, if you only replace a tool with another tool, but don't figure out how all of this fits correctly and jointly optimize it with the rest of the organization, then in the end, you will have a failed investment, I guess, right? Because that's why so many people are frustrated. Years and years, there's a new tool coming in and new another tool, but in the end, they feel like nothing changes. Yeah, yeah. I think, yeah, that's a great example. Tools are not silver bullets, right?

I think that's really what a lot of it comes down to because I think in observability, which I hear you guys are familiar with, it's not just about the tools and whatnot that you adopt. It's also about getting people to actually understand you guys are familiar with. And sure, tools can have trade-offs on how easy they make it so that your developers can understand it. But at the end of the day, there needs to be that social investment as well. So we can't just expect to introduce a new tool without underlying support systems and whatnot.

So when I'm thinking about adopting anything new, I'm also thinking about how do we go about it from a social process, right? Like how do we socialize the skills needed? How do we, through education, we're also looking at our current gaps, right? Like is the tool that we're, if we're evaluating our current tool, right? Is it not working because of its tool limitations

or is it because of like the educational factors and whatnot? So yeah, I think that's a great example of how important it is to consider both the social and technical parts of trying to solve a problem such as understanding your systems. So Leslie, another thing that I had in mind is because you said in the current economical situation that we're in, this is kind of puts a lot of pressure on a lot of organizations where you now need to rethink how you do things. And my question now is, is this something that you typically see that it takes external events that

you cannot control to have organizations think about how they need to change things? Or are there other ways to go about this and not just wait for the next economical depression? Yeah, I think there is a tendency for leaders to be reactionary. Right? So responding to like external stimuli that's not in your control. And I think like the best leaders are those who can be more proactive, right? Even preventative, right? Obviously, you can't prevent all your issues from happening, right? That's sort of by definition what it is, right? It's out of your control. But I do think as an example with hiring and whatnot, right? A lot of the reason why this was such a huge shock for the industry, I think, is because we were so used to over hiring and not leaning on efficiency and whatnot.

We waited until the moment that things got really bad to really introspect on, are we using our time wisely? But I think those leaders who were already thinking that way felt the impact a lot less because they were already in the business, right, like felt the impact a lot less, right, because they're already in the business of being efficient, right? So one of the things I emphasize is that like this, the recent changes in terms of like, you know, increasingly emphasizing leaning, right, and lean movements and whatnot, that's like not actually anything new, right? But I think now we're just having a more shock, like, hey, we actually meant it when we when we were saying those things. So I think, yeah, I think like, most leaders are in a more reactionary, you know, way of thinking, but I

think the leaders who can get themselves to think more proactively are the ones who, like, are most set up for success during those hard times of like change. Yeah. Yeah. I think it almost feels like I have another kind of analogy. Earlier I talked about these tools, replacing one tool with the other doesn't really help you if you don't think about how to also change the processes.

In software engineering or in testing, we often talk about chaos engineering. Basically, forcing chaos on your system to see how it behaves and then optimize it. Could we say that if you constantly run chaos experiments against your organizations, you will be more resilient later on when actually disaster strikes from the outside? Yeah, actually, it's so funny. I keep putting off writing a talk about how to handle organizational incidents. And I, yeah, and I feel like the chaos engineering analogy is one that I like, has been sort of floating on the back of my mind, right? Or, you know, like an organizational, like a good example of how it could be an organizational incident is like someone leaves suddenly, right?

Like that's an organizational incident or at least an incident to your team, right? Imagine like, you know, that people call it a bus factor, which is a little dark. But you know, that's very real, right? Like people leave, people have drastic changes in their life that suddenly, you know, they have to go on. I mean, personally speaking, right, like I last year I had to go on leave for a bit because I had some personal issues happen. Right.

And like, to me, you know, I would say like my, I can tell how good or not good at my job, so to speak, I am based on how my team reacts to my absence. Right. And so, yeah, I definitely think there are ways of sort of having creative, there are creative ways of testing like your organizational resilience. You know, and I think it's definitely like,

I think the absence of leadership is a good one, right? And it's not to say like you should just like ditch your team sort of a thing, right? But there's something to be said about a team that is still resilient in the absence of their leader, right? So yeah, and I think that I love the chaos engineering analogy, so I'm like lighting up just hearing about it.

Yeah. You know, without giving away any information really about Dynatrace, one thing I can probably say is that I think we are proactive in those sides. Especially you know several years ago when there were tons of tech layoffs we didn't have tech layoffs because we were always a very cognizant of our size. I know within the last year or two in my organization and you know within the, there's been a lot of encouragement

for leaders to have new hires lined up. Are you talking to people? Have you identified future people you want to hire? Are you starting to mentor them and train them up for exactly that bus thing, right? If something goes on and we need to replace the one, are we starting from scratch or do we have people that we know we're going to be going to To see if we can move them up. So

Back to Andy's first question about either, you know being proactive Versus, you know not being proactive and just react, you know being reactive I guess It's it's you know, not something I really thought of it in in those terms, but it's definitely comforting to know that we've got some of that going on. Next thing I'll have to do though is schedule a month vacation on my team. And it'll just be a test for them. So... Hey, Leslie.

I guess we completely skipped the introduction part on where you can say, you know, I'm Leslie, I work as a staff engineer at the New York Times, right? We completely skipped that. So you do work for the New York Times and you mentioned earlier that your team handled it pretty well, even though you were not there for a little while. Do you have any, I don't know, any insights on what you did or what the team did to make it resilient? Any additional tips and tricks, best practices? Yeah, so I mean, I left during,

honestly, a pretty chaotic time. It was freshly after a major election moment. And I think the thing that set up my team for success, because we did, you know, the general election did go well, we were, which is like definitely a huge accomplishment. We didn't, we didn't experience any major downtime. So and that was like the first time, I think in quite a while that we had that milestone. So I think a lot of it did go down to just like thoughtful planning. Like I put a lot of effort into the general election, election readiness preparation plans. I was leading it up before my I went on leave.

And I think like that was ultimately what set my team up for success. I started thinking about that. I knew it was coming up and I started thinking about it proactively from very early on before even the wider news organization told us like, hey, it is now time to prepare for the general election. It was something I was thinking about since 20, since earlier 2023. And like the official kickoff for it wasn't until August, right? So I think it was that upfront thinking that I did that honestly set us for success in that regard. Because not only was it, and it was also helpful for myself

and my team, but also leadership and whatnot. When I had to step away, they knew what needed to get done based off of the plans I had laid out and whatnot. And I had already spent a lot of time socializing them as well. So I think a lot of it has to do with like sharing information, very frankly, like don't keep things to yourself

because then that creates sort of like the silos that we talk about in DevOps and whatnot. So I think for me, I try really hard to like lead into like that information sharing, whether that's through documentation, whether that's through having, you know, one-on-ones with or meetings, you know, recurring meetings with my stakeholders and peers. So that way, it's I'm not like a

singular point of, you know, information and therefore failure. Like it's I think, if you have can if someone can leave your organization, and you feel that like feeling of like, oh crap, like, what do we do? Like that's, that's something to pay attention to and address pretty immediately. So I think it was like, a lot of those combination of things. And it wasn't, I think it was like, a couple years of just me making sure like there's redundancy on anything that I have like to provide. And obviously, you know, I mean, everyone has their own

uniqueness to contribute, right? And I don't want to say this in a like, oh, you know, make everyone replaceable or anything. But I think like you, I think if you can reframe it as like, we're trying to help each other grow constantly, right, through information sharing, through teaching, through knowledge sharing, et cetera. Like that's where I think a lot of beauty can happen, so to speak, with respect to the kind of work we do.

Yeah, it's like resiliency planning for the human side. Yes. If something falls over, are you a, if we think about older architecture, are you the database or are you one of many services that, okay, we can limp on by and figure out a way, but we're not completely out of luck, right? Yeah. Also, Brian, it just reminded me about the previous podcast we recorded with Lisa Carlin-Curtis. She is also a founding engineer at Incidence.io, and she was talking about the importance of

sharing, the importance. She was talking about how important it is to embrace incidents and to be open about it and document them, share them, because the worst incident is actually the one that you're solving without anybody knowing because then nobody can learn from it. And if you're then gone, then nobody had this previous experience.

And I think that was kind of falls in line with what you just said, right? Like preparing and sharing and documenting. Coming back to platform engineering, I know you're officially listed as a staff engineer at the New York Times. Are you part of a platform engineering team or how does... Yeah, it seems like you're nodding. Are you part of a platform engineering team or how does... It seems like you're nodding. Can you explain a little bit on how you're organized and what platform engineering means

for you and your team? Yeah. Yeah. So save the fact that we've had some reorgs in the last year, but I've always been part of the platform engineering organization in my current role. Originally, we called ourselves Delivery Engineering, which was basically platform engineering, but we hadn't quite really leaned into the label yet. But that encompassed and it mostly

encompassed infrastructure platforms, which I do always name as an anti-patter pattern, if I'm being honest. Now we have addressed that. So actually now we're more fully encompassing the entire sort of like developer experience. So now our like most recent reorganization essentially is like covering, you know, even like full stack development, right? So, which is awesome. Like we we're still figuring things out. I think my leadership is gonna kill it in terms of like having a greater like platform engineering story.

So it's a really exciting time to work at in my organization. And so for us, platform engineering, it is ultimately about the internal developer experience, right? But we're like not just viewing it from the infrastructure side these days. So traditionally we had just been mostly focused on infrastructure.

So we have like our shared infrastructure platforms and whatnot, but now we're also talking about like shared tooling, right? Not just for infrastructure, like also our runtime language stories, right? Like, so we standardized on like Go and TypeScript, Python. So we're really thinking about like those, even holistically, across different parts of the team.

So we've grown a lot in the last six months especially, so a lot of unknown territory, but super exciting to just kind of really also talk about what platform engineering means because I think that platform engineering is equal to infrastructure platform is something we're really not... It's so ingrained, I think, in the platform engineering org, but I really don't see it that way. But I think it's really exciting that the Times is taking that more wider picture of platform engineering. sort of like experience, like a singular service, like what's the best practices for a service? What tools do they need to actually build services, etc.

So yeah, that's some of what's going on at the times. So we could say the times is with the times on platform engineering? I hope so. I would like to think so. So it keeps me here. Did you, coming back to that pendulum, did you, when you decided to standardize on certain runtimes, because you mentioned Go is your runtime of choice, did you work, who made that decision? And how did you come up with that decision? Yeah, so I that was so that decision, it wasn't I can't take credit for that one, that's for sure.

Actually one of my colleagues, her name is Sarah Duncan. She's awesome. She was a huge spearhead of technical standards at the times. And honestly, I came in and she had already laid down a decent groundwork and she and I just kind of kept forward with it alongside other people who of course you know wasn't just us two. But yeah so that decision it came to be in a more like grassroots consensus kind of a way which I am happy to talk about the like pros and cons of that. But yeah so it was it sort of started out of this it was like the first major standard

that was put together at the times. That was like organizational wide and like more in the government governance sort of side of things, which like in enterprises, I think like governance is a huge part of what platform engineering is. So, yeah, that was sort of the history behind that. And there was a lot of a lot of opinions that went into that for sure, especially because we had a history of a lot of drift. The Times is an extremely old organization. It's like 170 something years old. So we've been doing technology since way before Google even existed, for example. And so there was Cobalt there. There was everything you can think of possibly, before Google even existed, for example.

like what do we want the developer experience story to be at the times. So yeah, let me know if there's anything in there you want me to really elaborate on. I would love to because I did you, I hope you did. Did you involve your internal customers, your developers in that decision process? Yes, yes, for sure. And that's like something I really love to push is the inclusion of developers. And Sarah was actually the person I mentioned, she's actually a product engineer. And I think the product-platform combo is definitely very powerful. I talk about that in the talk I gave at QCon, like that pendulum between product and platform.

And I, like my personal opinion is that the folks who have been in both roles are often like particularly strong in platform engineering because they have both perspectives. So I think like her and I like brought that perspective together for sure, alongside some other like awesome coworkers like, I don't know if you know Ahmed Bebars, do you know? He speaks a lot in the cube kubernetes and whatnot. Yeah, yeah, I know I met him last two weeks ago in London. Oh, actually we talked about this topic and I also now I just put

it up here. Ah, yes. Yeah, because he wrote a book on platform engineering and the sub-tagline is crafting modern platforms as a product. And that's why I wanted to ask you if you have included your end users in the decision process of how you craft that platform and product. Yeah. Yeah. Nice. No, I mean, I think there were, I mean, I met a couple of people from the Times in London, just so many people and faces and names that sometimes it's a little hard when you just mention a name. Do you know him? Can you tell us also a little bit about, and this is for me always the biggest question that comes up when I talk about platform engineering is, have you found a way to measure the impact

that you have with your work? And how can you justify the number of people, the time, and the money you put in? But I think the question can be answered with, do you have a way to measure the impact or did you lay out a goal in the beginning? And then you said, now we are working towards that goal. Yeah, yes, that's a huge topic in platform engineering. Yeah, measurement is really difficult, right?

Like we have, there's a lot of, I mean, my thought process behind how to measure success is that usually you need multiple frameworks, right? And a lot of the science of it is sort of going across those different frameworks and trying to gather insights, right? I think having only one metric or even just one set of metrics can often be a downfall of platform engineering. If we over-index on Dora metrics or if we over-index on adoption, or if we over-index on service level objectives, those are probably the three most common that I think we tend to rely on or I see people, other organizations rely on.

I think as someone in SRE, reliability platforms, SLOs are definitely some of the metrics that I like to spearhead, if only because I think it ties it to the end user experience a lot more cleanly. But I think, like I said, the combination of those, of different is like really where the magic happens. So you know we also use Dora Metrics. Adoption is definitely a huge part of it for us too right like as a more specific example right we're a we're a tracing first organization so super huge for us and you know one thing that we do track is literally like the number of services that have And one thing that we do track is literally the number of services that have tracing integrated into it. So those are some examples of it,

adoption of our shared platforms. And the difficult part there is also figuring out the total market and whatnot, which is something that our product leaders have really taken a dive into and are figuring out. It's super cool to see Un whatnot, which is something that our product leaders have really taken a dive into and are figuring out. It's super cool to see Unravel, which is just the idea of, okay, given what is the actual market of adoption that we can have, right?

So number of services is going to be an important part of that, right? That's kind of one of the main single units that we're working with, also like teams. And it kind of, you know, it depends on the context of what you're trying to drive and adopt. But yeah, but in general, it's definitely very difficult. And I think like there's not as many, the best practices aren't as ironed out. I like that you had the exactly same discussion with somebody at KubeCon and I said before you start a platform, before you go down that road, first do market research, internal market

research. Do you even have an addressable market within your organization or are you still too small where it doesn't make sense to bring up a new quote unquote product that you then need to sell to your internal developers. So do market research, what are their pains, how can you quantify the pain points right now and how would you solve it and how would you make this pain go away and how can you then also prove that you really had an impact? Yeah.

I like it that you call it the addressable markets. That's really nice. Yeah. Yeah. Not my term. It's our product people came up with. had an impact. is before we start coding, Does it even make sense? Is there, looking back at your talks that you gave and also the recent one in London at QCon, is there anything else in those talks that we haven't talked about today in the podcast where you say, hey, this is something that I want to make sure people just know and understand and take away from my talk? I mean, so in my talk, I speak to like the power of community quite a lot. And you know, I think communities get the word that gets thrown out, thrown around a lot, right?

So it's hard to like figure out like, what is community like, especially in this, like work context and whatnot. But it is something that I do, like I do really try to drive in all my talks is the idea that like, you know, and I think it ties back to where we started, right, the idea that you can't think about the technical components without the social components. You know, so yeah, I think that would be the probably main thing I would want to leave people away with. It's just the idea of like thinking about the impact of the work that you do, both on

terms of like our technical systems, but also in terms of how it impacts other people, whether it's like your product end users or the way that, or your coworkers, right? Platform engineering is kind of interesting because your coworkers are your end users, you know, or your users rather. So yeah, I think it's just using that framework, I think across multiple contexts, not just like, yeah, not just, and not just like customers or you know. Yeah. Do you have an internal, I don't know, a community of practice and mentorship program?

Do you have regular internal meetups or how does this work within the times? Yeah, yeah. So we do have community of practices. So a lot of like our standards come out of there actually. So I really like lever, I really like to leverage those communities because one they tend to be passionate about the technology too, right? So it's like, I think like motivation is very rare and like expensive to cultivate. And so I really just like, I think that's like where a lot of opportunity for good work comes from.

So definitely love to like leverage like internal communities and whatnot. I think like it's, it's hard. I mean, the difficulty there right is like just sustaining them. Like that's the thing I think I've seen organizations struggle with is just like sustaining those communities, especially because they can be a lot of almost like extracurricular kind of work right but like also they've been super like essential to some of the work I've done in platform engineering with driving adoption right like I those are where I get a lot of my like technology champions right it was I'm building so for example I built a hotel based no JS library right and like some of I couldn't have done that with a lot of the folks that

I met in the like TypeScript, um, web, uh, community of practice. So definitely having those like institutionalization, like have institutionalizing things like that. I think it's super important because if it not only provides, you know, what it's providing, but it also communicates like an importance of that kind of work, right, whether it's mentorship or, you importance of that kind of work, right? Whether it's mentorship or, you know, community of learning, et cetera. I got two final questions for you.

The first question is more an organizational question. Why does the, well, let's phrase it in a different way. I hear a lot of people at conferences and they say, well, our company would never allow us to be on stage and talk about things we do internally. Why does the New York Times allow you and your colleagues to publicly talk about what you are doing internally? And may your answer be an encouragement to all the leaders out there in organizations that currently don't allow their engineers to speak?

Yeah, great question. I think, you know, to be fair, the times that we definitely have our process leagues for like getting things approved and whatnot. And I think a lot of it's though, because they want to give us, you know, the freedom to share knowledge and like also, you know, these opportunities for us to like grow as well. Like every time I go on, every time I go to a conference, like I'm meeting people and learning a ton, right? It's not just like a one way transaction. Like I definitely get a lot of out of it too. Yeah. And I think, I mean, I think it's not as surprising also when you think about what we're in the business

of, right? Like sharing information. Like our mission is to help people better understand the world, right? And that applies to the technical and engineering world, right? So I think that sharing, you know, wow, we have to be careful with it, you know, because some things can be sensitive and whatnot. You know, the general election stuff I talked about, it's easier to talk about now that it did pass, right? But I think in general, we like to

set ourselves as leaders of information sharing. And I think this is just kind of one example of our wider mission. Yeah, thank you. Hopefully, so whoever now feels themselves, hopefully more motivated to let your people present at a conference. It's a great way to not only share your experience, but then also learn because what I hear is, what I see is the more you share,

the more people are willing to share. And they come to you with the problems that they have, or also with some of the solutions that they have, which then helps you to then figure out how you can solve certain things that you've struggled with in the past. Brings me to my final question. So it's, as of the time of the recording, it's May, not May So it's the time of the recording.

It's May, not May. Well, the time of recording is April. The time this air will be May 2025. In the year from now, I assume you will be back at the next DevOpsCon or QCon or whatever conference it is. What will be the topic about? Any thoughts on what's the next big thing? Yeah, I think a bigger focus on enterprises.

It's all enterprise organizations are always a theme, I think, of how I think, approach my talks. Because I have a lot of enterprise experience. But I, as maybe a spoiler alert, I have some upcoming work where enterprise will be a huge part of the focus. So I suspect it will influence my talks as well. Well, thanks, Leslie. I'm looking forward to seeing all the new content that is coming out. We're not spoiling any beans, but it's really exciting on the stuff that you just told us off record.

But no, seriously, I hope I also get a chance to see you at some point again in person, whether it's over dinner or watching you on stage giving a talk. Folks, make sure that you are checking out all of the links in the podcast summary, whether it's the existing presentations. If it's okay, Leslie, we also put in your LinkedIn contact so that people can connect with you and follow up with you. Yeah, no, thank you so much. Really exciting. Brian, any final thoughts from you? Yeah, well, you know, it's funny because we've been doing some platform engineering talks

a few episodes ago and now we've swung back to it. Hey, there's another pendulum. But the, you know, the socio-technical side, I think, is You know, the socio-technical side, I think, is kind of a new concept. I mean, not really a new concept in practice, but calling it out as something to do, right? I mean, you could take a look at podcasts like this or other ones that are doing this or all the talks at the conference as one level of speaking about benefits, adoption and how things are working out for people. But the part that you highlighted that I feel is missing for most organizations is the internal, getting the internal buy-in, right? Thinking about the people who are going to be using these, making sure it's going to

fit their needs. Too often we see either top-down approaches to this is what our new setup or platform is going to be or these are the new tools or it might just even be a smaller group of people picking out for a larger and they're not, you know, I work in presales on this. I can't think of times when we have conversations about the wider organization who might be using our tool, what their preferences are, what their needs are. Not just, I mean, we talk about that with the group we're with, but if that group is making it, like, a lot of the people we're selling to aren't necessarily thinking about reaching out to the broader team to find that out, to make sure everything is gonna be good.

And it's, you know, I hadn't thought about it before, but obviously that's super important, right? Because you wanna make sure all your developers, your operations, your SREs, everybody who's gonna be doing all this stuff is gonna be happy and encouraged to use that, right? And it doesn't just stop when you're thinking about it and having those conversations,

it continues where once you do put in a new process or platform or tool in place, continually internalizing, sharing the wins, sharing successes, sharing pitfalls to avoid, so that it's that sharing of knowledge, right? Which you're doing at conferences and all that, that's gonna keep like interested in it. And I just don't know how much that's being thought of. So the fact that you said there's like, I guess even like studies around it and all right, is brand

new to me. That's that's kind of fascinating. I was I was a communication major in college, right? So I was, you know, more on the liberal arts side of things and how things work and it fits in to that side. So very, very fascinating ideas and topics and it's really cool to see that it's being thought of even though I hadn't known about it. So it's, yeah, wonderful. Thank you so much for being on. Yeah, of course.

It was great chatting with you both. Awesome. All right. Well, thank you everybody. And this is the, I guess this is the Technically Andy, the first podcast of our 11th year. So we've been doing this for 11 years, if you can believe it. So thanks for everyone who's been with us all this time. And we keep on learning from people like you, who are gracious enough to come on to our

show and we can't do it without guests like you so thank you so so much Leslie. Appreciate it. Yeah, thank you for having me.