The Dismissal of a “Fireman Developer”
6 December, 2017
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.
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.
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.
Sameer Kalburgi, VP of Engineering at Fieldwire, discusses how his team evolved from hiring junior engineers to building a team of -- and balancing -- mixed seniorities.
VP of Engineering at Fieldwire
Raghavendra Iyer, Head of Engineering at ReachStack, tells of his efforts to preserve the startup mentality of his team following the acquisition by a large company.
Head of Engineering at ReachStack
Matt Pillar, VP of Engineering at OneSignal, recalls how he helped merge two engineering teams at two different locations and how legal and cultural context made all the difference.
VP Engineering at OneSignal
Jackson Dowell, Engineering Manager at Asana, explains how he moved his project forward by coming up with a clear model of the system and problem that provided guidance to the team and helped communicate their efforts outward.
Engineering Manager at Asana
Toby Delamore, Product Manager at Xero, explains how skip-level conversations and maintaining an attentive relationship with engineers enabled him to keep a finger on the pulse of the team.
Product Manager at Xero
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.