Many of you probably know that my day job for many years now across multiple companies has been to operate primarily as an engineering manager. Now, that looks different from one company to the next. It looks different depending on the kinds of teams that you might be managing. What kinds of reports do you have? Are you in a startup? Are you in a larger organization? I've worked in multiple organizations, some a little bit bigger than others. I've never been in a mega large organization. Take what I have with a grain of salt if you're in one. I've never been in one of those kinds of situations, but I do think that what we're going to share today is still applicable to you as well. One of the things I've noticed since I kind of went down the road of becoming an engineering manager is that there seems to be a lack of engineering management specific content. There are some very good books out there. There are some good other podcasts that kind of focus. On this on this topic, but there there is still a lack of of information and guidance out there for other engineering managers. So what I want to do in this episode and in a series of episodes after this one, I want to talk about specific tools or tactics, you know, things that you might take into the workplace as an engineering manager. Now, before you leave, if you're an engineer. And not an engineering manager. I do think that this episode and the following episodes will be relevant to you still because one, you might one day choose to go down the management track. This will help you get a taste of some of the things that you might care about or might want to do as a manager. And, you know, either make that decision. Maybe it will help you make the decision one way or the other. And then secondly, because the things that we're going to talk about are not necessarily only, you know, something that engineering managers can do a lot of times in organizations, especially smaller organizations, lead engineers tend to take on some of these management duties. Right. And and also staff engineers, you know, project leads, whatever those roles are. A lot of the time. There is some. There is some crossover between the more formalized kind of engineering manager role and those leadership engineering roles. So I don't think that this episode or other episodes in this series, this kind of manager tools and tips series are necessarily going to serve you wrong. It won't be a waste of time by any means. So I encourage you to stick around and listen to these episodes like you would any other episode of Developer Tea. In this first episode, I want to give you some language that you can use a conceptual language or a mental model. If you want to call it a mental model, it's more just, you know, a concept for you to use to understand and very likely solve a lot of problems that your team may be having. So, you know, we'll start with with a problem that you might be experiencing. And then we can discuss some of the, you know, this this model, this language that may help you work through these problems. The problem you might be experiencing is you're not really sure how to order your backlog. Maybe you're struggling to understand exactly what the next priority is. Or maybe there is some kind of misunderstanding between you and another leader, maybe a product owner, product manager, program manager, your boss. And it may be that you're coming from another situation where all of this was very different. And you're trying to kind of wrap your head around how this new team does things. So the language I want to give you to kind of understand this problem is product lifecycle governance. Product lifecycle governance. What does this mean? Well, a lot of times we imagine that any company that we're working. Is going to have the same kind of product product development lifecycle. Right. A very natural assumption will be that however your last company worked is how your your next company will work. And so this this information is particularly relevant for those of you who are moving into a new role. You know, this this might be surprising if you're going from a developer role to an engineering manager role. But also for engineering managers who are moving from one company to another. So this concept product lifecycle governance is directly related to the product development lifecycle. You've probably heard of this at some point. The PDLC is what it's probably quickly referred to as the product product development lifecycle. Kind of walks you through the stages that work goes through. Right. If you think about how does something arrive on your engineers plate? Right. If you're if you're a manager. You should know or you should be able to find out. How does work ultimately end up in front of my report? Because the ideal state. Everybody wants to be working on the most important thing. There are very few people who would consciously choose to sit down and work on something. That you know their boss or their organization doesn't want them to work on. Okay. So what you're really asking. When you ask this question is. How do we determine. What the work is. And in what priority order we should work on it. How do we determine what the work is. And in what priority order we should work on it. There's a lot of things that go into that full lifecycle. Right. And parts and pieces of that. They're very granular in nature. For example. Whose responsibility is it. To populate the backlog. You may have an immediate answer that comes to mind. But I promise you. That there are probably a hundred other companies that do it a hundred other ways. So. Whose responsibility is it to populate the backlog. Could have multiple answers. There could be two. Completely different and still effective answers to this question. Right. So what you're really trying to do as a manager is understand. Where are the decisions. Being made. That's the governance part of the product lifecycle. So. If we're. You know determining. What are we going to do. Should we work on. You know tech debt. Or should we work on this new. You know this new feature. Is a common. Conundrum. That an engineering manager is faced with. How much. Tech debt should we take on. What is the. Governing model. For. How we manage tech debt. Right. That's really what the kind of thing that you're asking here. What is the governing model. For. When we are choosing to adopt new work in. Should we. You know work on the new feature. Or should we expand the existing feature. Who decides. Right. Again. You know even I have to. Kind of. Push against my preconceived notion. Of answers to these questions. I have ideas about. What an effective kind of. Setup might be. For this right. In that particular case. You know who should decide that. Probably somebody who has product expertise. But that's not always going to be. How your organization operates. So what you really need to understand is. Where are the decisions being made. Decisions are. The kind of the. The fuel of governance. Right. So who is. Governing. Who is. Who is. Changing the direction. Or moving. The energy. Right. Deciding what energy goes where. Who decides. What the team. Should be working on. You are probably part of that equation. As a manager. You are probably. One of the. You know. Empowered governors. Okay. So it's very important for you to understand. What your power is. What are you able to. To. Speak to. What are you able to govern. And what things are out of your hands. Or should you be working with someone else. To make decisions about. Ultimately. If you don't understand this. You could end up. Not executing where you're supposed to. Right. You're omitting. Your governance. Which is not good. Because you could end up. You know. Having chaos. In that particular area. And. I'll. Say. You could end up. Trying to govern. Where you're not supposed to. Or where the. The. Kind of model. Dictates you're not supposed to. And then of course. It could be that the model. Doesn't have. Good specificity. And that you. May need to collaborate with your peers. Or. With your product partners. Or with your team. To actually develop. A better governance model. So again. The language here is. A product. Life cycle. Governance. What is the product. Life cycle. Governance. And this is through. All stages. Really. You want to understand. You know. The ideation phase. Of. Of work. Where does it. Originate. You know. Are we doing. Product research. With our users. You know. When we get a bug. Are we. Evaluating the bugs. So that we can bring that into. Our bug backlog. You know. How. How do we surface tech debt. This is one that's. Often. Totally forgotten. You know. You probably have tech debt. That doesn't have any representation. In your backlog. Because you don't really have. Any governance model. For who's responsible. For surfacing. That. That deck. That tech debt. In a way. That can be. Actionable. Right. So there's. All of these. Aspects. Of governance. Are part. Of. The product. Life cycle. Governance. Model. And it makes sense. It makes sense. To write this down. It makes sense. To resolve. Over time. So. It makes sense. To iterate on it. To. To retro. You know. With other engineering managers. In the organization. With other leaders. In the organization. To determine. Is our governance model. Working. Or is there confusion. Is there frustration. You know. Do we have the right information. At these decision points. This is. You know. One of the main tools. That you can use. Especially. To establish. Some of the other parts. Of your process. If you don't have. If you don't have. Your governance model. Right. Then a lot of your other process pieces. Are probably going to fall apart. Because. Again. Your governance model. Is intended. To produce. What outcome. Think about it. The outcome. That your governance model produces. Is the idea. That everyone is working. On the right thing. At the right time. That is the whole point. Of this governance model. Is that. We are. Optimizing. Our decision making. And our processes. So that. All of our. Human resources. All of our. Deployed engineers. All of our. Individual contributors. Are all working. They are all focused. And expending their energy. Towards the right things. Towards the things. That we want. To spend our energy on. Right. If you don't have. The governance model. Then all of your other processes. That are. Kind of sub processes. Right there. They are. Intended to. You know. Help. You know. With. A smaller part of the development. Of the process. You are going to be working. On the wrong things. So. It doesn't really matter. How effective you are. On the wrong thing. Right. So that's. That's why the government. Governance model. Is kind of the. Like the entry. Point. To all of the other. Work that you'll do. Thank you so much. For listening. To this episode. Of developer T. This. Kind of special. Manager. Tips and tricks. I'm not really sure. What we're going to call. A series. You know. It should show up. In the title. Of the episode. But. Hopefully. This was. Insightful. For you. Even if you're. Just. You know. Just starting out. In your career. As a manager. Or if you're. An engineer. And you're. You know. Curious about the idea. Of becoming a manager. You could even ask. This question. Of your manager. And it might be. The first time. That your manager. Has ever heard of this. Then you can point them. To this episode. You know. That. Of course. Can spark. At theijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij