Making DevOps Beginner-Friendly with Laura Santamaria

Laura: [00:00:00] And this isn’t some type of snake oil. This isn’t a miracle that’s going to fix your organization because I’m never saying that I’m perfect.

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. Really excited about today’s topic and an awesome, awesome new guest. But before we jump into that, let’s hear a word from our sponsors. This episode is sponsored by CircleCI. Designed for modern software teams, CircleCI’s continuous integration and delivery platform helps developers push code with confidence. Trusted by thousands of companies, from 4-person startups to Fortune 500 businesses, CircleCI helps teams take their software from idea to delivery quickly, safely, and at scale. Visit arresteddevops.com/circleci to learn why high-performing DevOps teams use CircleCI to automate and accelerate their CI/CD pipelines. If you are like most of your friends in DevOps, you probably prefer using open-source solutions for observability, but you also wish you didn’t have to sacrifice scalability, performance, and simplicity. With Logz.io, you get the best of both worlds for your cloud environment. You can use the tools you love at the scale you need. Logz.io is a fully managed service that offers complete cloud observability for engineers on one unified platform: log management and cloud SIEM based on ELK, and infrastructure monitoring based on Grafana. To give it a try for yourself, sign up for a free 14-day trial today and logz.io/ado and for your chance to win a free Logz.io t-shirt. The worst thing about the Arrested DevOps podcast is when it ends. You’re left wondering what to do next. What are you going to listen to on your commute home? How do you occupy your time when walking the dog? What are you going to listen to during the quarterly all-hands meeting? But fear not, dear listener, there is a solution. You need to subscribe to Software Defined Talk right now. It’s a weekly podcast that recaps all the news in cloud computing, DevOps, and enterprise software. The hosts, Cote, Matt Ray, and Brandon Wichard, will keep you up to date on all things cloud while offering tips on how to optimize your Costco haul and how to PowerPoint. It’s a fun, free-flowing conversation that will keep you entertained and informed. What are you waiting for? Subscribe to the podcast today by visiting softwaredefinedtalk.com or by searching for Software Defined Talk in your favorite podcast app. Today, we’re going to be talking about how we can make DevOps more friendly and accessible to people who are new either to the community, to the concept, to the type of work. And joining me today is Laura Santamaria from LogDNA. Laura, can you introduce yourself to our guests who maybe aren’t familiar with you? Tell us a little bit about yourself and why we’re talking about this today.

Laura: [00:03:17] Sure. So, as Matti said, my name is Laura Santamaria. I’m a developer advocate at LogDNA, and I come from a self-taught background. So, I just really like talking about how to get people comfortable, how to bring people into the fold of how to do things, how a good culture might sound like. And my background is pretty checkered. I have a degree in science, and that Then I moved into teaching and education in a science museum, and then eventually wound my way into programming and development where I owned my first production system as a junior engineer. So, I learned a lot, and I like teaching other people about it. So, it’s just kind of a really favorite topic of mine to talk about how beginners can start to feel more comfortable.

Matty: It’s really kind of on point for this show, and longtime listeners may remember that back in the heady days of 2013, when Trevor and I started the show, this was supposed to be a beginner podcast. Because at the time, when I was starting to learn about DevOps in the years leading up till then, I listened to a lot of podcasts to learn, and they weren’t really very geared towards people who were new to it, which is, I realize, funny to say that it wasn’t geared to people new to DevOps when this is like in 2011 and 2012, when DevOps was only a few years old. But I felt like I had to sort of force my— be able to push through references and things that I didn’t have context for. So, I wanted to create a podcast for people who were new to it. And the line we always said was, this is for the people where your boss read about DevOps in the in-flight magazine and came to you and said, hey, we need some DevOps now. What happened is, over time, you know, we realized that not You know, we have an audience of all kinds of different backgrounds and experience with that, but it’s still part of our heart and soul of this show is to be welcoming and introduce this and help people who are just trying to get started. So, I love that we’re talking about this. I’m also amazed that 100-and-something episodes in, it took us to do a show that’s called Making DevOps Beginner-Friendly. So, I guess we’re not the most self-aware podcast that ever existed. But again, for longtime listeners, you would never refer to us as being self-aware. So, Laura, let’s start with it. Like, why is it hard to get started with this?

