Firing a software developer is one of the most challenging decisions an engineering manager has to make. In fact, I truly believe it’s the most difficult boss ceremony.
I try to convince myself that firing is easy because I’ve done it a few times. The truth is, it isn’t. Firing is hard because there’s a human being on the receiving end of this dismissal. You’re cutting ties with a person with whom you’ve developed a bond over the years, and that will inevitably stir up all sorts of emotions.
Only psychopaths would truly enjoy telling someone that their services are no longer required, that they will have to stick it out until something else comes along. During inflation times people are stressed even more. Now imagine letting them go when they might be paying double for groceries or mortgage payments.
Naturally, the person getting fired will feel hurt, undervalued, and deceived. They will probably express this during the conversation. So, what’s your plan of action?
The most important thing is to terminate a developer in a way that has your and your developer’s best interests at heart. I know, that might be difficult to do, but hear me out. Before we take a deep dive into firing an engineer, let’s outline the reasons to fire a software developer.
What Are the Main Reasons for Firing a Software Developer?
There are many reasons why you’d have to fire a software developer. Such reasons include:
- Poor performance: Consistently failing to meet project deadlines, producing low-quality code, or not achieving expected results.
- Violation of company policies: Engaging in unethical behavior, such as breaching confidentiality agreements, misusing company resources, or violating software development best practices.
- Insubordination: Refusing to follow instructions, disregarding authority, or displaying a persistent lack of cooperation with team members or management.
- Code plagiarism or intellectual property theft: Stealing or plagiarizing code, intellectual property, or trade secrets from the company or fellow developers.
- Misconduct or unethical behavior: Engaging in dishonesty, harassment, discrimination, or any other behavior that violates company policies or creates a hostile work environment.
- Gross negligence: Repeatedly making critical mistakes, causing significant financial loss, or compromising the security and integrity of software systems due to negligence.
- Lack of accountability: Consistently failing to take responsibility for one's actions, not admitting mistakes, or avoiding ownership of problems.
- Continuous conflicts with team members: Engaging in frequent conflicts, exhibiting disruptive behavior, or consistently creating a negative work environment.
- Incompatibility with the company culture: If a software developer is unable to adapt to the company's values, work style, or collaborative environment.
- Breach of employment agreement: Violating contractual obligations, such as working for a competitor while still employed or disclosing sensitive information.
If you have to fire someone based on any of the above issues, you can’t hesitate. You have to do it now. And trust me, if you don’t fire the person that needs to be fired, you may have bigger problems on your hands.
Kim Scott in her book, Radical Candor, tells an anecdote of the negative consequences of not taking action when an employee's behavior is harmful to the company. Long story short, if you don’t do it, people will see that you’re weak and they won’t respect you. The result could be your best developers leaving all at once.
How to Communicate Firing Your Software Developer
The Engineering Manager’s Human Side, Intentions, and the Purpose of the Meeting
It’s especially difficult for engineering managers to start the conversation about firing a software engineer. It’s also difficult to admit the feelings, fears, and difficulties that are associated with this difficult step. When you’re sitting down facing your developer, your conscience may be telling you:
“Don’t show any weakness because it will be used against you.”
“Don't expose yourself too much, or you'll get hurt.”
“Don't get tired of the long introductions.”
“Get it over with as soon as possible!”
If you listen to these voices, the developer you’re firing will pick up on the signals and will react or project his or her emotions negatively. He or she will think you’re:
So, if you want to build a favorable atmosphere during the firing process and “break up” in a healthy way, you have to take the risk and say how you feel at that moment followed by naming the real purpose of the meeting.
For example, you could say:
“Sarah, this is a very difficult conversation for me, and I've been preparing for it for a long time. I’m actually quite nervous about this meeting because I have a very difficult decision to share with you.”
This disclosure of feelings must, of course, be truthful and tailored to your personality. If you’re businesslike and serious, then it won’t look genuine if during the act of firing you’re overly apologetic or empathetic or way too emotional. On the other hand, an engineering manager that has been more personal and friendly with the developer can say more about his or her feelings, and that can be seen as credible.
The worst thing that can happen is for you to immediately (and ruthlessly) assume the role of an angry parent:
“Do you know why we’re here?! Well, I warned you, and now I have no choice but to fire you!? You’re done, out of here. Adios!”
The Decision to Dismiss With a Brief Justification
For many years, I’ve been thinking about the best way to share the motive behind this very difficult decision.
In my opinion, when starting the conversation with the following openers, the engineering manager actually appears to be afraid of taking responsibility for his or her decision:
“We have to part…”
“We are ending our cooperation…”
“You have to go…”
The best way, in my opinion, is to say:
“I've made the decision to fire you because…”
Keep it short and to the point. Many engineering managers sometimes say too much when justifying their decision to fire a developer. During this moment, it’s easy to start evaluating the developer and give him or her good advice. This is the worst thing you can do. Keep in mind that this decision is final and there is no time to help your dismissed developer improve on those faults that forced you to let him or her go in the first place. Giving good advice and assessments during the act of firing will hurt the dismissed developer and violate his or her dignity. You might as well be telling them to fight your decision.
To defend their name, many people are ready to do just about anything; they may start acting irrationally. So, in this difficult moment, never talk to the dismissed developer like this:
“You have to admit that you weren’t a good coder. Others are way better than you.”
“You should have done more code reviews or did your best to improve because now it's too late.”
“Oh, don’t worry. You'll be fine. I’m sure. You'll thank me someday.”
The rationale for the dismissal should be brief and relate to the engineering manager’s true interests. He or she should say:
“I have made the decision to fire you because, for the third time, you failed to complete the tasks set before you. This affects me and the department and will look like I have failed to implement our strategy. I don't want to take that risk. I’m sure you understand.”
“I have made the decision to fire you because I have been instructed to reduce employment in our department. I have no objections to the quality of your work, but I’m faced with a difficult choice. I have decided to fire those people whose absence, in my opinion, will jeopardize the ability to perform the new tasks for which I am responsible.”
Protecting Your Interests and Defending Your Decisions
Your developer, on hearing that he or she has been fired, will likely be furious, resentful, and will experience shock. In many cases, they will defend themselves and exert pressure to make you feel guilty about your decision. They will say something like:
“Why me and not…?”
“What have I done to deserve this treatment after years of sacrifice for the company?”
“I wonder how you'll prove to me that I'm unfit for the job?”
“Maybe the boss will give me another chance because I have a tragic family situation?”
Your most important task is not to get involved in a discussion about the rightness of the decision. After all, you did not take the decision lightly and no argument from your developer will change it. You also have no chance to convince the developer that it was the right decision. He or she is defending his or her image, so don't expect to hear, “Yes boss, you're right. You convinced me. You had no other choice. This lesson will definitely do me good.”
A developer who is fired will defend his or her self-esteem and often deny obvious facts. That’s a known psychological mechanism that is worth taking into account during this difficult conversation. Each of us reworks reality to our advantage and has wishful thinking when our self-esteem is threatened. Nobody wants to think of themselves as a pig, a lazy person, a cheater, a thief, or a completely irresponsible person.
Your task when firing is not to convince the developer to do anything. All you have to do is make him or her aware as soon as possible and maintain that your decision is final and that you won’t change it. Any discussions on the matter will only trigger negative emotions. It is best to provide the termination in writing by a third party. HR is often useful for this. Also, be sure you're familiar with the legalities of the firing. Know the company policies and procedures. That also means ensuring that the departing software developer's access to sensitive information, intellectual property, systems, and databases is revoked.
I know many engineering managers are often caught up in the firing, but they have to also protect the organization's assets by safeguarding confidential information and preventing any unauthorized use or dissemination of data. This is really important!
Negotiating the Dismissal
Some engineering managers want to end this difficult meeting for both sides as soon as possible. They feel guilty and helpless in this situation because they do not know what can and what should be done next with the developer after informing him or her of the decision.
However, there's only one reason why it's worth bothering to keep the conversation going — to protect your interests.
Usually, we have important needs that we want to protect when dismissing a developer, but we are afraid to talk about them. And yet most of us engineering managers are concerned mostly with not being labeled a heartless psychopath. The truth is, we should coordinate the firing so that it’s an amicable parting, so things don’t get out of hand.
We don’t want the dismissed developer to turn a firing into an ugly situation or drag us to labor courts. We want them to leave their workplace in order, settle all accounts, and not poison other teammates on their way out. So, if you want to avoid any of this, then you have to recognize the needs of the person being made redundant and make sure they are met.
For negotiations to be considered a success from the business’s point of view, you must convince the developer that you are not doing them a favor. You must show the developer that you are offering them an exchange in which you want to protect your vital interests. That is why it’s worth following our negotiation logic. Here it is:
Start by disclosing your own intentions and interests, and only then try to understand his or her concerns and needs. And, of course, be sure to paraphrase the interests of the developer who is usually afraid of the consequences of dismissal.
This part of the conversation may look like this:
“Now, I'd like to talk to you about the best way we can part. It’s important to me that you efficiently hand over your duties and documents and settle all accounts with the company as soon as possible. I would like to avoid any turbulence or tension. Is there something important for you to protect during this dismissal? Is there anything you are particularly afraid of in connection with your departure from the company?”
Many engineering managers are afraid of these questions because they think the developer will suddenly, out of anger, make unrealistic demands. They fear that the developer will demand a six-month severance pay or a new well-paid job or an extension of the notice period.
In my years as an engineering manager, I realized one very important thing: If the dignity of the dismissed developer is not violated, then he or she will behave rationally and request things that can be fulfilled.
It often happens that a surprised developer is not able to name his or her severance right away. That’s okay, don't pressure them to answer. Give him or her time to think, but be sure to come back to the conversation. Just make sure to close the formal side of the dismissal procedure. The dismissed developer needs to walk away knowing that they are finished at the company.
Haggle, For You and Your Dismissed Developer
Have you ever been to Thailand? 🌴 There, you have to haggle for everything. Why? Because haggling is actually normal practice. In fact, any form of communication between two people is basically a negotiation. And with negotiating, you don’t want to agree or give in so easily. Same goes for negotiating a dismissal - don’t give up too much too easily. If you do, you run the risk of escalating demands from the developer. They may lack appreciation of the effort you’re making to make him or her happy.
Here are the three basic rules of haggling during a dismissal:
- Emphasize your effort in the dismissal and the costs you will have to bear.
- Respect your developers and appreciate their needs.
- Always demand that your needs be satisfied.
If you ask: “What is important to you now?” and the dismissed developer says: “I would love to finish the course on Ruby on Rails that I recently started.” Then do not answer back quickly: “Go ahead, I see no problem. Is there anything else I can do for you?”
If you’re quick to answer and agree, the dismissed developer will certainly not appreciate your gesture because he or she will be convinced that your consent costs you nothing. We encourage you, at the end of this difficult conversation, to enter haggling mode.
To respond to his or her demand of finishing the course, you could say:
“It will be very difficult because you are no longer an employee at our company. It will not be easy for me to convince the accountant of such a solution. But, especially for you, also as an expression of appreciation for our several years of cooperation, I will try to arrange the completion of this course for you. However, I’ll try to do this on the condition that by next Monday you hand over your duties to your teammate. I also expect you to do it respectfully. Do you agree to that?”
Of course, during the haggling phase, agree only to those demands that are feasible for you. You must be sure that it’s a fair exchange. You should be assured that you will get something worth it for the effort and risk you take. In any other situation, say ‘no’ and ask for other ideas.
Gathering Teammates to Address the Termination
After firing the developer, the next thing to do is to gather the remaining developers from the team, those who could be affected by the changes. Address the dismissal. Be as direct in discussing the issue as you were when firing the developer. Mentioning the reasons for the termination is not recommended as this lacks professionalism. You may look like you’re talking bad about the dismissed developer, and the others won’t appreciate that.
However, if you think that the other developers will feel their positions could be at stake, you might give them a reason. In the event that you don’t give a reason, the remaining teammates will surely have their theories, but let them be theories and nothing more. You could address the issue using the following script:
“As some of you may already know, John is no longer part of the organization. I can’t go into details as to why he’s not with us because of confidentiality. If you have suggestions about how best to move forward on the project and how to minimize the impact of John’s absence, please let me know.”
Terminating a developer is a tough task. The project will slow down and have its setbacks for a short while, but staying positive is the only way to move forward. By sharing this positivity with the team, you could be stopping morale from sinking even further.
This moment separates a good engineering manager from a great one, as you’ll have to strategize and find ways to keep your remaining developers happy while looking for a replacement.
Sample Conversation: Communicating a Dismissal
Here’s a complete conversation in which an engineering manager, Amy, utilizes the algorithm for the effective termination of John, a developer:
ENGINEERING MANAGER (EM): Hey John, look, this is a very difficult conversation for me. It makes me really upset to have it, and I've been preparing for it for a long time. I've made the decision to fire you.
I want you to know that I consider you a great developer and that made this decision even harder for me. When I made the decision, I decided to be guided by a clear and important criterion. I decided to fire those people who will, in my opinion, pose a threat to the implementation of the new project, for which I am held accountable.
NOTE: The engineering manager names the purpose of the meeting and reveals her intentions with a human face. She communicates the decision to fire without delay and gives reasons at the level of her interests.
DEVELOPER (DEV): Amy, I'm surprised that I'm the one to be let go. After all, I've been working at the company for several years now, and you've never had any major problems with me. You said many times that you appreciate my contribution. Then why me?
EM: Listen, I really appreciate your commitment and I really enjoyed working with you over the years. Once again, I want to tell you that the assessment of the quality of your work is not a criterion for my decision, not even in the slightest. When making my choice, I considered the necessity of various people to perform the tasks facing me and the department. Based on this criterion, I have decided to fire you. This decision is final and I will not change it.
NOTE: The engineering manager has repeated herself to protect her decision and to protect herself against the escalation of conflict.
DEV: I get the impression that you’re concerned that there will not be enough work for me. But you know me. You know that I learn quickly and can do something else. Please, don’t do this. How about you just find me a suitable job with another team?
EM: I understand that you'd rather stay and learn something new. But I will not change my decision.
DEV: Look, you yourself admitted that I’m a good worker. Many times you were able to count on me and the company. And now you just say ‘Goodbye’? That’s all I am to you?!
EM: I hear that you’re bitter and I understand your disappointment. I really do. But I won't change my decision. I really want you not to think of me as a heartless person. I don't want you to think that I don't appreciate what you've done for the company. It’s also important to me that your departure takes place at the least possible cost to you and me. Therefore, please tell me, what would you most like to protect during this dismissal?
NOTE: The engineering manager moves from ‘decisions’ to ‘negotiations.’
DEV: I'm too shocked to think of anything right now.
EM: Do you need some time to think?
DEV: Yes, of course. My mind is blank.
EM: I understand. It will also be easier for me to talk about the conditions of parting when I’m not nervous as well. That’s why I propose that we close the formal side of this matter now. We'll come back to the conversation later. Please sign these documents.
NOTE: The engineering manager took care of the formalities of the dismissal procedure. This way, she protects herself against mishaps in the labor courts, or the developer going on sick leave, which is in many cases convenient for the developer at that moment.
DEV: What if I don't sign it now?
EM: It will not be easy for me and I would like to avoid this problem, but then I will hand you this notice in front of witnesses to complete the formality. But tell me, why would you be afraid to sign this document?
DEV: Well, you know, I'm afraid that if I sign this now, I will be in a lost position.
EM: John, I assure you once again that I want to make the best of our parting. It’s not in my interest to manipulate or deceive you. That's why I'm asking you to tell me what you'd like to protect at our next meeting. I also have important business in connection with your departure, and maybe we can work it out.”
The next day, if the engineering manager negotiates at the level of her interests and seeks a fair exchange, the conversation might go like this:
DEV: Amy, I've thought about it. It's still not easy for me. But since your decision is irrevocable, I have a few things that are important to me. Firstly, I’d like a generous severance package. Secondly, I'd like to get a very good opinion in case my future employer calls you.
EM: Could I maybe ask why these are important to you?
NOTE: The engineering manager prompts the developer to name the needs that are behind the requests.
DEV: You probably understand that if you do this I’ll have a better chance of finding a job.
EM: Ok, now I get it. You want to feel appreciated for your contribution to our company. Will my help in increasing your chances of finding a good job and recognizing your achievements the most important things you care about in connection with leaving?
DEV: Yes, that's the most important thing for me. I don't think I'm asking for too much, am I? I guess you agree with me?
EM: A good opinion, of course - I’ll give one. But congratulating you and recommending you to other employers is a completely different thing. Here I risk a possible strain on my credibility. But you know what? I’m ready to do it just for you because I respect you and consider you a good developer. I will do it on the condition that you close all matters with the company and the team in an exemplary manner. It will prove to me that you are as loyal and worthy as they come. Agreed?
NOTE: The engineering manager bargains and protects her own interests and fights for the developer’s satisfaction.
EM: But as for the additional severance pay for you, I say - no. I do not agree with this because the board warned me that I have no chance of giving any extra money. The reason is the difficult financial situation we’re in. I understand that you’re fighting for it because you want some form of appreciation for your work. I care about this too, so tell me, John, do you see other ways of appreciation that would not involve extra cash? Because I certainly won't get it for you.
NOTE: Clear refusal of extra pay and a re-invitation to negotiate in the area of other interests.
DEV: Thanks for making it clear, so I won't argue further. I can think of another interesting solution that does not involve too much money. For example, I’d like help in finding a new job.
EM: And how do you want me to help you with that?
NOTE: The engineering manager tries to clarify the developer's statement. She does not want to condemn herself for trying to imagine what the developer means. In this way, she protects herself from giving too much or giving not what the developer wants.
DEV: Well, for example, you can help me by subsidizing a training course...
[END]...or to be continued?
Finally, remember to end the toughest talks about firing on a real positive note. For example, you might say, “I appreciate you talking to me so honestly and openly. Thank you for giving me a chance to come to a meaningful understanding in this difficult situation.”
All conversations and meetings should end with appreciating the positives.
When you have to terminate the employment of a software developer, it's important to approach the situation with professionalism, empathy, and transparency. Effective communication, documentation to back up your decision, and adherence to company policies and legal requirements is essential.
Remember that treating the dismissed developer respectfully not only preserves their dignity but also upholds the reputation of the company. By handling this difficult boss ceremony effectively, you can be sure to minimize the impact on the other developers while maintaining a positive and professional environment for everyone involved 🍟