Words are Hard with Emily Freeman

Emily: [00:00:00] My brother was editing a podcast for me and he was like, would you like to put the explicit tag on? I was like, have you fucking met me? Get with the program, Tyler.

Matty: It’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matt Stratton. We have a, as always, a great show for you today or tonight or whenever you’re listening. But before we get into that, how about a word from our amazing sponsors? BridgeCrew is the all-in-one cloud security platform for developers. They automate and embed security throughout the entire development lifecycle so you can streamline your DevSecOps toolchain into one solution. By integrating infrastructure as code security and compliance into your version control systems and CI/CD pipelines, BridgeCrew empowers you to find, fix, and prevent cloud misconfig faster. Get started with BridgeCrew for free at arrestedevops.com/bridgecrew.

[00:01:09] The role of a developer or engineer has evolved into a security-first mindset. The ability to confidently build and deliver your software assets across the globe while also avoiding supply chain threats is a priority for organizations to remain successful. Cloudsmith is software supply chain management for modern DevOps practices. They provide a single source of truth for all software assets while integrating with the package formats your team is used to. With a focus on securing your software supply chain, Cloudsmith is truly at the heart of your DevOps ecosystem. To learn more and receive a firsthand look at their solution, please visit arresteddevops.com/cloudsmith. Rootly helps engineers manage incidents directly from Slack without ever needing to leave the tool. They handle all the boring and tedious manual work during incidents, like creating channels, looping in the right people, and acting as your scribe to document that ever-important timeline. Companies from 20 to 2,000 manage hundreds of incidents daily on Rootly. It’s super simple and easy to use. You can install it in 5 minutes or less. Visit rootly.io to learn more and mention Arrested DevOps for $1,000 off When you book a demo.

[00:02:25] Today, I am joined by friend of the show, friend of the DevOps community, friend of everybody who isn’t awful, well-known author and DevOps personality, shall we say, Emily Freeman. So Emily, thanks for joining me today.

Emily: Thank you so much for having me. I’m glad to be back.

Matty: I expect to spend the next hour talking about why you’re wrong about the Oxford comma, just so everybody knows.

Emily: That’s, that’s fine. Yes. I accept this battle is ongoing. You, you all are fucking obsessed with that fucking comma.

Matty: I think there’s a couple interesting things we could start talking about. You and I both just started new jobs and kind of moving some different stuff, and that might be interesting to talk about. I mean, by the time y’all are listening this episode, because in a lovely way we have a nice backlog of episodes at ADO, so by the time you’re listening to this, Emily and I will be like old hats at our gigs. But right now, as you’re listening, we both just started a week or either 1 week or 2 weeks ago, depending on who it was.

Emily: [00:03:27] So yeah, I’m on day 5.

Matty: Oh, see, I’m ending my second week. So I’m very an old hat there. I’ve lost my appeal as the new and shiny at the company. Emily, we’ll start with you. So what’s up?

Emily: Like, I am so excited about this move. So obviously I’m coming off of Microsoft. I was on their cloud advocacy team for a long time. And now I will be moving or am at AWS. So I am working on DevOps strategy and messaging across the entire product line. I’m really kind of focusing on how do we make all of these products make sense for the community?

Matty: That is pretty cool. I went to somewhere not quite as big. I left Red Hat, which is part of IBM, which is, if not the biggest company, one of the biggest companies out there. And I joined a startup called Pulumi. And it’s a little bit of a smaller org. I’ll put it this way. We have a weekly all-hands, the entire company is on a Zoom together every Monday and various other times, cuz you can do that. And it’s, it’s been, it’s been interesting to start up somewhere new. If you’re not familiar, this is coming back to a place that I’ve been before in a way, not the direct org, but the area. So Pulumi is around infrastructure as code and longtime listeners of the show may remember that I used to work at Chef. And there’s actually a bunch of us former Chef folks over at Pulumi, which is pretty exciting to come back and work with some old friends. Uh, and I’m doing developer advocacy over there as, as well.

Emily: [00:04:57] They’ve got some good people.

Matty: It’s really exciting and we’re growing and we’re adding the DevRel team is getting bigger in an exciting way. So keep watching this space, which is, I don’t know, that we talk about where we work very much on ADO. So to be honest, I realized I’m like, okay, so we’re having an episode where we’re just going to kind of talk about our jobs and, and a host talking about their job. And to be honest, this is maybe one of the first times it’s happened in going on 8 years of this show. So everybody forgive me.

Emily: ADO has been 8 years?

Matty: It started at the end of 2013. So we are easily now have been around for the majority of the time that DevOps has existed. Like we tipped that point where that’s a thing and we keep— I’m pretty proud of this show. I’m going to take a minute to talk about what we do, but we occasionally will kind of, when there are, hey, these are the DevOps podcasts you should listen to, or DevOps resources, ADO is usually at the top and it’s not always because of the alphabet. It sometimes is, which is a great thing about what we named the show is when there’s a list of things you should check out, we’re almost always at the top. But there was one the other day and I’ll put a link in the show notes. And it was again, kind of a list of like blogs and podcasts that you should follow in the DevOps space. And they scored them like on a matrix. Like there were different, like about, you know, like the Gartner Magic Quadrant. Oh, there should be a Gartner Magic Quadrant of that. I’m going to create that. No, it was like, there were different criteria. It was like, I guess it was like time. Timeliness or accuracy or like different things on a score of 1 to 5. And then that came up to the average and ADO was the only resource on there that scored a perfect 5. So that just tells me that this person doesn’t listen to the show. I’m kidding. I know who wrote the article. I saw it and I appreciate it, but—

Emily: [00:06:39] That’s awesome. You should feel very proud of that. The whole ADO team. Good job.

Matty: So actually here’s the thing I was kind of thinking about a little bit. So if you are unaware, Emily is the author of a fantastic book called DevOps for Dummies, which is about It’s a couple of years old now, right? When did that get—

Emily: Yeah, it was pre-COVID. So whenever that was, I think August 2019 is when it came out.

Matty: I’m not trying to say that it’s old and outdated. That’s not what I was getting at. But what I’m curious about is what has, like, when you kind of look back from the things that you were researching and the thoughts you were putting into the book, what’s a little different now? And especially as you’re looking at the stuff that you’re going to be doing with AWS around where that messaging is at. Because we can spend a lot of time talking about what is DevOps, what isn’t. We’re not necessarily going to get all pedantic about stuff, but things have evolved since Ghent in 2009. And even in the last couple of years.

Emily: Yeah, no, I think the market is really hungry for sort of the next phase of DevOps. Agile was roughly 20 years ago. DevOps is 11, 12 years ago. And so we are ready for the next sort of phase. And the thing I keep thinking about is Not necessarily like where DevOps for Dummies is now, but just how we talk about DevOps when it came about. And none of what I’m about to say is taking away from the importance that DevOps had at its time. I mean, it was absolutely fundamental and novel and all of that. But in 2009, when Andrew Clay Shafer and Patrick DeBois sort of birthed this idea, we had a much different engineering culture, right? Our teams were absolutely siloed. You had a developer team on one hand, and then you had an operations team on the other. And we had these silos and these walls over which you would throw code for the operations folks to deploy. That was sort of the setup. And so DevOps was very— a unique solution to bringing those 2 groups together, hopefully removing some of that animosity. And I think we’ve mostly been successful. Like, you don’t typically see Engineering teams in, let’s say, how do I not offend someone? In organizations that have adopted a DevOps culture, you don’t typically see that right now. Sometimes people have renamed the operations team a DevOps team. That’s not DevOps.

Matty: [00:09:02] What I was going to say, I wanted you to finish your thought, but I just want to kind of put a thing in there. What I am starting to see is the emergence of what’s called a platform team, which is what we’ve done is kind of in some ways Maybe moved the wall of confusion, but also abstracted the wall of confusion away. And we’ll put a pin in that. We’ll kind of come back to the idea of platform teams in a second, but continue.

Emily: Okay. I know, I love that. And yeah, so basically our, the way that people are set up is changing, but I think most importantly, the way our systems operate has changed significantly. We are typically not in a monorepo, typically not all focused. We have a distributed system. And so whether you’re containerized or not, things are all over the place. You have microservices, et cetera. And on top of all that, your people have become more distributed. We don’t typically go to offices anymore. We’re all over the world. We have remote teams much more than we used to. And so how do we apply these DevOps principles that we know work to this sort of distributed ecosystem and distributed environment? And the cloud adds this really unique aspect of this. And the thing that I keep thinking about is in many ways, any type of managed service It removes the pain, it abstracts the solution, but sometimes you lose visibility. And so how do you capture that telemetry, that observability, the visibility into how your system is actually working while still not getting into the weeds on some of this stuff? So that’s sort of what I’m thinking about, like in this sort of distributed DevOps model. What’s next for DevOps?