Laura: [00:05:50] I think this really gets us started into getting into the heart of the matter right away. Because to me, there’s so many things that cause DevOps to be a hard thing for people to get started in. So, first things first. The definition of DevOps is really hard to actually nail down. You know, everyone keeps saying, oh, well, you can buy DevOps, right? No, you can’t buy DevOps. It’s not— it’s a title now, yes, but it’s not something that you can just add to your organization and suddenly you have it. It’s a cultural shift, and there’s a lot of other things to think about there. In addition, though, to me, To get into this cultural world of being part of a DevOps team or part of a company that does DevOps in some shape or fashion, you need to have more history. And it’s like a chicken and an egg problem. So, you have to have enough background to understand how this whole thing works, but you have to get the chance to get into the hardware and get into the experience of what it’s like to not have it work. To be comfortable there. So there’s just this weird dynamic of you need to have the experience and you need to have the history and you need to have the hardware and you need to have all of these things, but you need to get part of this world before you can get the history, the experience, the hardware, the anything you can think of to understand the culture. So that’s kind of how I see that it’s really difficult to break in and feel comfortable.

Matty: [00:07:26] Context is a big part of this, right? And I think for folks who have long history in, whether it’s in operations or kind of, or creating software, doing this, and the why this is better sometimes becomes a little more apparent because you’ve been in the shit, right? You know, you’ve seen how it’s hard, right? And so, To a lot of folks then it’s like, well, this is natural. But if you’re coming into it, maybe you don’t have that context. It’s what’s interesting. I find that it could either be that there’s not as much of an understanding about why to push through to do the hard things to make it better. And then likewise, I can also see with not having that context, some of this just seems like common sense, right? Like it can also be like, wait, why is this a whole movement? Isn’t this just, Why wouldn’t you do things that way? And then you don’t have the, it becomes harder to be able to see how to affect that change.

Laura: [00:08:31] Absolutely.

Matty: If this is the way you’re used to it, right? Or this is your introduction to this kind of work.

Laura: And I guess I’d say I’m one of the people who would have that kind of like, this is common sense because when I took over that first production instance and I was, it was my first job being an official developer, things like that, I found myself in a group, well, the repo itself was built, the entire codebase, the entire system was built by a team that was focused on DevOps. I didn’t know anything different. And so, for me, it was just, I came in and this is just how you do things. And it makes sense. Of course, it makes sense. But I always notice that I forget that people don’t see it as common sense. So, when I walk into a new project or a new company and they tell me, oh, you know, well, dev does this, and then we hand it to ops, and then ops does this. And, you know, marketing’s over here, sales is over there. I sit there like, wait a minute, aren’t you all supposed to work together? Like, that’s kind of the point of this whole thing. And then I forget that, no, that’s not how we had been doing business for so long. So, just that experience in general is even more different if you want to talk about that kind of context.

Matty: [00:09:52] Yeah. And I think that’s too, without having that history, there’s a reason that people have been working the way that they’ve been working. It’s not because they were dumb and nobody figured this out, right? This was older, more traditional structures of engineering and operating systems and everything all arose to solve problems the way the world looked then. And that’s— and I think that’s where it can be, can be difficult, because either it seems like this is just an obvious thing and the only reason you don’t get it is because you just can’t figure it out and you’re an old fuddy-duddy or whatever kind of thing, versus like, because when you’re trying to affect change, you need to, to figure out how to bring people along for that, and you need to see where they’re at and what their context is. And so many things historically seem like solved problems now, right? You know, um, I, I remember, you know, when I had my new hire orientation when I joined PagerDuty, and there were a lot of folks in my new hire class who were, you know, relatively new in their careers that were, you know, just, just starting out, and they’re kind of walking through the history of PagerDuty and explaining where the product initially being just for managing notifications and an on-call schedule. And I could see so many folks were like, how was this a problem? Like this, this, and I was, and for me sitting there having lived through it a decade before of spreadsheets and email aliases and manual things, I was like, I would have killed to have had this because things, but things were different then. Right? And now, luckily, those are solved problems, but not everyone’s come along to that yet. So, having that context, I think, matters. But then, if somebody’s beginning, they may be beginning their DevOps journey, but they also might not be new to software engineering or operations. So, you know, someone new can either be somebody new to tech altogether, Can be somebody new to the workforce, can be somebody new to this practice. I think we’ve been talking a lot more about people who are either new to tech or new to the job force. But maybe we think a little bit about some DevOps beginners are actually very senior and experienced technologists, but they are, from a DevOps perspective, they’re new. And what do you think might make it hard for them? Like, maybe think about why is it hard for them?

