5 ms·

> Firing is dangerous, it can demoralize the team extremely quickly. Conversely, keeping clueless people around is demoralizing and insulting to the people act

> Firing is dangerous, it can demoralize the team extremely quickly. Conversely, keeping clueless people around is demoralizing and insulting to the people actually doing the work. I don't mean junior folks who get it but are building experience. A company I worked for hired a junior against the advice of the team (red flag anyone?). We spent 6-8 months with this individual spinning their wheels. They just did not get it. It created more work for the rest of the team to help them, redo the work correctly, etc. Did they fire him? Nope...they transferred him to another group within the company. And of course he's not doing well in that group either. Why should people work their butts off if it seemingly makes no difference? I've since left that company - this wasn't the primary driver, there were lots of other supporting reasons, but ultimately it came down to my loss of faith in management's ability to steer us in the right direction.

ddek 5y ago
The obviously clueless are rarely controversial fires. The problem is when leadership have a different opinion of the employee than workers. I'm on my notice right now. I started hunting a new job after the company fired their recently hired well-liked VP Product. Most of the organisation believed this guy had made a substantial positive impact, and the firing reasons were concocted. They weren't entirely unjustified (he was too expensive, and focus wasn't aligned), but I still disagreed. I've heard both sides independently, and nowhere near enough effort was made to find a better way. When people see good people fired for weak reasons, they become concerned for their own role. As a senior engineer, this is particularly worrisome. A huge part of my job is to disagree with people. Junior engineers want to reinvent wheels, project managers want to impose pointless deadlines, the (barely) technical co-founder just read an article about grpc; I have tools to constructively push back in all these cases. If I see people getting fired like this, then my career becomes a factor in my decision making. Ultimately, this firing has cost a small engineering team both it's senior engineers. I'm gone, so is the other senior (for the same reason). The CTO is management focused. There are a few other reasons I won't go into, but this team is in a very difficult position.
- layoric 5y ago
  “Weak reasons” obviously heavily dependent on priorities at the time, which can change quickly. On small companies it has a massive impact on others and that shouldn’t be taken lightly. I had a previous boss that hired someone senior to do X but their expectations of the role quickly changed and they were fired for not performing well enough. They jumped from a good job stable job and took a risk, asking all the right questions about the role but CEO/CTO never lived up to their side of what the role ended up being. This same CEO also admitted to me part of their management style was “push people to breaking point, and back off a little” to get the most out of people. I left soon after. I don’t know how to avoid working with this kind of leadership personality in the interview process but has definitely made me more cautious.
- yobbo 5y ago
  > A huge part of my job is to disagree with people. Junior engineers want to reinvent wheels, project managers want to impose pointless deadlines, the (barely) technical co-founder just read an article about grpc; I have tools to constructively push back in all these cases. This paragraph should be a great frame for so many problems. Engineers are people whose identities are wrapped in the perception of their intelligence. But value is created when we disagree and "the right" person wins.
weeblewobble 5y ago
> Conversely, keeping clueless people around is demoralizing and insulting to the people actually doing the work. I think this is only true in the most egregious of cases. A somewhat counter-intuitive thing I've learned is that highly productive programmers like working with less productive programmers. They've spent a lot of time with this person, maybe got to like them on a personal level. But beyond that, they don't have to butt heads all the time, it's one more person to stamp your diff without excessive nitpicking, someone to bounce ideas off of, someone to handle the more mundane coding work, someone to share blame with. Almost like an assistant programmer. A backfill will have to trained and knowledge-transferred again from zero. This isn't to say the organization is best served by keeping low-performers around at full salary to keep their high performers happy. That depends on higher level organizational goals. My point is to support GP's quoted statement in your post, that firing is dangerous and can demoralize teams.
aidenn0 5y ago
Any non net-negative developer being fired risks demoralizing the team. If they are net 0.1% as productive as a typical developer, but not preventing anybody else from getting their work done, they are a cost to the company, but not to the remainder of the team.
- GiorgioG 5y ago
  Agreed. This individual was a net negative. They could not get their work done, and thus required other engineers to pick up their "slack". Everyone pitched in to help mentor the individual, without much success. Compared to other similarly skilled/experienced developers we'd hired around the same time - who became productive in a few months, this person made zero progress. Not firing this person was demoralizing to the team. Moving them off the team to another group seemed to upset people even more than keeping this person around (I'd moved on by this time, but kept in touch with the team). Rather than doing the right thing for the organization (firing them) - management decided to make it someone else's problem in the organization. Yes from management's perspective they 'solved' the team's problem but the optics of what they did created resentment towards management.
- shultays 5y ago
  They are a cost to other developers as well. If one person is not able to (or choose not to) handle the tasks he is assigned to then he is a burden on others. Not to mention others' tasks can have dependency to that person's. In my experience (I think I had two people that intentionally slacks around and wants to get fired) the companies often put such persons on low prio tasks that barely matter. And be a bit more pessimistic with their estimates

ddek 5y ago

The obviously clueless are rarely controversial fires. The problem is when leadership have a different opinion of the employee than workers. I'm on my notice right now. I started hunting a new job after the company fired their recently hired well-liked VP Product. Most of the organisation believed this guy had made a substantial positive impact, and the firing reasons were concocted. They weren't entirely unjustified (he was too expensive, and focus wasn't aligned), but I still disagreed. I've heard both sides independently, and nowhere near enough effort was made to find a better way. When people see good people fired for weak reasons, they become concerned for their own role. As a senior engineer, this is particularly worrisome. A huge part of my job is to disagree with people. Junior engineers want to reinvent wheels, project managers want to impose pointless deadlines, the (barely) technical co-founder just read an article about grpc; I have tools to constructively push back in all these cases. If I see people getting fired like this, then my career becomes a factor in my decision making. Ultimately, this firing has cost a small engineering team both it's senior engineers. I'm gone, so is the other senior (for the same reason). The CTO is management focused. There are a few other reasons I won't go into, but this team is in a very difficult position.

layoric 5y ago
“Weak reasons” obviously heavily dependent on priorities at the time, which can change quickly. On small companies it has a massive impact on others and that shouldn’t be taken lightly. I had a previous boss that hired someone senior to do X but their expectations of the role quickly changed and they were fired for not performing well enough. They jumped from a good job stable job and took a risk, asking all the right questions about the role but CEO/CTO never lived up to their side of what the role ended up being. This same CEO also admitted to me part of their management style was “push people to breaking point, and back off a little” to get the most out of people. I left soon after. I don’t know how to avoid working with this kind of leadership personality in the interview process but has definitely made me more cautious.
yobbo 5y ago
> A huge part of my job is to disagree with people. Junior engineers want to reinvent wheels, project managers want to impose pointless deadlines, the (barely) technical co-founder just read an article about grpc; I have tools to constructively push back in all these cases. This paragraph should be a great frame for so many problems. Engineers are people whose identities are wrapped in the perception of their intelligence. But value is created when we disagree and "the right" person wins.

weeblewobble 5y ago

> Conversely, keeping clueless people around is demoralizing and insulting to the people actually doing the work. I think this is only true in the most egregious of cases. A somewhat counter-intuitive thing I've learned is that highly productive programmers like working with less productive programmers. They've spent a lot of time with this person, maybe got to like them on a personal level. But beyond that, they don't have to butt heads all the time, it's one more person to stamp your diff without excessive nitpicking, someone to bounce ideas off of, someone to handle the more mundane coding work, someone to share blame with. Almost like an assistant programmer. A backfill will have to trained and knowledge-transferred again from zero. This isn't to say the organization is best served by keeping low-performers around at full salary to keep their high performers happy. That depends on higher level organizational goals. My point is to support GP's quoted statement in your post, that firing is dangerous and can demoralize teams.

aidenn0 5y ago

Any non net-negative developer being fired risks demoralizing the team. If they are net 0.1% as productive as a typical developer, but not preventing anybody else from getting their work done, they are a cost to the company, but not to the remainder of the team.

GiorgioG 5y ago
Agreed. This individual was a net negative. They could not get their work done, and thus required other engineers to pick up their "slack". Everyone pitched in to help mentor the individual, without much success. Compared to other similarly skilled/experienced developers we'd hired around the same time - who became productive in a few months, this person made zero progress. Not firing this person was demoralizing to the team. Moving them off the team to another group seemed to upset people even more than keeping this person around (I'd moved on by this time, but kept in touch with the team). Rather than doing the right thing for the organization (firing them) - management decided to make it someone else's problem in the organization. Yes from management's perspective they 'solved' the team's problem but the optics of what they did created resentment towards management.
shultays 5y ago
They are a cost to other developers as well. If one person is not able to (or choose not to) handle the tasks he is assigned to then he is a burden on others. Not to mention others' tasks can have dependency to that person's. In my experience (I think I had two people that intentionally slacks around and wants to get fired) the companies often put such persons on low prio tasks that barely matter. And be a bit more pessimistic with their estimates