Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / Why We Fired Our Best Engineer
Transcript
- Lucas: You have an engineer who ships three times faster than anyone else. Their code is clean, their pull requests are rarely wrong, and they can debug a production issue in fifteen minutes flat. And you are seriously considering firing them. Luna: I have been in that exact room. It is one of the hardest conversations a CTO or engineering manager has to have. Because the numbers argue one way, and everything else argues another. Lucas: Right. And the thing is — the numbers can be misleading. When I say they ship three times faster, that is a raw output metric. It doesn't capture what happens after they ship. Do other engineers understand their code? Can anyone else maintain it? Are they creating a bus factor of one for critical systems? Luna: The bus factor — the number of people who would need to get hit by a bus before the project collapses. With a star engineer who hoards context, that number is often one. Lucas: Exactly. And that is a risk. But the bigger issue is usually cultural. I was talking to a CTO at a late-stage startup — around 150 engineers — who had a senior engineer we will call 'Alex.' Alex was brilliant. Could refactor a monolith in a weekend. But Alex refused to participate in code reviews. Would say things like 'reading other people's code slows me down.' Would reject suggestions from juniors with contempt. Luna: I have met that person. They are often beloved by the CEO because they ship features, but the engineering team around them is quietly bleeding. Junior engineers feel stupid. Senior engineers feel disrespected. Lucas: And that has a measurable cost. A 2023 study from the Stanford Center for Professional Development looked at this exact dynamic. They found that teams with one high-conflict, high-performing individual contributor experienced 27 percent higher voluntary turnover than teams without that person. So the question becomes: is Alex's output worth losing three good engineers who would otherwise stay for years? Luna: In most cases, the math does not work. But let me tell you a story from my own experience. At a fintech company I worked with, there was a star engineer — let us call him 'Raj.' Raj was a beast. He wrote the core payment processing system. But he never documented anything. He would only explain his design decisions in late-night Slack messages to a select few. Lucas: So the bus factor was one, and the knowledge was essentially encrypted in Raj's head. Luna: Exactly. The CTO eventually made the call to let Raj go. It was tense. Raj was shocked. But within two quarters, the team's velocity improved by 15 percent. Why? Because the remaining engineers were no longer afraid to touch Raj's code. They could refactor it, add tests, and actually understand the system. Lucas: That is the hidden cost. A star engineer can inadvertently freeze the team's learning. Everyone defers to them. No one challenges their architecture. The team's collective skill atrophies. And when the star leaves — whether voluntarily or not — you have a crisis. Lucas: So how do you make the decision? I think there are three metrics beyond raw output that every CTO should track. The first is the bus factor for each critical service. If only one person understands it, that is a red flag. Luna: The second metric I would call the feedback ratio. How many code review comments does this engineer give versus receive? A healthy ratio is roughly balanced. A star engineer who gives zero feedback but receives many is a net negative for the team's growth. Lucas: And the third is mentorship throughput. How many junior engineers have been promoted or have grown under this person's guidance? If the answer is zero, then they are not a multiplier. They are just an individual contributor, no matter how fast they ship. Luna: And those are hard conversations to have, because the engineer might say, 'But I am not a manager. Why should I mentor?' And the answer is that in a healthy engineering organization, every senior IC is expected to raise the bar for the whole team. It is part of the definition of senior. Lucas: Right. And if they push back, you have a culture problem. But let us assume you have made the decision to let them go. How do you handle the exit so the team is not demoralized and the knowledge is not lost? Luna: This is where many companies fail. They fire the star engineer and then act surprised when the remaining team feels insecure or angry. You need a clear narrative that is honest without being vindictive. Lucas: I think you say something like: 'We are building a team where everyone can grow and contribute. We have decided that this role requires collaboration and knowledge sharing, and we have parted ways because of a mismatch on that expectation.' Simple, factual, not personal. Luna: And you need to back it up with action. In the Raj case, the CTO scheduled a week-long knowledge transfer session where Raj documented everything — whether he wanted to or not. It was part of the severance agreement. Lucas: That is smart. Make the documentation a condition of the exit. Offer a generous severance in exchange for thorough handoffs. Some companies even hire the person as a contractor for two weeks specifically to document and pair with successors. Lucas: But there is also a preventative side. How do you avoid getting into this situation in the first place? Luna: Hire for culture add, not just technical brilliance. And during the interview process, include a peer coding session where the candidate has to review someone else's code. Watch how they handle it. Are they constructive? Do they explain their reasoning? Lucas: And set clear expectations from day one. At the onboarding, say: 'We expect every engineer to participate in code reviews, write documentation, and mentor juniors. These are not optional.' If someone pushes back early, you can address it before it becomes entrenched. Luna: I have also seen companies use a 'no asshole rule' — the term comes from Robert Sutton's book. It means that no matter how talented, if someone consistently demeans others, they are out. And the rule has to apply to everyone, including the CEO's favorite. Lucas: And it works. I have seen companies that enforce that rule religiously have lower turnover and higher overall performance. Because the team trusts that the culture is protected. Lucas: So let me sum up. Firing a star engineer is painful, but sometimes necessary. The metrics you should watch are bus factor, feedback ratio, and mentorship throughput. If all three are red, the output is not worth the cost. Luna: And the way you handle the exit matters. Be transparent with the team, secure the knowledge transfer, and reaffirm your commitment to a collaborative culture. Lucas: One last thought. A listener once told me that after they fired a star engineer, the team's morale improved dramatically. One junior engineer said it was the first time they felt safe to ask questions. So the question every CTO should ask themselves: is your best engineer making everyone else better, or just making themselves look good? Luna: That is the real litmus test. And if the answer is the latter, you probably have a hard decision to make.