The sunny side of firing someone • Hacker News Board

Re: The sunny side of firing someone

#91

Post by Jensson » Sat, Mar 12, 2022, 10:01 PM UTC

humanrebar wrote: post #84

lumost wrote: post #68

Earlier quoted context omitted.

Companies rarely fire tenured staff except for layoffs. Often this is due to issues such as - Tenured staff have a track record, if they are suddenly under-performing it seems more likely that their manager is to blame. Rather than a lack of ability. - Tenured staff have institutional knowledge which can be hard to estimate and replace, the fact that a bad engineer still knows why something was done a certain way and…

Lots of good points here, but maintenance work for profitable systems seems like a valid use of time. Now, some profitable systems are slowly bitrotting and tenured engineers can keep busy doing routine work while failing to address or escalate the bitrot. But I think people who are good at making sure boring and stable things stay boring and stable are usually underappreciated.

Companies pay for people do to maintenance for profitable system even if those systems doesn't much need maintenance, meaning lots of people in those roles don't do much. The point isn't that all maintenance engineers are worthless, but that it is an area where you often can be incompetent but still be kept around.

Re: The sunny side of firing someone

#92

Post by exdsq » Sat, Mar 12, 2022, 10:06 PM UTC

stretchwithme wrote: post #81

exdsq wrote: post #80

Earlier quoted context omitted.

A company secretly screen recording me makes me shiver

"evidence a very poorly performing employee was reading articles on the web most of the day" Sounds like probable cause for a warrant. Not that employers needs a warrant to use their own property, but to assure employees that they aren't being watched unless there's legitimate suspicion.

I think this is illegal in Europe or parts of Europe! I’d feel differently if you were told this would be happening.

Re: The sunny side of firing someone

#93

Post by mushbino » Sat, Mar 12, 2022, 10:07 PM UTC

lumost wrote: post #68

mkl95 wrote: post #22

Back when I was a junior developer I used to think tech companies -even the smallest ones- generally had some kind of reasonably accurate performance review process, where engineers who were underperforming for a while were eventually weeded out. In my experience ever since, that's simply not true. There are "teflon engineers" out there who can get virtually nothing done and make one mistake after another, and get aw…

Companies rarely fire tenured staff except for layoffs. Often this is due to issues such as - Tenured staff have a track record, if they are suddenly under-performing it seems more likely that their manager is to blame. Rather than a lack of ability. - Tenured staff have institutional knowledge which can be hard to estimate and replace, the fact that a bad engineer still knows why something was done a certain way and…

In my experience, an inner circle is established at a company when it is still relatively small. Those fortunate enough to be in that protected circle can do no wrong. Any hires after that in group is established bear the brunt of that companies issues. It's very true with startups.

Re: The sunny side of firing someone

#94

Post by dccoolgai » Sat, Mar 12, 2022, 10:28 PM UTC

worker767424 wrote: post #61

andy_ppp wrote: post #30

Earlier quoted context omitted.

Smart, gets things done on time, pleasant to work with. Pick any two and you’ll do fine. Neil Gaiman’s commencement speech. I think if two are lacking for a while you get fired…

> Smart...pleasant to work with Does anyone have tips for having high code standards, but still pleasant to work with? I got feedback that I have high standards, but I also go to the effort of explaining why I think an approach is better in code reviews and don't talk down to people in code reviews (and got feedback saying this), but I'm not sure it's enough.

Try this; 1. every PR review call out one neat thing you _really like_ and maybe ask how they figured that out 2. Be explicit in the dichotomy between "recommendations/nits" and "you shouldn't merge this". Weight things toward the former. Have a style guide for the latter things and be very conscious of when someone is violating the actual style guide or just your own biases. If you really have high "standards" write them down... Otherwise they are just whims, not really standards.

Re: The sunny side of firing someone

#95

Post by fizx » Sat, Mar 12, 2022, 10:29 PM UTC

franklin86 wrote: post #74

Have any managers here been asked to fire ppl so the company could more easily raise another round of funding? Firing as a signal to investors that the company won’t waste money.

Not at a growing young company.

There are cases where a late-stage startup got into too many businesses and the next investor wants them to cut a line of business. Like I can imagine Uber having to shed UberEats if that was going poorly, but the investor liked the core driving business.

Re: The sunny side of firing someone

#96

Post by dccoolgai » Sat, Mar 12, 2022, 10:48 PM UTC

dccoolgai wrote: post #94

worker767424 wrote: post #61

Earlier quoted context omitted.

> Smart...pleasant to work with Does anyone have tips for having high code standards, but still pleasant to work with? I got feedback that I have high standards, but I also go to the effort of explaining why I think an approach is better in code reviews and don't talk down to people in code reviews (and got feedback saying this), but I'm not sure it's enough.

Try this; 1. every PR review call out one neat thing you _really like_ and maybe ask how they figured that out 2. Be explicit in the dichotomy between "recommendations/nits" and "you shouldn't merge this". Weight things toward the former. Have a style guide for the latter things and be very conscious of when someone is violating the actual style guide or just your own biases. If you really have high "standards" write…

To put a finger point on the advice above: you should _never_ be enforcing "your standards" but the "team's standards". If you can't tell the difference, that's its own kind of problem.

Re: The sunny side of firing someone

#97

Post by pedalpete » Sat, Mar 12, 2022, 10:56 PM UTC

I had to look at the author's name to find out if I was Bob! Though the latter paragraphs about ignoring the other engineers requirements about reviews, etc don't fit.

After a few gigs that didn't go great, I ended up at a research org, where my less than perfect code that would do things in a non-scalable way was actually appreciated and a benefit. This org had amazing engineering capabilities, and amazing research. I was an oddball that straddled the line between the two.

My engineering improved slowly, and I eventually ended up in management, and now run two start-ups. I don't get to code much at all any more, but the experience has given me a new direction in life.

It's great when a manager can recognize that even though you're not the right fit for that company, it's possible your weakness there could be a benefit to someone else.

I can't remember who I was listening to on a podcast, but they said that rather than firing people, they would regularly recommend they go work for a competitor. :)

Re: The sunny side of firing someone

#98

Post by burlesona » Sat, Mar 12, 2022, 10:57 PM UTC

onion2k wrote: post #56

burlesona wrote: post #4

Great article. Firing someone is hard. Even for poor performance it can be really hard, like heart-pounding fight-or-flight anxiety-ridden hard. It’s worst when the person who is doing badly at their job is a nice, well-liked person like “Bob” in this article. But it helps when you realize everyone involved in that situation (a person is dragging the team down) is miserable, and the misery only ends when that person…

Finding someone everyone likes is harder than finding someone who's good at their job, so the reasonable thing to do is to encourage the nice-but-useless person to do better rather than fire them and have the entire team demoralized by that event, and by the recruitment process, and the additional stress while there's an unfilled role. In my experience improving someone's work is often really easy too - you just need…

That may be the case sometimes but it’s not universal. Some people are not that motivated and don’t really want to work hard at their job, for any number of reasons.

One of the worst hires I made was a person who was an accomplished engineer in another tech stack and aced the technical interview, but when he showed up to work had nearly no interest in learning our stack or working more than a few hours a day. I spent 6 months trying to help him learn, but even after all that he was being outperformed by new grads, because they were trying and he wasn’t.

The person was friendly and well-liked. But nobody wanted to collaborate with him because they knew it would just make their work harder than doing things solo.

When we let him go, it was a big productivity boost for the team, even though everyone was sad it didn’t work out. The morale impact in the short-term was neutral, but within a few weeks as everyone saw there was literally no drop-off from his absence, everyone realized it was necessary and morale went up notably.

Re: The sunny side of firing someone

#99

Post by toomuchtodo » Sat, Mar 12, 2022, 11:26 PM UTC

cryptica wrote: post #20

I wish that getting fired would not carry so much stigma as it does today. I got fired 3 times in my early career. 2 of those times I believe were completely unfair, only 1 time made sense because I had burned out and lost motivation (also, the company wasn't doing well financially). In all of these cases, getting fired was a valuable life experience. The 2 times which were unfair, I learned that people can be unjust…

Great comment, great advice.

Re: The sunny side of firing someone

#100

Post by throwawayweed » Sun, Mar 13, 2022, 12:13 AM UTC

Years ago, I was Bob but a junior engineer.

I had previous experience working in research, and tended towards a more hacker's style of coding that had always been good enough for the prestigious lab where I interned. Looking back, the older guys on my team were signaling disapproval to management but would never correct me to my face, and never offered constructive feedback. My manager was largely the same way. People in tech tend to be terrified of controversy and struggle with conflict.

Getting PIP'd was the best thing for me, because it established clear standards and goals for me in my role. In sixth months, I got promoted. Sometimes it's a communication thing.