The Dismissal of a “Fireman Developer”

Problem

"Two years ago we had to lay off someone I would call a 'fireman developer'. He had several very appreciable qualities: he got on well with the team, he had a lot of experience, he was willing to help, and often was the first to be there when the production was on fire. But he also had some indisputable flaws: he was reactive rather than proactive, he was too much of a perfectionist, leading him to not deliver on time, and his projects did not move forward. He was also not able to organize himself to take ownership of the projects he was recruited for. Overall, he was doing a good job, but not his own. As long as we were a small team, it did not create any problems. But, as the team of engineers grew, we had to give responsibilities to everyone and we realized that his profile didn't correspond to our needs. We decided not to adapt the organization to him, but rather let him go."

Actions taken

"Most of the team did not see it coming, and it created a gap between managers and engineers. He was one of the first employees to be fired, and his departure created a noteworthy drop in our happiness indicator. A group of developers received the news particularly badly, isolated themselves from other developers and in the end, they all left the company."

Lessons learned

"Personally, I dedicated a big part of my energy and time to explaining our decision in a human way to the team, but it didn't hinder the creation of this group of troublemakers. Is there a good solution for this problem? I don't know. But clearly there were two options:

• Keep the underperforming employee, and assume that his role was as a team binder.
• Fire him, but accept the price to pay. Have a toxic working atmosphere for a while, and ultimately maybe several resignations."