Back to resources

Firing Somebody for the First Time

Leadership
Firing
Team Reaction

23 November, 2021

William Bajzek
William Bajzek

Director of Engineering at Sapphire Digital

William Bajzek, Director of Engineering at Sapphire Digital, remembers the first time that he needed to make the ultimate sacrifice on behalf of the well-being of his team.

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

Honesty in Leadership

5 February

As a Leader, can you show your weaknesses to your team? Your vulnerability to your team? Not only can you, you must.

Leadership
Kamal Raj Guptha R

Kamal Raj Guptha R

Engineering Manager at Jeavio

"You don't care about quality" A story of single metric bias

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.

Product Team
Productivity
Team Reaction
Alex Shaw

Alex Shaw

Chief Technology and Product Officer at Hive Learning

People Oriented vs Task Oriented

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?

Leadership
Kamal Raj Guptha R

Kamal Raj Guptha R

Engineering Manager at Jeavio

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero