Whether you've just become an engineer or maybe you are already down the path and you're at 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 Cottrell. 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. Certainly, if you are a team lead engineer, if you're 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. So 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. And 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 projects succeeding, of time passing. You have context. You have, you know, you've kind of built up equity in a company, relational equity, that kind of thing. So 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. So the first model that I want to talk about today, is kind of a meta model in a way. Most of what we do as managers has an indeterminant output. You'll see this expressed in a lot of different ways. If you were to Google, you know, what is the ultimate goal? How do you measure a manager's performance? Some people say that you measure managers performance by looking directly at the team's performance. This is probably a useful way of thinking about evolution. 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, and 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 they're kind of parallel to our team. Since they did it, whoever is responsible for all of the teams, they kind of copy-paste the process across all 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. It's 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. And 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. This 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, a process can help with this. And so 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, a process in which, and I'm reading this directly from Wikipedia, 99.99966% of all opportunities to produce some feature of a part 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, think about the process, and think about the impact of the internet on the world. In a totally new way. But first, we're going to talk about today's sponsor. Trying 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, host Saranya Barak takes us on a journey, an exploration of a pivotal year, 1995. It's not that long ago. Most people listening to this show are probably, 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 seven is available right now, and listening through the, the first episode, it feels like magic. It's kind of the beginning of this lore, uh, that is now a part of my job every day. And probably a part of the, 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 podcasts, 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 company, or you're a little bit of a! 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, 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 is 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 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 a process. There are so many ways that you can change a process. There are so many ways that you can change the actual output, 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 you into a much deeper effect. That gets you into a much deeper evolution. 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 lagging 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 rote 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, 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, you're not going to be able to change the way that you're thinking about your process. 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 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. So all of this comes back to the same kind of 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. iTunes 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. And 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 kind of impactful ways. Both for you, since you're giving them something of value, hopefully. And for the podcast. So 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.