Episode 100: Aaron Aldrich on the Power of Vulnerability in DevOps

Brian Dawson:

Hello, this is Brian Dawson, and I'm joining you with another episode of DevOps Radio. Today with me, I have another exciting conversation with a person that I was just telling him I'm surprised we haven't gotten a chance to cross paths personally, but I'm glad we got a chance now. This is Aaron Aldrich.

Brian Dawson:

He's a DevOps advocate and Managed OpenShift Black Belt at Red Hat, as well as being the creator and host of Tabletop DevOps, which is streaming monthly on Twitch. So I'm here with a professional and an organizer of devopsdays in Hartford, Connecticut, New York City and Boston, and the bio is actually long. There's a number of other things. So I'm going to shift it down the stream to Aaron to explain more. Aaron, how are you?

Aaron Aldrich:

Hi, I'm doing wonderful. How are you today?

Brian Dawson:

I'm doing great. I'm doing great. Like I said, look, I can't complain it's a busy day, but I cannot complain when I get an hour to sit down and have a meaningful conversation with people that are doing things in our DevOps space. I mean, I can complain, but I won't.

Brian Dawson:

To start though, I'm glad to have you and to start, can you give our listeners a brief overview of what your role is? What is the mouthful that I kind of stumbled upon, Managed OpenShift Black Belt at Red Hat. And then, we can dig in a bit into what your career background is and some of the other things you are doing.

Aaron Aldrich:

Yeah, absolutely. So at Red Hat, so I'm focusing on their OpenShift product and specifically our managed service offering. So it's looking at all the stuff that's platform as a service, as opposed to the, you install it and run it yourself offerings in that corner.

Aaron Aldrich:

So my role is to help getting people on board with that new concept of operating; operating from a managed service, as opposed to operating their own platforms. A lot of my targets are big strategic accounts and doing lots of enablement and evangelism, but targeted at customer accounts as opposed to broad audience [crosstalk 00:02:28] on board.

Brian Dawson:

Right. And so, there is still kind of that underpinning, that a bit of a community building aspect, evangelism aspect, but in the back, there is a commercial goal.

Aaron Aldrich:

Yeah, absolutely. So it is very much still a lot of evangelism and things and honestly, a lot of these big enterprises are sometimes... A meeting with them is bigger than some conferences I've been to. They've got 200 engineers in one room and they'll have three breakout sessions for worktops later. You're like, "Oh, this is a lot of software engineers that all work at the same place."

Aaron Aldrich:

But it's great, these are a community of people coming from Connecticut that had a lot of enterprise backgrounds, so it's actually a group of people I've always consistently been like, "How do I reach these people and try to bring people into the new world of DevOps and operating?" So it's like, "Oh, this actually works really well." I think having that commercial backing gives incentive for Red Hat to send me into these accounts.

Brian Dawson:

Yeah. And that's funny, that's where I should be clear about this nuance thing. I did have an opportunity just yesterday for a track I'm chairing for another event to speak with the founder of NADOG. And we are kind of having this conversation about kind of open source communities, commercial communities, et cetera, et cetera. So I don't want to imply that there's a commercial consentive as a bad thing. It is still community building and it is still empowering people with knowledge and connections in order to go solve a problem.

Aaron Aldrich:

Yeah, absolutely.

Brian Dawson:

So you have, I'm going to dig into your career a little more. So in addition to what you are doing now at Red Hat, as I said at the top, you actually have had a heavy focus for a number of years around evangelism, kind of the DevOps space, collaboration and sharing, again, devopsdays, Tabletop DevOps. And then more interestingly as we'll dig in later, but you could start now, you've also had a focus on not only resilience engineering, but resilience engineering as it applies to mental health, right?

Aaron Aldrich:

Yeah.

Brian Dawson:

So how did you end up functioning in this space where you're a community organizer, community leader?

Aaron Aldrich:

Yeah. So this is sort of a, I guess going backwards on my career path, but at the time I was working for a small group company in Connecticut who was doing consulting and managed services for a lot of different businesses were around and happened to through coincidences be involved with the folks out in Denver, through Jason Hand and got invited out to their devopsdays.

Aaron Aldrich:

And this is sort of early on where I kind of knew what DevOps was, but never really dove into it or knew the community or anything else. I had been doing some of the practices and so on, but nothing very focused. And so, I went off to devopsdays Denver in 2016, I want to say, and just completely fell in love with the community and like, "Oh yes, this is it. This is the thing I've been talking about. I have words and a name and a group of people that are on board with this thing." So yeah, just totally fell in love with that community.

Aaron Aldrich:

And when I got back to Connecticut after that conference was looking up like, "All right, where's my local meetup group?" And it was just, this thing doesn't exist. It was like, "Oh, so I guess that's the universal sign this is your group now." It's like, "Oh, okay, thanks."

Brian Dawson:

Right. "I want some more of that, where is it?" "Since you for it, here goes mission."

Aaron Aldrich:

Yeah. "Congratulations, you're the organizer." Like, "Oh, thanks." So I was running the DevOps Connecticut meetup group for a little while and found a group of people there that were interested. And I was like, "Hey, I want to do devopsdays and bring it here. We've got stuff in New York City and Boston, but there's a lot of people in the middle. Let's try and bring it there and have our own unique focus."

Aaron Aldrich:

Each community kind of has its own angle. I've been to a bunch of devopsdays and they're definitely unique to the city they're in, based on the groups that are there and the communities they attract and what businesses are around that are practicing. So I got to really meet-

Brian Dawson:

And just curious on that, how would you describe at risk? And obviously, you have a sampling. What is the orientation of the heart for devopsdays community? And surely, it's changed over time. That is that-

Aaron Aldrich:

A little bit, but it's largely influenced by who are the folks in tech in that region? And so, Hartford, Connecticut is big insurance like Aetna, UnitedHealth Group, Optum, Medicare, Cigna are all in that region. So there's a ton of finance and regulated health industry tech that's around. And that's actually got a lot of interest is, how do you take these DevOps practices? Because there's a bunch of startups, especially in New Haven area has a lot of, some of the startups and the agile folks.

Brian Dawson:

A lot of the FinTech startups.

Aaron Aldrich:

Yeah, and stuff like that. We get the concepts and we understand that, but now how do I apply that to my 100 year-old company? We've been doing technology since the '70s and '80s, it's very brownfield. It's got lots of tech debt, lots of stuff that we need to move and it's a big ship, right?

Brian Dawson:

Right. We got a lot of-

Aaron Aldrich:

I help bring people together who met each other for the first time in the same company as they were just to meet randomly.

Brian Dawson:

"We're doing that, really?" Yeah.

Aaron Aldrich:

Yeah, exactly. Those moments like, "Where do you work?" It's like, "Oh yeah, me too." Like, "Oh, you're down with this person?" Like, "Yeah. Okay." So yeah, just those funny moments of trying to get these communities together and try and figure out, what are the universal practices we can share and what can we learn from each other?

