Hacker News new | past | comments | ask | show | jobs | submit login
What happens over time if each year I fire all my below average programmers? (quora.com)
192 points by rmason on Apr 6, 2017 | hide | past | web | favorite | 104 comments

Imagine this: Joe, your best performer, has a bad year. He ran into personal issues (divorce, death in the family, illness, etc). Joe was on a steady streak, then his performance cratered for a while. It's nothing permanent. Do you fire him?

Ballmer's organization would. I've seen it.

In Ballmer's organization, groups deliberately used head count to hire low-performers, who would then be put on the chopping block in review cycles. The horse-trading games in review meetings were brutal. People wrote self-reviews, but they didn't mean anything because it was all decided ahead of time. It was all a big kabuki dance pretending that the company could measure people accurately, even across widely separated groups (an SDE II in the Xbox group was not the same as an SDE II in Windows, believe me).

Oh, and God help you if you get into one of these situations: Say you're a seasoned veteran, a senior engineer, and your boss got out of school three years ago and has no idea how to defend you in stack ranking. Or your manager is an over-the-hill engineer who doesn't want to manage but was forced into it, and doesn't even buy you equipment, much less give a crap about you in a stressful meeting he doesn't want to attend in the first place. Or you're reporting to a political climber, who will throw you under the bus just to be a "yes man" to someone else in political power.

One year I was a "ten percenter" and in peril of losing my job. Two years later I was getting promotions and on the partner track. Go figure. We can't pretend that reviews are even remotely accurate given this scale of noise.

I think that deciding pay scale / ranking and deciding who should be let go should be a different set of criteria, and probably a different review cycle. Not totally unlinked, but not utterly congruent, either. This would also handle the "high paid asshole" who is productive, but totally toxic and doing damage far in excess of his pay.

Ranking and firing should both occur at review time, but "Should we fire somebody" is an independent metric from ranking.

The lazy are the easiest. Fire them. They are also the rarest.

The malicious are also easy. Fire them NOW. If I catch you sabotaging somebody or gaming metrics in a way that causes problems, you're gone immediately. I will invoke "at will employment", get rid of you immediately, and I won't tell anybody why so I can avoid the legal nightmare. Fortunately, they are also quite rare.

The next layer are the underperformers. The question here is generally: "Why are they underperforming?" This generally requires a good look in the mirror as well as a look at the employee.

It may be employee issues: divorce, health, etc. At which point you have to judge some level of future expectation with past expectation to balance current performance. You may not decide to get rid of someone like this right away.