Matty: [00:10:37] I think that’s really key to think about, like Black boxes are not inherently bad, right? Because there’s plenty of things in my life that I don’t have visibility into, and I just need to know they either work or they don’t and what to do if they don’t. Right. And I think that’s where those abstractions come in. Like you do have this part where you sort of, when you’re commoditizing a resource, that’s, that’s even a little bit of the thing to think about is that it’s, for lack of a better word, make your peace with the fact that you don’t see All those pieces. And that’s something that’s hard when we’re changing, cuz you’re like, wait a minute, but how do I know what’s happening with how resource allocations happen? And you’re like, but do you need to know?

Emily: Yeah. Right.

Matty: As long as the promise is fulfilled. And, but you also have to be able to tell what to do if it’s not. And how do you mitigate around that? So you’re kind of moving the abstractions around and understanding what it is that, that matters.

Emily: Yeah.

Matty: I was going to say that’s the sort of problem with any kind of a lift and shift mentality of any kind, whether it’s to your data center, to the cloud, or moving from IaaS to a containerized thing is you’re going to want to see, how do I reason about this in the context and the lens that I’m used to? And this is the thing that happens in any kind of transformative work. Used to have this happen at Chef a lot is I’d be— someone’s like, hey, want to check out Chef? We have this whole way that we build systems. And so we want to know, there’s a, you know, this is a very common way that would happen. There’s a, we have the 16-step process we do to build a server. How does Chef do all of the steps? And they would come and ask, how do you do this? How do you do this? How do you do this? And so wait a minute, let’s take a second and look at this, because if you do step 2 different, you don’t need steps 3 through 10 anymore. So it’s not, and it’s the same kind of place where this can happen when you think about containers as lightweight virtualization. And then you’re gonna be like, how do I know If it’s doing this and you’re like, you know what? As it turns out, you don’t need to, but you need to know other things. And it’s still about what do you, why did you need to know this thing that you are used to knowing other than just to know it? Because you’re like, I always have to know that.

Emily: [00:12:42] Yeah. So the, obviously we think about incidents a lot more than maybe the average. And so I was hearing someone speak about rollbacks the other day and it was just, you need to know what was changed in the system and who changed it, et cetera, et cetera, which we can talk about. You arguably don’t need to know who changed it, but whatever. And then it’s Yes. Okay. Yes. System A was updated, but our systems are so integrated. I mean, it’s, it’s a spaghetti of roots. Like I think a lot about it’s, it’s plant roots. There’s no orderly way to see what root is, what belongs to one plant versus the other. And so yes, System A might have been the thing that’s changed, but if you’re myopically looking over here, you’re going to miss things that may have been impacted or maybe reacting to whatever else has happened over in System B or C, et cetera. And so that’s what it’s like. How do you get visibility into that quickly?

Matty: Well, and I think there’s all sorts of places in complex systems where we had contributing factors that may have been a precipitating event that we don’t have visibility into now anyway. Right. That’s sort of the thing. It’s, oh, today I can tell, I can look at this particular load on, on, on this VM or on this thing here or whatever, but I can’t tell that when it’s in serverless, when it’s this thing. And you’re like, okay. But there were other things that were happening that you accepted that you didn’t have visibility into and you somehow managed just fine because it delivered its promise. Like, you didn’t know that the power company rerouted how electricity delivery was happening to you. Like, all sorts of things change in your complex system that you have no knowledge of, and you don’t need to. And that’s the thing for us to understand, is that you, you don’t have to know every single thing that might have come in because you need to know it to the boundary upon which you can influence the change. Right. Whereas, whereas it’s going to that contract or promise that the system is supposed to deliver.

Emily: [00:14:37] Yeah. It’s a little bit like the decisions we made about logs. You obviously, you can’t save every piece of data that ever happens to a system. So what, how do you define what you should be able to see and what you shouldn’t be able to see? And again, like with the, I mean, just stack traces, how do you see a stack trace to the whole system, especially if you’re in a cloud provider and have a CI/CD. And it’s like, you do. I think we have for good reason and positive things have come from it. We’ve abstracted responsibility, but I, yeah, I’m just, I’m really into this visibility aspect right now. It’s like, how do you decide what you need to know? How does the customer get visibility into areas that they don’t think they need to know, but you know, maybe you get extra information. Is this an opportunity for machine learning and artificial intelligence and AI to kind of step in and provide some of those insights across the DevOps story. I don’t know yet.

