When a Team Member Underperforms: Train or Let Go?

I previously answered a Zhihu question titled “What does the worst programmer look like?” and received many comments.

Over the next two years I devoted extensive effort to training one subordinate, only to realize later that my biggest mistake was training for too long.

My management philosophy has always been “If you can train, try to train.” A stable, high‑output team needs to develop existing members, not just keep hiring.

During those two years I performed thorough code reviews, not only pointing out problems but also explaining why the code was poor, what the correct approach should be, and even providing demo snippets. I walked him through many requirements, discussing boundary conditions, exception scenarios, and non‑functional concerns such as performance, security, and maintainability.

I believed that as long as I kept teaching and gave a little more time, people would grow, so I kept telling myself, “Give him a little more time.” That “little more time” stretched to more than two years, after which I had to admit that not everyone can be cultivated.

As of 2026‑07‑12 I am still handling issues left by his code. He rarely considers edge cases, exception handling, performance, or security, and whenever a feature becomes moderately complex he leaves bugs.

Someone might ask, “But you kept doing code reviews, didn’t you?” Yes, but I also write code, lead the team, and own core business and technical features, so I cannot spend all my time reviewing a single person’s work.

If I do not review his code carefully, the defects will surface either immediately after release or months later; today I am fixing one such problem.

A long‑term employee who cannot work independently costs not just his own time but the entire team’s.

His code requires others to review.

After release, others must take over the work.

When production issues arise, others have to rescue.

Thus, one person appears to be working alone while actually consuming another’s time, often the manager or a core team member, slowing overall team efficiency.

I have since adjusted my management approach. I still believe in nurturing talent, but I no longer train indefinitely. I will invest time, provide hands‑on guidance, conduct serious code reviews, and give growth opportunities, yet if sustained effort and feedback show no improvement, I will cut losses.

The manager’s greatest responsibility is not to prove the ability to train everyone, but to ensure the team continuously creates value.

So, when asked whether to keep training an underperforming subordinate or replace them, my answer is: first try to train, but set a clear deadline for the training.