However, a LOT of the time, the issue is on the company side. Did this person get hired too high in the chain and now sticks out? (Happens when hiring goes from scarcity to glut) Does this person need extra training? (Got moved to somewhere they don't really belong because of "reasons"). Does this person need extra resources? Are you simply expecting something too far out of line? At this point you need to come to grips with the fact that you are dismissing this person because the COMPANY doesn't wish to expend the money/time/effort to fix the problem. And too many people underestimate the amount of resource they're going to lose to try to get a replacement. Having chosen to train certain employees rather than fire them and hire a replacement has given me some of my best performers and most faithful workers over the years. It's also given me a couple of my biggest bombs--but I'll take the ratio for now. If I really decide I can't expend the resource, I will fire you, but I'll probably give you a nice recommendation as well as some extra time and help to find your next job.

I have also recommended firing people who were above average performers simply because I judged them to be too much of a drag on everybody else. I'm happy to take criticism all day long--I've got a really thick skin. But other people don't necessarily, and I do have to think of the other members of my team. Too much friction, and I'm going to get rid of the abrasive. Sorry, that's life.

Reviews are an unecessary evil, you shouldn't do them if you don't have to and you shouldn't tie actions to them.

If someone is doing well, tell them right then.

If they keep doing well, find ways to promote them into roles that better benefit them and the organization.

If someone is screwing up, tell them right then.

If they keep screwing up, put them on a corrective action plan. If they don't improve, only then do you consider firing them.

Most US states allow fire at will, so building elaborate paper trails is rarely necessary and just a waste of time/butt covering.

Gosh I like this! Eliminates the artificiality. Eliminates the competition and the anxiety. Replaces all that with something natural.

Why is this approach so rare? What's the downside?

> Why is this approach so rare?

It needs a competent and hard working manager who also has time to do it.

IMHO the "lazy" and the "malicious" are the ones making policy. They certainly aren't going to be fired, so - again IMHO - this policy is a non-starter.

I tend to fire those who write IMHO, primarily for the humble part, but also, who else's opinion is it :-?

It's an explicit recognition that the statement is one of personal opinion. Without the marker, it could be understood differently.

I'd probably not use the IMO or IMHO shorthand in a business setting, but I definitely will qualify a statement of personal opinion in a context where it might be misconstrued.

Well, thank goodness I don't make comments on Internet forums as my day job!

In addition to this, I would add a "proof is in the pudding" argument if the arguee is still not convinced:

Microsoft got rid of stack ranking in 2013. Their stock has almost doubled since then and now everyone's talking about the "Microsoft renaissance". Correlation isn't causation, but it's hard to argue that stack ranking is a good thing after a turnaround like that.

I think Microsoft's depressed stock value and stack ranking are both symptoms of the fact that Ballmer was a clown.

And one of his biggest clown tricks, bigger than "Developers Developers Developers" or throwing chairs, was messed up HR policies.

Microsoft my hire PR folks but under Ballmer, office would never appear on ios and Android. I was there when a clean built application was rejected only to be approved by Satya governance.

We would not have seen open .NET, open vscode, Typescript, Ubuntu subsystem, Powershell.

Even in the cloud, Linux would have never made to Azure. Ballmer saw Linux as threat, Satya saw it as a platform to build things on.

It was a night and day difference when the shift happened. Every team built their own hacked version of Jquery and suddenly we could just use a pre-built one. Code was cleaner, teams moved faster. Open-source was encouraged. No stack rank.

Stock doubling is not a coincidence. Ballmer just didn't understand developers.

Messed up HR policies, squandering opportunities to enter the phone market, doubling down on an unwinnable war against open source... His management gaffes are many and varied.

Stock valuation is an incredibly bad way to measure company performance.

Their stock started climbing about 8 months before they got rid of stack ranking. I wouldn't chalk up Microsoft's stock growth to "they suddenly figured out how to treat people better."

I suppose you're free to believe what you want, but the microsoft renaissance is literally the companies marketing/PR.

This is what they pay people to say on websites like Hackernews/Reddit, etc so that people like you and I start repeating it.

It's not that cut and dry for me. I do see objective differences in the Microsoft of today.

* Visual Studio Community is now free.

* Visual Studio Code is free and surprisingly awesome, IMO. It's now my default text editor, having replaced Sublime Text.

* I think what they're doing with .NET Core, VS Code etc. is great, they've realised after completely missing the boat on mobile that they can't control all the platforms anymore, they've been forced to think cross-platform. They've been forced to think beyond Windows for the first time in their history really, and that's a good thing.

* Their traditional allergic reaction to anything open source seems to have been given a strong dose of antihistamines. They've open sourced a bunch of their own stuff and they're now #1 for open source contributions on GitHub.

* I like Azure, I like that they're making their own hardware - I used a Surface Pro 4 as my main machine for a while and it was pretty good, "devices and services" as Nadella has said.

Bear in mind that I hated Microsoft back in the day. I only ever begrudgingly used Windows, I stayed well away from any of their development tools, preferring open source languages and frameworks even when working on top of Windows. If I needed to run a server, it was Debian (this is still more or less the case for me today). I used to run Debian as my main desktop OS for a few years. Today a Mac is still my main machine. I say this because I want it to be clear that I'm coming at this topic from a place well outside the world of Microsoft. I am well acquainted with the alternatives.

Besides Ballmer, there has been a generational change at Microsoft. Is the publicity around this change somewhat marketing driven? is there still plenty of room for improvement? Sure, no doubt. But I think it's a bit disingenuous and overly cynical to 100% attribute it all to marketing/PR spin.

Forgot the crucial point.

* Rampant spying in Microsoft's products is at an all time high.

And it's not going anywhere.

Windows 10 and so on. Yeah I know, I get it and it's not OK. They're obviously not alone in the exploitation of their user's data, however. I say that not as some kind of equivalence-based excuse but because it's a problem involving multiple organisations and industries. And while my main point is that Microsoft has - in some ways - changed for the better, in most cases, at the end of the day, the nature of a public company will always be to make profit measured in quarterly periods. And much like the proverbial scorpion (and frog), a public company will keep trying to make profit measured in quarterly periods to the potential detriment of its own long term viability and that of the greater societal context within which it exists. My point here being I don't think it's realistic to expect that anything other than external pressure will change the privacy situation you highlight.

And when the majority doesn't seem to care about loss of privacy unless maybe it's about their dick pics[1], I think you're right in that the privacy situation as it currently stands is not going anywhere.

Perhaps a little more on topic, the HR practices of Microsoft may have improved somewhat, but I have some acquaintances that work there and it's still not all roses in that area either from what I hear.

So I can commend Microsoft for what they're doing better while still recognising where they suck. It doesn't have to be a binary all or nothing situation. At least not for me. It ceased being a religious war for me a long time ago.

1. https://www.wired.com/2015/04/john-oliver-edward-snowden-dic...

Yup, I was there around that time and it sucked. But this is only the seed kernel of the rot that happens.

I think there's a PG essay somewhere about "front of mind" and how it impacts what you do. As a founder if you're thinking all the time about funding it blocks you from thinking about building stuff. The same sort of dynamic exists with job security. If you perceive that it's actually pretty difficult to lose your job, if you perceive that lots of people at various levels know your value to the company and are willing to go to bat for you, that helps a lot. It helps even more to push those issues out of the front of your mind, so that day to day you tend to worry mostly about making stuff and solving problems, things you are intrinsically motivated to do. What happens when the working environment becomes more cutthroat is that those issues bubble up and become more front of mind for more people. People think about how to work the system, people evaluate everything that happens based on how it will advantage or disadvantage them in reviews. People who spend most of their time working or gaming the system find that spending their time that way is fruitful.

Folks who are intrinsically motivated see these changes happen and they perceive the quality of their working environment diminish. The most talented among them often find out that it is easy for them to find work elsewhere, and they do so. And this begins a cascade process of brain drain. One of the prime motivators for intrinsically motivated and talented technical people at a workplace is being able to work alongside other talented and interesting technical people. Every talented person that leaves reduces the quality of the working environment for the remaining folks, and makes them more likely to leave.

Meanwhile, as good folks leave it becomes more and more difficult to execute on challenging projects. The talent pool has been diminished and the people with the most experience have also left. It doesn't take long for the "corporate culture" and working environment to change dramatically from one where people spend most of their efforts on "getting stuff done", people enjoy their work, and lots of big, challenging projects continually get done with a high degree of quality to one where people tend to think about their motivations mostly in terms of a paycheck, are constantly searching for a way out, and there's a downward spiraling level of quality and achievement in terms of projects.

When I observed my management "re-interpreting" their goals and results to paint themselves "green" across the board -- with the obligatory yellow or two, to make the results look "realistic" -- I lost the last of my respect for that company's performance review process. And, about that time, the last of my respect for such processes, overall, as well as for HR being anything other than a mouthpiece of the extant power and its self-serving goals.

To my embarrassment, I'd gone against my intuition and continued to try to work with the process.

Performance reviews are your time to observe the company's actions. If they don't treat you well, get out. Simple as that.

Maybe, in some cases, a manager is genuinely seeking an employee's improvement and continued tenure. And goodness knows, I'd like to think their are institutions, not to mention a prevailing attitude, seeking to improve and empower their staff.

But, "Office Space" is real. Get used to it. Think for yourself.

> When I observed my management "re-interpreting" their goals ..

Wow, you actually know what your management goals are, instead of having to find out by reading in the trade papers that the company is now totally X Y Z focused, X Y and Z being whatever the tech flavour of the month is :)

