Live data from Hacker News

It's Never Too Early to Fire

a16z.com

181–189 of 189 posts

Re: It's Never Too Early to Fire

#181
post #46

Earlier quoted context omitted.

I work in the UK and it's similar. Except we have a lot of diversity due to a vibrant contractor (at-will) market. Which the Tories are trying desperately to destroy, for some reason. Permanent employees are basically impossible to fire. It's a mixed bag I think. On the one hand, there is a large social benefit to having such gov enforced job security. On the other hand, it drives down wages, and hurts companies that…

"Permanent employees are basically impossible to fire." That really isn't true at all - you can be fired for pretty much anything in the first two years and after that the process is pretty straightforward. I've never seen a company fail to get rid of someone they didn't want working there - one way or another.

It's harder to do in Europe, but it's still possible. Especially, as you say, if there's management determination that the person has to go.

Re: It's Never Too Early to Fire

#182

Earlier quoted context omitted.

As a senior programmer with a bit more life experience, I quit somewhere after only 2 months. They valued me, the pay was great, the tech challenges were interesting, but their processes drove me potty. I have never regretted it and only feel relief whenever I think about it. I walked straight into another job. If I were to stop freelancing and get a job again, I would just leave it off my CV.

but their processes drove me potty. Out of curiosity, in what direction? (Also in the process-driving-me-round-the-bend camp, but concerned that a lot of alternatives might be a case of "out if the frying pan, into the scrum"...)

Bad agile, bad tools, bad QA, dysfunctional ops. Their sql ops said they'd get me a backup within 2 days and then 3 weeks later still no sign of it and we had to go live without testing.

The agile bits were standups before we'd even got anything to do, card votes on how long features would take and I was saying months and everyone saying days, but I was the only one with any significant experience. Lo and behold 4 weeks later when I left it still wasn't done. There was some nonsense around the kanban board when they'd move things when nothing happened, tasks were really poorly split up so some bits would just get stuck, etc.

Re: It's Never Too Early to Fire

#183

Earlier quoted context omitted.

how is it "hard" to fire in the USA

In private industry, very easy. Employment is at will. Except for senior people who may have custom contracts and classes of people protected by anti-discrimination law, the employer, not employee, owns the position.

True, but in fairness, the US is also a rather litigious society, and improper termination is one of the things people are inclined to sue over. That's why mature companies tend to put some procedural obstacles in place to keep managers from firing people at the drop of a hat. Typically the manager has to show a long series of specific deficiencies in the employee's work and attempts at counselling and remediation before they are allowed to fire someone.

Things are sometimes done more quickly at smaller places, but even then it's fairly common for employers to offer termination agreements, typically for a few months salary, to avoid even the possibility of litigation.

Re: It's Never Too Early to Fire

#184
post #24

Actually, pretty good advice in the opposite direction, too. If I had known at 18 that I could have easily and successfully walked away from teams, bosses, companies, partners, and investors who gave 'bad vibes', I would easily have (at least!) an extra couple million in the bank. I wasted countless opportunities waiting for things to get better, when I probably intuitively knew that they wouldn't. Partly, it was bec…

I'm exactly in that condition, how did you overcome?

Re: It's Never Too Early to Fire

#185

Earlier quoted context omitted.

> You are the problem. A minor point. I recently had to let a junior level person go after "giving them a chance" for around 5 months. I did everything I could, extra mentoring, warnings, gentle pressure, lighter work and finally, an opportunity to shift into a simpler projects so that they'd get more comfortable. This was, as the article mentions, emotionally draining for me and unfortunately, the dislike split over…

I agree with everything you said but I think you place to much blame on yourself as a hirer. There will also be people who put on a good front but just want to coast once they get in. This is especially true in big companies that are loathe to fire. I know people say to keep ramping up the testing and difficulties of interviews but we've started to create a culture where all you end up with is people who are good at…

I can see how your observations about these people are different manifestations of the problem I saw in my employee. My impression was that he was drunk on the whole "cool startup" attitude that's so rife these days. Things like a bean bag in the office were so important to him and he wasn't willing to deliver any work.

Re: It's Never Too Early to Fire

#186

Weirdly, I think we would all benefit quite a lot from a normalization of fast firing. Part of the reason it's hard to get a job is that companies are afraid to fire you, so they jump through all kinds of strange hoops to try to predict how good an employee you'll be based on, really, no information. This also forces companies to filter out "possibly good" candidates and only hire "probably good" candidates. If it we…

Sounds like permanent PIP for all employees, along with an unpaid PIP for when you are let go.

Re: It's Never Too Early to Fire

#187
post #181

Earlier quoted context omitted.

"Permanent employees are basically impossible to fire." That really isn't true at all - you can be fired for pretty much anything in the first two years and after that the process is pretty straightforward. I've never seen a company fail to get rid of someone they didn't want working there - one way or another.

It's harder to do in Europe, but it's still possible. Especially, as you say, if there's management determination that the person has to go.

You really can't generalize across Europe

Re: It's Never Too Early to Fire

#188

Earlier quoted context omitted.

yup, basically kept getting increases in pay (but not promotions or authority to change the situation I was in for the better) to stay. Don't take the bait. it's an admission that they know you are more valuable than you are being treated, and an acknowledgement that your misery in the situation is not going to change, which is exactly why they are hoping you will be ok with continued frustration in lieu of more mone…

That's still a pretty good deal though. Plenty of companies will never budge on money. They'd rather you quit and just find another sucker.

sometimes.

However, if a company has gimpy organization and technical APIs for many complex pieces of software and or processes in which making mistakes is costly and expensive, it is economical to raise someones salary $15k than have to invest in a newb to spend the next 7 months being able to operate as quickly as you do. It took me about 7months to be up and running efficiently with everything and be able to train other people. I still had to perform at full capacity on day one, but I was less efficient and because mistakes were so costly, I would have to wait 30-45minutes to find someone else to confirm an operation before making one, instead of making a mistake in production, until I knew how to do it myself.

In the manufactoring line, bottlenecks for tools being down was calculated by the millions per hour, because linear bottlenecks in product production actually cascade down a 4 months timeline for meeting product deadlines, which have payment associated with them, and significant penalties for being late.

Additionally, metrology tools to check errors sometimes cannot, based on chemistry and physics, detect errors in production until multiple steps down the line. So if there is a mistake in a base design, it won't get picked up for 3 weeks, and the entire line has to be restarted, so it really helps to have people know how to not screw up even if there isn't an official process for it.

They kept me on because I worked hard, and because I knew how to use over 18 different independent horrible pieces of software with no APIs, and run them simultaneously in realtime in production while operating a team of 15 people.

Losing me was uneconomical for them.

Re: It's Never Too Early to Fire

#189
post #140

Earlier quoted context omitted.

the big thing here is the struggle between companies like amazon google apple who have tons of applicants, and a startup who has less applicants, and less experience from hiring false positives and identifying false negatives. They acknowledge that they turn down many good people, but also most if not all of the people not qualified. They arent worried about false negatives, they are worried about false positives. So…

There is no real evidence that companies like Amazon / Google / Apple are actually better than other organizations at filtering out false positives, or that they have struck the optimal balance between false positives and false negatives. These are simply unsupported subjective assertions.

mm, perhaps but I'm echoing documented hiring philosophies of the companies. They are aware they make mistakes. But they feel confident they filter out a majority of false positives along with many false negatives. They have their own metrics for determining this in relation to how many people they hire are able to complete a minimum satisfactory work.

They have documented people who can do this in relation to the people they hire, and even have internal portfolios tracking employees by age, experience, major, and schools, as well as how they performed on interviews. This is a fact.

Everything is subjective. But ultimately a company decides based on its own subjective priorities how an employee meets up to their subjectively defined needs for the position that person fills, and they can pretty onjectively within that context evaluate whether the person can do the work or not, and even track commitments, errors, time to cdoe to completion, amount of bugs, amount of time team has to spend fixing their bugs, etc, and parse out a pretty good idea of performance.

Thats why theres multiple books written by these companies designed to help you pass their interviews, as they have identified indicators of low performance in interviews....

All companies can do this, but many don't, and many arent based in software and therefore do not have embedded ability to track performance metrics the way code commits can.

small companies can do it too, but big companies who also have this system in place can take advantage of larger sets of data for more accurate indicators that seem to correlate with low performance.

Post reply on HN