Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / Why Your Best Engineers Could Be Your Worst Managers
Transcript
- Lucas: There's a pattern I see over and over in engineering orgs — the senior engineer who is absolutely crushing it, gets promoted to manager, and then six months later everyone is miserable. Luna: Right, the classic 'lose a great engineer and gain a bad manager' situation. Lucas: Exactly. And I want to be specific here because the numbers are stark. GitLab's 2025 DevSecOps survey found that 63% of engineering managers had received zero management training before taking on their first people-leadership role. Zero. So we're throwing people into a completely different job with a completely different skill set and just hoping they figure it out. Luna: That's a crazy stat. And it's not like managing people is an extension of writing clean code. It's a totally different muscle. Lucas: Exactly. And look — this isn't an attack on engineers. It's a structural problem. The typical career ladder in tech only has one real path upward, and that path goes through management. So you get the scenario where a senior engineer, say at a mid-size SaaS company, gets promoted because they're the best coder on the team. Suddenly they're spending 60% of their time in one-on-ones, sprint planning, stakeholder meetings. Their actual coding output drops to near zero. And the team loses the person who was unblocking the hardest technical problems. Luna: And the worst part is, the new manager often feels like a failure. They're not doing the work they loved, and they're not sure they're good at the new work either. Lucas: Yeah, that's the cruel irony. The thing that made them promotable — deep technical skill — is almost irrelevant in the new role. And the stuff that matters now — coaching, conflict resolution, organizational awareness — they've never been trained for or evaluated on. Luna: So what do you actually do about it? Because I think most CTOs know this is a problem, but the default is still to promote the best engineer. Lucas: Let me give you a concrete example. There's a company I worked with — about 200 engineers, B2B SaaS. They had a backend engineer, let's call him Mark. Mark had been there four years, knew every microservice inside out, wrote the most reliable code in the org. Naturally, when the team needed a new engineering manager, they offered it to Mark. He took it because it was the only way to grow. Within three months, his team was complaining he was micromanaging, he was frustrated he couldn't code, and the senior director was wondering why that critical service was suddenly accruing tech debt. Luna: Classic Peter Principle scenario. Lucas: Exactly. So what did they do? They actually created a parallel track. A 'staff-plus' role — same level, same comp, same prestige — but no direct reports. Mark got to stay on the codebase as a principal engineer, mentoring juniors through pairing and architecture decisions, not through performance reviews. The company kept its best coder coding, and they hired an external manager who actually wanted to manage. Luna: That sounds like a smart fix. But it requires the organization to genuinely value the individual contributor track, not just pay lip service to it. Lucas: Right. And that's the deeper issue. If the IC track maxes out at 'senior' and the only way to get to 'principal' or 'director' is to manage people, then you're incentivizing the wrong behavior. Some of the best technical leaders I know have zero direct reports. They're the ones designing the architecture, setting technical strategy, mentoring the next generation. Luna: But I do want to push back a little — isn't there some skill overlap? I mean, a good engineer needs to communicate clearly, understand requirements, collaborate. Those are people skills too. Lucas: For sure. And some engineers do make fantastic managers. But the skills are different enough that assuming one implies the other is dangerous. A great engineer can write code that a machine executes perfectly. A great manager has to understand what motivates each individual person — and that's not something you learn from a debugger. The GitLab survey also showed that teams with trained managers had 30% higher retention. Training matters. Luna: Let me ask a tough question then — can you actually train someone to have empathy? Or to be a good coach? Or are some people just not cut out for it? Lucas: I think empathy is something you can develop, but it's not a three-hour workshop. It takes deliberate practice: active listening, giving feedback that's specific and non-judgmental, asking open-ended questions. Some people have a natural head start, but I've seen engineers who were terrible at it become great managers after a year of coaching. The bigger problem is that most companies don't even give them that year. Luna: So if you're a CTO listening, what's the one thing you should do differently starting next week? Lucas: Two things. First, before you promote anyone into management, require them to go through a structured training program — even if it's just a six-week cohort with a professional coach. Second, make the staff-plus track real. Give it the same salary bands, the same decision-making authority, the same board visibility. If you only reward headcount growth, you'll get managers who don't want to manage. Luna: And if you're an engineer who just got offered a manager role and you're not sure it's for you? Lucas: Ask yourself honestly: do you enjoy helping other people succeed more than you enjoy solving technical puzzles yourself? If the answer is 'I like both equally,' that's a red flag. Management is a full-time job. If you can't imagine being excited about a day with no coding, then the staff track is probably a better fit. And there's no shame in that. Luna: Yeah, I think the stigma is finally fading. I know a few principal engineers at big tech companies who are revered, make more than many directors, and barely manage anyone. Lucas: That's the future. And honestly, it's better for the company too. You get to keep your top technical talent engaged and productive, while letting people who actually want to manage do that work. It's a win-win. Luna: If today's conversation gave you something to think about for your own team, I'll just mention what keeps this show going — listener support. A small group of folks chips in at buy me a coffee dot com slash fexingo, and that's what lets us keep every episode ad-free. Lucas: Yeah, we really appreciate that. It's a simple model and it works because of you. So back to the practical stuff — let's talk about what a good manager training program actually looks like. Luna: Yeah, give us the playbook. Lucas: Alright. I've seen a few versions work. The best one I've encountered is a twelve-week program where new or aspiring managers meet weekly in a small cohort. Each week covers one skill: giving effective feedback, running a one-on-one, delegating without micromanaging, handling underperformance. There's homework — real conversations with team members — and they debrief in the group. Luna: That sounds practical. And it forces them to practice before they're fully responsible. Lucas: Exactly. One company I know also pairs each new manager with a mentor who's a seasoned manager in a different part of the org. That way they can ask dumb questions without worrying about their reputation. Luna: So what's the biggest mistake new managers make? If you had to pick one. Lucas: Giving too much direct feedback. Ironic, right? They think they're being helpful, but they overwhelm their reports. A new manager hears 'give feedback' and they start pointing out every small thing. What they miss is that effective managers create an environment where people can figure things out themselves. You don't need to fix every typo in a pull request — you need to ask 'what do you think about this approach?' Luna: That's a really good nuance. It's about asking questions, not giving answers. Lucas: Exactly. And that's hard for engineers because we're trained to solve problems. But managing people is not a coding problem. It's a coaching problem. And coaching requires patience. Luna: I think that's a good place to leave it. If you're an engineering leader, next time you're about to promote your top coder, maybe pause and ask whether they actually want to manage people — or just want the title. Lucas: And if they want the title without the people, build the staff path. It's worth it.