Latest / The Difficult Boss Podcast with Fexingo: Managing Up, Toxic Managers, and Workplace Survival / Why Competent Managers Make Poor Leaders
Transcript
- Lucas: There is a very specific moment in almost every technical career where you realize your greatest strength has become your biggest liability. It happens when you get promoted from being the person who solves the hardest problems to the person who is supposed to make sure the team solves them. I have been tracking this phenomenon for years, looking at promotion failure rates in the tech sector, and the data is pretty brutal. Luna: Right, because the skills that got you there—deep focus, rapid execution, expert-level judgment—are exactly what you are supposed to stop doing as a manager. So why do so many people double down on the old habits instead of letting go? Lucas: It comes down to identity and comfort. When you are an individual contributor, your value is measured by your output: code written, designs shipped, deals closed. As a manager, your output is invisible until something goes wrong. That ambiguity creates anxiety, and the quickest way to soothe that anxiety is to step back into the work you know how to do. You start fixing bugs yourself because it is faster than explaining the architecture to a junior developer. Luna: But isn't there also a genuine fear that if you don't control the quality yourself, the product will suffer? It feels like a professional responsibility to ensure standards aren't slipping. Lucas: That is the rationalization that keeps competent managers stuck. Let me give you a concrete example from a mid-sized software company we analyzed last month. They had a senior backend engineer named David who was promoted to team lead. David was brilliant. He could debug a distributed system in minutes. But within six months, his team’s velocity dropped by forty percent, and turnover spiked. Luna: So the team couldn't keep up with him? Or did they just disengage because he wouldn't let them drive? Lucas: Both. David would rewrite pull requests that were already functional because he didn't like the naming conventions. He started attending every single stand-up meeting not to listen, but to interrupt with solutions. The team stopped proposing ideas because they knew David would just implement his own version anyway. He wasn't managing; he was hoarding work under the guise of quality control. Luna: That is exhausting for everyone involved. The junior devs feel like they are never good enough, and David probably thinks he is carrying the entire department on his back. Lucas: Exactly. And the irony is that David believed he was helping. He thought, 'I am protecting the team from mistakes.' But what he was actually doing was preventing them from learning. When you solve the problem for someone, you rob them of the only mechanism they have for building competence: struggle. You cannot learn to swim by watching someone else stroke through the water while you hold their ankles. Luna: So how do you break that cycle? Because once you are in the habit of jumping in to fix things, it feels risky to step back. What if the deadline is tomorrow and nobody knows what to do? Lucas: This is where most leadership advice fails because it is too abstract. It tells you to 'trust your team' or 'let go.' But trust is not a strategy; it is a feeling. You need operational tactics. The first thing we recommend is the ninety-minute rule. If a problem takes less than ninety minutes to resolve, you handle it. If it takes longer, you coach someone else to handle it. Luna: That creates a clear boundary. It forces you to ask, 'Who on my team can do this?' rather than assuming only you can. But what if nobody on the team has that skill yet? Lucas: Then you teach them. And yes, it will take longer today. It might take three times as long for Sarah to write that module than it would have taken David. But next month, Sarah will be able to write it in half the time David does. You are trading short-term efficiency for long-term capacity. Most new managers fail to make that trade because they are evaluated on quarterly deliverables, not annual team growth. Luna: It is a tough sell to upper management, especially if they see the same metrics as the manager. They see the missed deadline and blame the leader, not realizing the leader is trying to build a bench. Lucas: They absolutely do. And this brings us to the second critical shift: moving from hero to architect. A hero saves the day at the eleventh hour. An architect builds systems that prevent the day from needing saving. In David's case, he was constantly fighting fires caused by unclear requirements. Instead of writing the code to patch the gap, he needed to create a checklist for requirement gathering that his team could use before any sprint began. Luna: So the work shifts from creating the solution to creating the process that generates solutions. That sounds bureaucratic, but it actually frees up cognitive load. Lucas: It is bureaucratic in the best possible way. It removes the guesswork. When you rely on personal brilliance, you are a bottleneck. Everyone has to wait for your brain to engage. When you rely on documented processes, the work flows continuously. You are no longer the CPU of the team; you are the operating system. You enable everything else to run. Luna: I love that metaphor. But it requires a level of self-discipline that feels counterintuitive. You have to sit there and watch someone do it slightly wrong, knowing you could fix it instantly. That is painful. Lucas: It is deeply uncomfortable. And that discomfort is the signal that you are growing. If you are not frustrated by the inefficiency of others, you are probably still working too much. You have to tolerate a certain amount of messiness in exchange for scalability. Think about it: if your team depends on you to be perfect, you are limited by your own hours and energy. If they depend on each other, you are limited only by their collective potential. Luna: Which means your job description changes completely. You are no longer responsible for the code; you are responsible for the culture around the code. That is a much harder metric to track. Lucas: Precisely. And this is why technical managers often burn out. They try to apply engineering logic to human dynamics, expecting linear inputs and outputs. But human teams are complex adaptive systems. You cannot optimize them like a pipeline. You have to nurture them. You have to create an environment where failure is a learning event, not a fireable offense. Luna: If the culture punishes mistakes, nobody will take risks. And if nobody takes risks, innovation stops. So the manager's role becomes psychological safety first, technical guidance second. Lucas: Yes. And that requires vulnerability. You have to admit when you don't know the answer. David struggled with this because his entire identity was built on being the smartest person in the room. Admitting ignorance felt like losing status. But in reality, asking 'What do you think we should do here?' signals confidence. It shows you trust your team's judgment more than your own immediate reaction. Luna: It flips the power dynamic. Instead of commanding, you are consulting. That makes the team feel ownership over the outcome, which increases engagement and retention. Lucas: Ownership is the key word. People care about things they help build. When David rewrote the code, he owned the success and the failure. When he coached Sarah, Sarah owned both. And when things went wrong, David learned alongside her. That shared risk is what builds a resilient team. A team that relies on one hero collapses when that hero gets sick, quits, or goes on vacation. A team that relies on each other adapts. Luna: So the ultimate test of a manager is their absence. If you leave for a week and the project stalls, you haven't managed; you've just created a dependency. Lucas: That is the litmus test. Can the machine run without the mechanic holding the wrench? If not, you are not a leader; you are just a very expensive individual contributor with a calendar full of meetings. The goal is to make yourself obsolete in the daily grind so you can focus on the strategic direction. Luna: It sounds like a lot of work to get to a place where you barely work. But it is the only sustainable way to scale impact beyond your own two hands. Lucas: Exactly. And it starts with small steps. Pick one task you usually do yourself and assign it to someone else with clear expectations and a check-in point. Then step back. Watch what happens. You might be surprised by what they achieve, and you might be relieved by how much mental space you gain. Luna: It is scary to let go, but staying in control is a slow form of suffocation for both you and your team. Breaking the habit is worth the initial friction. Lucas: We deliberately don't run ads on these. If you want to support that choice, the link is buy me a coffee dot com slash fexingo. Luna: Yeah, and that kind of direct support lets us keep digging into these nuanced career dynamics without chasing clicks or sponsor agendas. It really helps us stay independent. Lucas: Thanks for that. Now, going back to David—he eventually made the switch. He started delegating the core module development to his senior dev, Maya. For the first month, he hovered. He checked her commits every hour. But then he forced himself to wait for the scheduled review. When the code came in, it wasn't perfect, but it was solid. And Maya was proud of it. Luna: That pride is the fuel. Once she experienced that ownership, she started taking initiative on other tasks. She didn't need David to tell her what to do next. Lucas: Correct. Within three months, the team’s velocity returned to normal, but the quality improved because multiple brains were solving problems, not just one. David finally realized that his job wasn't to be the smartest person in the room anymore. His job was to make the room smarter. Luna: And that shift from ego to service is probably the hardest lesson for any high performer to learn. But it is the only one that matters in the long run. Lucas: It is. And for anyone listening who feels stuck in that loop of fixing everything yourself, ask yourself this: what would happen if you stepped back today and trusted your team to handle just one thing?