Matty: So I, I want to also think a little bit about, we could talk about analysis of, of our complex systems a lot. And I think we will, but I want to go back to when we kind of talked about where the ways that our teams work. And one thing that is potentially a hot take or whatever, or contentious is not all silos are bad. That’s the thing we talk a lot. There’s a reason I think there’s a lot of stuff in the DevOps movement where it feels like we over-rotated on things. And we did for a really good reason because they are the things that are harder and they have to be stressed. So for example, people get the impression that when we talk in DevOps, we, all we ever want to talk about is culture and we never want to talk about tools. And that’s not true. But the reason that we talk more about culture is you don’t have to tell engineers to play with tools. They’re just going to do that. Right? Like that, that will happen. You don’t have to stress it. Because that piece of the equation kind of gets handled, but the stuff that’s hard or is not necessarily immediately apparent. And so the same thing we were very big about, you gotta break down the silos and it’s not really about making even a flat organization. It’s about cross-functionality.

Emily: [00:16:40] Yeah.

Matty: But silos as they exist, there’s a reason that we have silos, like not the abstract silos, but literal grain silos. They exist for a reason and for safety.

Emily: And so, yeah, you gotta separate sorghum from wheat.

Matty: Right. So I think there, there’s definitely place because I think when you get too close to this, you get into that idea that DevOps is NoOps, right? Which is just that everybody can do everything. And by can, I don’t mean are enabled to, but are capable of. I still feel like I have this conversation so often about pushing left. And this came up. I was on a, I was on a pretty, pretty cool webinar the other day for A Cloud Guru. And actually Jess Kerr, who’s one of our hosts, was on it and Keshav Williams and Donovan Brown. One of the things that came up is kind of through the conversation was this thing about we’re pushing everything left. And I was like, but the thing we have to understand is remember when we talk about pushing left, we’re not pushing responsibility or we’re pushing awareness and thought, but we’re not pushing the work left. But that’s what people are hearing when we’re saying push the operational ideas towards the developers. It doesn’t mean we’re asking the developers to do the work of the ops people. We’re asking them to That, that in that lifecycle, the left is like where we’re thinking about it in the lifecycle, which means as a component, we’re thinking about that thing, but we’re not saying— if you sort of said like through this matrix or this kind of iterative steps from left to right, okay. Step 2, if you will, has always been done by developers. So we’re going to push things to the left, which means now it’s in step 2. So those people who were working in step 2 just do all that shit now too. We’re like, no, bring the people who You’re taking step 4, what used to be step 4, and moving it to step 2, except you’re bringing the people with it too, right? It’s not just the— it’s, you’re not moving work left, you’re moving awareness left and consideration left. And that’s sort of the thing I think people run into is this idea that what we’re trying to do by enabling this is you’re not trying to make someone do the work of 2 people, which is unfortunately what usually ends up trying to be the thing, right? You’re saying you’re creating this awareness. But there’s still domain expertise. Ops is a skill, right? And it’s like the example I always love to give is years and years ago, back when CDW did have competitors, although now I don’t even know how relevant CDW is anymore. Everything changes. But I worked for this company called Midwest Computer Works in the mid to late ’90s. I was the webmaster.

Emily: [00:19:00] Thank you. Is that your actual title?

Matty: That was my actual title.

Emily: That’s amazing.

Matty: And I worked, and the person that I basically worked with the most was the one who did like, did kind of all our advertising, cuz it was a mail order company and she put the catalog together and stuff. And it would drive her up a wall because people would come to her and be like, hey, Tammy, this afternoon, can you teach me everything you know about Photoshop?

Emily: Oh yeah.

Matty: Right. And so that’s that same idea when we think about this thing about, okay, we’ll teach developers how to be ops people. Okay. This is, that’s a domain of knowledge, right? Like that you’re tapping on. So I think it’s about having, you need to have awareness, but you don’t have to have the expertise. It goes back to the whole myth of the 10x engineer and that everybody can know everything and you just can’t. We used to be able to actually, like there was a time I ran systems where I could keep the whole system in my head.

Emily: Exactly.

Matty: And you know what it was? It was a LAMP stack basically.

Emily: Cool.

Matty: You can do that. You can’t do that.

Emily: No, absolutely not. It’s impossible. No, I think I mostly agree with what you’re saying. It’s the concept of being aware of someone’s specialty, of understanding their constraints, their motivations, their concerns, hopes, fears, et cetera. That is radically different than knowing how to do something, right? And I mean, like, there’s a— I can read JavaScript mostly. I can understand some of the fundamentals of that language community, but no one needs to see my fucking JavaScript. It’s really bad. So it’s like that. I can appreciate someone else’s skillset and that helps me better communicate and better understand the entire system. That does not make me a frontend engineer. It doesn’t even make me a Node engineer. Like, I don’t need to be close to that at all. I also, to be frank, I think we’ve over-rotated on some of these terms. Like, we’ve been leaning on some of this so heavily and it’s just getting more and more hand-wavy. And I just, it’s okay, cool. So move left. What the fuck does that mean? Tell me how to actually apply this to my system. And I think that’s where DevOps in its current iteration is coming to its— not close, but we’re on, we’re in our late adoption phase and it’s time to think about what’s next.

Matty: [00:21:11] That happened even in kind of the earlier days because it felt, I think it was like 2014 was probably the big year when it was like every single talk at every single DevOps Days was about empathy. And you know why? Because nobody knew what the fuck empathy was and they had to get beaten over the head with the idea to be empathetic. Cool. You know what you got to do next year? You got to tell me how to do it now. Right? Like it was, I had a talk I gave, I gave it a Deserted Island DevOps last year, but I gave it a different name. But the non-cutesy Animal Crossing name of it is, okay, you’ve convinced me we have to collaborate. Now, how the hell do I deal with people? And it was the, okay, I buy it. You got me empathy. But this stuff matters.

Emily: Cool.

Matty: I would like to do that now, please. And I think that’s the thing, the time for, and it doesn’t mean that the conceptual conversation stops because not everybody in the entire entire tech industry understands the concept of shipping left— shifting left. Shipping left, that’s what I do. That’s called rolling back all my code. I’m always shipping left.

Emily: Wait, you might want to work for Evergreen. They might be hiring.

Matty: Um, that’s when— that’s when you pull things out. Oh, oh no, removing code from prod. So a red diff is called shipping left. Oh, we just created it. We just created a word. We created an idea. So when you’re removing unused stuff from prod, you are shipping left. Anyway, but now it’s okay. Now tell me how to do it. Right. Okay, cool. I understand we have to do that, but where’s the practical application once you get the concept? And I think that’s the hard thing to communicate and get people to understand. You’re right. That’s again, it’s in the later adoption. Now we’re like, okay, generally speaking as an industry, we’ve got these first principles relatively well understood.

Emily: [00:22:46] Yep.

Matty: I still think you are being a little optimistic about that adoption. And how prevalent it is. I, I would put it this way, not to, to pick on this, but like I spent the last year working primarily with public sector customers, especially in state and local government. And there’s all sorts— this is a lot of this is still new, but that also applies to a lot of enterprise too, right? There’s, so there’s still plenty of, there’s, there’s plenty of people to talk about who, who still need to get the base ideas, but there’s also a lot of people who are like, cool, again, got it, Emily. Yeah, we gotta shift left. Cool. Now will you please tell me how to do that?

Emily: No, you’re absolutely right. The adoption phases are gonna overlap, right? So as people— and I’m not saying that DevOps doesn’t have, uh, usefulness or value to people now. I’m saying I don’t want to wait until the very last curmudgeonly company adopts this concept to be thinking about where we’re going And I think you see this hunger. Like if you, if you look at the startups, it’s okay, cool. We got this. What’s, how do we apply it to this massive distributed abstracted cloud managed service? That’s just, that’s where I’m thinking right now. It’s like, how do we start to answer those questions? How do we even start to understand? Yes. From a people component, but also a systems component.

Matty: [00:24:10] I’ve been, been thinking a lot about this idea of cloud engineering and as a discipline. And I think that’s the thing, because I think, I think cloud engineering, if we think about that as this idea of a discipline, is what most people mean when they’re saying SRE. Like, that’s the thing that’s, it’s tough with SRE is actually a very specific way to implement how you do cloud engineering or how you do it. Site reliability. And a lot of folks are not doing true SRE, and this is not a one true Scotsman kind of thing. It’s just saying, no, you actually aren’t doing that. And that’s okay. I’m not saying you’re doing poorly if you don’t do SRE, but that’s not what that is. And, but in absence of a more precise term or like, it’s okay, but then what do I call it? Okay, cool. I didn’t have nothing else. This is the closest match. And I think this idea of cloud engineering also really extends to this idea of providing platform. And I think that’s what a lot of these platform teams, whether or not this platform, like, cause that’s the thing is, as I am, if I’m running a platform team or I’m part of a platform team within an organization, I’m providing a service to the people that are building upon that platform. Right? Like for gross oversimplification, it’s my internal Heroku. Like that’s the dream of what people think they want to do is something like that to be like, hey, I’ve got this feature team over here. That’s just building a product. Like honestly, they really hopefully don’t have to give a shit about too much of the operate, the nuts and bolts of the operation. They need to think about it from the operation of the application.

Emily: [00:25:42] Yes.

Matty: Right. And providing its service and what you can do at scale and what you need to do when you get to scale is you do need to have this platform team. If it’s a platform team or you call it, like you think about that’s made up of cloud engineers who are providing that, whether it’s your OpenShift running locally. Yes. I’m running OpenShift on my laptop. I have tried to do that. But you know what I mean? Because again, like where it goes, that’s sort of the thing. Like if I’m providing a platform, it’s relatively trivial and should be not that important for the consumers of that platform to know exactly how it works. They need to know what it offers and how to consume it. Just like we need to do that if we’re consuming a platform or a service like AWS. And this goes back— Corey loves to talk about this and he’s not wrong. This multi-cloud myth that it really is because that’s the lowest common denominator, because you’re not using the platform. Now, if you want to have something like that, Then yes, what you have to do there is you have to have your platform in front of it. If you, if it’s for some god-awful reason, it’s very important to you to be evenly distributed across Azure and AWS, then what you need to do is you need to build a platform in front of that that manages all of that bullshit for you.

Emily: [00:26:54] Oh my God. That’s giving me a headache right now. I’m gonna go take something. No, I, yeah, I think it’s also interesting in cloud engineering, it feels less like you need to understand all the underlying infrastructure and more that you need to be an infrastructure optimizer, right? You are trying to optimize the system based on the applications you are running and what you know about the infrastructure it’s on. Oh, like that, that for me is right where that sweet spot is. Would you agree with that or no?

Matty: I think so. I think so. Because it’s just, it’s like saying that a sysadmin has to understand the components. I mean, it’s really just moving the things up. As a sysadmin, I have to understand the components of the servers that I had in my rack. So that I could create, then present them as resources to the consumer of that. Okay. All we’ve done is we’ve moved that instead of me caring about CPU, like the actual physical machine that I was again abstracting away to the consumers of it. Now it’s services from a cloud provider of some kind, right? Or my own thing that I’m running. Right. So I think that’s what you’re doing is you’re just, we are moving it along, but you are providing And that’s where I think it really does come back to that the real idea is providing a platform. And it doesn’t mean you have to create— when we say that I am creating and providing a platform within my organization for my development teams, if you will, I just can’t think of the right— I keep wanting to say a feature team because that’s the best way to not overload it with that it’s developers, because who knows what it’s made up of and it doesn’t really actually matter. But we’ll just say feature team for this purpose, right? So if I am providing a platform for these feature teams for my business to be able to deliver value.

Emily: [00:28:33] Yeah.

Matty: What happens behind that, that’s up to me because that’s an abstract, right? Like I am just saying, here’s the thing you have. And the oversimplification is just from a container scheduler perspective, right? It’s just sort of saying, cool, here’s a container.

Emily: Yep.

Matty: You don’t, and it will run for you. And I though have this expertise and knowledge to be able to figure out where that goes. And I am intentionally being a little obtuse by saying that because it’s the lowest common denominator of a unit of work. Yeah, in that way, but there’s so much more to it. But what you’re, what you’re doing— so again, what it doesn’t— when I say I’m building a platform or creating a platform, it doesn’t mean bespoke, artisanally crafted Kubernetes that I build in my own special way with my own thing. I can cobble that platform together 100% from other services, and, and I don’t even have to put a portal. I’m not— again, I’m not talking about that. What I’m saying is I’m just saying I’m Creating and presenting the platform upon which the business can run. That’s what a platform is.

Emily: Yeah, it’s a service with an interface. That’s it. Like, yeah. I think also from a human perspective, one of the problems I would personally like to solve, and I don’t know that I can because it’s, it might actually just be a human problem. So it’s little lizard brains back there. They’re always messing with us. But I think if you look at the stack and so at the very top, like thinking like a frontend engineer really focused. On the user interface. And then you go down and it’s okay, I’m looking at backend engineers working in whatever language you want, Python, Node, whatever, doing these services. And then you look at the sort of platform team and then you look at the actual underlying infrastructure. I feel that across the industry, people prioritize the skill levels at each of those points in the stack differently. Right. And sometimes it’s devs who win. I would say oftentimes it’s devs who win. And then like sometimes Google obviously overindexes on, in my opinion, overindexes on SREs and that sort of in their internal hierarchy, as far as I understand it. So how do you stop valuing people based on the skill sets they have? And that’s what gets really tricky because when you’re talking about the whole software development lifecycle and thinking about it cyclically and moving things left and all of that. So much of bringing that awareness is removing the fear that you aren’t valuable, the fear that you’ll be replaced, and, and adding that the empathy we’ve been talking about for 12 years, which is this shit is hard. It doesn’t matter where you are, it’s hard. It’s hard in different ways, etc., etc. And people are different, people have different passions and different natural abilities, but it’s all valued the same.

Matty: [00:31:19] I think it’s a visibility problem and I don’t know how you solve it, but I’ve said before that working in ops or system administration or whatever is a lot like being a corporate lawyer. Nobody knows when you do your job well, but they know when you fuck up. So the same thing, your, your normal internal counsel at your company, most of the time, like you don’t know all the times they kept you from being sued.

Emily: Yes.

Matty: Right. But you only know about them when, when they miss or even necessarily their fault, but right when things fail and the same thing tends to happen within operational roles because it’s just that work is not visible. And I’m not necessarily saying it should be. This is not about making sure that, because, because this happens outside of tech too. It’s like at any time with an organization, the more visible and the closer to someone who doesn’t understand the domain, being able to make the connection to value, right? Who are people in an organization that almost everybody understands what they do, and what their success means for the company? Sales. Yeah, right. Who are some of the most visible people in our organization? Is sales. And very— I don’t want to say rightly so, but completely understood why, right? There’s, there’s— because capitalism. Got it. So, so I’m not, not necessarily saying you shouldn’t prioritize that, that it’s wrong, that’s what happens, but that’s why. And versus if— so when we think about as you’re going down that stack, so you’re again, as you’re thinking like within, let’s not even talk about within the tech part of your organization within that, but just over the overall organization, someone who doesn’t have, it’s, I’ll tell you this, you know, I get, I work for, you know, an infrastructure as code company, like people who are not in tech, it is almost impossible to get them to understand what something like Pulumi or Terraform or Chef or anything like that is because they don’t even know that there are literally hundreds of thousands of devices that are running running a website, right? So you’re like, I don’t even know why this is a problem that you are— that needs solving, is that you have hundreds of thousands of things that have to be configured. Because what do you mean? Don’t you just write some code and you’re done? If I even understand that.

[00:33:30] So it’s totally fine. Nobody should have to understand everything. But those more plumbing, like, under— again, the further you go down the stack, the less visibility there is to the impact, even though its actual impact is equal. And I think that’s just, again, like you said, this might just be a general people. I mean, there’s all sorts of things that organizations can and should do. And I think as a, as an industry, there are things we can do, like how we talk about stuff. It’s again, this idea of it’s why NoOps was a bad idea, right? Because, and continually like thinking about operational excellence and thinking about these things as disciplines that provide value. And why they provide value. But the further you get down that stack that you described, the closer you get to utility, right? Which is nobody— what’s probably a very important, one of the most important things to a manufacturing concern? The freaking power company. How does a power company get any recognition? Of course not, because they just provide a service. So the closer you are, the further you get away from that visible thing, the product, the further you get away from the visible part of the product, the harder it is for people to even be aware that you exist, much less the value you provide. So it’s hard. I don’t have an answer, but it’s hard.

Emily: [00:34:53] Yeah, yeah, I know. So maybe we should title this podcast, I don’t know.

Matty: There we go. Maybe that’ll be it. We were saying we were trying to think of the title. I think it’s something that we should be continually trying to be aware of, in especially as people who provide education and content and development within the industry about how we talk about things. And, and I think the thing is, again, talking about this idea of that cloud engineering, like, that’s a thing that kind of makes sense. Like, people kind of get that, right? Like, we’re talking about it. And I— that’s why I really always go back to how much I really like the idea of operational excellence, right? You’re really starting to elevate and understand that exists. And I think this comes in as well— this can come in as a leadership problem problem. I feel comfortable enough that I’m distanced enough from this that I don’t think anybody will know. But very early on in this podcast, probably not this episode, but in the life of ADO, yeah, probably maybe, yeah, probably about 6 months into the show, Trevor and I had a guest on who awkwardly was a customer of the company where Trevor was working and I had just left. I don’t remember the exact overlap, but doesn’t matter. She was a 10th magnitude customer. And during this recording, the furious typing that Trevor and I were doing to each other about, because of all the things we couldn’t say, because it was someone that, that we had a business relationship with, but she made a point and said something to the effect of the value of DevOps is it protects— something about to the effect of it frees up time for the most important resource in your organization, the developers. And I was so like, oh, especially because I’m not a developer. I come from ops. And you’re like, I know you, I always knew people believed that, but nobody ever said the quiet part out loud like that. But so that’s the thing.

Emily: [00:36:45] Now we all do.

Matty: Yeah. Yeah. Now everybody says it. So that’s sort of the thing is to think about is that the value is not based upon the function. It’s your visibility. Visibility. Yeah. It’s hard.

Emily: Yeah. I’ve been having this conversation for the last I don’t know how many years. I have a principled issue with massive companies saying, we’re obsessed about the developer. And if it were a totally inclusive term, no problem. But I would say 90% of the operations community does not identify as a developer. I had this fight with myself writing DevOps for Dummies. I defaulted to engineer. I recognize that in other countries and other, like, disciplines of engineer, it means a very specific thing. That has flaws as well. AWS uses builders, which is interesting in that I think it’s— that is AWS, not the industry. I’ve never heard that term outside of that ecosystem. But yeah, it’s just, how do you speak about the full industry without excluding people?

Matty: Words are hard, which is— that is what we’re going to call this episode. At least I like it. That’s what, that’s what the URL is going to be called. I may give it a different title, but it’s definitely going to be The show notes will be at arrestedevops.com/wordsarehard.

Emily: [00:37:56] I like it. Yep. No, I mean, I’m just going to continue using engineer, but it is, it’s hard to think about and it’s just, it’s hard to educate people on what other people do and why it’s important without making anyone feel like they need to know that because they, they don’t obviously. So you don’t need to know every single detail of every single discipline. I know how to change my windshield wipers. I’m not going to go change the tires. You know what I mean? So there’s a way of appreciating someone else’s value and their contributions without having to take all of that responsibility onto yourself.

Matty: Well, I think that is, is where it lands. Words are hard. How do we get better at our words, but mostly get better at our actions? And this has been a really great conversation, just sort of going a little bit into what’s changed. I would love to hear it. We would love on the show. Go ahead and tweet at us @arrestdevops. You can tweet at Emily too. I’m sure she’d love to hear it. What do you think?

Emily: I’m verified now. Did you hear?

Matty: Yes. Also, by the way, so I just wanted to point out, I believe you were like, oh, now that I’m verified, do I have to not swear? I’m like, do you not? I hope so. I was like, there’s a lot of comedians that are—

Emily: [00:39:01] I swore 3 times in the thing and people are thinking I’m serious. I’m like, no, I’m not fucking serious. You think I could clean up my mouth at this point? No, it’s a lost cause. Embrace it or walk away.

Matty: This episode is definitely tagged explicit. Actually, I think I tagged them all explicit, like, just by default. Fault at this point. It’s just safer.

Emily: Can I also say my brother was editing a podcast for me and he was like, would you like to put the explicit tag on? I was like, have you fucking met me? Get with the program, Tyler.

Matty: I think I, I could be wrong, but I’m fairly certain that, cuz my kids, my kids don’t listen to this show, but they listen to my other podcast. And I think they were unable to listen to it on their iPad because it’s tagged explicit and I’ve got content limitations on their devices. So, so we just listened, we just listened to that show in the car and it’s fine. But if you head over to arresteddevops.com/wordsarehard, you can see this episode’s show notes, which I’m not sure exactly all they’ll have in them. We’ll probably put in a link to Emily’s book so you can do that and any other fun stuff. If you go to arresteddevops.com/itunes, you can leave us a review in the iTunes store. I know it is technically called Apple Podcasts now. But I still call it the iTunes Store, and so does our website. And, but actually, leaving the reviews, that supposedly helps other people find the show, and we read them. And if you— I mean, you’re already listening to the show, but if, if you aren’t listening to it on Spotify or iHeartRadio or Audible, we are on all of those places if that’s a better place for you to listen to the show. Now, I just found out about Audible, uh, a week or two ago that we were listed there, and And I guess that’s a place you can listen to podcasts. I just listened to audiobooks there, but it is what it is. Hey, by the way, so is there an audiobook of DevOps for Dummies yet?

Emily: [00:40:48] No, I asked Wiley if we could do it and they said no.

Matty: So my, my thing with that was I got the audiobook of Accelerate and Nicole. Yeah. Here’s the problem. So I like to listen to audiobooks. As I’m going to sleep.

Emily: Yeah. Same.

Matty: And I tried to do that. And as I told Nicole, I said, I can’t have you reading me a bedtime story. So I haven’t really been able to listen to the audiobook yet. That’s funny. I have read the book. I just haven’t listened to the audiobook, but yeah, that’s the downside of when it’s an audiobook with someone and you listen to them the way that I do, it gets awkward. But Emily, this was fun. You haven’t been on in forever. So what’s up with that? Now we’ve got another 4 years from now, you’ll be on the show. Again.

Emily: Exactly. I, my new role’s more outward facing than, than my previous one ended up being. So I’m excited about that.

Matty: Oh, cool. You can come on anytime.

Emily: Woohoo.

Matty: So this is Arrested DevOps. And remember, there is always DevOps in the banana stand.