Whether you've just become an engineer or maybe you are already down the path and you're at the kind of a senior level. At some point in your career, you're likely to face the choice of whether or not you want to become a manager. We're going to be talking about some models that managers can use to improve the way they think about engineering management. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Today's episode is pointed towards managers. It's going to be the first in a series of episodes about management, about engineering management specifically. But I want to point out that the principles that we're talking about in these episodes apply to engineers as well. Certainly, if you are a team lead engineer, if you're kind of splitting your responsibility between writing code, producing code, and leading a team in some way, then these episodes are going to be particularly valuable to you. If you are an engineer and you haven't gotten to this crossroads yet, then these episodes might help you prepare for that or decide whether you even want to pursue it. Maybe something that you can choose a different path from. That's the goal of this episode is to introduce some ideas, some models, and in fact, we're kind of temporarily, at least, titling these episodes, the model manager, model manager episodes of this show. My hope is that this will be an ongoing series. We'll come back to it and add to it over time. There's not a specific roadmap for management. Management is not a progressive career as much as being a software engineer might be, because a lot of the skills that you use as a manager, you can use as the senior, most level manager. Most of the progression that you will experience in your career as a manager is likely going to be the result of project succeeding, of time passing. You have context. You have built up equity and a relational equity, that kind of thing. A lot of the skills that you use on day one, you're going to be honing and continuing to use those same skills throughout your entire career as a manager. The first model that I want to talk about today is a meta model in a way. Most of what we do as managers has an indeterminate output. You'll see this expressed in a lot of different ways. If you were to Google, what is the ultimate goal? How do you measure a manager's performance? Some people say that you measure a manager's performance by looking directly at the team's performance. This is probably a useful way of thinking about it, but probably also an incomplete way to think about it. Some people say that the output of a manager is process. What is a manager responsible for? They're responsible for honing a process. I want to focus in on this one today. I want to talk about how we measure the success of a process or how we observe a process to begin with. There's a lot of different things that we could classify as processes. It's kind of an overloaded term. There's a lot of baggage that the term comes with. Processes might be something that you feel weighed down by as an engineer or even as a manager. There's good reason for this. A lot of the processes that we've inherited, maybe from an HR department or maybe from the team that came before us or maybe it's from another department or another pre-existing engineering team and their parallel to our team. Since they did it, whoever is responsible for all of the teams, they copy-paste the process across all of the teams. Generally speaking, when we talk about process, we're talking about something that is a uniform way of accomplishing something. That's a very broad, intentionally broad description, a uniform way of accomplishing something. This uniformity is determined usually in some kind of documented fashion. We have whether it's a tool that's kind of enforcing the uniformity, maybe the manager themselves is kind of ensuring the uniform execution of that process. Whatever it is, there is some kind of standardized way of determining what steps to take so that your approach to kind of trying to accomplish something is uniform. The idea of business processes isn't new. This isn't something that came along when we started building software. This is something that has been around for as long as we've worked as people. Because a process, especially a uniform process, is intended, generally speaking, to produce uniform results. Of course, this was particularly important in the industrialization age when we started making things that were actually standardized. When you have humans producing something that needs to be standardized to a particular specification, process can help with this. Our preconception of what a process provides gives us the idea that we have some kind of inputs, typically some kind of raw input, that we can perform some kind of action, perform some kind of modification to that input, and then produce something out of it. In this way, processes are very much a functional part of our businesses. And so, for most of our kind of human history, especially documented human history around processes, we focus on that output, the quality of the output. If you're like me and you've heard of Six Sigma, but you've never been trained in this concept, the idea of Six Sigma is actually to produce a process in which, and I'm reading this directly from Wikipedia, 99.9966% of all opportunities to produce some feature at the park are statistically expected to be free of defects. In other words, Six Sigma is intended specifically to improve a process based on defect rates. As an engineering manager, I'm going to challenge you to think about processes in a totally new way. At first, we're going to talk about today's sponsor. Going to comprehend the impact that the internet has had on the world, it seems incomprehensible, but not that long ago, the internet was brand new. In fact, in this season of Command Line Heroes, hosts Serraniac Barak, takes us on a journey in exploration of a pivotal year, 1995. Most people listening to this show are probably remember 1995. It was the start of the dot-com boom, but a lot of things had to come together for this to actually happen. Season 7 is available right now, and listening through the first episode, it feels like magic. It's the beginning of this lore that is now a part of my job every day, and probably a part of a lot of people who listen to this podcast job. Now it's easy to just go and grab a domain name. Everything is kind of automatic, but once upon a time, there was actually a person, a woman that you would have to call to get your domain name, and they managed it directly, like by hand in a spreadsheet. It's pretty amazing to hear the evolution of the internet from the people who were there. Go and find Command Line Heroes anywhere you listen to a podcast. We'll include a link in the show notes. My thanks to Command Line Heroes for their continued support. Whether you have a good or bad relationship with the concept of business processes, team processes, engineering processes, I hope to change your mind about the goal of a process. As it most of the time, businesses that implement a strict process, they are thinking about the outputs as a product. This makes sense for a lot of business types, but it doesn't make very much sense for software engineering. Yes, we can improve our products by instituting good business practices, but our biggest asset and the thing that we need to be refining every day, especially as engineering managers, is the team. Often our software is almost a direct reflection of the team that's building it, the quality of the software, and the ongoing effectiveness towards a business goal, those things are much more correlated with the quality of the team. So I want you to think about the output of your process as human behavior. Think about the output of your process, the primary output of your process as human behavior. Because here's the reality, creating a process, especially a process that all of the work that your teams are doing has to run through, this is effectively building the behaviors and the habits that your team will adopt. A lot of times when processes are created, we're not thinking about the fact that we're training people in the behaviors necessary to accomplish those processes, to actually effectively use those processes. And so when we think about the amount of influence that we have on human behavior, when we change a process, this becomes absolutely the most critical output of your process. Because there are so many ways that you can change the actual output, right, the product output of a given process, but human behavior is a lasting and a much more effective lever. When you change a process that changes behavior, now you start getting into much longer term, much more kind of deeper effect than simply changing the code that gets produced. So I want you to think about the human behaviors. And of course, it should be noted that we're not just talking about changing behavior directly. We're talking about changing the environment that people are in and the behavior is a long term. Being indicator meaning that you're not going to make an adjustment to your process and then immediately see a behavior change. A lagging indicator means that the person will change their behavior in order to accomplish their job theoretically. But we're not looking for a root action change. That's not what we're looking for. What we're looking for is how does this affect the mindset, the approach, how does this change the way they're thinking about their work, the way that they're interacting with other people, their mental health. This is the most critical part of measuring the effectiveness of your process change. Now I can hear people's skeptics that are thinking, well, if you change the process and it produces a worse quality output, it doesn't really matter what the behavioral change is. My simple counter to this is that when you produce the right kinds of behavior change, the quality of the software is another lagging indicator. Of course, you can build in the concepts of checkpoints or reviews, feedback. But all of this realistically is going to be a part of the behavioral changes. We're looking to have a healthy feedback as a part of our team structure. Well, that healthy feedback is likely, very likely, to produce the quality that you're looking for in your software. All of this comes back to the same core thesis, if you want to call it that, that the output of our processes, the primary output of our processes is human behavior. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Command Line Heroes for their continued support of the show. Go and check out this dive into the past, the pivotal year of 1995 and the years around it. You can find season seven of Command Line Heroes wherever you listen to podcasts, including where you listen to this one. This show would not exist without your support and frankly, it wouldn't exist without you sharing it with other people. There are a lot of ways that you can share this podcast or you can amplify it to other engineers. One of the most important ones is leaving a rating and review in iTunes. Of course, this helps the show climb the ranks in iTunes. It's a very important part. Games isn't the only one you can leave a review in a lot of the various podcast players that you use, so those reviews help as well. Then of course, sharing it directly or maybe even indirectly on social media, but sharing the show as you're listening to an episode and you think of somebody that you think would benefit or would appreciate this particular episode, sharing this specific one with them. That is one of the most impactful ways, both for you since you're giving them something of value, hopefully, and for the podcast. I appreciate those kinds of interactions so deeply. If you want to go deeper with the concepts that we talk about on this show, with me and other engineers.