Immediate management. Those "Mind the Gap" type people? Yeah, I could guess pretty well. But it wasn't what was coming out of their mouths, often.

Good point, though.

Well, what if you countered it with a lucite slab?

>In addition, there are people out there who are constant scaffolding to everyone else. You have to watch out for them, but not because they’re trouble. Because you could be trouble :)

>Their individual productivity looks poor, but they’re natural givers. You fire them, as Microsoft did, then the teams they are in, literally collapse overnight.

1000x this. I've seen it happen. Some people are just naturally team players. They help other people shine. They see success as making the team succeed. One thing he didn't mention is these people tend to be well liked by their coworkers, so when you fire them the rest of the team goes into a deep funk which has everyone sending out resumes.

Stack ranking is dumb. At one time you could have made the argument it might be effective in its brutality, but not any more.

This is exactly the type of developer I try to be.

I've been in this industry about ten years now, and I've learned that while I am capable of a very high level of productivity I am not capable of maintaining it consistently. I can do short bursts on command and I can occasionally maintain it for a couple of months at a time, but I inevitably crash and start to drift.

I don't think I'll ever be the "rockstar" that puts repeatedly puts out amazing stuff, day in and day out for months and years. I know those people. What I can do is ensure that I deliver value during my "drift" periods by helping coworkers, implementing iterative improvements in existing processes, and doing systems-level design work.

At my current job, we work in two-week sprints. Right now, I've been working on a feature for six weeks that should have taken me no more than three. I completed it this sprint it a burst of productivity; last sprint I made little progress on it, but was able to complete a slew of smaller side tasks that helped the whole dev team.

I also spent a lot of time reading and "tinkering" with other parts of the codebase and the libraries we use which resulted in my becoming a domain expert in a couple of new areas. Because of that, at least twice another dev came to me with a complex problem in that area and I was able to point them to a simple solution in only a few minutes - in other words, my yak shaving had resulted in an immediate time savings for them and a longer-term time savings by drastically reducing the amount of code that we'll have to maintain going forward.