Laura: [00:12:27] Right. I was going to say that, for me, the biggest thing that I find whenever I’m interacting with people who we would consider new, whatever their background is, is just helping them understand that you’re allowed to ask questions. And I think especially with people who have, you know, been around the block with being a software engineer, being on an ops team, and they’ve been in that, let’s say, a waterfall model, or even just that other culture, coming into this culture, they don’t feel like they remember how to ask questions. They don’t feel like they understand that this is a safe place to just come and say, you know what? I don’t understand why you’re asking me to do this. I know I have all this background, but why are you asking me to do this piece? And I think there’s a comfort level and a safety perspective almost that is really something that we have to work on maintaining whenever we introduce somebody to this world. And it’s hard, right? This isn’t an easy thing. There’s entire industries dedicated to how do you set up conversations, right, with people who are new to something, been around the block a while, making that whole space available and interesting. And to me, this is one of the biggest things that I think, for example, DevOps Days, when it’s done well, this is what DevOps Days does, is it provides the space to feel comfortable and ask a question and say, I don’t know what this means. And it helps helps introduce people who are the safe people to ask questions of, because they’re the ones who are getting up, proposing an open space, being there, and being open to questions, and pretty much saying, this is your time to ask me anything. And I think that’s really what a good DevOps Days does. And I think a lot of meetups are here too. But my biggest problem is, how do I get them there so that they feel comfortable to show up? Then they realize they’re starting to— it’s okay to ask questions. They’re starting to understand that once they get there, but reaching out to the rest of the community can be a little difficult sometimes.

Matty: [00:14:33] So, I think another thing to keep in mind is that for folks who have been around the block, so to speak, and spent decades working in technology, it’s We’ve heard this all before is a lot of times how people feel. There’s always something new and the new thing that’s going to save the industry and do whatever. And it’s very easy to become jaded towards that. And especially when you feel like the folks evangelizing it and shouting from the rooftops about it are not like you. And I can mean that in a lot of different ways, but the way that comes to mind first is, and I think we’ve gotten better in the industry about this, but for a long time, and this was one of the biggest challenges, was the advocates, the people who were doing this kind of work and were talking about it, were all the digital darlings, right? Were all the cloud-first, you know, again, it’s the typical, you know, your Netflix, your Facebook, your whatever. And so how many times, I can’t tell you, Or they hear, that’s great, but we’re a bank. And so, I think one thing that helps is understanding, and the more that we all share our stories, the better identification can come. And that’s the thing, that’s one of the most powerful things I think that happened for the whole movement was DevOps Enterprise Summit. Because before DevOps Enterprise Summit, there was a belief that DevOps in the enterprise was different. There was this very short-lived idea of enterprise DevOps, There was— and the thing that was interesting is a lot of us in the community, we knew that this work was happening in the large enterprises, but nobody was talking about it because that was the way the culture around these organizations was, was you didn’t get up on stage and you didn’t write blogs and do things like that when you worked for a bank or an insurance company or a government entity. And DevOps Enterprise Summit came along, And all of a sudden, all these folks from these large enterprises and government organizations were getting up on stage and talking about what they did. And I think for a lot of folks who felt almost, you know, maybe they wouldn’t put this in those words, but probably felt excluded or felt that it didn’t apply to them, said, wait a minute, oh, now you’re talking my language, right? Because I have a different problem than Uber does, but I have a similar problem that JPMorgan Chase does. And so, I think it’s really powerful. I think sharing stories is— and I think the stories need to be as broad as possible, right? Because everyone’s going to identify differently. So, when you can find that, and again, that’s why, back to your point, one of the most powerful things in events like DevOps Days are open spaces, or at other events, birds of a feather, when it’s like, okay, great, I want to go talk to someone who’s got a really similar use case or problem or environment so I can identify. And then the thing is, once you know something can be done, yeah, you’re probably going to be able to do it. But if you don’t know that it can be done, it can seem insurmountable.

Laura: [00:17:53] I think that There’s a lot of ways that we, as a community, I guess, anybody pretty much looking at DevOps as a culture and saying, this is our community. One way we can also make people feel more comfortable is going to them and saying, hey, there’s options. Hey, I’d like to talk to you about where you’re getting stuck. I want to offer my assistance. Just, you know, offer help in whatever shape or form. One thing I can say is going out and talking to random companies or even just putting myself out there on— there’s some different Slack communities. There’s a Slack community I’m part of that I pretty much said, yeah, sure. I can answer a question about X or Y or Z. And I’ve had people ping me in DMs because they want to know, I’m stuck here. How did you do this? Have you done this before? Can you help me? And being able to model that experience and model how to do it and model that helpfulness as well, I think, is really another way to make sure people understand that this isn’t an exclusion and this isn’t some type of snake oil. This isn’t a miracle that’s going to fix your organization because I’m never saying that I’m perfect. But I can at least help and I can help you get there. That’s another piece where reaching out to those people that are maybe not completely comfortable reaching out on their own is a really great way to help make it more beginner-friendly too.

Matty: [00:19:26] There’s just lots of different channels. I think that’s the thing we have to remember. You have to meet people where they are. And that’s both in their context and in their— where they are in their journey, but also just where they actually are. Not everybody goes to conferences. Not everybody goes to meetups. Not everybody’s on Twitter. And you’re not going to find one place that’s going to work to talk to everybody. And I think that’s another way to help make this thing more welcoming is to find the ways that people want to be communicated with. So, we’re talking a little bit about, like, how we can do this from a larger perspective. Then if we kind of pivot a little bit and think about from within a team. So, if you have a team that’s already kind of working, like, maybe you’ve got a team that’s following great DevOps practices, you’re being very successful, It’s great. You bring in some new folks who maybe haven’t done this work before, haven’t been part of that. So, so what can a team do to help these folks follow these practices, like learn and adopt them, and not have them feel like they’re less than because they haven’t done it before?

Laura: [00:20:35] I think probably the biggest thing to me, again, is that safety, that awareness that there’s a, there’s someone you can ask. So, identifying people who have the patience, because not everybody does have the patience to help onboard someone new, right? Not everybody does have that patience. And you don’t want to force someone who’s not necessarily going to be great at it to try to pull it off on their own. But identifying those people who are going to be OK about answering the same question a few more times, answering all of that a few more times, but also to make them feel like they’re part of the group and bringing them in and noticing those opportunities for, this is where I can help you understand how we do things. This is where I can help bring you into the culture of how we do DevOps. That kind of information, as well as, like you said, meeting them where they are. If they do better with documentation versus talking to somebody and asking questions, maybe you set them up for success there with documentation and information and as much as you can share with them. In addition, set them up with, if they need the hardware to understand, like, Oh, I can go have a sandbox where I can go learn the actual process part. Set them up with sandboxes, make it something that they can go and play with and know they’re not going to necessarily take something down that’s important. So that any of those type of learning situations that we would do for anyone on a team, really, but explicitly do them for that cultural side as well. And to me, that’s probably one of the biggest parts is just, again, Showing people that they’re welcome to come and learn and not expecting them to know it all already, which I think is where a lot of teams kind of say, you’re just going to figure it out as you go. Let’s go do this. That’s too intimidating, to be honest. I mean, we’re all human, right? It’s really intimidating to join a new team and suddenly have to hit the ground running. We all talk about drinking from the fire hose and all of those lovely terms that we love to use. But it’s still intimidating, no matter how many times we say it.

