Firing Somebody for the First Time
23 November, 2021

Director of Engineering at Sapphire Digital
Problem
The first time that I ever had to fire somebody was really tough. They were hired years earlier by a different team for a role that turned out to be not what the team actually needed, and eventually transferred to my team when theirs was dissolved. Although they’d spent time trying to develop the necessary skills, they never got to the level the team needed in order to deliver.
It was a difficult and unfair situation all around; this person was trying hard to grow into what the team needed but was so far out of his comfort zone that it wasn’t really possible to make that progress. They were given lots of opportunities for mentoring and training, but ultimately that cost the team a lot of time and effort that was not paying off.
Actions taken
When this problem became recurring and apparent, we initiated a performance improvement plan. It was a ninety-day shape-up-or-ship-out kind of thing. The employee seemed to improve for a while, enough that we let up the pressure, but gradually the old behavior returned. Since our HR had largely turned over during this time, they lost track of the performance improvement plan and we were back to square one.
During this time, I was promoted to director and eventually, the new leader of my former team came to me, asking for advice about this employee. It turned out that the team was spending so much time attempting to coach this person through their work that often they would decide it was easier to just do it themselves. It was overburdening the team and it needed to stop.
The first thing we did was reach out again to my leadership and HR to bring them up to date on the situation. I told HR we needed to solve this problem and that I wanted them to lay out guidelines for us so we could be sure we were doing everything by the book. We put this person on a new performance plan that was very similar to the previous one and documented every relevant interaction we had for months. I prepared a visualization of this person’s contribution to the team that compared to others, demonstrating that their contributions were maybe one-quarter of the next person up. That actually backfired on me, because instead of working to improve their skills, they instead tried to do things that made that visualization, in particular, look better.
The HR process was slow, and the problem became more urgent as I was being pressured to hire for the team but did not yet have the budget to do so. We really just needed to make it happen. I gathered all of my documentation and was finally able to convince HR that we had a solid case to let them go. The bureaucracy was frustrating but I recognize that ultimately it was there to protect the company and myself.
HR was concerned about how the team was going to react, but, more than anything, they seemed to be relieved. Now, they would finally have the time that they needed to focus on the work that they were actually getting paid to do.
I was offered the opportunity to let my boss or HR deliver the news to the employee, but ultimately I knew that I would not have been able to live with myself if I didn’t do it myself. HR prepared some talking points for me, which I rewrote in my own words, and then I fired myself in front of a mirror many times until I felt that I was ready. I laid out the discrepancy between their performance and our expectations, the opportunities given, and the lack of progress shown. I have not had to fire anybody since, thankfully. I hope that I never have to do it ever again.
Lessons learned
- Having a sense of trust with my managers gave me the space to go to them for guidance when I felt like I had met a roadblock. I felt safe discussing things like this with them, knowing that no rash decisions would be made as a result. Interfacing with HR directly would have been riskier. They tend to be more reactionary, and not always in a way that’s helpful.
- Documentation is good for more than just firing somebody. You need the documentation when promoting, for example. Anywhere that a manager needs a fair and impartial account of how their people are doing is a point in time where you should be documenting all of the relevant facts. I love tools like Jellyfish that show us all of these different objective metrics, like how long it takes an engineer to accomplish a task. I can look at all of the things that a person is really involved with. Sometimes, this objective perspective on the work will show me problems that I didn’t even know that I had.
- Having conversations with people directly and early when you notice them struggling is one of your main responsibilities as a manager. What are you having trouble with? What can I do to make things easier for you? Those are difficult conversations to have at times, especially if you’re someone who grew into management without having sought it. I want to give people feedback and I want to make sure that they leave every meeting feeling good about their standing on the team.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
5 February
As a Leader, can you show your weaknesses to your team? Your vulnerability to your team? Not only can you, you must.

Kamal Raj Guptha R
Engineering Manager at Jeavio
3 February
This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.

Alex Shaw
Chief Technology and Product Officer at Hive Learning
20 January
As a Lead or Manager, one could naturally incline more towards being either people oriented or task oriented. Which is better? Do you know which side you lean more towards?

Kamal Raj Guptha R
Engineering Manager at Jeavio
10 December
Supporting principles on why being data led (not driven) helps with the story telling.
Vikash Chhaganlal
Head of Engineering at Xero
29 November
Why DevSecOps matter and what's really in it for you, the team and the organisation?
Vikash Chhaganlal
Head of Engineering at Xero