Now, if my value to the team were measured only in how quickly I completed the task that was assigned to me, I'd be barely meeting expectations. If you consider my overall impact it's an entirely different story. This is exactly what my employer does, and is a large part of why I joined them. I have the freedom to focus on tasks that are not on a tight timeline, and to reallocate myself if I need to or if I'm able to provide more value elsewhere.

I wouldn't last six months at Ballmer's Mircosoft, though.

This is a great explanation of the destructive consequences of what's called Stack Ranking (I think Intel still does it).

Even if you're a sociopath and don't understand the reasons outlined in the article: how do you figure out what "average" is? Lines of code? Bugs fixed? Even if you had a meaningful metric, evolutionary pressure would cause people to select for it, which isn't what you want (you want a diversity of skills).

> how do you figure out what "average" is? Lines of code? Bugs fixed?

Whatever you choose, it stops being an effective metric the moment you begin to use it to gauge performance.

This form of argument always seemed disingenuous to me. After spending some time with a programmer, especially in a work environment, it's easy to get an overview of how strong their skills are, and average would mean either the average of your employees or the average of similarly-positioned employees in general, neither of which is hard to have a handle on after being in the industry for a bit of time.

Just because you can't with current technology write a program to give an output from 0 to 100 grading a metric doesn't mean that the metric is impossible or even difficult for a human to evaluate. Leave your metric at "a heuristic evaluation of the employee's overall effectiveness" and the only way to "game" it will be to be a better employee.

> After spending some time with a programmer, especially in a work environment, it's easy to get an overview of how strong their skills are

If you're another programmer, yes perhaps. But I've seen weaker developers consistently claiming undue credit from management through superior social skills enough times to know that, even with the best evaluation system in the world, it's _always_ possible to game the system.

More to the point, as the article points out, I've seen teams full of "stars" who's collective success depended on that weaker member that fixed all the bugs no one wanted to touch. Scoring that persons value directly would have missed their value entirely.

In my dystopian nightmare, the employees rank each other to determine who's below average.

Welcome to the "360 degree review": https://www.qualtrics.com/qualtrics-360/360-degree-employee-...

I wish I had made it up to tweak your nightmare but it is reality at quite a few sucky companies.

> If you're another programmer, yes perhaps.

And even then, we can only really evaluate developers below and maybe slightly above our own skill level. And only if they're working in similar areas to us.

I think what you are suggesting is a classic recipe for office politics.

It frequently can be more difficult for a supervisor to get an accurate assessment of a direct report's skill level than a peer, both because they have many other demands on their time and because employees know it is important to put best foot forward in interaction with their boss (or, more cynically, make themselves look better than their peers/competitors).

If you leave your metric fuzzy, as you suggest, managers/whoever is doing the assessment will tend towards 'gut feel' and you will get people optimizing to be their boss's best friend or to be the one who makes life easiest for them, instead of optimizing for those who are doing the best job.

It isn't always this bad: individuals in manager roles can mitigate this by doing their job well, but the system overall can tend that way.

You have over-simplified the problem, apparently assuming that people will just do their jobs and not engage in a kind of guerrilla warfare intended to keep their jobs.

Example: I once worked with a guy who knew he was an underperformer - he was also a manager, reporting directly to the CEO.

He ensured his job for many years by sabotaging all of those around him, and then whispering sweet nothings into the CEO's ear about how he couldn't achieve the targets set because everybody else around him was incompetent. For example, he would sell something big as cheap as he could, so we would lose money on staffing while building the (not software) project, and in the last few days before it was to be delivered, he would come in with a major structural change that he knew about for weeks in advance, and it meant double-shifts with no extra pay for the workers. When the CEO came down on the business for not making a profit, he made sure that he was first in line, and complained about how we just weren't doing the job right, weren't working hard enough, all the usual kind of crap.

He got caught because he once placed a few orders online, from a street address that didn't exist. It happened to be just a couple of doors from his house, so he would be pretty much the only person who would reasonably be expected to know about this. Nothing happened to him at all, and I was held responsible for not filling those orders, causing them to be cancelled. (I have absolutely no idea how this happened and nobody could explain it to me except for the CEO, who refused to on grounds that if I used my brains I could understand it.)

The manager eventually resigned, incompetence widely known, and his replacement found his unlocked filing cabinet that contained a complete run-down on everyone, and what he could blame on them to get them fired if his position became untenable.

You implicitly assume such a measure is theoretically possible. Perhaps it is, but just asserting this as fact is not enough to make your argument valid.

I believe that product development is creative, collaborative work and that there is no theoretical or practical way to design any sort of universal scale to rate individual contributions into it. Each team and problem combination is different. If I'm right with my belief your argument falls down.

Not only that, but if I am right then what comes into play is team and collaboration dynamics, which rely on trust and safety far more than on individual brilliance. If so, any attempt to "get rid of the bottom half" will simply destroy collaboration and guarantee a dysfunctional product team.

Come on, can we at least try to be scientific here on HN?

You get an impression of someone's skills. Fine. Now, if I ask other people, do they give the same impression? How well are these impressions correlated with actual work output items? How do you measure intangibles like "contribution to team spirit"? How well are these impressions correlated with other forms of prejudice? How well do you rate someone with very different skills doing a different job?

How do you even define "better employee"? Surely that's something thousands of pages of business books have been devoted to?

> After spending some time with a programmer, especially in a work environment, it's easy to get an overview of how strong their skills are

if you are a significantly stronger programmer than they are AND 'some' time is 'alot' of time.

This is one of the reasons I dislike anti-discrimination laws.

Well hopefully everyone dislikes them but seriously is there any better alternative? And despite the serious drawbacks the net result in countries I'm familiar with (US, AUS, DE) have been significantly positive.

I suggested a compromise limiting them to manual jobs and the like, in which the performance is easily measurable for example.


One of the evidence often used in these lawsuits is performance reviews.

You loose it all. The talent, the new ideas, the customers - until even eternal monopolies fall apart. Any metric will be gambled, and thus, the best metric is to correlate success with teams, and keep the good ones with rewards, while putting the problematic ones in quarantine among which people can still migrate. Repaired Teams are moved out of quarantine, all without explanation. Success is only determined with "historical" distance - aka 1 or 2 years. https://www.youtube.com/watch?v=YyXRYgjQXX0

Great read. This type of cut throat culture inspires nothing but negativity in the work place. I am a firm believer in helping your developers improve instead of firing them. However, there is of course always a situation were people must be let go.

Your programmers find above average employers?

I laughed hard at your brilliant comment. Thanks for that. I needed that boost while I work on my resume.

1) You hire terribly and develop people terribly if it's that easy to hire people better than your current staff (you should fire yourself) 2) Your good people leave for more secure jobs with people that aren't misanthropes 3) Over time it tarnishes your reputation as a destination 4) Over even greater time, it stunts the development of your professional network.

This is a pretty good Quora answer, all things considered.

This is a common practice among sales organization here in British Columbia, as it was championed by Jimmy Pattison. He started in car sales, and now owns billions in assets here in BC. Having worked in sales, I understand the logic behind it. I disagree with it, but I understand it.

The mantra seems to be "when you have great sales, you can commit many sins". Not exactly the best motivator for an ethical institution.

An alternative, and more effective sales methodology IMHO, is Jim Collin's "Good to Great" https://en.wikipedia.org/wiki/Good_to_Great

You may agree or disagree with my views, but if you're a company that fires the bottom 10% on a regular schedule, I can promise you this: I will never work for you.

Yes but... this only works in sales type environments where every worker is only interested in themselves, sales at all costs without regard for others, and it rewards the worst type of psychopathic personality

Couldn't have said it better myself :)

This happened at a company that I worked at previously. All of the "good programmers" left to more honest and less stressful workplaces because they could. This left only average programmers remaining. Without the good programmers to mentor the remainders, people started to fall into bad habits and started slipping into "below average" territory.

"What happens over time if each year I fire all my below average programmers and get better ones?"

Easily answered:

    f(t) = 2^-t

         t     f(t)
     0.000    1.000
     1.000    0.500
     2.000    0.250
     3.000    0.125
This obvious mathematical result stands apart from the expected morale issues. It also ignores the "get better ones" expectation, since that will never happen once word gets out.

