DevOps is for product engineers too | Lesley Cordero

Hello, everyone. My name is Lesley Cordero, and welcome to my talk on how principles of DevOps and its adjacent disciplines, like site reliability engineering and platform engineering, fit into the current landscape of product engineering. For some context behind why I wrote this talk, it came from a place of needing to find a way to communicate the value of DevOps and how it connects to our current context in the software industry. I figured this is the perfect place to come and speak about this. Because of that, my talk is a little bit more visionary than it is nitty gritty technical, but I think it's super important for us to grow an appreciation for each other's domains. That importance is something that we're all responsible for making an effort to understand. With that said, I'm going to introduce myself a little bit more thoroughly. Currently, I'm a staff engineer at the New York Times. I'm the tech lead for the reliability platforms engineering team, which sits under our wider platform engineering organization. Prior to my current role at The Times, I was also a tech lead on several teams, both within product engineering and platform engineering. One of the main observations over my career, regardless of the domain I was specializing in at the time, is that our industry struggles with finding value in each other's work, particularly when it comes to different roles and specializations. Speaking personally, a large part of why I switched to platform engineering is because I had spent so much time in the DevOps communities when I was working to improve my product's observability footprint. Fundamentally, a lot of that had to do with the fact that DevOps is fundamentally about culture, right? It's fundamentally about bridging gaps between roles that might not necessarily understand each other, but want to. It's a bit disappointing when we see things like 'DevOps is dead' being thrown around. Because then where does that leave me and all the other folks who gravitated towards this space? It's one of the only spaces that I think I genuinely felt that the human components of building and operating software are just as important as the technical ones. This comes from a place of sociotechnical thinking, which I won't go into too much here, but that is fundamental to the type of culture I think both DevOps and platform engineering should be trying to cultivate. To further emphasize why I think this conversation is important for us to have right now, it's because operational expertise is more critical than ever, but the landscape is shifting for operations roles. I would extend that to say that it's shifting the landscape for product engineering roles too, particularly with the current excitement around platform engineering. This quote comes from Charity Majors in her keynote talk on platform engineering at DevOps Days, New York City, 2023. My interpretation of what she means by this is that operational expertise is not only very much alive, but it's actually more critical than ever. This has to do for a variety of reasons, including the role of generative AI and the chronic worry that our jobs are going to be automated away, or the fact that operations organizations are starting to be treated as cost centers, which might introduce an extra layer of job security. Holding this intention with platform engineering and its re-emergence, she also says that what it looks like is changing. Regardless, this tension is our current reality. It's important to lean into the messy details of what it means to apply DevOps principles regardless of your technical or technical domain expertise. Now, since this talk is about how DevOps fits into the current landscape of product engineering, I still haven't made up my mind on how much I agree with this, but I do think there's some kernel of truth here when Charity said that there isn't enough room for non-staff-plus engineers. It's uncomfortable to say this, because what reasonably good person doesn't want to be welcoming to junior folks? Especially given how I began this talk about emphasizing the positive impact it had on me far before my staff engineering days. I began this talk by saying about the positive impact that this space had on me, right? It's easy to say when I'm already a staff engineer is basically what I was trying to get at. The way that I've come to reconcile this is that platform engineers are supposed to be stewards of quality for our platforms. It's supposed to encompass basically what it means to build software at our company. I think in that, that is the unique place that staff engineers can have. At the same time, they have to be intentional about how we mitigate the unintentional consequences of emphasizing seniority. Ultimately, I think that has to do a lot with being able to invest in less senior folks since they're ultimately the future of this industry and because that's going to keep our industry as a total sustainable. Exemplified by the state of layoffs these past few years, there's a strange underappreciation and aversion to investing in less experienced talent. At some point, that's going to catch up to us. So, what do we do in the interim? I think both staff product and platform engineers hold the responsibility for investing in less experienced engineers through mentorship, leading by example, thinking socio-technically. One distinction between product and platform engineers is that platform engineers are often best set up to centralize operational and platform knowledge because the very nature of centralization means that platform engineers...