The Hard Conversation: When to Let Someone Go

You let an engineer go when their judgment is not improving and their presence is actively degrading the judgment of others. Not when they write slow code. Not when they miss a sprint. Not when a feature ships with bugs. Those are correctable.

What is not correctable is an engineer who ships machine-generated code they cannot explain, who creates production surfaces that no one can reason about, and who trains the Apprentices around them to do the same. In the old world, that engineer was slower. In this world, they are a liability.

The engineer who makes your team smarter—who raises the quality of judgment around them even if they write less code than anyone else—is the person you build around. The Multiplier you cannot easily measure is often the one holding everything together.

If you are not sure which kind you have, check what happens the week after they go on vacation.

Your termination criteria become a mirror of your hiring criteria. You hire for judgment. You fire for its absence. Velocity problems get coaching. Judgment problems that infect others get separation.