If I worked at such a company, whether I was an HPE (I'm not) or an Average (probably at least), I would never recommend or invite anyone else in to that culture. If someone I knew really needed the job, I would at least describe the culture and say "it's up to you." But I certainly wouldn't be part of the underground recruiting team that, ideally, everyone should be.

And I'd stay for my own reasons, until not.

This is/was done at my current employer; Honeywell. Of course we had to outdo GE and make it 15%. I knew two managers who quit over the process, rather than fire their reports. Of course we had 360 reviews also. The same corporate jackasses must travel from company to company screwing stuff up.

Easy: you'll be "firing" the company's stated corporate values running counter to the practice and "hiring" operational values aligned with it.

What are those fired/hired values? I don't know and likely neither do you. Considering it's a practice based on arbitrarily judging others (ie.firing Equanimity), I'm guessing Compassion & Kindness also take a walk, with Joy soon to follow. I don't need to know anything more about your company to know I don't want to work there...sounds like a dreary place to work.

It's not only important to intentionally design your culture in alignment with your values, but for the values to be aligned with the organization's needs. Humans and organizations don't need rankings. They need resources. Designing a culture around rankings ignores needs and is thus an unfriendly environment for people. They'll then do whatever it takes to meet their needs, regardless of corporate values.

In short, enjoy your cultural grab bag!

This sounds insane. Why would you hire a cohort of employees only to fire them later?

This may make sense in professional services firms with a pyramid structure. That's a situation where "up or out" might make sense.

But a dev team? There are just way to many inter-dependencies in software development. Plus, social skills aren't a "must-have" for further development as an engineer the same way they would be for a professional service provider (e.g. lawyer, consultant, accountant). So the political aspect of rank and yank, just serves no purpose.

Finally, software is an industry that's growing faster than the old manufacturing firms like GE (where rank and yank was popular).

If it's cost pressure that's causing you to fire people, then perhaps you should have outsourced that dev work to begin with. Part of it was obviously both expendable and/or temporary, so not treat it as such?

This sounds insane. Why would you hire a cohort of employees only to fire them later?

The simple answer is "because it's cheaper to hire them and see who works out than to put together a better hiring process". No hiring process is going to be perfect; at scale, companies can reasonably say "X% of our hires aren't going to work out".

Consider the situation of university scholarships. At my institution, we offer entrance scholarships based on high school grades, extracurricular activities, and an application essay. If a student doesn't maintain a 3.5 GPA (we have A+ = 4.33, but the average grade awarded across the institution is 2.80) then they lose their scholarship.

Every so often someone says "hey, why are we taking their money away? Why are we making them stress out over keeping their grades up?" -- and my answer is always that if they're having trouble maintaining a 3.5 GPA, we made a mistake in giving them the scholarship in the first place.

Now, the situation isn't entirely analogous; in particular, if someone has worked at your company for 10 years and repeatedly demonstrated that you didn't make a mistake by hiring them, a single bad year probably doesn't contradict that. But if you know that you have a consistent rate of 10% of your hires turning out to be mistakes, it's not completely unreasonable to go around to your teams and say "those 10 people you hired last year? Figure out which one was the mistake".

I think there's a time and place to fire toxic people and low performers. But to code that into any sort of forced rule seems short sighted. I'm surprised companies like Microsoft even attempted it.

Does anyone know if stack ranking is ever applied to the C-suite? For example, fire 10% of VP's in companies that have multiple VP's.

I don't think that the problem here is the society that firing people creates, but rather that we don't have a very good definition of performance.

A similar problem occurs when you try to define evolutionary fitness. There are trends and correlates, but we have never found any universal criteria for fitness.

Two things:

* People try to game the system to get a high score instead of performing well

* People leave the good teams and flock to the bad teams because then they are not below the average anymore.

People do not behave as predicted by these models, they cheat. That's why it doesn't work.

Let's note the difference between "fire all my below average programmers," and "fire my 10% worst performers."

The former is obviously insane. The latter isn't, though dogmatic and literal interpretation of it as a rule rather than a guideline has bad results.

Firing the bottom 10% is still corrosive when you get to the implementation, just go read about how it worked at MSFT.

Firing people when they don't meet expectations is fine, but having enforced quotas is highly problematic.

I mean, on some level I totally agree. Having enforced quotas is highly problematic.

I kind of feel like managing a very large organization, on the scale of Microsoft or even larger, is a matter of choosing the marginally less highly problematic approach than all the others.

Telling everyone to "fire people when they don't meet expectations" works pretty well in a 100 person company where the execs can more-or-less check the work of the line managers and intervene when someone is avoiding firing their low performer. It's not a solution in a 120,000 person organization.

What happens instead is some managers tolerate their low performers. And then low performers flock to their team and high performers escape it, and their team becomes dysfunctional. And then it infects all the teams around it with dysfunction. And by the time this bubbles up to a level where you can be reasonably sure that everyone's aligned and high performing and able to effectively intervene, you've got rot throughout entire departments, and fixing that causes incredible morale problems of its own.

So you adopt some kind of policy that you believe forces your line managers to have some kind of accountability.

Now, is stack ranking the least-worst policy? I dunno. I've never been in charge of Microsoft. They certainly weren't at their best during their stack ranking time, but you could plausibly point fingers in a lot of other directions to explain their overall bad performance in that time period.

But what is the alternative? I don't think you can just give everyone the Netflix culture deck and tell them to go to town. Netflix is 3,500 employees, not 120,000. It's pretty unlikely that Netflix's solution scales to Microsoft's size.

> So you adopt some kind of policy that you believe forces your line managers to have some kind of accountability.

But, it doesn't. Actually evaluating the people within your scope of control (at a minimum direct reports) and holding them accountable for concrete, business-meaningful results does that.

Stack ranking doesn't, and moreover it transparently obviously doesn't in a way which has obvious adverse impacts on subordinate organizations which are effective, so it not only fails to establish real accountability for lower management, it sends a message to lower management that upper management is more interested in pro forma shows of "doing something" than actual concrete business results, which—aside from.the direct adverse impacts of stack ranking itself—has adverse cultural impacts on management throughout the organization.

The alternative is to find a more qualitative means of evaluating people without bringing in arbitrary concepts like "average."

Learn or learn not. There is no fail.

The main difference is how quickly the decline happens. The end result is the same.

MSFT was in the 10% camp and are still in recovery.

The later is too. Its just renaming the same method and introducing a "objective" metric that is gambled again.

What precisely do you think is obviously insane? Stack ranking as a total doctrine, or "aggressively fire low performers" as a general guideline? Do you think that Netflix's culture deck is crazy, for example?

Smaller teams may have all good people. Yet they must fire someone to meet an arbitrary metric. Its corrosive.

You can try to consider cross-team measurements, so as to fire the 'bottom 10%' across the company, perhaps preserving good teams. But how do you compare the value of an IT performer with an embedded firmware designer with an OS driver supporter with a backend schema architect? Their criticality to the company can differ wildly.

Further, after a cycle or two, teams should be stable and have suitable members. But the scythe keeps reaping, destroying what it was trying to build.

...you understand that the idea is that you hire to replace the people you fired, and that you suffer turnover as well, right?

Yes, applying a strict stack ranking mechanism to an arbitrarily small team does not have good results. Agreed. That's what I mean by saying, it has bad results as a dogmatic rule. But the goal is not to reduce your workforce by 10% every year, either.

> the idea is that you hire to replace the people you fired

And if you can't hire because of budget constraints? Or you had a 5 person team that was gelling well, but now you've tossed one to the curb and replaced them with someone new (and burdened the remaining team with the interview process in the interim).

Any "fire x percentage" mandate is going to suck when you're looking at a team of high performers. Or, the manager is just going to hire a dud for the express purpose of having someone to fire the next go around. I've seen that happen more times than I want to think about.

Of course, I didn't even mention hiring as I assume we all know its a terrible solution. Hiring is a spotty, error-prone process. Its arguably better to train who you have, than take another roll of the dice. Hiring is how you got into the situation you're in.

Ah, the "never fire anyone" approach. You can train all low performers into being excellent employees!

That is far more detached from reality than stack ranking is, and far more destructive than stack ranking is to a large organization.

Stack ranking is exactly intended to deal with the fact that hiring a spotty, error-prone process. It says, "No, you can't only hire high performers, whether by having brilliant hiring processes or by training low performers. What you need to do is fire the low performers and roll the dice again. Because eventually the dice will roll high."

No, but obviously minimize it. Don't manufacture reasons to fire, like the stacking scheme does.

Yes, it is insane. It's a pressure cooker, which induces personality traits in folks that are undesirable at best. People figure out how to game the system, squash the less assertive/aggressive/self selling types and keep fighting for another day.

Amazon has this same problem.

There's no difference between the two in regards to morale; you'll encourage gaming of metrics in either case. You shouldn't fire people simply for being lowest performer on the team because there will always be a lowest and thus someone is always in fear of being fired even though their work may be just fine. Any place that does this shit will have shit for morale. It's plain stupid.

Yes - the big killer is the "bell curve".

Once people realize that making other people look bad is in their interests the organization is doomed.

You need to get rid of poor performers but that should be based, as far as you can possibly manage it, on an objective standard.

I think you mean "a non-objective standard." The great virtue -- and great flaw -- of stack ranking is that it's very, very, very objective.

And, as people have pointed out, that means that it can be gamed, and can be applied very inflexibly an inappropriately. But the virtue is that it gives people relatively little opportunity to get out of engaging with it at all.

> I think you mean "a non-objective standard." The great virtue -- and great flaw -- of stack ranking is that it's very, very, very objective.

Stack ranking usually takes as it's key input management subjective evaluations of staff performance, which is why the subject units are usually small suborganizations. It's mechanistic in what it does with that input, but it absolutely is not usually based on purely or predominantly objective measures.

Organizations which spend the effort to develop meaningful objective performance measures usually also spend the effort to find better uses of them than inputs to rank-and-yank systems.

Keeping low performers around isn't great for morale either. Watching parts of your product go down in flames because someone had no idea what they were doing, and then having to do 10x the work to clean it up and do damage control with customers.

A team of excellent people will still have someone at the bottom of productivity on that team; that doesn't make them a low performer. I think you're confusing poor performance with ranking. If you have 10 awesome developers, are you going to fire the 10th best just because he's the 10th? That's what's being discussed, firing the bottom guy without regard to whether he's actually good or bad, merely because he's the bottom guy.

There is clearly a minimum size beyond which it becomes highly dubious to assume that, in this group, the worst 10% are bad performers. Like, if it's a 10 person group, it's not particularly hard to select a 10 person group where the worst person is pretty good.

And this is where "dogmatic use of a rule instead of a guideline" comes in. Stack ranking down to the level of every team has bad results.

But it is equally true that in a large organization (and the only places that would even consider stack ranking have hundreds or thousands or tens of thousands of employees, not 10), you just don't have nobody but high performers. It's not possible.

I've discussed stack ranking before on HN, and I feel like there are a lot of people here who want to believe that you never need to terminate anyone. That's not true.

There also seem to be a lot of people here who believe that the fundamental failure mode of most organizations is being overly quick to fire. That's also not true -- though there are exceptions.

You have to understand that firing an employee is extremely stressful for most managers. So much so that lots of managers will very willingly live with a terrible performer who's a huge drag on their team rather than terminate that employee. And so we get management doctrines that are aimed at forcing managers to actually terminate their problem employees.

I'm not a fan of stack ranking, though I've also never worked at an extremely large organization. But it's not a fiendish plan created by mustache-twirling villains in order to cause people pain for sheer sadism. It's a deeply imperfect practice that should be looked at with a clear understanding of what motivates it. Dismissing it as sociopathy speaks a lot more to the commenter than the practice.

> But it is equally true that in a large organization (and the only places that would even consider stack ranking have hundreds or thousands or tens of thousands of employees, not 10), you just don't have nobody but high performers.

But even in those organizations, the "stack" doesn't consist of thousands of employees, as the unit on which stack ranking is done is lower-level units (often very low-level), not the whole organization.

You read the several times in which I said, "Don't apply stack ranking to small teams"? Do you think you're arguing with me?

I'm pointing out that your defense of stack ranking in large organizations ignores the manner in which stack ranking is actually applied, even in lagrrge organizations (and there is a reason it's not done across broader groups, too; because large organizations that have good enough objective performance metrics to apply consistently organization-wide have better methods of applying them to make decisions than using them as inputs into stack ranking.)

So, what, you're opposed to people talking about how they think large organizations should work instead of how they actually work? There are about two dozen people in this thread that you should be directing your comments to.

But also: If we're talking about an organization where it is impossible for a manager of, say, a 100-200 person department to figure out who the 10-20 worst people are across his entire department -- where he's helpless and just has to say, "Well, I don't know, I'll punt down to my lower-level managers," that's prima facia evidence of a dysfunctional org. What is the doctrine that you feel is going to lead to better termination decisions in that org?

> So, what, you're opposed to people talking about how they think large organizations should work instead of how they actually work?

Stack ranking is based on forced rankings of employees by managers who are familiar enough with them to theoretically be able to provide an ordinal rank of their performance. There is no way this works in large groups, it only works in small subunits.

If you have actual objective measures of business-meaningful performance, you have to throw away a lot of the meaningful data to reduce it to a ordinal ranking and use it for stack ranking, which is why organizations that do have such measures use them for more useful accountability than is provided by stack ranking.

It still seems bad to me. Lets suppose your hiring process is fantastic, and there is an unlimited pool of high quality candidates. Every time you fire a below-10% person, you hire someone who is better than everyone else on the team. In that situation, you've designed a company where EVERY employee has been with the company for less than 10 years.

Your stipulations are not based in how the world really works, especially for large organizations. Nobody has a fantastic hiring process and an unlimited pool of high quality candidates.

