Firing a developer is one of the harder things a founder or manager does, and doing it badly carries risks that a normal firing does not, because a developer often holds your code, your system access, and knowledge that lives nowhere else. Handled poorly, a firing can leave you locked out, in the dark about how your own product works, or with a damaged team. Handled well, it is decisive but careful: you protect the knowledge and the access before you make the change, then you make it cleanly. The goal is to end a relationship that is not working without letting the ending damage the product or the team.
Key Takeaways
- A developer holds code, access, and knowledge, so a careless firing can cost you all three.
- Protect access and capture knowledge before you make the change.
- Be decisive once the decision is right; dragging it out helps no one.
- Handle it professionally to protect team trust and morale.
Protect Access and Knowledge First
Before you fire a developer, do the preparation that a developer firing specifically requires. Know exactly what access they have, to code, servers, accounts, third-party services, so you can revoke it promptly and completely at the right moment, avoiding a situation where a just-fired person retains the keys to your product. And capture what only they know: the context, the decisions, the undocumented parts of the system, because knowledge that leaves with them can hurt more than the empty seat (what to do when a developer quits mid-project covers the knowledge-capture side in depth). This preparation is what separates a clean firing from one that leaves you locked out or lost in your own codebase.
Be Decisive, and Professional
Once the decision to fire is genuinely right, made after honest evaluation, not a rushed reaction, act on it rather than letting it drag. Keeping a developer who is not working out, out of avoidance, harms the product and the team, and a decisive, professional handling is better for everyone than a prolonged limbo (when a developer isn't working out covers making that call). Handle the firing itself professionally and respectfully, because how you treat a departing person is watched by everyone who stays, and a firing done with fairness protects team morale while a cruel or chaotic one poisons it. Decisive and humane are not in tension; both matter.
| Do | Do not |
|---|---|
| Map their access before firing | Fire, then scramble to revoke access |
| Capture their knowledge first | Let context walk out the door |
| Act decisively once decided | Drag it out from avoidance |
| Handle it professionally | Make it cruel or chaotic |
A Concrete Version
You have decided a developer has to go. The careless version: you fire them in the moment, then realize they still have access to your production systems and were the only one who understood a critical part of the code. The careful version: before the conversation, you know exactly what access they hold and are ready to revoke it, and you have captured the essential knowledge, through documentation or a handoff, so it does not leave with them. You then handle the firing decisively and professionally. Afterward, you have your access secured, the knowledge retained, and a team that saw the situation handled fairly. Same decision, but the preparation is what made it clean rather than damaging.
The Honest Counterpoint
Careful preparation should not become an excuse for indecision, and there is a failure mode where a manager prepares forever and never acts, keeping a bad situation alive. The preparation, securing access and capturing knowledge, should be prompt, not a monthslong delay while the problem festers. It is also worth being sure the firing is genuinely warranted rather than a reaction to a rough patch that better management or clearer expectations could fix, since a firing is costly and disruptive. The balance is to confirm the decision is right, prepare quickly to protect access and knowledge, and then act decisively, rather than either firing carelessly or delaying endlessly.
The Bottom Line
Firing a developer well means recognizing what makes it different from a normal firing: they hold your code, your access, and knowledge that may live nowhere else. Protect those first, map and be ready to revoke their access, and capture what only they know, so the firing does not leave you locked out or lost. Then act decisively once the decision is right, and handle it professionally to protect the trust of the team that stays. Prepared, decisive, and humane is how you end a relationship that is not working without letting the ending damage your product.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
