Hacker News new | ask | show | jobs
by iamsomewalrus 1431 days ago
Hire for fire feels like an urban myth. We do a lot of work to find you, interview you, hire you, and train you. Managing someone out is also a lot of work.

That being said a company as big as Amazon will always have edge cases.

4 comments

The myth I heard was: Manager has 10 employees who are absolute rock-star engineers. They love their team, work great together, and deliver amazing results.

This manager obviously doesn't want to hurt this awesome team or lose any members, but Amazon wants them to churn out the bad engineers (which this team may not have).

So instead of finding faults where they don't exist, our manager hires 2 engineers with little to no chance of working out in the team long term, give them some busy work, puts them on a PIP, then eventually fires them, only to soon replace them with two new victims.

It sucks to be a victim, and it sucks to knowingly do that as the manager, but it does work out great for the team and the manager - so I think it could happen (maybe not super common, but it isn't unrealistic in my mind).

That's the problem with applying a curve as a rule. In a large org it's probably true across the board. But there will be outlier teams. How does an org handle those?

You can critique Amazon for basically saying "don't worry about it" so managers may invent plans like hire-to-fire to game the system and overall someone's gonna get screwed on that team, but it's a tough problem to solve - otherwise, what's to stop managers from all simply claiming "no, my team's a special case"? Introduce special cases and it'll just be gamed through that mechanism.

I'm a firm believer that if you want to avoid things like that you have to avoid large organizations. A large organization is highly incentivized to be bureaucratic so to minimize the effects of unexpected losses and to keep the money machine running.

>otherwise, what's to stop managers from all simply claiming "no, my team's a special case"? Introduce special cases and it'll just be gamed through that mechanism.

You lost me. Why should we want to stop managers from saying that?

You got the myth part right: having a single team with 10 rock-star engineers.

1. Amazon isn't so special that even they can control the distribution curve to only have rockstars,

2. This is too big for a single team in the first place, let alone 10 rockstars,

3. You don't want any rockstars, let alone only rockstars on your teams,

4. Managing low performers is a magnitude more work than solid performers; no manager would do this to themselves on purpose. It would be easier to cut their 2 least rockin' stars.

I hate that some people say rockstars and mean ‘really great developers that write beautiful working well documented code quickly and work great as part of a team’.

And other people say rockstars and mean ‘assholes that churn out new features really fast with incomprehensible code and then leave others to maintain their monstrosity as they move on to the next thing”.

I assume Amazon is large enough to have a team somewhere with 6-10 of the ‘good’ version, and also a team somewhere with 6-10 of the assholes.

> Managing low performers is a magnitude more work than solid performers; no manager would do this to themselves on purpose. It would be easier to cut their 2 least rockin' stars.

Then what do you do a year (and a half for Amazon) later for the next cycle?

One of the many problems with stack rank cull N% of your employees every year is that "every year" part. At whatever level it's mindlessly applied, if the company wants to keep it at the same head count you by definition have a steady churn of hires, which I'll grant you won't always be good, and fires.

If 2 pizzas can’t feed 10 people, the chances are there are some health questions to be asked about a given team.
> Hire for fire feels like an urban myth. We do a lot of work to find you, interview you, hire you, and train you

Your unspoken assumption here is that recruiters, HR and managers have perfectly aligned incentives. It is trivial to find instances when this is not the case - e.g. a high-performance team being forced to fire their "least effective" member[s]- this relies on the theory that talent is uniformly distributed across Amazon.

Amazon manager here: I just did a mental count of our URAs while I have been at Amazon. More than 3/4 are new hires fired in less than a year.

Hire-to-fire is neither a conspiracy nor a conscious tactic. It's the natural consequence of what we managers are put into.

If HR wants you to URA someone out, who would you rather lose? The experienced SDE who is productive and is responsible for projects you don't want delays in; or the new hire who's still trying to learn company tools.

That's why hire-to-fire is a thing.

It's cheaper to allow an employee on the low end of HV transfer in from another team.