But in that fantasy situation, you've designed a company where everyone is with the company for 10 years (unless they voluntarily leave), and where your overall quality level is amazing and always increasing. It sounds like there are worse problems in the world.

Firing the lowest 10% isn't as obviously insane, but it's still insane, at least as an ongoing policy.

You probably won't have any left because the above average ones will start to feel insecure.

My programmers? Who the fuck do you think that you are? These are human beings; you, not so much.

I actually saw someone advertise looking for "code monkeys". Needless to say, they still don't have any programmers.

Who are you responding to? The author of the Quora post? I know it probably took a long time to craft your argument, but you might want to read the post. He is not advocating this.

As for "my programmers", this is a shorthand and maybe not worth losing your cool about. I refer to Australia as "my country" without implying that I own Australia and "my company" without implying that I own Intel.

I was responding to this kind of reasoning even being on the radar; the caption was enough to make me feel sick, didn't feel the need to go further. More like a Freudian slip in my ears, referring to specific human beings makes all the difference. Skimming the article proves my point, all about numbers with barely a mention of humans.

"In addition, there are people out there who are constant scaffolding to everyone else."

I assume the use of 'scaffolding' here, means an average programmer who through personal skills, raises the performance of the whole team.

I think I read that at Microsoft (when they had stack ranking), high performers would avoid being on the same team with other higher performers because someone always had to be ranked at the bottom - even in a team of exclusively high performers.

One thing which really worked well for me is to fire engineers who do not grow. It is true that "growth" is really hard to measure but that is point of being a good and smart manager.

I was at a start-up that did this, and then expected the remaining developers to then keep the original workload with added responsibilities.

I would agree.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact