As you begin to gather your influence, as you begin to climb the ladder in your role as a software engineer, if you move into the management track especially, this episode is directly geared for you to avoid one of the biggest mistakes, one of the biggest mistakes that you can make as a technical leader. It's very simple to fall into this trap and I want to help you avoid it and I want to give you the alternate path that you need to take instead in today's episode. My name is Jonathan Cottrell. You're listening to Developer Tea and my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. You may believe and you may even have seen an engineering leader. Uh, do this thing. You may believe it's the right thing to do and that, uh, that picture looks like this. Your tech lead keeps tabs on everything. They know all of the implementation details. They know every tool in the stack. They are unequivocally a master of the craft and anything that goes into production, they have laid eyes on. They have laid eyes on. They have laid eyes on. They have laid eyes on. They have laid eyes on. They have laid eyes on. This sounds like what we imagine at the beginning of our careers is the direction we need to head eventually, that we eventually need to be so aware of everything going on in the product that nothing can get past us. We are the catch all the net. We are the safety mechanism that everything that goes out has our fingers on it. Our fingerprints on it. And this makes sense intuitively because when we're early in our careers, people are telling us to do more of that. When you're a young software engineer, your manager might tell you to take ownership over something. To get involved in pure code reviews or to design one of the bigger, uh, you know, bigger features, one of the implementations that is on the roadmap. And so it's intuitive to believe that if it worked back then, then I keep doing more of that and I can continue growing. But the truth is significantly different from this. The truth that one of the best things you can do is to give up control. Interestingly, this idea that you should be the master of the craft is somehow accidentally intertwined. With an over control. This means that once again, nothing goes out without your fingerprints on it. This means that nothing can go out without your fingerprints on it. If the team gets used to you being the only subject matter expert or you being the only technical master on the team, then they will become dependent on you. This will slow your team down. This will mean that you have less control. You have less control. You have less freedom than you used to have. This will mean that you have less autonomy and more stress. Ultimately is an unsustainable route towards leadership. Some people do walk this pathway, but they tend to pay for it in the long run. And so this is why I say it is one of the most critical mistakes that you can make. One of the biggest pitfalls you can step into as a tech leader. So what? Is the alternative option. If you're not going towards control, you're not just ignoring it. You're actually going definitively the opposite direction. This is one of the rare circumstances where your counterintuitive response is actually the correct one. The counterintuitive response here being to turn around and walk the exact opposite direction of control. What this means is that you are actively finding ways to let go of control of the things that you are leading. This is, once again, especially true for managers. You may believe that by letting go of control that something is going to go awry. And actually, that might be true. But that's also true if you have control. This is one of the most important things. This is one of the most important lessons that you can learn as a manager. That is, just because another human is involved doesn't mean that there is a higher risk of failure. In fact, you may have been presenting a higher risk of failure than the second human. The fact that you are now spreading the knowledge, the fact that you are bringing other people into the technical know-how that you already have gained, is increasing the likelihood. Rather than decreasing the likelihood, that you're going to catch critical problems before they happen. By bringing people in and providing them the opportunity to develop their own responsibility to work with autonomy, you are creating a better likelihood of success. This is because everybody has different skill sets. Of course, we know this. Diversity of background. Diversity of personality. Diversity of perspective. But you also now have more than one machine running. In other words, it's a bunch of parallel brains that are all caring about the delivery of this thing. It's not just your fingerprints that can sign off anymore. And so if you find yourself wanting to gain more control over the thing that you're building or over the team that you're leading, if you're trying to get more details than you really need to be able to make decisions at your level, stop yourself and ask why. Almost invariably, the answer comes down to one simple word. Trust. Trust is your ability to let someone else fulfill a critical need for you. In this context, this is what trust means. Let me say it a slightly different way. For you to trust someone on your team, that means that, you are not personally responsible for something that you will be directly affected by. You are allowing another person to take responsibility for something that will affect you directly. What this actually looks like in practice is that the organization is going to hold you, the manager or the tech lead, accountable for this work, even though you are not the one performing the work. And this is the disconnect that most people have a hard time understanding. Can I rely on other people to perform work that I am being held accountable for? Now, I want to be very clear that just because you can rely on other people to do the work doesn't mean that in every case you should be shuffling all of your responsibilities off onto other people. That is not what a good leader does. But instead, what you're looking to do is to change your responsibilities. So instead of you focusing on, for example, writing code as a manager, perhaps a more important thing you can be doing is thinking about the career path for all of your reports. But if you don't have time to do that because you are stuck focusing on delivering a feature that your team is responsible for, there is no one else who can be responsible for thinking about their career. In other words, the thing that only you can do is being dropped. Great leaders understand that this is the shape of gaining leverage. You take responsibility for the things that are uniquely suited or uniquely kind of limited to your role. And you give more responsibility to your team. You give up control. You walk in. Exactly the opposite direction of control. You find ways to give up that control so that you can take responsibility for the things that are more important for you to be doing. Thanks so much for listening to today's episode of Developer Tea. I hope this will help you start to think about what it means to be an engineering leader. If you're not following this and I challenge you to think about how what your relationship is with control in particular, you may find it difficult to find the evolution of evolution and evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may replaced evolution may