Matty: [00:22:41] I think another thing to remember is that some of this way of working is going to inherently feel wrong to some folks because they haven’t done that. And I think that’s a thing to acknowledge and be aware of and not turn it into, okay, well, this is either A, B, you know, so I need to be, when someone’s uncomfortable, Encourage them to ask questions, but also encourage them to share why they’re uncomfortable. Because a lot of it may seem insecure to people. They may seem like you’re compromising security. Oh my, how do we possibly give devs access to prod? This is wrong. This is not how we did it everywhere I’ve always worked. And what a lackadaisical company I must have just joined. And now I’m really scared. And kind of giving that opportunity to surface it, because also, just because someone’s been working differently, they may have some interesting insight too. People coming in will ask questions about things, or they will raise challenges about things that you might just accept and then realize and say, oh, not saying we should go all waterfall and complete, like, you know, wall of confusion here, but we never really thought about that. That’s kind of a problem maybe. And, or so you either can say, oh, you know what, that’s a really good point. And here’s how we address that. You know, I didn’t think to point that out, or That’s a really good point. We should actually think about that a little bit because maybe we missed that. So I think it’s, I think we should always be open to how people that are new to the team can help contribute to make it better because they have a different perspective, even if inherently that perspective might feel a little polarized. So not being dogmatic about it. I mean, it’s again, it’s saying like, well, this is how we do things. That’s great. So we’re going to follow these approaches, but that doesn’t mean we can’t discuss them and dig into them and continually iterate and improve. I think another piece of when you’re bringing folks in is it’s really important to look at opportunities, whether it’s with pairing, whether it’s with shadowing, you know, rather than just sort of turning someone loose and saying, okay, here’s our docs. Right? And that talks about all the ways we do it because so much stuff is undocumented knowledge, especially when it comes to styles of work and communication styles. One thing that I think is really important, I’ve done this on other teams, is we have kind of a shared document that’s a living document that we review a couple times a year, which is our rules of engagement. It’s our how we work document. And it’s not necessarily a whole bunch of things about like the queue for this type of work is in this Jira board and whatever, but it’s here’s how we communicate when we’re on meetings together. Here’s how we talk about problems together. Here’s a— so it’s a lot of that stuff you might call cultural things that have become the norms of the team that really we feel when we’re participating in them, we feel like they go without saying. But the only reason that happened is because we’ve been doing them. And maybe we were there when they developed. So, just as it’s just as important to document the technology and document your process, documenting your style in so much, not in a dogmatic way, but just again, whether it’s saying, this is our way of work for this team, and we review it regularly. And adapt and iterate and improve. I think that is something that can be really helpful when someone’s coming in and it’s a different way of working.

Laura: [00:26:19] Another thing that I like adding on to that is having the first— having each new person spend time updating the docs. Just essentially saying, you know, not only do I want you to start understanding how we work, the communication, all of that information of just what our team’s style is and all of that. If there’s something here that you’re finding that someone is doing, add to this doc. We expect you to add to this doc because there is going to be that unknown knowledge, that undocumented knowledge somewhere out there that needs to be added and it needs to come in. And I think that also gives people the sense of the team as well. Because it lets them know that, yes, you’re supposed to document this. And part of documenting it is also questioning how it works. Because if you can’t question it, how do you actually know enough to document it? How do you know enough to be able to build something out of nothing? And so, to me, that’s another component. It’s like, I hate to do this, it’s like joining an incident. And sitting down and being the scribe for the incident because you don’t know what’s going on. And the very first thing you should do is go write down what’s going on. So, there’s so much to look at there as well, just bringing that kind of idea in. And if you can explain that, I think it’s one way to make it clear that this isn’t set in stone. These are guardrails. These just kind of help us go down the road together. But if we need to repair the guardrails or change the direction that they’re going, then let’s do it. It’s not worth it sitting there and just saying, these are fixed forever, if they’re heading towards a cliff. That doesn’t really work. So, I have to agree with you on that point. And just, that’s how I have always thought about it, are those guardrails going along next to the entire team.

Matty: [00:28:17] I think the thing I would caution, and I really do like the updating the documentation as you go, and especially as you’re beginning, is how that gets framed, right? Because there maybe isn’t, you know, you’re not looking for success in that process by how much you updated. But I always like to think about it when you learn something, when you discover something and it wasn’t there, right? Add to that, and you’re testing the documentation by following it along. But it’s, I guess the way I’d say it, it’s unlikely that this would ever happen. But in the unlikely event that the docs cover everything, then that’s fine. You don’t have to touch them, right? Like, because otherwise, but if you sort of set this expectation to say, well, your job is to update them, right? Then I’m going to think that my criteria for success is I’ve made changes. And then maybe I’m going to feel like I have to introduce changes. I’m either going to feel unsuccessful because I didn’t, or I’m going to look for changes that don’t need to be made just so that I can say I did what you asked me to do. So it’s a little bit of like validate and update, validate and confirm and update the documentation. So, and it’s a really good test of that stuff to have someone go through that and actually do the things. And I’ve found myself, it’s another reason why, and then on the other side, besides just being incumbent upon new people joining, But it’s why runbooks, even if you feel like you know this process super well, but you have a runbook for it, you should actually follow the runbook. I don’t care if you’re the one who wrote the runbook. You should pull it up and follow it because that’s how you’ll be able to know what’s going on, right? And make sure that and validate that it’s working and that it’s valuable and that you didn’t miss a step because of assumption, right? Or that you haven’t changed something but forgot to update the doc.

Laura: [00:30:15] Right. And I mean, so a little bit about my background. One of the jobs I’ve had is a technical writer. And one of the big things is you go through the docs every single time, go through and do auditing, because the UI changes and you don’t have it updated. You have this piece or that piece that hasn’t gotten updated properly. So, like you said, even if you’ve done this 1,000 times, You never know if a step has slightly changed, like the arrow is now on the left side of the button instead of the right side of the button. Make sure you check it every single time. And to me, that’s also the same with bringing someone new on board. It’s also a chance for the veterans of the team to validate the same schedule of books and information and all of that at the same time. So in general, I think that’s all in there.

Matty: Now, when we think about the larger community and our culture of the movement, if you will, if that’s the way to espouse that or kind of encapsulate it, what makes it feel unwelcoming to people?

Laura: [00:31:30] There’s a lot to unpack here, I think. And I’m going to speak based on my background because I think that’s the place where I have the most background to actually speak about it. In general, one of the things that I think can be intimidating is just like joining any new group, right? You don’t know everyone. You don’t, you don’t have those connections yet. You don’t know who’s safe to talk to in terms of asking beginner questions versus who maybe it’s a little too intimidating to go ask them something. And I think that that experience can— because let me put it this way, because there is so much going on in our community, it’s really difficult to understand where to go. And that can be an unwelcoming experience right there in general. I got lucky because I fell in with an entire meetup group and then ended up at DevOpsDays Austin as a volunteer, and it’s just kind of snowballed from there. But like I said, I got lucky because my company put me in the right position. My company at the time put me in the right position to be there. I don’t think everybody else gets that chance. So, the onboarding experience just to the community is just as difficult as the onboarding experience to a new team, except you don’t have the given of we’re all at least in the same email database, right? Or Slack or Teams or whatever you’re using, right? So, without that, like, I’ll give you an example. I didn’t know about Hangouts Slack for, like, 3 years. No one told me because I didn’t know, and I didn’t know to go look for it. I had no idea there was a community Slack for DevOps. And I found it and I’m like, wow, where were all these people when I was trying to figure this thing out? Like, kind of like, shit, throw the table, you know? Ah, but by then I already knew enough people that they told me where to go and I just started joining the channels they were in and then branched out. And that’s kind of how it works, I guess. So I’d say that’s probably one thing. And then For those of you with experience, and I say this in the most loving way possible, it can be sometimes really intimidating to talk to all of you with all your war stories and be like, I don’t have those, sorry. Am I allowed to share my information now? It can be, it can be just something intimidating, but I don’t want to stop people from doing it though, because I learn a ton from war stories. But at the same time, how can we as a community make it clear that even if you don’t have war stories, you’re still allowed to be here?

Matty: [00:34:33] I think that’s a really good point because we tend to default to those experience stories and because it’s very freeing to be able to share them. But, and sometimes people do use that as a way of proving credibility, right? And then, then it can feel like, well, I don’t have that, so I don’t have credibility. Uh, so thinking about how you can share your experience, but in the way of, oh my goodness, thank goodness this isn’t true anymore, right? Not like, oh, you sweet summer child, you have no idea how things used to be, right? But more like, I’ll give you some context and But then also maybe invite a little bit of, okay, but what still sucks? So, the thing is, so, Laura, you’re telling me, you say, I don’t have war stories. Oh, you do.

Laura: I know I do now.

Matty: And they’re about DevOps, right?

