Eric (0:15) Hey there, and welcome to the office of the IT guy, the show where we celebrate the people and talk about the technology that's changing our world. (0:22) I am your host, Eric, the IT guy, Hedricks, and my mission here is to share a love for open source and help build a stronger community. (0:28) I'm so thankful that you tuned in because the office is now open. (0:48) Hey there, and welcome to the IT guy show. (0:51) I'm your host, Eric, the IT guy Hendrix. Eric (0:52) This is episode eight talking about the art of continuous improvement. (0:57) And, if nothing else in this episode, we're going to once and for all solve the question of how do you arrive? (1:04) And spoiler, you you never do. (1:06) But in order to in order to tell the story better, I actually ran into this gentleman at DevOpsDays Kansas City. (1:13) He's part of the Dora Team. Eric (1:15) We'll talk a little bit about what that is. (1:17) Heavily involved with Google and and the DevOps community. (1:20) So without further ado, let me introduce mister Nathan Harvey. (1:24) Welcome to the IT guy show. Nathan (1:25) Hey there, Eric. (1:26) Thanks so much for having me. (1:27) I'm really excited to be here. Eric (1:29) Yeah. (1:30) It feels like it feels like almost an eternity since DevOpsDays Kansas City. (1:36) Yeah. (1:37) That was in the spring, and now here we are in fall. (1:40) So it's been too long. Nathan (1:42) Yeah. (1:42) And a couple of things have changed since, I'm sure. Eric (1:47) Maybe not much unless unless you're continuously improving. Nathan (1:51) There you go. (1:53) In in which case, like, if you've been continuously improving ever since that time, one of the sort of markers of continuous improvement is that you're making small iterative steps. (2:04) So you might not even feel like much has changed. (2:07) But if you were to pause for a minute and look back, I think you would see you've come a long way. Eric (2:12) My hair is longer. (2:13) Does that count? Nathan (2:14) There you go. (2:15) See? Eric (2:17) Well, before we get in too deep, because this is a topic I'm very passionate about, before we get in too deep, Nathan, why don't you introduce yourself? Nathan (2:25) Yeah. (2:26) Sure. (2:26) So hi, everyone. (2:27) My name is Nathan Harvey. (2:29) I lead up Dora at Google Cloud. Nathan (2:32) So Eric (2:32) Not the explorer. Nathan (2:33) Not not the explorer. (2:35) No. (2:35) Not the explorer. (2:36) We'll talk about what Dora is maybe in a few minutes. (2:38) But I'm a I'm a developer advocate within Google Cloud. Nathan (2:42) And leading up Dora means that I lead up a research program that's been well, for over a decade now, has been studying how do teams get better at delivering an operating software. (2:52) As the leader of Dora, I work together with researchers. (2:56) I work together with professional services folks at Google Cloud. (3:01) I work together with product teams at Google Cloud. (3:03) And most importantly, I work together with our customers, trying to help them take this research and put it into their context so that they can use our findings to really guide how are they going to transform, what new technologies are they going to use, what new processes are they going to adopt, and how are they gonna change the culture of their organization? Eric (3:25) I love it. (3:27) Now we we don't have two factor authentication on the show. (3:30) But to verify that you are indeed not a robot or, I guess, in today's day and age, not an AI. (3:37) Why don't you tell us what you do for fun when you're when you're not when you're not Dora ing for for Google? (3:42) What what do do on the side? Nathan (3:44) Yeah. (3:44) So first of all, Dora ing for Google is super fun, but maybe that makes me sound like an AI. (3:49) The thing that I one of the things that I really enjoy doing on the side, my wife recently, three years ago, started a a little retail boutique in the town that we live in. (4:00) And so I like to hang out in her shop and meet with customers and offer them a free beverage, you know, and just have nice fun interactions. (4:09) And she has really built a great community around that shop. Nathan (4:14) So I love spending time there. (4:16) And then, of course, I'm the father of three children, so I love spending as much time as I can with them, although they're all room children. (4:23) So it's very difficult for me to find time where all of our schedules align. Eric (4:28) I I can I can sense that in my future? (4:30) We have a blended family of four. (4:32) And even even now with with being a blended family, we're we're already dealing with the the struggle of, okay. (4:40) Everyone's going to be here on this night. (4:41) So it's literally going on everyone's calendar. Eric (4:44) Family night. (4:45) We'll watch a movie. (4:46) We'll play a board game. (4:47) I don't care. (4:47) We're all just spending time together because we're all under the same roof. Eric (4:51) So I can I can totally relate to that? Nathan (4:53) I love it. Eric (4:55) So we've we've hinted at it. (4:57) So what what is DORA kinda in fact in fact, when I met you, you gave a talk at DevOpsDays, Casey, about, what, ten years of of DORA. (5:07) So why don't you, real quickly, just, you know, two minutes, walk us through what DORA is and where it came from? Nathan (5:12) For sure. (5:13) So DORA is a research program, as I mentioned. (5:15) And we have to go all the way back to 2009 where John Allspa and Paul Hammond gave this talk at Velocity called 10 deploys a day at Flickr. (5:25) People were going mad. (5:27) How can you do 10 deploys a day? Nathan (5:28) That's ridiculous. (5:29) This was 02/2009. (5:31) Remember? (5:31) Later that year, the first DevOps days was held, and and this really started the movement of this DevOps community, this DevOps movement that many of us have been a part of over the ensuing fifteen years. (5:44) Well, a few years into that at Puppet Labs, Alana Brown had this idea that DevOps is, like, gaining momentum. Nathan (5:50) We should do some research to figure out do are people adopting these practices? (5:55) And if so, what happens when they do so? (5:57) Like, what are the results of adopting these DevOps practices? (6:01) So she kicked off the initial round of study. (6:05) A few fast forward a few years and doctor Nicole Forsgren joins up with the folks at Puppet Labs and really brings a little bit more scientific rigor and and and academic approach to the research that was being done. Nathan (6:18) And, really, Dora has ever since published annual reports, typically known as the accelerate state of DevOps report. (6:26) And these reports look into, well, how do teams get better at delivering and operating software technology? (6:33) And we look at ways to measure that. (6:35) How do you measure software delivery? (6:37) But more importantly than the measurements are what things actually contribute to improving those particular measures. Nathan (6:44) And over the course of the study, the kind of the top findings really quickly. (6:49) First, software delivery performance matters. (6:52) We see that having teams with better software delivery performance predicts better organizational performance, you know, things like profit and market share, things like that that all of us, wherever we work, care at least a little bit about. (7:06) But, also, better software delivery performance predicts better well-being for the employees within that organization. (7:13) And that we all we all could use a little bit more better well-being. Nathan (7:16) Right? (7:17) Less burnout, higher job satisfaction, things like that. (7:20) But the truth is it's not just, like, how do you measure software delivery? (7:24) We have to think about the things that improve those measures. (7:28) And there, we look at technical capabilities, things like, are you using continuous integration and version control? Nathan (7:35) But we also look at how information is processed and things like change approval processes within your organization. (7:42) And, fundamentally, the biggest finding that we have is that the most fundamental piece of all of this is the culture of your organization. (7:50) Culture is such a strong predictor of how well your organization is going to be able to ship ideas, ship software changes, and lead to those great outcomes like organizational performance and better well-being for our teams. (8:03) That's what's really, really important. (8:05) Mhmm. Eric (8:05) I love it. (8:07) So you you talk about all this started back in 02/2009. (8:10) I was that that was kind of when Eric was busy convincing people that it's okay to virtualize your workloads. (8:18) Mhmm. (8:19) I mean, that's how far back all this goes. Eric (8:21) I I distinctly remember so many conversations about you could never virtualize a database. (8:27) No. (8:28) No. (8:28) Don't don't do that. Nathan (8:30) Yeah. (8:30) It's it's it's really it's been a really fun journey because, of course, we've seen, you know, virtualization and then sort of virtualization to the next level with cloud sort of emerging around that time as well. (8:42) And so over the years, we've we've been very fortunate to sort of watch these trends as they come. (8:47) And, of course, there's always something new, whether it's the cloud or then a a big move to containers. (8:53) And, I don't know, look around today, AI is shaping a lot of how a lot of us are interacting with our work today. Eric (9:02) Yeah. (9:03) It's it's been exciting to watch. (9:04) I mean, everything from cloud native to Kubernetes to to, like you said, now AI, it's it's been quite the, it's it's been quite the journey. (9:13) And, honestly, I I got lucky choosing technology as my career path because it's always changing. (9:21) There's always something new to learn. Eric (9:23) In fact, I'm in the midst of a job shift right now. (9:27) I was one of the products, technical product marketers for Red Hat Enterprise Linux. (9:33) And after doing that for almost five years, three years in marketing, two years in sales, now I moved up to the cloud and hyperscaler partner team. (9:43) So now I'm talking about the entire Red Hat portfolio. (9:45) And so the the timing of this particular episode could not have been better because I'm in the midst of this transition because I was still hungry for change, still hungry to keep growing. Eric (9:58) I think that brings us to the crux of our conversations today of what is continuous improvement. (10:04) We're not talking CI like like pipelines. (10:07) We're talking, like I I see this from two different levels, Nathan. (10:12) Sort of a personal and then a a professional or corporate level. (10:18) I I'd say that you and I are probably more more engaged with the with the personal level of continuous improvement. Eric (10:23) What what did what does that mean to you? Nathan (10:26) Yeah. (10:26) I think continuous improvement I think first well, maybe first first, congratulations on the new role. Eric (10:32) Well, thank you. Nathan (10:33) That's pretty exciting. (10:33) A transition is is often both exciting and scary, and it's a good it's a good point in time to remember this idea of continuous improvement. (10:43) And I think at a personal level, continuous improvement, you know, it's kind of what it says, like, on the box. (10:49) Right? (10:49) It is about continuously learning and changing the way that you approach whatever task it is that you have at hand or whatever job or role that you have. Nathan (11:00) And I think it's really important because if if you wanna do continuous improvement well, it does require some reflection. (11:08) Right? (11:08) And and, honestly, in the course of my career, I've found that reflection, like, pausing to reflect on how am I doing, am I headed in the right direction. (11:17) This is a it's a tough thing to prioritize because in that moment of reflection, it feels like you aren't actually doing anything. Eric (11:25) Right. Nathan (11:25) But what you're actually doing is setting yourself up for future success. (11:29) So if you wanna practice continuous improvement, I think first you have to figure out some things that really matter to you and then have a way to assess, are you making progress towards those things, and have feedback cycles that enable you to learn as you change things. (11:46) And and, frankly, you can't change everything overnight. (11:49) And it's also really difficult for us to do because we don't live in a lab, like, change just one thing at a time. (11:56) Just Eric (11:56) one thing at a time. Nathan (11:57) Like, we can't do that either. (11:58) There's too many too many things around us. (12:01) The context is so so super important. (12:03) But as an individual, as you go through your career, as you work together with your team, picking one, maybe two areas that for the near term, you wanna focus on changing a behavior, changing a skill set, whatever that happens to be, And just really leaning in and reflecting on how your progress is going there. (12:22) To me, that's what personal continuous improvement is all about. Eric (12:26) And I can I I'm like like I said, I'm in in the throes of this? (12:32) And it's funny you talk about taking time to reflect. (12:36) And the this this notebook that I carry around with me, it's always in my bag. (12:40) It's always nearby. (12:42) It's where I go to just throw those thoughts down. Eric (12:45) And in the early pages of that notebook was just this this nagging feeling of being stuck. (12:53) I'm not I'm not growing. (12:54) I'm not I I looked at back at 2023 and even at this point, the first half of '24 and go, did I really learn anything? (13:03) Did did I did I take a risk anywhere? (13:06) And the answer was no. Eric (13:07) And so it it was a process of, I've got a really cushy job. (13:12) I'm working on Linux. (13:13) I'm I'm in technical marketing. (13:14) I go to conferences and talk to people. (13:16) I've got a podcast. Eric (13:18) I could coast, but I cannot tell you how much I wish that I could just be okay in that space. (13:24) But I love to learn. (13:26) I love to take chances. (13:28) Relaunching and rebranding this podcast was was a a risk that I took. (13:33) And so far, it's paying off. Eric (13:34) I'd I'd like to think. (13:36) But is is there a danger? (13:40) If someone's in the audience and they're they're happy, they're content where they are, but if they were honest, they haven't taken any risks. (13:47) Is is is are they in danger? (13:49) Is that something they should consider shaking things up? Nathan (13:53) Well, I think this is one of those places where context really matters, and I'm glad you used that word content. (13:58) Right? (13:58) You can be absolutely content in an aspect of your life, and having that contentment actually opens up space for you to improve something else that you might care about in your life. (14:10) And so maybe today, your career isn't the driving force, isn't the thing that you're really trying to advance. (14:18) You're content. Nathan (14:19) You're happy with the work that you're doing. (14:21) You feel like you're providing value to your organization or to your customers. (14:24) You're getting some value out of that. (14:26) Maybe the the place where you want to invest in continuous improvement as an engineer is in woodworking. (14:34) Right? Nathan (14:34) And that's that's completely different than what you you're probably being paid to do as maybe a software engineer or an operator or something like this. (14:42) But maybe you do want to pick up another hobby, something like woodworking. (14:46) Right? (14:47) No one's gonna pay you for that yet. (14:49) But this is a place where, again, an approach of continuous improvement can really help. Nathan (14:54) And while you're content with sort of day job, you can invest those extra cycles, the extra energy that you have towards something that you really care about and that you wanna drive forward. (15:05) Now that's not to say that continuous improvement can't help you get better at work because, obviously, it can. (15:10) I think that there there can be a trade off. (15:12) Like, I wouldn't be overly concerned if you're content with some aspect of your life. (15:17) But you should probably be looking at other ways where you can grow, where you can continue to learn. Eric (15:24) I love that. (15:26) So what about on the what about on the organizational level? (15:30) What do we what do we need to be looking for as an organization for continuous improvement? Nathan (15:36) Yeah. (15:36) This is this gets a little bit more complex because, of course, we're talking about organizations. (15:42) I can control many of the things that I do from a day to day perspective, but an organization is itself a complex being entity where there are all sorts of, you know, different incentives in place for people in different parts of the organization, communication paths through the organization, and so forth. (16:01) At an organizational level, if we want to actually have a practice and a mindset of continuous improvement, continuous improvement really comes out of this idea of Kaizen, which comes from the Toyota production factory or their Toyota production system. (16:17) And Kaizen and and continuous improvement is all about eliminating waste eliminating waste. Nathan (16:23) So get rid of the things that aren't actually providing any real value. (16:27) Now at an organizational level, it can be very difficult to adopt a practice of continuous improvement. (16:35) And one of the things that makes this so difficult is that the idea of continuous improvement is that anyone can point out waste. (16:44) Anyone in the organization can call it out and say that's a wasteful process or that's a toilsome thing that doesn't provide any real value, and we should eliminate that or change it in a way that will make it provide value or make it less burdensome on the employees. (17:02) Here's the challenge. Nathan (17:03) Not every organization is open to just anyone pointing out waste and and saying, hey. (17:09) We have to fix this. (17:10) And in fact, in some organizations, when you do that, you might be looked at as, you know, the messenger of bad news. (17:18) And all too often in organizations, when someone brings us bad news, we want to ignore that. (17:23) We might even wanna punish the person that's bringing us that bad news, that's pointing out the waste. Nathan (17:28) We we can't be in that scenario. (17:31) And this is this kind of goes back to all of that culture stuff that Dora has studied over the years and how culture is so foundational. (17:38) If you have a culture that actively works against this idea of continuous improvement, you're gonna have to change something or give up on continuous improvement. (17:48) But there are certainly pitfalls to doing that. Eric (17:52) So I think most of us could probably say where we're at either personally or organizationally, whether maybe you're in a sales organization. (18:02) You can you can see what percentage of sales you're making. (18:05) You can see, customer retention. (18:07) You have metrics. (18:08) So I think most of us have a decent idea of where we're at. Eric (18:13) Mhmm. (18:14) But like any any trip worth taking, you've gotta have a destination. (18:19) So when when we're looking at something like continuous improvement, I I tease this in the opener. (18:25) Do you ever really arrive? Nathan (18:27) Yeah. (18:29) That's a good question. (18:30) I think that it's kind of given away in the beginning of the phrase also continuous. (18:35) Like, this is ongoing. (18:37) This is unfortunately or fortunately, it's it's never ending. Nathan (18:41) We really want to try to get better a little bit every single day. (18:46) Continuous improvement also kind of thinks about this idea of compound interest and how valuable and powerful compound interest is. (18:54) Right? (18:55) So we could spend the next two weeks getting 10% better, and that would be our 10 per like, our two week improvement plan for the year, or we could get 1% better every week across the year. (19:06) And, of course, that 1% better and 1% better and 1% better, it's gonna add up much more quickly, and you're gonna move yourself or your team or your organization much further along the journey that way. Eric (19:19) You know? (19:20) And I have a conversation often with younger systems administrators, people that are actually doing the work unlike me who's graduated, jumped off that ship, jumped onto the marketing boat. (19:32) I'm I'm not sure which which analogy to go with. (19:34) But, you know, being able to I I now market products, but still my target audience are sysadmins, operations folks that make sure that the lights stay on day after day. (19:47) And the the common question, the common fear that I come across is we're being pushed more and more to put things into pipelines to automate tools like Puppet or SaltStack or Ansible Automation Platform, whichever the product is. Eric (20:03) I I talk to sys admins all the time that are maybe not terrified, maybe that's over overplaying it a little bit, but are worried about this idea of if I automate my job, does that mean that I get let go? (20:16) And I I think the I think the ultimate answer, and I want your feedback on this, will be no. (20:22) Because somebody's gotta write that automation. (20:23) Somebody's gotta be there when the next generation of of said product or or when a new data center is stood up or something. (20:31) Someone's gotta be there to innovate and build that automation. Eric (20:34) Someone has to be there to continue to manage the technical operations. (20:42) The we're we're not at a point yet where AI is writing other AI. (20:47) We're not at a point where AI is able to take on a Kubernetes cluster or a fleet of Linux servers and just manage them. (20:55) Maybe ten years from now, we'll we'll be there, and that'll be a different conversation. (20:58) Hopefully, I'm retired and on a beach serving mixed drinks to people by then. Eric (21:04) But for now, automation is just another tool, another way of getting better. (21:09) And one of the things that I like to talk to sysadmins about is find the most tedious painful thing that you do on a regular basis and automate that. (21:19) Then then the next week, you find the next most tedious thing or something that usually has a a time frame associated with it. (21:30) One of the things that comes to mind is standing up new infrastructure, standing up new used to be hardware, standing up new cloud instances, hardware, virtual machines, wherever, and creating users, setting corporate defaults, those kind of things. (21:45) Being able to build up an an image from scratch up to a corporate standard is something else you can look at automating. Eric (21:51) And I I see that as as a function of continuous improvement that would really open yourself up if you take away that tedium to be able to to focus on other things like learning new technologies. (22:03) Like, is this admin? (22:05) If if I were still managing Linux servers, I'd be really interested in, say, the Kubernetes space. (22:09) And is this a technology we wanna pursue? (22:12) How will AI help us build better infrastructure? Eric (22:16) It it allows you to take the knowledge that you've gained and add to it or capitalize on it. (22:24) Or crazy thought, take the PTO that's been racking up in in your in your account. Nathan (22:32) Yeah. (22:33) That that really resonates with me. (22:34) I came up myself as a sys admin, and I tell you what, I've bespoke built servers by hand. (22:40) I had names for them. (22:42) I lovingly cared for them. Nathan (22:43) I came home and I told my children's stories about the servers that I built. (22:47) But, eventually, I did discover tools like Puppet, and then I I I ended up using I used Puppet, and then I ended up using Chef. (22:55) And I I I loved using Chef so much that I joined the company, and I spent about six years working at Chef. (23:01) And I would run into system administrators all the time and and was helping them get comfortable using Chef. (23:08) And I think there's a couple of things that you mentioned there. Nathan (23:10) First, is this automation going to take away my job? (23:13) That's a real fear that people have. (23:15) And I I don't think that automation will ever take away your job. (23:19) It is going to open you up and give you more capacity to do the things that bring more value both to yourself and to your organization. (23:28) You're probably gonna end up solving harder problems, more difficult problems. Nathan (23:32) But, of course, there's also the there there's this truism about automation that when we automate things, you you can't automate what you don't understand. (23:42) I said that's a truism. (23:44) It's a lie. (23:45) I've seen it happen all the time. (23:47) People automate things they don't understand. Nathan (23:49) Now when you do that, it doesn't necessarily lead to great outcomes. (23:53) Oftentimes, the automation goes bad or something just doesn't work the way that you like. (23:58) And so I think to your your point around specialties and having that specialized knowledge, understanding what's happening underneath the automation is just as important as being able to write the automation and and be able to execute that automation. (24:13) I also found that this this was a great way for me as a system administrator to collaborate with the software engineers that were in my organization. (24:23) They were very good about software engineering practices. Nathan (24:26) Practices. (24:27) They knew them very well. (24:28) They didn't necessarily understand the system bits that I cared about. (24:32) You know? (24:32) Where's our package repository? Nathan (24:34) What are we installing here? (24:35) What are we configuring? (24:36) They don't they don't understand any of that, but they understood software engineering practices. (24:40) And so by pairing with them, we could both get smarter. (24:44) I could learn better use of version control, better use of automated testing, and all of those practices that a software engineer just kind of takes for granted. Nathan (24:53) And along the way, I could help them learn a little bit more about the production environment in which their applications were running. (25:01) And and hopefully and in fact, this did lead to less finger pointing. (25:05) You know? (25:05) Something's broken. (25:06) Well, it must be the infrastructure. Nathan (25:08) No. (25:08) No. (25:08) It must be the application. (25:10) We both had a better understanding and better empathy for the difficulties of both sides of that equation and could really relate to one another that way. Eric (25:19) But back in my day, it there was a lot of that finger pointing, a lot of throwing work over the wall. (25:24) The only thing the developers and sys sys admins admins could could agree agree on on was blaming the networking people. Nathan (25:29) Of course. (25:30) Of course. Eric (25:30) It's your application. (25:31) No. (25:31) It's your server, and we'll just blame network. Nathan (25:34) It's always the network. (25:35) Right? (25:35) It's always the network. (25:37) Yeah. Eric (25:39) So we know where we are. (25:41) We know that there's a destination that we'll never fully achieve because Mhmm. (25:46) Lord knows by the time we we arrive that that goalpost has moved on down the line. (25:52) So how how about getting started? (25:55) If if you're stuck, if you're stagnant, if you're burned out, how can you at least start down that path? Nathan (26:03) For sure. (26:03) If you're stuck, stagnant, and or burnt out, I think my first piece of advice to you is the last piece of advice that you gave, Eric. (26:11) Take some of that PTO. (26:12) Get up and walk away. (26:14) Well, just walk away from the problem, walk away from the work for as long as you can afford to do so. Nathan (26:19) Give yourself that mental break and and truly use it as a break so that you can come back reenergized about the work that that's that is right in front of you. (26:29) And then I think the the the place to get started, like you said, find the thing that bothers you the most. (26:35) And and I I typically use the word toil. (26:38) Like, what's the most toilsome thing that you have to do? (26:40) And toil for me, it's it's something that you have to do, but it it doesn't provide any meaningful value or any long term value. Nathan (26:50) So it's something that you have to do today and maybe the same thing you'll have to do again tomorrow. (26:55) And then the day after that, you'll have to do it again. (26:58) How can we automate that away? (27:00) And, frankly, start small because if if this is the first thing you're automating, maybe you don't have a whole lot of experience with automation. (27:07) It might be good to go pull in one of those software engineers and and and do some pair programming or at least some pair design on that to get some inspiration. Nathan (27:16) And just remember, like, as you move forward, things are going to get worse, but they're also going to get better. (27:23) They're also going to get better. (27:24) We're gonna learn as we go. (27:26) And this is the the the whole point of continuous improvement, I think, is look. (27:31) We are always going to take steps in a direction. Nathan (27:34) Sometimes those steps are going to be fruitful and sometimes maybe not so much. (27:39) But it's kind of the mindset of, look. (27:42) We're actually taking an experimental approach. (27:44) And when you run an experiment, you start off with a hypothesis. (27:47) I believe that by automating this particular task, I'm going to save myself, I don't know, two hours a week. Nathan (27:55) And and then I have a choice about what do I do with those other two hours. (27:58) But I also know I can't get the automation done in two hours, so I'm gonna have to make an upfront investment in that automation. (28:05) And the first thing I automate, maybe on an with a new language or a new framework, that's gonna be the most difficult thing. (28:11) And I'm most likely to get it wrong, and it's okay. (28:14) I just I just have to know that and make that investment. Nathan (28:18) And then see after you've run that automation, like, over time, am I am I getting better? (28:24) Or perhaps it's making me worse? (28:26) I don't know. (28:27) But make sure that you're learning from that because better than continuous improvement, I think, is continuous learning. (28:34) As you continue to learn and then take the lessons that you've learned and apply them to what do you do next, that's the thing that really matters. Nathan (28:41) So there's no no there's no guarantee of immediate success. (28:46) But in an experimental approach, when we have a hypothesis, the faster we can validate or invalidate that process, the better off we are. (28:55) And whether the hypothesis like, whether the experiment succeeds or fails, we've won because we've just learned something new. (29:04) And you have to take that approach to the work that you're doing. Eric (29:08) So true. (29:08) I mean, it's it's it's kind of cliched, but it's it's very true that you oftentimes learn more from failure than you do from success. (29:17) If you write if you write a program, if you write a script and it works the first time, k. (29:22) Great. (29:23) You've got a program or a script, but does that really tell you how things work? Eric (29:28) But as as you're as you're explaining as you're explaining this, one one thing came into mind was time is probably a huge factor in something like automation or continuous improvement. (29:40) Mhmm. (29:41) But what about what about taking something what about automating something that you may spend six or eight hours automating and only takes you ten to fifteen minutes? (29:53) How would you justify it to management? (29:56) How would you start to shift that culture? Eric (29:59) And if if you don't mind, the first thing that came to mind was human error. Nathan (30:04) Mhmm. Eric (30:04) The first thing that jumped in my brain was if we automate this, yes, we may have to make a substantial initial investment, especially if we're new to the automation. (30:14) One of the things that I think about was, well, now no longer am I in there typing 16 commands or copying and pasting from from a six year old document that three administrators before me wrote. (30:27) But instead, we are automating it. (30:29) And now every time that that fifteen, hopefully now, like, four minute process runs, we know that the automation is there, that it's solid, that it's tested, and Eric doesn't misclick or miscopy a command or forget to copy a command and have to redo that. (30:47) So one of the first things that comes to mind is not only time savings, but also risks risk mitigation. Nathan (30:53) Yeah. (30:54) The nice thing about automation is that it will do the the the thing that you've automated. (30:59) It will do that probably faster than a human could and almost certainly more consistently than a human could. (31:07) Now sometimes that's good. (31:10) It could also be bad if you back to this idea of you can't automate what you don't understand. Nathan (31:15) If you write some really bad automation, it will do that really bad thing quickly and, regularly and with consistency. (31:23) So you you you do have to be careful about that. (31:27) I also, you used a trigger phrase for me, so I just I have to come back Eric (31:31) to it. Nathan (31:32) You you mentioned human error. (31:34) And and, frankly, human error is like, that that phrasing is kind of a cop out. (31:38) Right? (31:39) We all work in complex sociotechnical systems, and the system basically produces the outcome that the system is designed for. (31:47) And so if a human makes a mistake unless it's, like, intentionally harmful. Nathan (31:55) Right? (31:56) If a human makes a mistake, it's not it's not we should not attribute that to human error. (32:01) We should look instead at the system. (32:04) And maybe they push the wrong button. (32:06) Why do we have that button? Nathan (32:07) Is that button necessary? (32:09) Why is it so prominent on the UI? (32:11) Why is that why does that command exist? (32:12) I mean, there's so many different things that we can look into there. (32:16) But, really, we we should all assume that each and every one of us shows up to work to do the best that we can given the context and the information and the goals at hand that we have. Nathan (32:28) And that will necessarily mean taking risks. Eric (32:31) Mhmm. Nathan (32:31) And and we have to live in a place, in a team, in an organization where taking risks is okay. (32:38) Because what happens if if you take a risk and it fails and then you sweep that failure under the covers or under the rug, no one can learn from that, including yourself. (32:49) And so we have to be very careful about that. Eric (32:53) So I'm I'm smirking because as you're as you're reframing human error, the thing that came to mind was the the dreaded conversation back in my help desk days of, well, I told the computer to do this and it didn't do that. (33:07) It's like, no. (33:08) The computer did exactly what you told it to do. (33:11) It it went through its algorithm. (33:13) It went through its programming. Eric (33:14) It did exactly what you told it to do. (33:16) But what you told it to do was not what you thought you were telling it to Nathan (33:19) do. (33:20) Yes. (33:21) Yes. (33:22) I wish that computers and humans would do what I meant, not necessarily what I said. (33:27) Yeah. Eric (33:28) Exactly. (33:29) So we've got we've got risk mitigation. (33:31) We've got time savings. (33:33) Are there some other things that people can use to sort of justify or encourage their organization towards a path of continuous improvement? Nathan (33:42) Yeah. (33:42) There's a couple of things. (33:43) So first and foremost, I think if we go back to the individual level, it is about career growth and and meeting the outcomes that you're seeking. (33:51) And it doesn't matter what what those outcomes are. (33:54) Right? Nathan (33:54) But let's say today you're a junior sysadmin and you're doing everything by hand. (33:58) One day you don't wanna be a junior sysadmin. (34:01) You want you want to move up the ranks. (34:03) You wanna have a bigger impact on the customers that are using your systems. (34:08) Automation can be a path to help you get there, and and that automation is new learning, continuous improvement. Nathan (34:16) So you're you're getting better over time. (34:19) So I think that's really important. (34:20) And then another thing, I think it is it is really important to recognize that without support from leadership, it can be very, very difficult to make investments in continuous improvement and and investments in improving anything. (34:36) And so, hopefully, your leaders are on board, and you can go and talk with your leaders and get that support and buy in and and, frankly, the the the goals to go and do that, the incentives to make continuous improvement work well. (34:52) If you can't, I think, you know, maybe you can hide some of the improvement work that you're doing. Nathan (34:59) Maybe the thing that takes eight minutes manually and you get it down to thirty seconds if you automate it, find some time to get that automation done, and then, you know, I'm not suggesting that you lie to your supervisors, but you utilize that to make your life better. (35:16) Mhmm. (35:17) And you you have you have the autonomy. (35:19) You have the permission. (35:21) Frankly, you have the responsibility to take that on to take care of yourself. Nathan (35:25) And, hopefully, your organization and your leaders will recognize and reward that. Eric (35:32) So I I did that. (35:33) The the last company I worked for is a sysadmin before I made the the switch to product, was very averse to anything DevOps, anything container. (35:45) To them, the those things were just fads. (35:47) It was DevOps was a bunch of hippies, and and it was eventually going to go away. (35:52) Now part of me wants to go back, you know, that was ten years ago now and just say, you were wrong. Eric (35:58) But I've like to think I've evolved a little bit since then. (36:02) But so it it was one of those organizations where, again, operations guy. (36:07) So operations scarce had to do patching at, like, midnight Yep. (36:13) Or one in the morning. (36:15) And so, I mean, having a young family, sleep was at a premium. Eric (36:20) And so having to do outages at, like, one in the morning was was brutal. (36:25) But I was the junior guy on the team. (36:27) I was just a systems engineer. (36:30) Not sure why I was a systems engineer and still responsible for patching, but that's a different conversation maybe with alcohol involved. (36:37) But the the the weird thing was that, you know, here we are still manually applying patches to hundreds of Linux servers. Eric (36:46) And we have to do it at night because we don't dare take something out of the load balancer during the day. (36:51) And so what I realized that I could do was you can actually run yum at the time or d n f or or whatever your package manager is, and you can do a download only. (37:03) So it'll go out and it'll it'll still take inventory of all the packages you have, all the packages that have updates, and you can actually tell it, download everything. (37:11) But don't install. (37:12) Don't upgrade. Eric (37:13) Don't don't make any changes. (37:15) Just literally download download those packages to your hard drive. (37:19) So the day of an outage or if it was a Saturday, the day before an outage, I'd go in and I'd schedule a cron job to go in and say the outage starts at one p one 1AM. (37:31) I at 01:05, kick off that package download. (37:35) The the DBAs or the web application administrators would be shutting their stuff down, and I would be taking that time to, like, wake up because I'd I'd go to bed at, like, eight or 09:00, try and get a few hours of sleep in before I had to be up half the night. Eric (37:49) And so I'd I'd wake up. (37:50) I'd log in. (37:51) I'd go jump in the shower. (37:52) I'd come back, and by then, the packages were downloaded. (37:55) The apps teams, the DBAs, everything was was shut down and ready. Eric (37:59) So all I had to do was go in and just run and sit back and yawn, stretch, and try and stay awake. (38:06) Then packages would be installed and handed back. (38:09) And DBAs and apps teams and everything were like, that was really quick. (38:14) It's like, yeah. (38:15) We hey. Eric (38:16) It's middle of the night. (38:16) We got a we got a wide open Internet pipe. (38:18) It's it's great. Nathan (38:19) There you go. (38:20) Don't tell anybody. (38:23) Yeah. (38:23) But but, you know, that that that's a great example of taking one small step forward that really helps both yourself and, as it turns out, it helped the entire team. (38:34) Now we can go back to this idea of doing late night deployments and how how much that really impacts your productivity over the long term and certainly the next day. Nathan (38:46) Maybe that's why they did them on Saturdays because then you could have Sunday to rest and you'd be ready to go on Monday when you came back to work. (38:53) That doesn't seem very humane to me. (38:55) And we certainly have better ways of operating today. (38:59) And so, hopefully, if you're listening, you aren't doing those 1AM, 2AM weekend deployments and and outage windows. (39:07) Hopefully, you're you're moving to something that is much more sustainable over time. Nathan (39:12) And that's that word sustainable is super important when we talk about continuous improvement as well. (39:17) Right? (39:17) We aren't talking about changing everything overnight. (39:19) You can't change everything overnight all the time in a sustainable way. (39:23) We are talking about sustainable improvements that we're making throughout the course of a career as an example. Eric (39:30) For sure. (39:31) And and a tip to the wise, don't go in and tell your management that everything they're doing is wrong and they should change it. (39:38) Younger Eric made that mistake. (39:41) Didn't go over well. Nathan (39:44) Yeah. (39:44) I think I think that's that that is a good point that in an organization at varying levels of the organization, you have visibility into different things. (39:54) Right? (39:54) And so if if if the only thing that I can see an impact are are the things that are directly related to either my work or my team, I may miss the forest for the trees. (40:05) And I'm trying to fix this here tree. Nathan (40:07) Well, the the whole forest is on fire. (40:09) It doesn't matter what you do to fix this tree. (40:11) It's not gonna have any real meaningful results, potentially. (40:14) Right? (40:15) So at different levels, you can see different problems, different opportunities across an organization. Nathan (40:22) So keep that in mind. (40:23) And then the other thing I would keep in mind is it is important to understand how like, what are the politics and the culture around me within the organization? (40:32) You mentioned earlier, like, an organization that was like, oh, this DevOps thing is a fad. (40:37) Great. (40:38) Then I will never use the word DevOps, but what I will do is talk about how do we automate our releases? Nathan (40:44) How do we build better feedback mechanisms into our development processes? (40:48) How do I collaborate with another team member who's who's on a different team? (40:54) All of these things are things that you might do if you were doing DevOps. (40:57) But if we never say the word DevOps, we can lean into those principles and those practices, and and we'll see that they late lead to much better outcomes for everyone involved. Eric (41:10) To kinda close that loop, the this this company that had me doing patching for hundreds of servers at 1AM that I basically went and told that this this is a terrible idea. (41:21) We're we're gonna really screw ourselves. (41:25) The funny thing is when I was working there is when I was recommended the Phoenix Project. (41:30) And so for if you're listening and you've never read the Phoenix Project, go read it. (41:34) I swear that that the authors were standing in some of the same companies that I was and just wrote a book about. Eric (41:42) It's it's like a novel that introduces a lot of these concepts that we've that we've talked about. (41:47) And and no one in the book says anything about DevOps. (41:50) But but so I I blame getting a little overexcited because it's like, I read the Phoenix project and then I read read the DevOps handbook and it's like, oh my gosh. (42:01) These people have there's there's a name for all these things that I thought, you know, it would make sense if we did it this way. (42:06) And it's like, oh my gosh. Eric (42:08) This is a this is a thing. Nathan (42:09) It's a Eric (42:09) real thing. (42:10) And so that's when I went to my first DevOps days Kansas City conference. (42:13) And two months later, I went to work for GitLab as a solutions architect. (42:19) That was that reading the Phoenix project was literally the the moment that shifted my career from being a sys admin, lifelong sys admin to moving into product to eventually sales and now marketing and hosting podcasts and going to conferences by choice. (42:36) So it it was, I mean, it was one of the worst environments I'd ever been in, some of the worst technology deployments I'd ever seen, but it it it really changed my career and changed my trajectory. Eric (42:49) And it a lot of these principles, like continuous improvement is something I live every single day. (42:55) And it's it's not can you can you get a 10% gain in a quarter? (42:59) It's am I am I not where I was yesterday? (43:02) Have I moved forward? (43:03) And sometimes that means taking a step back. Eric (43:06) So maybe some days you you lose a couple of percent. (43:09) But if if overall you're projecting forward and you're moving forward and you're not where you were, You know, it's it's funny to talk about the this this old IT job I had in light of I'm getting ready to celebrate five years at Red Hat and kinda doing the same stuff that I've been doing for the last five years despite the job transition. (43:28) It's it's really exciting to look back and go, I'm definitely not where I was then. (43:35) So it's very, very conveniently timed episode. (43:39) I I really appreciate it, Nathan. Nathan (43:40) Alright. (43:41) That's awesome. Eric (43:42) So as as we wrap up, are there any closing thoughts? (43:45) Anything you wanna you wanna make sure people don't forget? Nathan (43:48) Yeah. (43:48) I think that I I just wanna come back to Dora for a second. (43:51) Like I mentioned, that's the research program. (43:53) We published an annual report. (43:55) Our annual report for 2024 will be coming out soon. Nathan (44:00) Our current target is mid October, so definitely watch for that. (44:05) And, Dora, our our tagline is get better at getting better, which is another way of saying, like, just embrace this idea of continuous improvement. (44:14) And so I encourage everyone to go over to dora.dev or dora.community where you can learn more about the research, you can download previous reports, And, of course, you'll be able to catch the 2024 report in about two weeks time. Eric (44:29) That's awesome. (44:30) Yeah. (44:31) I had you you and I were talking about this at the conference that and actually was familiar with your work before you and I'd ever even met. (44:39) I'd I'd read those reports. (44:41) I'd used it to to kind of color my thinking of, you know, where do I need to be from a from a personal level. Eric (44:47) Granted, most of my career, I've been an individual contributor, so I haven't really had the the pull to shift things, but I can at least I can at least project onto my own career what do I need to be ready for. (45:01) But it it's amazing work. (45:03) The reports are are really helpful. (45:05) Lots of graphs and explanations, so it's it's easy to digest even if you've never read one before. (45:11) Awesome. Eric (45:12) And then from my side, if if you haven't, check out the Phoenix projects and and look at some of the things that Dora does. (45:18) It'll really help inform your decisions not only for yourself, but also for your organization. Nathan (45:24) Yeah. (45:24) And in addition to the Phoenix project, you can also read the book Accelerate. (45:28) Accelerate is written by doctor Nicole Forsgren, Jess Humble, and Jean Kim. (45:32) Accelerate is the culmination of the first four ish years of the DORA research program put into a book. (45:39) So I definitely recommend reading that after you've read the Phoenix project. Eric (45:44) Yes. (45:45) Point of clarification though, I wouldn't suggest the audiobook. (45:49) I listened to it as as an audiobook, and it was not as helpful. (45:53) Maybe that's just because numbers and I don't get along. (45:56) So I I definitely would it were me reading it again, I'd definitely pick up either an ebook or a physical copy just so you can actually visualize some of the numbers. Nathan (46:07) Yeah. (46:07) For sure. (46:08) There's also a good bit a good section in this book that's about the methodology used in the research study, which either you're a researcher and you'll, like, really geek out on the methodology used, or maybe that's not your jam and you can trust that the scientists behind this are using good rigorous methods and just skip that third of the book that talks about the methodology or skip it. (46:31) Listen to it on two x speed, something Eric (46:33) like that. Nathan (46:34) And then if you are listening to audiobooks, I always recommend buying the receipt. (46:38) If you have the audiobook and you listen to it, you've got the receipt that you can go back to and check out, you know, the physical property. (46:45) Awesome. Eric (46:47) Nathan, thank you so much for joining me. (46:49) Really appreciate your time and and taking a look at continuous improvement. Nathan (46:53) Alright, Eric. (46:54) This has been a lot of fun, and I hope that all of the listeners do one thing in the next week to take a step forward. Eric (47:02) I love that. (47:03) Yep. (47:04) One step forward is all all you gotta worry about. (47:06) That's it. (47:07) Awesome. Eric (47:08) Thank you, Nathan. (47:09) Thank you everyone for listening. (47:10) Make sure to like this episode so I know, what types of content to focus more on. (47:15) And if if you wanna get connected with with with Nathan, he's got a a link tree, which actually picked up on at the same conference and love it. (47:27) I think you've got a website, contact information, social media, all the things in So one now I don't have to list out six different places to find Nathan. Eric (47:35) Just follow the link to his link tree and you can get connected with Nathan. (47:39) And you're you're traveling frequently, so you you might actually run into Nathan at a conference. (47:45) But also make sure to wow. (47:48) I speak for a living, and you can tell we're recording in the evening because my I'm just words are done. (47:54) Make sure you subscribe so you get get notified anytime I release new content. Eric (47:58) Hoping to have a new episode out here in a couple of weeks. (48:01) I've got, like, three different guests that I'm waiting on scheduling times for, but try to release this podcast every two weeks. (48:07) But if you're listening to this on the day of release, definitely go subscribe to the Fedora channel as well. (48:13) The Fedora Linux podcast is a is a is a passion project of mine, and we'll be talking here in a week's time about Fedora quality assurance, also known as QA. (48:22) We'll be talking about whether it's important or not to test your code and and what it means to test code, what what testing pipelines are. Eric (48:31) Maybe we'll talk a little bit about the Fedora beta project Fedora beta program a little bit. (48:36) So plenty of content coming your way. (48:39) Really appreciate you taking the time to listen. (48:42) And, on behalf of my guest today, Nathan Harvey, I've been Eric, the IT guy Hendrix, and this has been the IT guy podcast. (48:49) So we look forward to seeing you again next time.