LogDNA is now Mezmo but the DevOps State of Mind podcast you know and love is here to stay.

Liesse Jones: Steve Pereira is a DevOps enthusiast and an expert in software team performance. He leads the largest DevOps community in Canada and is the founder of Visible, where he coaches teams to boost flow and value using his four key maps of DevOps.

Welcome to DevOps State of Mind, a podcast where we dive deep into the DevOps culture and chat with friends from small startups and large enterprises about what DevOps looks like in their organizations. 

I'm Liesse from LogDNA. Join us as we get into a DevOps state of mind. 

All right, Steve, thank you for being here. Great to have you on the podcast. 

Steve Pereira: Thank you for having me. 

Liesse Jones: Before we dive into all the fun DevOps questions, can you just tell our listeners a little bit about yourself and your career up until this point?

Steve Pereira: Sure. I've been in tech for over 20 years in various different roles. I actually started in, I started by fixing computers, like physically building and fixing them and breaking them a lot. And that got me into tech support. And then I got into desktop support, and then I got into IT management, and then I got into build and release engineering, and then systems engineering, and then infrastructure engineering, and then consulting, then I was a CTO, then I started Visible. 

Liesse Jones: Full range of experience. That is awesome. What has been your favorite part of that? I mean, probably it's where you are right now, one could assume, but I like to think that they're like shining moments in each of those different phases of life that stand out.

Steve Pereira: Yeah, I like to think that too. I think that's a good way of looking back. Certainly there's this strange relationship between challenge and adversity and enjoyment, especially retrospectively, like when you look back, some of my worst jobs have been some of my happiest working moments because you have… you know, misery loves company. And you work with folks who are also in the trenches with you, and you're both like neck deep in the mud. And you're sort of looking over at those people. And you're like, “these are my people. We're getting through this.” And when times are easy or things are going well, you don't necessarily form that same bond, you’re forming a different type of bond.

And then there's other cases where you're kind of in the middle and things can be competitive and you can have different incentives. And so that's all to say that I think you're right, that there is positive in every experience and looking back, I've seen no shortage of that. I’ve felt very lucky to do all the things that I felt like doing over the course of my career. I never went to computer science school, like I'm not a traditional engineer in any sense. I'm very bad at writing code and I've always been focused on kind of the human/machine interaction. And now I'm focused on the human-to-human interaction.

Liesse Jones: I love it. 

Steve Pereira: And tech is like this undercurrent thing that kind of ties it all together and makes it interesting and complicated. But, you know, as I've gone further in my career towards this kind of human-to-human aspect, it's definitely got more rewarding, more complex, and far more interesting. 

Liesse Jones: I find it really interesting that you bring up the phrase, “misery loves company.” I have found as my career has progressed, like sometimes when things are going too well, I second guess myself and feel like things need to be hard for a little while to grow or to teach me a new experience that, you know, I may be oblivious to.

But I'm also trying to challenge myself to not think that way. You can still grow and be challenged and motivated by things, even if they're not hard. Yeah. I don't know. It's like a personal battle I'm dealing with right now.

Steve Pereira: Yeah. Well, I totally hear what you're saying and you don't have to manufacture that also.

Liesse Jones: Totally.

Steve Pereira: I mean, it's partially just a question of aligning yourself towards a north star that is challenging and valuable instead of, you know, we get into that point where we're like, okay, well now what do I do? Or how do I best apply myself? Or how do I best take advantage of the situation or contribute without that north star is very—like you're basically just looking at the tip of your toe and the next step, instead of like the top of the next peak. Right? I think that taking a step back and saying, oh, wait a second, things look okay. But maybe that's because I'm not looking far enough in the distance, or I don't have clarity on the destination and I'm just doing okay ‘cause I'm walking the same path over and over again. 

Liesse Jones: Yes, absolutely. I think that's a great way to frame it. 

So knowing that you focus a lot of your time and headspace on solving the people-to-people problem, I'm curious what you think DevOps mean—or what it means to you. I like asking this question of everybody because everyone's answers are different, which is the whole point of having this podcast is to illuminate all of the things that it means. So, what does DevOps mean to you?

Steve Pereira: So many things, but I can be concise and precise about this. I think it's a big problem for that very reason, that it means something different to every single person. That to me has been the Achilles heel of DevOps since day one and something that I have kind of lamented very publicly in some cases. 

One of the first things I ever did in the DevOps space was I gave a talk, in Ghent at the five-year anniversary of DevOps Days, which was in 2014. And my talk was, “DevOps is a MacGuffin.” And for those of us who have no reason to know what a MacGuffin is, which is everybody, unless you're in film school—which I'm not, I have no business talking about this—either a MacGuffin is a thing like a plot device, right? Most people have seen Pulp Fiction and it's the briefcase, right? It's a briefcase that no one knows what's in the briefcase, but it doesn't matter because it's like the mysterious thing that kind of moves the plot along. That's the way I think about DevOps. And it hasn't changed. Like since I started thinking about it, it's just—it's a thing that we've followed to get us further to where we're going, but I don't think it's valuable in a sense as a clear target. It's anything but a clear target. 

And so part of what I've talked about since I started talking about DevOps was the moment you start talking about DevOps, you should stop talking about DevOps and start talking about a specific outcome or target or deliverable or facet of what is encompassed in that so that you can actually make some progress. Because otherwise it's very difficult to have conversations where it means—like, try having a conversation about value or something that two people don't have a common understanding of. Like, you'll just run in circles. 

But if we talk about continuous integration, if we talk about trunk based development, if we talk about infrastructure as code, we can start to make progress because it's a little bit more defined what that means, what that is, what it delivers. Nobody is buying DevOps. They're buying a specific, valuable customer outcome. So the more we focus on that and the less we focus on whatever it takes to get there, I think we have more productive conversations because that's what business cares about customer outcomes. Customers care about customer outcomes. We should all care about customer outcomes, whether that's internal customers or external customers. So whatever's going to get us there. If our gap is we don't have enough automation in terms of infrastructure or our branching strategy is ineffective, we should get to those specifics as soon as possible.

And DevOps is sort of like the solar system in the universe. It takes you from like everything down to like something slightly more targeted. But inside of that is where the people are. The people are in a city, on a continent, in a country, on a planet that's tiny inside of that thing.

And we have to get to the street corner, where you’re standing across from someone else, where there's some intersection that you can talk about. And you can say from my perspective, here's what it looks like. And the other person gets from where I'm standing, here's what it looks like.

And we can say, oh, that's because you're on the Southeast and you're looking Northwest and I'm on the opposite. And now we know where we are and where we can go.

Liesse Jones: I love that. I think that's a great way to explain it, but I would challenge it a little bit and ask you if you think the concept of DevOps has been helpful as a tool for those conversations to happen. Yes, I agree it's confusing. And people aren't saying the same thing or speaking the same language. But as a “movement,” if you will—I'm using air quotes for those listening—do you think that it's been helpful?

Steve Pereira: Oh, a thousand percent. Yes, absolutely. I mean, we have a mountain of evidence that that is true. My specific point about DevOps is that it's necessary but not sufficient. It's something that gets you from having one silo in development and not caring about what's outside of that. To now you have two silos that are very closely related and hopefully somewhat intertwined, between development and operations. But now, and what I'm really interested in these days—and I think a lot of folks are getting interested in—is what's the full range, what's that full scope of value creation and delivery across the organization, which includes dev and includes ops, which are very, very challenging aspects of this. Often what we find is that the real big hairy problems that are slowing us down are now outside of dev and ops because we've done a great job with this. DevOps has really driven a lot of valuable insight and conversation and it allows people to get on roughly the same page and then dig in and be like, okay, well, inside DevOps, let's talk about this specifically or for us to get to our vision of DevOps what we're lacking is these capabilities or this level of performance, and that's super, super valuable. 

Liesse Jones: Yeah, absolutely. And so you're saying now the challenge or the goal that people are chasing is incorporating the business, and the marketing, and the sales, and the finance aspects as well. Is that right?

Steve Pereira: Yeah, because I think—and largely because DevOps has been so successful—it really has busted that wall between dev and ops and provided a much healthier understanding of what it takes to build and ship. And it's no longer the bottleneck, we no longer have that constraint between dev and ops.

We do in a lot of places that, you know, they're on their way, but, you know, conceptually, we used to have that block was just like, we wouldn't even think about integrating those things and we wouldn't even know where to start. Now we know what good looks like. And we know that there's a pretty clear path to success there.

We have metrics to show what good looks like, and people can sort of plot themselves and say, you know, we're not quite there yet, but we can see the light at the end of the tunnel. We know what it's going to take to get there. And so I think very soon, and some folks are already walking this path right now, is what's the next constraint? What's the next bottleneck? What's the next pain point that we need to tackle in order to get to that next level of performance?  

Liesse Jones: Absolutely. From our perspective internally at LogDNA, I feel like we are very lucky to be able to already work in that style, but we're just shy of 150 people. It's a lot easier to implement at the size that we are right now. And having started this when we were 40 people a couple of years ago I think has made it a lot easier.

How do you think massive enterprises are doing right now? Not to throw anyone under the bus, but…

Steve Pereira: Yeah, no, not to throw anyone under the bus. I mean, there is a spectrum, I would say most organizations, a massive enterprise or otherwise, like I know small companies that really struggle with cross silo collaboration—it's not hard to find yourself in a really challenging structure and workflow that is not facilitating collaboration or value delivery. 

I think it's very hard for us to actually wrap our heads around what it's going to take to really build a machine that helps us do our work together as separate people who have separate capabilities and narrow focuses and fields of view. That is a hard, hard problem for people to solve.

And our default isn't to put our hand up and say, “I don't understand what's going on and I can't see what's happening.” We're sort of encouraged to put our heads down, push through, get the thing done and asking for help can be seen as a sign of weakness. And asking questions can be a sign of not believing in the goal or, you know, not understanding. There's a lot of risk in collaborating in some of the most valuable ways.

The vulnerability, the transparency, that it takes to really collaborate effectively comes with a lot of discomfort sometimes, and is not welcome in a lot of organizational cultures. So I think that's a big hindrance and that's where we see this big stretch or spectrum of capability is because it's not necessarily organizational size. But it’s much more likely that you're going to run into those problems because of Dunbar's number, like the number of people that you have to stay in touch with and the level of dependency that's present in an organization, it really is a function of size 99% of the time. Unless you're a company like Amazon, where from the very beginning, they said, we're going to have this two pizza team concept and that is never broken.

And they've crafted an organization around these very strict rules that are built to avoid that problem. And the number of organizations that follow that level of rigor and principle and structural strategy is almost zero. It’s single digit percentages. It might even be less than 1% of total organizations in the world. It's very hard to do. 

I'm involved with organizations all the time where they want to get there. They want to do that. Between knowing that that is the goal and getting there is this desert with fog, and Lego pieces, and quicksand, and vultures and it's pitch black the whole time. It's really not clear how to go from where you are to that place, because culture is a complex system. And when you start moving the dials and pulling the levers, you don't know what to expect. And it's very hard to predict what is going to make a difference and move you more towards that target operating model. 

Liesse Jones: Absolutely. You're doing some work and helping organizations see a little more clearly as they walk through that desert. You've coined this phrase, the four key maps of DevOps, which I would love to dive into. I think these are really good, foundational frameworks for people who are maybe early in their DevOps adoption or midway through, they think they've figured it all out and they need to push themselves to really unlock their full potential. So, let's talk about the four key maps of DevOps. The first one, outcome mapping, talk to me a little bit about that. What is outcome mapping?

Steve Pereira: Maybe the best way to start from a high level is why these exist in the first place. And that is, I got fairly obsessed with value stream maps when I first started using them in a very rough way, in my last role as CTO, we had a lot of tight deadlines, we had a lot of ineffective and inefficient processes, and we were looking at big backlogs of work, whether it was onboarding clients, or onboarding new hires, or getting features out of the door and value stream mapping was basically—I used it in the most basic sense of just like laying out what are we doing and how long does it take to do anything? And that worked really, really well. 

Then I actually started to sort of look at, okay, well, how do we sustainably change the organization based on what we discover in the maps? Which led me to capability mapping, because it was sort of like, okay, well we found all these opportunities in the value stream, we found the parts of the process that aren’t working very well. How do we improve them and who's going to do it? And so capability mapping was looking at all the stakeholders that were involved in that value stream, where they were in terms of capability and skill level, and whether the gaps that we identified had any clear path to getting better.

Like if we identified that we need test automation, then the first question would be okay, who's going to own that? And we look around the team and nobody owns it right now, so no wonder it's a problem. And then what's it going to take to get better? Well, we don't have any documentation right now so there's another reason why it's like, no wonder it's not working. And then, you know, it takes forever to train people on this. And so digging into capabilities was the next step. But as I tried to share this with folks and use it outside of my personal context, I quickly ran into the problem of like, we're not really clear on what we're doing or what we need to do. And that's where outcome mapping was born. 

Outcome mapping is like my completely ignorant effort to create something that takes us from, what are all the things that we want to how are we going to get to a specific target? I say ignorant because there's many different ways you can do this. There's existing maps. There's people use impact mapping for this, and there's all kinds of stuff that I didn't know about. And so I just built this out of complete ignorance like a lot of engineers do when they don't have time to research all possible alternatives. But it did the job. It would take us from all the things that we could possibly look at, focus on a single outcome, and then break that down and look at what's between us and that target outcome.

So I'll come back to start from the beginning with that context, that was probably really distracting for folks. 

Liesse Jones: It was great. We're full circle now. Back to outcome mapping.

Steve Pereira: We're back to outcome mapping by way of everything else—almost everything else. 

Liesse Jones: Yeah, it's great.

Steve Pereira: But outcome mapping is, let's take pains, goals, ideas, questions, lay them all out, try and group them together and narrow down a target outcome. By outcome I mean, a description of, “we have reached this state right now.” An outcome map is almost like a press release. “We have achieved X” and it's a forward-looking statement that sets a destination. So an outcome map might be, we release features twice as fast as we do currently. Or, we release every week. That's pretty common.

Then what we do is we take that and the first thing we look at is why do we want to do that? Because it's very easy to assume that, because this thing is valuable to me and I'm like, Mr. Leader Manager or whatever, whoever, then everybody else gets it and everyone else is just going to fall in line, which is absolutely not true and unreasonable to assume.

So the first thing we look at is why is that valuable to internal leadership, customers, individual contributors, anyone else who really needs to have this resonate with them so that they can buy in and be like, “okay, yeah, that sounds like a great idea.” And then, what we look at next is obstacles. What's between us and the outcome, because we should be very clear from the very beginning, like, what are we going to trip over? Where are the Lego pieces? And then we will look at investigations. How do we find out more about the obstacles to try and avoid them? And how do we find out more about how to get to the outcome as fast as possible, or with as little effort as possible? Finally, we look at measurements of progress. So how are we going to know that we're moving in the right direction?

And that really takes us from like, okay, well, we can be working on a million different things, we have like so many different ideas and problems to solve to one thing that the whole team can rally around. And then we break it down into like, okay, people know how we're actually going to get there.

And the next thing that we do is map the value stream because the value stream is the machine that delivers the outcome. And right now most teams don't know what that looks like. So their odds of getting to their desired outcome are very slim. Because if you don't know, by what method you're going to arrive, where you're going to arrive, it's like, “I need to get to Japan. I have no idea if planes even go there or if I have to take trains and a plane and an automobile or a camel or whatever else.” We know these things, but we're not going to Japan. We're going to the great unknown. 99% of the time we don't know where we're going. And so we need to sort of break things down into how are we actually going to make that happen?

The other piece is we need to make this happen not just once, right? We need sustainable practices that we can repeatedly leverage to deliver the next feature, and the feature after that, and then twice as many features six months from now, and then three new products, and then we're going to have an acquisition and we're going to have to weave that into the portfolio.

And everything's just going to get more and more complicated. So any opportunity to kind of simplify and clarify, we should probably take it now. So the value stream is going to show you, what are we doing right now? How long does everything take? Where are the constraints and bottlenecks? And then we design a future state, like a prototype future state. What could this look like in three to six months? And that's very fuzzy because we haven't mapped capabilities yet. We haven't mapped dependencies yet. Those are the other things. 

So the next thing is dependencies. And that's basically what are the contributing factors to the bottlenecks and constraints? What are the things that are making those constraints happen? They're usually outside the team or else they would have been solved by now, unless they're linked to a missing capability, but usually these things are all mixed up together. So the dependency map nowadays looks a lot like a Wardley map if folks are familiar with the Wardley map. I like plotting dependencies in a Wardley context, which means we plot dependencies relative to a value stream, but also on a landscape that includes customers, the proximity of each of the components to the customer—so some things are way deep in the stack, like down at the infrastructure level and they're very hidden away, other things like front end code and the mobile app or really close to the customer—and then we have an evolution axis, which means there are some things that haven't been invented yet, or they're just in prototype and they're all the way to one side. And we consider those to be very important IP for the company and differentiators because you can't get them anywhere else. That's why they're like super bleeding edge and very much in a prototype state, in a development state. And then you have other stuff that's super commoditized, right? So you have stuff like services you can get from AWS, for instance, where it's like, if you start building something that AWS already supplies, you're going to lose, because no matter what it costs, they are providing it cheaper than you could ever build it.

Liesse Jones: Right.

Steve Pereira: And so being very clear about what you're getting from commoditized services and the things that you have to build—because we can only afford to build the things that we have to build—that gives us a sense of how all this fits together. And it's way more complex than we typically understand, which is why it's so valuable to map these things because you start to realize, “oh, wait, before we sign up to create this new thing, we should be very clear that we need to do it.” Or, you know, we should be looking really hard at how to make that happen without building anything, if we can avoid it. 

And the last thing is capability because the last thing is if we want to remove dependencies or address dependencies, we're going to need those capabilities inside the value stream. So if I want to stop going to my shared services team and asking them to build me a new environment or provision some data somewhere, then we either have to have the capability to build that as a service—so to create some kind of platform around it or an API around it, and then make that accessible to the team instead of going to a person, you go to this service and it's like a pull now—or we start to consume that from an external service, you know, maybe we're doing something internally that we can do by going somewhere else to get it. And then the last thing is, can we actually train people inside the team to do this thing instead of going outside to get it done? And that can remove a lot of wait time, but it's also expensive. You have to know whether that's worth it and whether that's the right approach. 

So the combination of all these things and the way that they flow together, your desired outcome gets broken down into what is going to make that happen. That's the value stream. The value stream is going to show you what's currently not working and what you need to focus on. That's going to point you to dependencies that are contributing to the areas that are problematic, and then you dig into capabilities to try and address those constraints and dependencies. And all of that culminates into a very clear picture of what's between you and your target outcome.

Liesse Jones: That is awesome. To put it into context for people who this might be a completely new concept for, do you typically do this when you are, you know, creating the product roadmap for the year or the quarter, or however often people within an organization do it? Or do you do this every time a feature request comes up? You know, one of your larger customers says, “hey, I need this capability, go build it for me and then I'll continue to use your service.” How do you think about that?

Steve Pereira: That's a great question and a great frame, because I think that those are somewhat opposite ends of a spectrum. Well, the real end of the spectrum, where almost everybody is right now, is never doing it. People don't map things, they don't actually take the time out to figure out, like, what are we doing? And what does it look like? And that is partially because we don't have good models for doing that. I think a lack of example, and structure that people can be comfortable with is a big contributing factor to that. Right now we have a big blank whiteboard and it's like, well, I don't want to look dumb by drawing a bunch of boxes and then having to connect them all together. And I don't know what I'm going to get out of that. And doing it in front of other people just sounds terrifying. So part of flow engineering is that all of these maps have simple structures to kind of get people comfortable with the idea of just building this out. It’s a guided path with guard rails rather than a blank slate. 

Liesse Jones: And going back to your statement from earlier, we do not live in a culture where people are encouraged to ask why, especially if their manager is saying, “go do this thing.” And so without a framework like this, where there's a safe space to ask, “why are we doing this?” it can feel very uncomfortable.

Steve Pereira: Yeah. I think that's a major advantage of this approach is that it kind of encourages you to step back and ask questions that we're not encouraged to ask you, you're given permission to ask, like, what are we doing? Which is a very risky thing to ask under normal circumstances. Although in almost every case, nobody else knows. 

Liesse Jones: Right.

Steve Pereira: How can you know? You can never know a hundred percent, so it's like always a valid question. It's just so uncomfortable because it sounds like we should know. 

Liesse Jones: Yeah. And that sounds like a challenge to whoever came up with the concept in the first place. So I think once we just take that down a notch and assume positive intent and assume that people are asking for clarity, not to challenge, that's a very powerful and foundational thing.

Steve Pereira: Yeah. I think that part of the advantage of having outside facilitation is that I can be the person who doesn't have political ties to the situation. I can ask those questions safely and I can sort of act as a proxy for folks who can't ask that themselves and I can play ignorant and I can say, “well, how does that work?” And you know, “does this make sense to anyone? ‘Cause it doesn't make sense to me.” Like I can play dumb and kind of act as the facilitator for that, which I like a lot. It makes my job really easy ‘cause I'm encouraged to ask dumb questions because I get bad outcomes when I think I know things. It's funny, even as myself, when I think I know, “oh, this is going to be lack of test automation like it is everywhere else,” I always get into trouble by not really asking the basic questions and not approaching the situation with a beginner's mind and a level of curiosity and humility. 

But to get back to your question, before I veered us off course, really what happens is that people map these things when they're at a point where they can't see the light at the end of the tunnel.

It seems like things are getting worse and worse and they don't have a better alternative. That's where we are currently. It's like an act of desperation and people call up Steve and they're like, “we don't know what to do and you're the last number on the list.” And then what I encourage folks to do is to periodically do this exercise. Because what happens is when you map things, unless your map wasn't useful, you act on what you learn by mapping and that changes the system. And so the map needs to update. So your map is only as good as the current state and what you haven't yet done, and then the moment you do something, the map changes. And now folks are listening in and they're like, “oh great, so we have to map every three weeks and this is going to cost us a million hours and dollars.” And that's only true if you were starting from total ignorance, every single time. You do, as you incorporate this practice, the maps live continuously, you can update the maps, you build this capability that makes it faster and faster to update the maps. And it becomes part of just how you make sense of where you are and where you're going. And it really provides this useful layer of information that isn't present anywhere else. Like I always have, I have maps running for years that I come back to every couple of weeks, and I update, and that's my current state. And I can share that with anyone and anyone could catch up to where I am, which is really powerful. 

And so having these continually updated means you can have a new hire joining the team, look at the map and say, “I know exactly where we are and where we're going. And I can plug myself into this scenario and be useful.” Like if our gap is test automation, I can see how that's affecting our target outcome. I have capabilities in test automation. Therefore I know exactly what to do to positively influence our most important and critical deliverable. And that is very hard to get anywhere else. You don't get that from JIRA. You don't get that from anything else that I've ever seen. 

So I would say before you start off on a big journey, for sure, if you're leaving the Shire on your way to Mordor, then mapping is really valuable. Taking stock of what's between us and where we're going is really valuable. And it can instill a lot of confidence and alignment in all of the people who are involved from the beginning, but all the people that you’re going to pick up along the way, because who you start with isn't who you end with necessarily. But also that periodic, “I think we could be doing better. It feels like things are slowing down.” Those are all reasons to stop, take a couple of hours and map. It's really not a huge investment and it always saves 10 times as much time as you spend. 

Liesse Jones: For people who are interested in learning more about mapping or working with you on mapping, what are the first steps that they should be taking?

Steve Pereira: There's an eBook that explains this probably slightly better than I have here, in a visual way as well, which I find helpful when we're talking in a podcast because this is a very visual thing. So there's a free eBook at flow.visible.is that folks can download and go through the start to finish process. That'll also sign them up for a course that will come every single day and they'll get a separate module to walk them through the material and spoon feed it to them. So, however easy you want it to be, hopefully that is achieved by just going to that link. 

Liesse Jones: Awesome. We'll be sure to add that link in the show notes. Super, super helpful. I feel like we could continue talking about this for hours more, but unfortunately people need to get back to whatever they're doing at work after listening to this episode. 

Steve Pereira: Life! Get back to your life, people. 

Liesse Jones: Challenging the way that they're approaching their entire workload and career, you know, hopefully you will have turned a light bulb on for some folks. I know that you have for me, so thank you for the conversation! It's been awesome to chat with you and we'll be sure to link to your website and your social media so that people can be in touch.

Steve Pereira: Wonderful. Thanks very much. 

DevOps State of Mind will be back in the new year with more conversations about the tools and processes that are essential for a successful DevOps culture. In January, I'm chatting with Chris Steffen, a research director for information security at EMA. We'll discuss DevSecOps predictions for 2022 and what it takes to compete as a vendor today and a wildly crowded market.

I'm Liesse. Thanks for listening to this episode of DevOps State of Mind brought to you by LogDNA. If you'd like to hear more about the DevOps culture, subscribe to the show and then pop over to LogDNA's website at logdna.com to learn how to be more productive in a DevOps world. 

DevOps State of Mind was produced and edited by Pamela Lorence from StudioPod media. Thanks for listening.