Laura: Right. Yeah. I mean, at the time when I first joined, it was like, I’m kind of sitting there listening to all these people with so much more experience than me. And it was just like, I’ll just sit back here in my corner. Little did I know that I had all of this wealth of experience that I could share. And I mean, this is the other thing that I’ve been telling a lot of the new folks, at least here in Austin, is some of my war stories don’t come from me being in DevOps. Because part of the experience of what the DevOps culture is, is about communication. And I can tell you so many stories from my history about communication that aren’t even funny anymore. Well, they’re funny now, but at the time, they definitely were not all that funny. So I guess to me, there’s that— one of the things that we like to do in general with people is to build a community, you share an experience, you share, and you try to say, I have something in common with you here, let’s go talk about it. But when people don’t understand that you don’t have to be a dev or an ops person to have that experience that you can then plug in and share. When they don’t understand that, they don’t feel like they can be part of the community. And to quote, kind of, well, semi-quote, one of the famous DevOps books about the Phoenix Project, right? It’s not necessarily that it’s only about dev and ops. There’s security, but Even if you go outside of the quote-unquote technical people to go to talk to marketing, support, sales, all of these people all have the same stories. And we all can be part of the same discussion, and we can learn from each other. They don’t have to have stayed up till 3 AM working on a production server that decided to go sideways, and your customers are screaming at you over the phone. And by the way, that’s probably support dealing with the customers screaming at you and all of those things, right? Like, you don’t have to have that experience of being glued to a computer screen while your manager is right behind you breathing down your neck while you’re trying to understand what just happened. You can still also be that person that the next morning had to deal with the boatload of emails that came overnight from all of your partners that are saying, hey, this thing didn’t work last night. Why not? They’re still part of the conversation. And I think that’s one of the places where we can build ourselves as a community is to just say, let’s all be part of this together because how else can we move forward?

Matty: [00:38:08] And I think there’s an interesting thing that can happen. And I’m going to tread lightly with this because it might be a little controversial. But like you said, shared experience is a thing. So I think you can have a broad space, but I think it’s also really powerful to sometimes have those— the ability in an ephemeral way to sometimes be able to share that scar tissue, that shared experience. And I think that’s where like things like open spaces and BOFs and stuff really are fine, right? Because you’re like, okay, you don’t have to have like this whole experience to be able to come to DevOps Days again, for example. But somebody can totally propose an open space, which is, you know, AS/400 admin war stories, you know, and cool. And so for that, in that moment, you can say, but you’re also identifying that that’s what that shared experience is going to be about. And you don’t have to. So yeah, you maybe will want to have had that experience to participate in that 30-minute conversation that’s happening. But it’s not about the whole conversation of the movement and of making things better in our community, but you get a chance to be able to identify to that. So I think we want to be inclusive, but part of that is also still giving the ability— I’ve been struggling with the right way to say this— is to have some exclusivity. And it’s not about keeping people out. It’s just sort of about having a moment and having a space to be able to share that particular experience. But it’s not a required admission to the bigger conversation.

Laura: [00:39:51] I look at that as there’s this term that we used to use back when I was working in the university systems called communities of practice. And this is back when I was doing research and things like that. We talked about having communities of practice because it’s, it’s not saying that you’re necessarily excluding people and saying that they’re not allowed to attend, they’re not allowed to show up, but they’re not allowed to come learn from you. And personally, like, if there’s somebody who wants to talk about something really, really specific, I kind of want to go sit and learn from them because they probably have something in, in their talk that I’m going to glean. And if I can abstract it, it can help me somewhere else. I’m not going to say I have their same shared experiences, but I definitely do have something that I can learn from them. But a good setup for a communities of practice scenario is essentially kind of like an open space. And it’s kind of like birds of a feather. And all of these things that have made unconferences successful is this experience of We need to be able to say, I’ve had this experience, I don’t know what to do with it, come help me. Or, I’ve had this experience, come learn from me. And that, to me, is what a really good community of practice can be. And that, I think that still has a space in DevOps Days, in DevOps in general. We should still have those. But we should be aware also of the wider context. That we live in. I mean, it’s the world as we know it, I guess.

Matty: [00:41:28] I absolutely agree. I think one last thing I want to think about that’s a little more tactical and a little less— and is when we think about sharing practices and how we especially— and this is going to be kind of a tool-ish kind of bent. But when I look at there’s a lot to learn when you’re getting involved in DevOps, right? And it can seem really intimidating, right? Because it’s just a broad amount of tools. There is a lot of technology involved in DevOps. Tools are part of it, right? And that’s great. I think that a lot of times when we create tools and do things, we’re like, we’re going to throw up some API documentation and kind of throw that out there. And then, you you’ll figure it out. And I think thinking about ways to understand that people who are trying to come into this might be coming from where part of what the story needs to be is, why am I doing this? Why does Kubernetes matter? Rather than just, okay, now go run these commands and look, and now you have a cluster. Why did I want a cluster in the first place? And not saying, well, point to a blog that says that, but make that part of the entire story when I’m going through a tutorial. So what I’m saying is, if you’re building tutorials, reels, make them journeys, right? So it’s not like, okay, cool. So I wrote this automation and now I have an S3 bucket. Why did I need an S3 bucket? So what’s the story, right? And, you know, say, okay, the problem you’re trying to solve is X, and here’s how you do it with this tool. And then you’re like, oh, okay, I can recognize and I can empathize and I can identify with that problem, right? So now it makes some sense to me. But when it’s— but we tend to write tutorials that are, here’s the thing to do to make this outcome, to make this, this, or make a thing happen. But, but what’s the larger thing? So I think that’s a big thing to think about when we’re, when we’re building ways to, to bring people to help them learn is, is we keep— because it goes back to context, right? Where does this fit into the big smushy world? Of your life.

Laura: [00:43:36] Yeah, the ability to zoom in and out is probably the biggest thing about DevOps to me. That ability to just understand how the world itself is put together and then zoom down into a piece and work on it, then zoom back out. Because, I mean, we can’t talk about the entire pipeline of the world and, you know, taking a look at DevOps and shifting left and all the lovely jargon that we have everywhere, right? You can’t do that unless you can zoom out to at all of it and then be able to zoom in to look at one small piece. Like, you have to be able to have that dichotomy of vision, I guess you could say, of just being able to zoom in, zoom out. It’s like having a camera with a really, really good lens and you wish that you had it. And so you could zoom in on, like, you know, the butterfly on the flower, but able to zoom out to catch everybody in the picture. I think that’s probably the most important part.

Matty: And I think that’s a pretty good way to wrap us up there. DevOps is about zooming in and zooming out. You heard it here first. So, normally, this is the time of the show when we talk about all the great conferences you can go to and everything, but, you know, kind of topically, things are shifting, but that doesn’t mean that there aren’t places where we can catch up with each other in a social distancing kind of way. So, Laura, where Where can our listeners catch up, catch up with you and see what’s going on and interact in a very safe, non-pandemic way?

Laura: [00:45:05] Right. Yeah, exactly. As long as we don’t do that.

Matty: Right.

Laura: I’m definitely going to be virtual at Spring Live. It’s an online virtual 24-hour conference. Spring Live is happening March 19th, I think. But keep an eye out there on Twitter. Um, I mostly will be saying where I’m going to be on Twitter, and I know that’s not necessarily everybody’s jam. So if you don’t know how to reach out to me there, you can also, uh, keep an eye or send the contact info, I guess, to LogDNA. This might be another way to reach me, I guess. But if you look for me on Twitter, I’m @nimbanatus on Twitter, and hopefully we’ll be able to actually spell that in the show notes, or there’ll be a link to your Twitter in there. There we go. Otherwise I have to spell it up over here, and that would be lots of fun. But you can keep an eye out for me there, and that I’ll be posting where else I’ll be on the internets. But I also do this thing called A Minute on the Mic, so you can come watch the videos. They’re going to be posted up to YouTube, so just look on Twitter at, at hashtag A Minute on the Mic, or go to admititonthemic.com. There’s also a YouTube channel. It’ll be lots of fun, but mainly I get a bunch of other people to answer a question in a minute and it’s really very entertaining. So that’s the best places you can find me right now.

Matty: [00:46:27] Awesome. Yeah, my upcoming conference is 100% virtual and it’s FailoverConf. I will be one of the speakers at FailoverConf, which is happening on April 21st. We’ll have a link in the show notes, but if you go to failover-conf.haysummit.com, you can register.

Laura: You—

Matty: the CFP may still be open at the time that we’re publishing this episode. So if you had a talk canceled and you want to be able to have an opportunity to share that with people in a virtual way, FailoverConf might be great for you. So head on over to arrestedevops.com/beginner-friendly-devops. For this episode’s show notes, where we’ll have links to these things we’ve just been talking about, as well as you can find Laura’s Twitter there. And if you go to arresteddevops.com/itunes and leave us a review in the iTunes Store, that actually does help people find the podcast, apparently. And, you know, you never know, we may, may read it on the show for you. And we also are apparently on Spotify and iHeartRadio, if those are your jams. So, Laura, thank you so much for being part of the show today. It was a great conversation, and I’m really, really pleased we got to talk.

Laura: [00:47:42] Yeah, thanks for giving me the space to talk about this, because it’s always something on my mind, and I’m so happy that both you and I were just like, this is the best topic ever, let’s go talk about it. So, yeah, thanks for listening.

Matty: I’m Matt, @MattStratton. This is Arrested DevOps, and remember, there’s always DevOps.

Laura: In the banana stand.