Aaron Aldrich:

When I was organizing, it was always a combination of trying to highlight folks who've been successful in those environments, who's been successful in the enterprise doing these types of things? As well as trying to bring in some of that outside influence of like, "Yeah, I know we've been doing it this way for a while, but what are other people doing? Where else can we be successful? And what are the hard lessons to hear, especially now. What's the stuff you don't want to listen to?"

Brian Dawson:

We had a conversation actually with Pete recently, a recent DevOps Radio guest. And we were talking about happy path. There's a lot to be said about the inspirational talks we have at these area meetups. And then in particular, at big conferences like, "Here's the possibility of what we can do." But he was highlighting and be curious to see if you have thoughts on this, if you agree or disagree.

Brian Dawson:

But that sometimes where that fails is where people believe that that happy path laid out for one organization, one, not without its challenges, but two, can be copy and pasted into their organization. And I think people struggle there and he was making the case that, "Look, there's value in it." I love that you said for sharing the hard lessons and also ensuring that you're informing people a phrase I probably plagiarized from somebody years ago, I don't remember who. But it's pragmatic not dogmatic, right?

Aaron Aldrich:

Right. Yeah.

Brian Dawson:

These are lampposts, they're not a hard tried and true recipe for how it fits in your org. So any thoughts as have you experienced that? Have you identified any ways within your evangelism and community, how you sort of facilitate that motion and cross-pollination?

Aaron Aldrich:

Yeah, for sure. That's definitely I think there's the... So tempting to just be like, "All right. Give me the five steps I have to follow to get a DevOps working. Just give me the five steps."

Brian Dawson:

It's my first DevOps.

Aaron Aldrich:

And it's the constant struggle of like, "Okay, well, we can give you five things that worked, but can't give you five things that would get you where you want to go." It's a slightly different thing. I can more give you a map and show you paths, people have taken, but I can't promise they're still there. I can't promise they'll work for you or that your landscape will look the same when you finally arrive, right?

Aaron Aldrich:

So yeah, it's been interesting being in that path and trying to find, what are the universal things that we can talk about? What are the things that will always be true? Or what are the practices we want to reinforce? Which has been a big shift, I mean, it's been a big shift, I think, software wise and what I've been interested in what we've been looking for, like the whole build versus buy conversation.

Aaron Aldrich:

It was so interesting early on like, "Well, I want the option to do everything. I'll build it myself, but I'll do all the custom stuff." And now it's very much like, "You know what, that's not valuable to me what I do or my business. Let me just buy the thing. It's going to have a lot of opinions, but it's going to do it.

Aaron Aldrich:

It's going to do it whether it's not the way I would do it, that's fine. It's just going to get my software delivered and now, I can focus on the business logic and the stuff that's unique to us and everything else and all the repeatable boring things can just be baked in."

Brian Dawson:

Fantastic point. Now I want to drill you just a bit more for a second on your career and maybe we can share what may be a bit of vulnerability. We'll see. I noticed commonality in looking at your background in that, I am not I'd say formally computer science trained. I did what I call you build your own CS degree and then kind of figured my way through it.

Brian Dawson:

And for me being in an industry, I mean, even if I look at a past list of some of my guest, where there's these phenomenally credentialed people it's always felt like a little bit of and I think I got past it, but we talk about imposter syndrome.

Brian Dawson:

I always suffered a bit of imposter syndrome, but I also know and love to highlight, hence why I'm bringing this up, that there are many, many, even as you go back into history, extremely impactful people in this space that either come from a liberal arts education or a Poly Sci, or none at all.

Brian Dawson:

And so, I'm just curious and we have a common alley. I was set to be a sound engineer. I was going to be a music producer and sound engineer, and it looks like you started at a similar path. Can you share your thoughts on your path to where you are today?

Aaron Aldrich:

Yeah, for sure. I know we were talking about it earlier when I said it was funny that I can just get up if I did and walk a couple steps and grab the sound engineer's handbook off my bookshelf because when I went to school originally, I was going to go for music. I'd always had an interest in tech, love music. Play electric bass primarily and got way into it in high school in the jazz band, and all that sort of thing.

Aaron Aldrich:

And so, I was looking at Berkeley as like, "Great, I'm going to go here. They've got great industry connections. They have some of the best equipment in the world because they've got those types of connections. This is where I want to learn how to do sound engineer and music production." And that was my thought process of a career of combining those two.

Aaron Aldrich:

And for me, I ran into this is where sort of my mental health journey starts, although it's all in retrospect that I recognize it, at the time I had no idea. But in retrospect, it went through a major depressive episode and dropped out of school and eventually got into tech through the kind of support line. Always kind of get a computer as I can do internet support and help people get online and unplug your modem 100,000 times a day.

Aaron Aldrich:

But eventually, making that path into ops and CIS admin type work which is sort of something I've noticed, I think a lot of ops backgrounded folks or at least traditionally, I don't know how much it holds up for modern junior ops folk and DevOps. But especially when I was there, ops seemed the realm of the street educated computer folks who grew up hacking it together and figuring it out and trying to make components work together based on whatever they could find.

Aaron Aldrich:

And we would work with software development all the time, but it was always from this... I'm talking about all the silos and everything, but dev always seemed very... They went to college, got a CS degree and they're getting the programming and I'm like, "Okay, you're going to give me whatever and I just have to make it work in whatever hardware I get." "Okay. Fine."

Brian Dawson:

Yeah, very much so. And that's why I'd say one of the reasons that's important to bring up as we touch upon mental health, career paths, imposter syndrome. I was talking about that dynamic with Erika Chestnut recently. And she is a quality assurance leader. She's a quality assurance leader at Calendly. And we were talking about this dynamic.

Brian Dawson:

I also had this conversation with my brother who's a quality assurance leader about sometimes QA can be compromised in their position because they feel that they don't have authority or voice, that you have the scholared developers that have the depth of the science and know the space. And I think at times though, it's a different dynamic say when we talk about traditional CIS admin or ops and devs, there's a similar dynamic.

Brian Dawson:

And so, I bring it up for, I guess a couple of reasons. One, is to kind of really for our listeners especially people getting started understanding that there's a path for everybody to offer value especially in modern software delivery. But then that gets to the other, I think part of DevOps and the democratization of software delivery recognizes that everybody in the delivery pipeline has value, right?

Aaron Aldrich:

Yeah, absolutely. It ties into some of the resilience engineering and safety concepts that dig into that as well, and why DevOps is successful at instead of looking at these silos of functions of, "We're just going to toss it and it'll mechanically develop here and deploy here." Of actually getting the people together and understanding the realities of the difference between work as imagined versus work as done. That's the thing that DevOps is trying to touch on and understand, what does work actually look like and how can we improve that?

Aaron Aldrich:

So getting all the stakeholders together in a room where we can have this conversation. And then part of that ties into safety and resilience engineering is the part of empowering your sharp end. The sharp end are like your chop wood carry water folks, people doing the work who are your QA engineers and your ops folk who are trying to get it running and live.

Aaron Aldrich:

And the people actually making the changes and the [inaudible 00:17:37], empowering them to make those decisions and say, "Hey, this looks weird. We should do something different." Or, "I need to investigate this." Or, "We shouldn't do that." And giving them the ability to make those calls and what makes your systems more... It turns out the people are why your systems work in the first place and we'll make it [inaudible 00:17:54].

Brian Dawson:

Right. A lot of threads I want to pull there, I hear it sounds like both and you tell me if I'm wrong structurally giving them the ability to make that call, but maybe even more so culturally empowering them to make that call. Is that correct or is there a difference?

Aaron Aldrich:

Yeah. I think it all reinforces each other. Culture is sort of the word to wrap up all of our practice and ideas and attitudes and reinforcement. And I think in that is the practice of how do you organize your team and how do you give them the empowerment. And I think it's why this is the great DevOps conversation. Like, "Why do you always talk about culture? How can we always talk about culture?" Well, it turns out that's important to everything, having that culture of reinforcement.

Aaron Aldrich:

And the culture and practices you use should inform the tools you use to operate. And those are going to reinforce the culture that you have, and it's going to just... If you're doing it right, it should feed back and reinforce itself. You don't want to have a culture of openness and empowerment, but then by the time you get into your change management tool, you've got to wait for three approvals and you've got to contact somebody. Now your tools and your culture are mismatched and you have a challenge.

Brian Dawson:

Yeah, fantastically said. I have been calling it or for a number of years the DevOps Trinity. To get the right balance to achieve the Trinity, it can't just be people and culture. It can't just be process and practices. It can't just be tools and technology. You may start with one, and like you say, it may be iterative, but truly achieving transformation requires entirely addressing all of those.

Brian Dawson:

Which brings up, so you started on the resilience engineering and ultimately, incident response discussion. What's brought you to being so focused on these topics right now and is there any particular science on these topics that become relevant and what will hopefully soon be post pandemic I hope or pre post pandemic? But what parts are interesting-

Aaron Aldrich:

We've finally got at the time slush that has been this pandemic.

Brian Dawson:

Yes. Oh my goodness. I'm double vaccinated. I'm finding that I now times slush, mind slush, I think there's going to be a lead time until I actually start to think normally again.

Aaron Aldrich:

Oh yeah. I have no idea when I will finally... Mental processes and habits will return that were there before. I've already got a handful of friends and folks that are like, "All right. I'm getting on a plane for the first time. I've already forgotten to pack like four or five things. Wish me luck." And these are from industry folks that are used to flying 100,000 miles a year. They're like, "I have no idea what I'm doing anymore."

Brian Dawson:

Yeah. And you probably travel a lot. Recently my son came, "Dad, can I borrow a toiletry bag?" And I realized my toiletry bags, they're like time capsules from January, 2020. Right?

Aaron Aldrich:

Yeah, exactly. There's moment where I'm like, "Oh yeah, that's... I don't know. I put it away months ago and I don't know where it is."

Aaron Aldrich:

No, it's fine. Engineering management, resilient engineering and post pandemic life. So yeah, I think it's always been an interest, I think is my background coming from support into junior CIS admin. Ops stuff has always had this on-call extra hours, you're going to be available if something goes wrong type of work process. And so, I've been interested in those conversations, like how do we deal with burnout? What's the way to sustainably or humanely do on call?

Aaron Aldrich:

Because I've been in all the rotations from, "You are just expected to be available all the time and that's part of your payment." To like, "Yeah, you have a rotation. But when you get called, you get a base overtime pay plus hours plus this." And it's like, "Okay. All right. That's a little bit different." But it's still the same type of... To modern, now where there's very few DevRel emergencies, it's very rare that you get called at midnight [inaudible 00:22:22]. "Oh, no, the community is fine. It'll be there tomorrow. We'll do that tomorrow."

Brian Dawson:

The world will not end.

Aaron Aldrich:

So yeah, so it's been kind of all over the place in that regard, but definitely the human element of it. How do we do this that we can work outside of this 9:00 to 5:00, which takes away from our family time. It takes away from all of our time outside of work and demands a lot of us, and is there ways to do this sustainably? Are there ways to do is better than we've been doing?

Aaron Aldrich:

And so, I was always really interested in the work that happened at Etsy years ago when they started pulling all their data out of like, "What is our on-call look like?" I think John Allspaw started some of that stuff, but I don't want to-

Aaron Aldrich:

He's done a lot [inaudible 00:23:06] in this world for a lot of things and part of it started at Etsy and I don't know if this was him or not, but he was part of that whole realm. And I met folks like J. Paul Reed and John Allspaw at these DevOps conferences.

Aaron Aldrich:

And I was like, "Oh, this is actually really, really interesting work that dives into not just what are the technical stuffs and how do we do this? But how do our organizations learn? How do our organizations get better at doing what they do and how can we actually reinforce the practice and culture in order to get the results that we want.

Aaron Aldrich:

And so, it was this realm of technology that focused very deeply on the community and the people that are actually doing the work and how can we empower them to do that work better? How can we grow as groups as opposed to just what's the latest technology that's going to enable me to work this out? What's the newest Kubernetes? Right?

Brian Dawson:

Yeah. I mean, it sounds like, but leaving the human... Bottleneck is not the right word because it's actually more kind of pressured the human impact and effect untouched. We bring in the new technology, but we don't address the key underpinnings.

Brian Dawson:

How would you say we, before we get in back into the pandemic part of it as you mentioned, 2017, a little earlier when you were engaged. We were starting to focus as a community on this stuff. Well, how far do you feel we've progressed? Do you feel relative to other areas, this is still an area that needs significant improvement? How would you characterize that?

Aaron Aldrich:

I think it's probably the area that I think consistently needs help. Because it's very easy to market a product and it's very hard to market a process, and how do we convince people that they should change how they act and how do we implement that in an organization, and who even does that? How do you buy a new practice? So I think so much of that is very much done through community work and getting more people involved and trying to teach people more stuff. And it's constantly sort of run at heads with like resilience, I think is a big one.

Aaron Aldrich:

Resilience engineering is starting to happen. And it happened initially with like... What's a good example? Observability is a really good example. So observability sort of emerged at probably about that same time. I think is when that terminology was starting to come out, we were starting to shift a little bit away from monitoring and start talking about observability.

Brian Dawson:

Yeah. In 2018, and then really grabbed the whole... Became a market and practice term round 2019.

Aaron Aldrich:

And that was really a thing. It started out as a separate word and it was like, "Okay, we're using this for a reason. This wraps up this whole practice, you have the Google SRE documents and how this is relating to SLOs and everything else." And then by now, it's anyone who ever has any marketing product has the word observability slapped on it.

Aaron Aldrich:

So how do you combat the, I'm trying to teach you a completely different practice using this terminology versus someone who's just trying to sell you the product using the same terminology? And it's like, "Yeah, I guess if you buy that product, you can check the box if that's what you're trying to do, but if you're actually trying to improve practice it's going to take some work and we got to learn some things."

Brian Dawson:

Yes. Oh man. Well, I'm still keeping away from pandemic for a moment. We'll get there where the thought is the struggle. We talked about kind of that commercial aspect. The value of markets developing and people buying into... I mean, just look at DevOps, people buying into practices and the commercial interest and kind of me being built around them definitely has a lift. But on the flip side of that, then you have to kind of do a de-duping of clarification of the difference between buying something and actually doing the work of implementing the original practice, right?

Aaron Aldrich:

Right. And not just recreating the same mistakes with different names.

Brian Dawson:

Right. As always, we'll always say as for a vendor and I'm sure you've been there, doing evangelism for commercial organizations is making the difference. I am not saying if you buy... You cannot buy DevOps in a box. You cannot buy observability in a box so to say, you can buy the tool. You can't buy resilience engineering in a box.

Aaron Aldrich:

Right. As Nathen Harvey, I think said it; you can't buy DevOps, but I can definitely sell it to you if you'd like to. And many companies are very happy to sell you DevOps if that's what you're after, but you can't buy it. That is the-

Brian Dawson:

The catch and if you can be real. So the pandemic, how has the pandemic changed the view on incident response and resilience engineering?

Aaron Aldrich:

A lot of us are sort of running on probably more than we should be energy devoted to work. I think a lot of us are running degraded, so to speak. And it actually came up even early on in the pandemic. I want to say probably about a year ago now when the first failover comp happened. And it was something that made me think about it during the pandemic was actually Paul Reed talking about how we're all probably...

Aaron Aldrich:

The concepts were, how do we deal with cognitive overload? When we're at capacity, what do we do in order to bring that down? And part of it was sacrificing thoroughness. And then the sort of offhand comment was just, "We're probably all sacrificing thoroughness right now." And it's like, "Oh yeah, that's true."

Aaron Aldrich:

I'm like, "Wait a minute, what are the implications of that? If we're all sacrificing thoroughness, and that's one of the tactics we deal with to deal with cognitive overload, that means all of us are cognitively overloaded. All of us are operating at 100% all of the time, and that is not sustainable."

Aaron Aldrich:

So I think there's a lot of reckoning to come with post pandemic figuring out how do we shift this back to separating this work and real life. So many of us like the comment; we're not all working from home right now, we just all happen to live at work. I think it's been one of the comments tossed around.

Aaron Aldrich:

I think it's really true, pandemic working is not remote working. This is definitely not the remote working I've done previous to the pandemic. It feels very different. Lots of different stress in pandemic, remote work versus regular life remote work.

Aaron Aldrich:

I don't know what the changes will be, whether it'll be more understanding of what it looks like when people are overworked and dealing with this all the time or more understanding of how bringing work into our houses affects that, which I'm hoping all of these things come out of the pandemic and we can create some healthier work at home cultures and on-call cultures from that understanding what the actual costs are of long-term overloading.

Aaron Aldrich:

At the same time, I think we're going to see a lot of people not learn the lessons and a lot of people switching jobs over the next few months because I think, it's just people coming out of the pandemic like, "You know what? I'm done with this. I'm going to go move on to the next thing, because I just..." Too many scars, too much trauma baked into the past year.

Brian Dawson:

To where I'm sitting in the past year. Well, yeah. And it's interesting that you say, I mean, obviously across many spectrums, industries, people have made a kind of we could go to FanDuel with bets about what's going to happen coming out of the pandemic.

Brian Dawson:

I think you had a couple of things that I would feel confident about. Some people are going to learn, some companies are going to be like, "Wow, we really cut cost; no office, no overhead, no AC. That's the way we're going to go." But have it being driven from a cost motive, not human centered.

Brian Dawson:

What is the efficiency mode, or even if, look, it's a cost motive. That's fantastic, we all can benefit from that. But hopefully, there's not too many, there's a larger contingent that is saying, "Yes, this is a great opportunity. Now, how do we take our lessons and engineer it so that our benefit is not just saving money, but our benefit is healthier team, productive team members?"

Brian Dawson:

I was going to say you either sacrifice thoroughness, which is particularly of concern in resilience engineering and incident response or something else gives capacity, or you refuse to let either of those give, i.e, you just let stuff drop or you refuse to let either of those give. And there's some people that have this nature and what's compromised is you. You figure out how to make those work, but you sacrifice yourself.

Aaron Aldrich:

There's four different actions I want to say that are the actual academic, here are the things that we do during cognitive load. And interestingly enough, they're actually the same for back-off methods when services get overloaded. One of them is you sacrifice thoroughness, so do less. One of them is shift work and time, so you delay stuff or do stuff earlier. One is to pull in more resources and I would think that it was just to drop stuff, just don't do it. So two of those.

Aaron Aldrich:

The deeper conversation that I think Paul has about it is two of them being tactical, two of them being strategic. So when you're dealing with these things, there are certain things you can do. But pulling in more resources, that's something you'd probably have to go to another team, you probably have to ask somebody. It's going to affect their work. There's more that decision making process.

Aaron Aldrich:

And part of one of the things, I actually wrote a blog. As I was turning that around in my head the first time, I was like, "There's a thing that we're doing now because the work home separation is so blurred where we can very easily take from ourselves rather than another team." So the thing that we're doing is we're shifting working and time. We're calling in resources of time and we're eating from all of that recovery time that we would normally have.

Aaron Aldrich:

And it's very easy to stop to recognize it because it's, "Oh, let me just get this one thing done. I'm going to wake up early and do that." Or like, "Oh, let me eat dinner and watch the show, then I'll go finish that email I was working on." And don't know how much time we're pulling from ourselves or what is that doing to our recovery time when it's spotted with work, as opposed to a prolonged time where we can focus on what we care about and everything else. So yeah, I think that's all of the things that play into it.

Brian Dawson:

That is funny, like you say, with your devopsdays. Okay. Yeah. Those are words, you just gave me words that I can attach to some of this stuff I've been thinking. And now, as we've said, you're passionate about mental health. I think it's obvious that what we're talking about here translates well to, and as important part of the mental health conversation.

Brian Dawson:

One of the things I would ask you is in your work or your opinion, how can organizations help support the mental health of their ICs, of their practitioners, their team members; be they developers, be they CIS admins, be it QA. But just the team, what can companies do?

Aaron Aldrich:

It's such a broad question. I can say almost anything it'd be right.

Aaron Aldrich:

No, no. I was starting to think of like, how do I narrow this down to bring the scope in? Because mental health is such a broad conversation, broad topic. And I think part of it is especially right now, giving space for people to work differently and work less and take the time they need. And I'm seeing a lot of that happen, especially around the... I'm try to think of, when this is recorded and how do I create a timeframe for all of this? Especially all of the other-

Aaron Aldrich:

Yeah. Right. How does this all fit? I'm like, "Okay." So right now, like the Derek Chauvin trial just wrapped up and the verdict was just announced yesterday for time reference for anyone listening to this in the future. So there is a considerably additional cognitive load for lots of people and especially, Black Americans right now that are having a completely different experience than I am in this moment, and a completely different level of stress just through daily life where work doesn't fit.

Aaron Aldrich:

And having an understanding of being people are human only have so much to do and having that grace to say like, "Yeah, whatever you need right now to get back to a place where you're able to focus on this, what can we do to provide that for you? Is that time off? What do we need to do to make this happen?" I think that's a big thing is just listening and being open to it.

Aaron Aldrich:

It's tough because in the realm of mental health and I'm sure underrepresented minorities feel this in tech too. There's a lot of distrust that happens in that conversation. So I have ADHD, which I've been open about and have talks that I've given about. So I don't mind talking about it.

Aaron Aldrich:

But when I'm having those conversations at work, they're still couched and defensive and I don't always show all my cards, because I've gone through this before and I've had the past where I've had the managers say, "Hey, this is a problem. What can we do? How can we help you?" It all comes out that way.

Aaron Aldrich:

And then the minute we have that experience of saying, "Hey, here's all my neuro-diverse cards, let me lay them out for you." And then, it's like, "Oh, actually that's not going to work for us." And you're like, "Oh." So you have a lot of experience of being open and getting hurt on that. So it's hard to do that. And it's hard to get people to understand too, when you're trying to explain a situation of whatever it is, whatever is the particular thing that applies to you.

Brian Dawson:

Well, and not to interrupt too long, I think involves also there is even when you adhere to a principle of that type of disclosure, I think there's always a latent fear that it may be weaponized either then or maybe weaponized against you later. So there's some hesitance.

Aaron Aldrich:

Right. And it's pretty, when they might think it's [inaudible 00:37:05], well, just shouldn't have that fear or whatever, or I want to open up, but we've all also had that experience of someone saying those things and being very honest and expecting that level of like, "You willing to give me the help I need because we have this trust relationship." And having that not be the case after. So it's not an unfounded fear, it is a fear of that happening because we've done it two or three times already.

Brian Dawson:

Right. I'd like to, I think take a moment to share you actually give me an opportunity, you just triggered actually some really interesting things and I appreciate your observations say of the trial that just closed yesterday. But really this unique thing of the pandemic when it comes to mental health and I know we have to get into the question track. I can't use too much time, but I feel really interested in sharing something that I was ashamed of. And what I didn't realize is, first, I work at a company I've worked remotely for, I think, 20 years now and which is crazy because I'm only 29, but that's another story.

Brian Dawson:

And I've worked remotely for about 20 years now, and they've always been very different remote work environments. I do work in a company that is a very high touch, remote work environment, CloudBees. We're very community focused, passionate about what we do. We use a lot of video. We stay in contact. But pre pandemic, you always had a conference, you had a devopsdays in Hartford, you had a company offsite, you went and spent days in office where you over and you got a level of connection.

Brian Dawson:

I also realized that when I traveled as much as it seemed like trouble, it was a break. It was mental time. I'd get on a plane. I'm forgiven, I can't be reached, laptop's off. And when other people traveled, they weren't on my calendar. So a couple of things happen. One is the calendar just filled up because everybody is there in their seat all of the time. Slack, all of a sudden blew up. The whole company's using it, no Salesforce on the field.

Brian Dawson:

But I'm like, "I got this remote work." But then frankly, and to get through it, we started to unwrap as an African-American in tech, a person of color in tech, there's a lot of things that I had pushed away that the George Floyd incident and kind of the awakening and the Black Lives Matter movement of the summer, then piled on top of this pressure of a new world with a bunch of calendars.

Brian Dawson:

And we flash forward for people that didn't even have that experience, the stress of the pandemic, the change in the family dynamic, the insurrection. There's been all of these things that in this context of the pandemic and the load, a lot of us are lacking time to deal with them and we're lacking the social support system. So what I wanted to share and it took me months to start to open up about this first time this publicly.

Brian Dawson:

I'm in the middle of this, when I had this. I got this. I've worked remote. I've dealt with kind of the secret racial undertone for years. Just somewhere out of the blue, it smacked me in the face. And I spent a Saturday just everything's coming at me, I'm overwhelmed.

Brian Dawson:

And went in my bedroom and I just sat on my bed and I started to tear, I started to spiral and spin and I felt like I got a taste of and I know it was what clinical anxiety feels like, what helplessness and kind of what to start to have a nervous breakdown may feel like.

Brian Dawson:

And so, I wanted to share that with you and the audience because it tied in, but what I also wanted to share and commend you on is here and prior the value of you being vulnerable in sharing. Because I literally that day, I didn't go down and tell my wife because I didn't want to worry her.

Brian Dawson:

I, for a couple of weeks, didn't tell anybody, but a couple of people closely. And then, I started to realize that we're all probably feeling some of this. So anyway to steal from the time where I get to learn from you, Aaron, I just wanted to share that because I've had the brush with it in this context. And I think it's important that you're focusing on this stuff.

Aaron Aldrich:

And I appreciate you sharing it too, that vulnerability was something to learn too. And I recognize it as something, if I can share this and to my advantage, I'm a White dude in tech, so I can go say these things and sacrifice my... I can risk it a little bit easier because I know that I've got safety nets and other things I can lean back on. And so, my hope is that I can leverage the privilege that I get to be vulnerable about other things and have that ability to open up about it.

Aaron Aldrich:

And so, if that's what I could do at least through this, that was what started my talks about mental health in tech that I've given a couple of places. And I always appreciate hearing other people too, because as much as I will talk about it, be vulnerable at a stage, I'll have those moments where... depressed or anxious or just losing my mind and don't want to tell anyone, because I'm embarrassed about it.

Aaron Aldrich:

"Oh, I'm supposed to have it all together because that's what I talk about now." To get to the side of it like, "How come I'm still struggling?" And it's like, "Oh, right. That was the whole point I've made is that we're always still struggling."

Aaron Aldrich:

I think there was like a TikTok video that would around that was, when people make mistakes, yes, we give them grace. Everyone's imperfect. Everyone has that. When you make mistakes, it's the end of the world. "I made a mistake? Are you kidding me? No. I'm terrible, I'm just an imposter. No."

Brian Dawson:

Right. "I've been a fraud the whole time." The hardest thing is to forgive ourselves. We can hopefully forgive others, starts at home to sound corny. To dig into some more of your work around here, so you've actually run emotional intelligence workshops with, and for the reference audience, emotionalapi.com.

Aaron Aldrich:

Another thing that slightly sacrificed itself to 2020.

Brian Dawson:

Oh, really? Well, tell me about it. And is there anything that we can take away from those workshops that you can share with a [inaudible 00:43:25].

Aaron Aldrich:

Yeah. It's definitely something I'm interested in trying to start back up again, but we'll have to see where everyone is once the dust settles after the pandemic.

Brian Dawson:

That was mode five, that thing just had to drop.

Aaron Aldrich:

Yeah, exactly. That was like, "You know what? I have no space for this whatsoever. That's going away." So John Sawers started this emotionalapi.com. He gave a talk whenever it was in the before times of Hacking Your Emotional API, which I think he still does it. You can find it online at emotionalapi.com. And it touched on a lot of things I had been working on personally, emotionally and other concepts.

Aaron Aldrich:

And I was like, "Oh, this is really interesting. I need to talk to you." The first time I heard it. I was like, "All right. We need to talk because this is aligned with something and figure out what's here." And part of it was both of us kind of working on either various little workshop processes that help out through all of this. They're all about, how can we understand where we're coming from? What's happening emotionally, how can we apply this to teams? How can we understand other things all things around...

Aaron Aldrich:

So he has something called the emotional retrospective, where it's basically just this process of, let's look back at the past week and let's do a retrospective on the week and figure out what were the highlights, what was the main thing? What's the thing that stands out to you? Let's dive into that. How does that make you feel? And how can you process that.

Aaron Aldrich:

Part of it is actually processing the emotion as well for that retrospective of what physical action does that feel like. Well, how do you want to do that? Do you want to jump up and celebrate that? Did you celebrate your wins this week? What did you do? When you got angry, you can feel that anger, there are safe ways to do that and ways we can make it happen. That's part of it.

Aaron Aldrich:

And other parts of it were around team communication, it's always around vulnerability. Ultimately, it always comes down to being open to talk about these things almost always from a leadership or management perspective that needs to start that conversation, but trying to provide techniques of saying, "Hey, here's one way you can look at yourself. Here's one way if you've got conflict that we can deal with it." Here's a process of what it might look like, here's a way we can deal with accountability.

Aaron Aldrich:

Broken promises, so to speak, in a team happens all the time. You've got things that you said you would do, you missed a deadline to do all the stuff. If that's problematic, can we structure the conversation around that to work towards an actual solution rather than getting caught up not processing the emotions that we feel or feeling that frustration or whatever, and then taking it out on somebody, can we actually process and get the solution-

Brian Dawson:

Process it versus having it manifest in some harder to discern.

Aaron Aldrich:

Right, exactly. It's sort of being explicit instead of implicit. Instead of this, "You should just know how this makes me feel." It's like, "Well, they're not you though." We need to say the words and explain them and understand where it's coming from.

Brian Dawson:

Corny analogy that you just triggered for me is when we talk about kind of the originating principles of CI, is the cost to remediate a bug, the longer it's delayed and I'm going to miss the... increases by order of magnitudes. So the closer to the keyboard of the introduction of an issue that we can find, debug. Find and fix a issue, the lower cost, it is. There seems to be a bit of analogy, if we learn how to identify it, discuss it and address it in a professional yet vulnerable way, it's actually going to cost everybody less that may be discovered in production so to say.

Aaron Aldrich:

And it's sort of, I think I've said before is every DevOps transformation has some group therapy aspect of it, there is always some group therapy portion that happens. But that's it because part of it is how do we actually build this high functioning team? And time and time again, you dig through it and it's, well, we have to build psychological safety and we have to build common ground on the team.

Aaron Aldrich:

You're not going to successfully build that unless you can build that vulnerability and people feel safe to be able to say those things like, "Hey, I can't perform the tasks I need to today because I'm having a rough mental health day for whatever reason."

Aaron Aldrich:

And if the person in your team is not able to say that, they're going to keep trying to do the thing, they're going to do a poor job. Everyone's going to have a bad time. That's going to be what happens instead. Instead of saying, "Hey, I can't perform this to the level I need... that you're expecting from me, how can we adjust this? Does someone else need to do it? Is that just okay? Can you just push the deadline and nobody cares? Let's just do that, right?

Brian Dawson:

Right. Well, there's an interesting thing I want to ask before I move you to a few more questions. So you did signal, obviously the team leader, the organizational leader, it's really going to be a primary point of establishing this system of psychological safety so these things can happen. But are there things outside of that? What does an individual contributor, say a developer's role on a development team? Any suggestions for what they can do to exercise or influence this?

Aaron Aldrich:

Yeah. I'm trying to think of what came out of that, that was really good. I think part of it is the self-awareness aspects of that, of things like that emotional retrospective. Those are things you can do yourself and at least understand where you're coming from.

Aaron Aldrich:

One of the things that's really changed the way I look at that is having these techniques to look at emotions and where they come from. And what's happened over whether it's my past week or the past day is... It's a combination of therapy techniques.

Aaron Aldrich:

Not to completely peek behind the curtain, but there is no shortage of therapy techniques that are here, that if you've gone through this, you'd recognize them. But that's really valuable understanding like, "Oh, I'm really mad at this person right now. What's happening here? Is this, I'm mad at them because they're a bad person? Is this triggering something, is this whatever else?"

Aaron Aldrich:

Being able to approach a work situation and be like, "Hey, look, I need to just walk away process what's happening here then we can have a conversation. And I've had those times where I've been like, "Hey, look, this is what occurred. This triggered a whole bunch of stuff in my life. You didn't mean to do that. It's not right for me to take that out on you, but understand that's what happens. So let's figure out how we can get towards a place of agreement here. Because theoretically, we're on the same team working towards common goals. Let's fix the disconnect instead of-"

Brian Dawson:

Yeah. I love the emotional retrospective. Sitting down and taking some time. And the fact that you can do it with yourself seems awesome as a team though, I know there's some people that are like, "Well, this sounds really squishy."

Aaron Aldrich:

It's super squishy, but it's great. Squishy things are fun.

Brian Dawson:

Right. I mean, who doesn't love a squishy ball, the squishy toys? And then I hear something else in what you said and I reflect back because I think it resonates with a tool that I've seen and developed that we don't all naturally lean into.

Brian Dawson:

And it is then also taking a moment to go through the exercise of assuming good intent, assuming that you'll ultimately want to get to the same objective and then taking an empathetic view to putting yourself into your counterpart's position like, "Okay. What led them to react this way? What led them to slam down the keyboard and say that we needed another input value to the function call?"

Brian Dawson:

And there may be some deeper stuff behind that, that if we process both where we're coming from and they're coming from, we may be able to arrive at common ground without unnecessary... All right. As I knew, Aaron, I told you I was going to end up leaning in on some things and missing some of the things we're supposed to ask. I do want to flash forward to before I get into DevOops and some resources, which I think are awesome resources that you'll have to share.

Brian Dawson:

I mentioned at the top of the show that you're a host of Tabletop DevOps which streams monthly on Twitch. I'd like our audience to know about that and hopefully go visit it. Can you just take a moment to tell us what it is? What do you talk about?

Aaron Aldrich:

Yeah, absolutely. So it's pretty low stakes at the moment. Mostly my goal was to combine the fact that I liked Tabletop games and the fact that I like DevOps into one thing and streaming on Twitch. So mostly it's a bunch of DevOps folks get together, people in the industry and we'll play some form of board or Tabletop game. We started out with a game of werewolf, sometimes called Mafia depending which one you're familiar with, which actually works really well over Zoom turns out.

Aaron Aldrich:

So we've played that with eight or nine people over Zoom as the sort of inside baseball on that is that it was a devopdays staple for a very long time. Andrew Clay Shafer would frequently suggest werewolf as one of the open space sessions. And so, that would just run during a lot of the open spaces was werewolf the [inaudible 00:53:14]. So I started that with that.

Aaron Aldrich:

Josh Zimmerman came up with a scenario for a role-playing game called 10 Candles, which is super interesting, tragic horror game that I immediately fell in love with, so we played a whole DevOps scenario on that. We've done I think last month with the folks from Alma, we did a game, Keep Talking and Nobody Explodes, which is the one where one person gets a bomb. It's a video game, so they get a digital bomb and everybody else gets the diffusal manual.

Aaron Aldrich:

And so, you have to work blind to try and help this person diffuse the bomb without... You don't get to look at it and they don't get to look at the instructions, that's the dynamic. It's actually a really, really good incident management practice. So if you're ever looking for, what can we do that is fun, not related to computers, but helps us get better at something related to computers? That is a great game for it.

Aaron Aldrich:

Werewolf is actually a really interesting game to facilitate because you get all of the information while everyone else has limited information. And watching the way people deal with conversations and information flow is really interesting from that perspective. It's really fun to watch. What do people do? What do people think? How do they change their actions as they revise their mental model of what's happening? It's actually a really interesting way to watch werewolf happening.

Brian Dawson:

Well, first I want in, but I'll talk to you about that. I want to figure out how I can get in, on one of the sessions. When are new streams posted? How do they get it?

Aaron Aldrich:

Right. Good question you asked. So we're currently streaming on Deserted Island TV, so it's twitch.com/desertedislandtv or @tabletopdevops on Twitter. You can follow one or the other and you'll get the right information. The Deserted Island group was started by Austin Parker at LightStep last year when he started the Deserted Island DevOps conference, was the one in Animal Crossing.

Aaron Aldrich:

So that's happening again, the end of this month, that's happening April 30th. So that will happen live there as well, you can register on desertedisland.club, or whatever, the actual useful URL is; desertedisland.club will get you there.

Aaron Aldrich:

They're doing that at the end of this month as well for their second conference in Animal Crossing. And then I'm actually looking to figure out how we can tack this month Tabletop stream on the end of it, so that we have a big, long whole event. So come tune in when you want and do that.

Aaron Aldrich:

I think our goal and sort of future vision for Deserted Island TV would be this wonderful place where folks can just do whatever they want and experiment with like Twitch streaming and programming without having to have their whole channel and run it and create a fan base because there's already a group of people that follow. So that's sort of our hope and intent and dreams, and we'll see where it ends up, but-

Brian Dawson:

I love it. And as you and I discussed at the top and listeners have heard over months or years is I started in the gaming industry and still very much have an orientation sort of around those virtual experiences. So I love it. And I'll register it with you now. I don't know what it takes to get to seat at the table, but I'm interested. I want to play one of the games.

Aaron Aldrich:

Yeah. We'll talk after this and we'll figure that out.

Brian Dawson:

Okay. So on to a vulnerability question. What DevOops, not DevOps, Dev-O-O-P [inaudible 00:56:53] smack software development or career technical or otherwise really, challenge have you faced during your career that was a learning moment for you that can help our listeners? And the more raw and embarrassing and damaging, the better.

Aaron Aldrich:

I'm trying to think of what's a good one. Some of it's so funny because I've been doing dev relative evangelism. It's like my oops blast radius has been reduced, it's been harder to break all of production when I can't touch it. So I'm trying to think of like, "What's a good way that's half of there?"

Aaron Aldrich:

So we've had one time that, this was back a while ago when I was doing network admin stuff. And so, we're working for or I was working for the federal courts in Connecticut, so complicated, but working for the federal government, not the local government. And that network by the way, is super complicated. There is like a nationwide campus area network that is the federal judiciary and all of it is publicly round-table IP addresses. Good luck. It's bonkers trying to figure this out.

Aaron Aldrich:

So we're trying to figure out like, "Okay. How can we properly create our namespace?" Because the place we were at had been neglected for a while, but part of it was bringing in new equipment. So we're setting up all these brand new switches and everything. And of course, we've got some other one that we brought in that we're looking to reconfigure and it got plugged into the network.

Aaron Aldrich:

Unfortunately, its configuration had it as the primary and authoritative switch config, which propagated the switch config out to all of the other [inaudible 00:58:43] and we just took down the whole network for the courts because all of the switches took the new config and dropped all their routes and nothing was routing anywhere. So that was fun, which fortunately we went back and had our images and had to just flash the updates to all of the switches one by one throughout the court system in three different physical locations across Connecticut.

Brian Dawson:

Right. It's not like you just remove it and boom, everything's is back.

Aaron Aldrich:

No. Yeah. Everything was down hard so that was a fun day for everybody.

Brian Dawson:

So what was the cause, what did you learn from that? What have you taken away?

Aaron Aldrich:

Well, we definitely learned not to plug stuff into live networks to begin with. Those are getting nowhere near the production [inaudible 00:59:26]. Part of it was learning how this works. It was a big lesson like, "Oh, that's how that works. That's good to know." Which was all Cisco networking stuff at the time, which as I'm sure limited applicability to my software defined networking that everybody's doing now.

Brian Dawson:

Well, I don't want to project it on you, but you were learning... To be corny, you were learning in prod, unfortunately at that time.

Aaron Aldrich:

Exactly. That was exactly it. It was learning in prod. I think there were lessons both from the... For us, at the time was like, "Okay. We can't just throw these things around, we've got to actually have a process here." Which is sometimes when you find out you need a process is when you cross over the edge, that's sometimes it. But there are also lessons in how do we deal with these incidents and come back from them, and all that sort of thing, and dealing with communication.

Aaron Aldrich:

I learned a lot about intergroup communication in that job. You will never have a more political job than working in politics. If you think your company politics are tough, imagine working with elected people in lifetime appointment. I worked with a bunch of people who aren't my boss, who all have letters signed by the whatever president appointed them to the bench. That was where we were.

Brian Dawson:

I can only imagine. Yeah. Right. Because there's two layers of the problem you're dealing with there. And when you talk about response and remediation, that extra dimension really comes in because now everybody has some stake in view and absolutely no idea why it went down, but everybody is vested in it and you have to manage that.

Brian Dawson:

Well, no, I think there's a couple of great lessons there and that are actually even relevant. The incident response as we move to software defined networks and places where we are actually able to have virtual typology that we can go in and play with. And as much as we have this term test in prod, well, take that in context certain situations you don't test in prod.

Aaron Aldrich:

The other process that we have a lot now, I think, especially as config management has come out and we've got infer code and doing all these sorts of things, have really shifted that process. A lot fewer times you're going to plug in a physical hardware switch and have to go physically address the physical switch settings. And like, "Oh crap. Where's my serial cable? That happens a lot less.

Aaron Aldrich:

But the other thing we've gotten is understanding like, "Oh, if I have these configs backed up, this downtime is almost a non-issue like push out a bad change, roll it back. We're good. Or feature flags have been a big thing. And what are the implications for the combination of infrastructure as code and feature flag? It's like, "Oh, wow. You can push out changes and turn them on and off? This is wild."

Aaron Aldrich:

So yeah, I've loved the migration of development and code techniques into the world of ops and understanding like, "Oh, we can take advantage of all of these software techniques and what happens when we abstract the things we work with further?" What can these abstractions give us? What power can they provide?

Aaron Aldrich:

Right. Some of it's operationalizing, making things super repeatable and super inexpensive to run. Some of it's just better practice.

Brian Dawson:

Better practices, visibility, audibility, leaning sort of towards for one of a better word, it's the software practices of collaboration driven through version control as we moved to the AAC movement in the ops space. Now, all of a sudden we get out of the isolated CIS admin, shouting over... I'm painting a very stereotypical of a picture, but we now get to bring shared knowledge to the table to address these things in an easier way.

Aaron Aldrich:

Yeah. It's been a shift in how we think about things too, I've enjoyed it. I think it's been a great process of, it's so easy to default back to the like, "Okay, I'm going to dive in, get my hands dirty and figure out how to make it work." And making that shift to like, "Okay. No. That's good for learning, but it's not good for practice."

Aaron Aldrich:

It's good to do that and figure out what the problem is and fix it that way, but now I need to figure out how can I do that without getting my hands dirty and do it every time or avoid it happening in the future? How can I build this programmatically or codified my policies and all these sorts of things to... It's been a really interesting mix in watching the evolution of these processes and tools together.

Aaron Aldrich:

And then, I think the other side of it has been helping to shift some ops practice into development too, of how can we deal with incidents? How do we deal with surprises? What do we deal with when our theory doesn't work in the real world? It's like, "Yeah."

Brian Dawson:

Our theories always working in the real world. What are you talking about, Aaron, now?

Aaron Aldrich:

I think every works on my computer comment would disagree, but that's great. It doesn't work in prod.

Brian Dawson:

Right. So many threads to pull on that one as well, but I know I have to get you out. So I do want to ask a couple of more things before I let you go. One is, do you have a book, a podcast, a resource, a person you should follow? Obviously we got Tabletop DevOps, which is a must follow, that you wholeheartedly recommend to our audience that they must go out and check out.

Aaron Aldrich:

Probably, I'm trying to think, there's so many things I have right now. So definitely check out the Deserted Island DevOps conference at the end of this month because that'll be a fantastic resource with wonderful people. I'm trying to think of what's been a really good podcast that would fit well here. I'll drop a couple, I'll say Arrested DevOps is sort of been the defacto devopsdays organizer run podcast, whatever. The hosts there are Matt Stratton and Bridget Kromhout who have both been global organizers for a long time.

Aaron Aldrich:

And the other podcast, I think that's really good as Greater Than Code. As far as focusing on the human behind technology, they do a really fantastic job of that. All of their conversations are really about the human side of code. Greater Than Code [inaudible 01:05:57] that. So those would probably be the two big podcasts and conferences I would say, or find whatever devopsdays is near you because those are my favorite hands down.

Brian Dawson:

And thank you for those. One of those podcasts, Greater Than Code I have not checked out. So I'm going to get it subscribed. I'm going to break norm here because it's very relevant to what they say and share a book that many have read. I actually learned about this because there was a book club with the Azure team at Microsoft around this, and someone pointed me to this.

Brian Dawson:

This is called Dare to Lead. If I could get in the time of a podcast to the actual title page, it's Dare to Lead: Brave Work. Tough Conversations and Whole Heart. Daring greatly and rising strong at work by Brené Brown. And I don't know, Aaron, if you've read it, I'd say check it out. Look at the synopsis.

Aaron Aldrich:

Yeah. I'll check them out.

Brian Dawson:

For the people that are tuned into a lot of the focus of what Aaron's discussed, especially the word vulnerability, there's just some great topics and discussions around that. So Arrested DevOps, Greater Than Code, Deserted Island later this month. And I've cheated and added in Dare to Lead for anybody interested. Well, Aaron, thank you for that. Before we head out of here, any final thoughts to share with the listeners?

Aaron Aldrich:

Well, I was going to throw out one book recommendation, but-

Brian Dawson:

Oh, go ahead.

Aaron Aldrich:

I'll do that. I'll get there. We'll make it to final thoughts.

Brian Dawson:

We'll get the final thoughts.

Aaron Aldrich:

I was just thinking resilience engineering, we were talking about it. I would be remiss if I left you without a good background for that because it is an actual academic field of study with actual terminology that has meanings and not just marketing jargon.

Aaron Aldrich:

So Behind Human Error, which is a book by a bunch of people; David Woods, Sidney Dekker and Richard Cook are the three folks that I've followed in different capacities. Really, really good. This is the one that's going to start diving into resilience engineering and that sort of thing. So Behind Human Error, you could look for that.

Brian Dawson:

I'm going to look it up, thank you.

Aaron Aldrich:

Yeah. Final thoughts. I guess my final thoughts are to remember the human elements that we have in everything, especially behind technology. It's so much the tendency to be like, how do we engineer out human error? Is probably a term I've fringed out more than once.

Aaron Aldrich:

And remember that the only reason anything works in the first place is because the humans were there putting it together and holding it up when it was trying to fall apart, that's the only reason it works. And the only reason we built it in the first place is because some humans wanted it to exist. So if we cut that out of our technology, I think we miss the part that makes it interesting in the first place.

Brian Dawson:

Awesome. And I have just now made a note to remove human error from my lexicon. Well, Aaron Aldrich, DevOps advocate and Managed OpenShift Black Belt at Red Hat, as well as a zillion other things that you do to help the community. Thank you for your time, man. I've really enjoyed having a conversation with you about this and I look forward to hopefully post pandemic or maybe even pre pandemic us being able to get together around some things.

Aaron Aldrich:

Yeah, for sure. Thanks for having me.

Brian Dawson:

Thank you all for listening. That's another episode of DevOps Radio. Make sure you subscribe and stay tuned so you don't miss the next one. Thank You. All right. That is a wrap.