What happens over time if each year I fire all my below average programmers?
quora.com
quora.com
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.
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.
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.
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.
Why is this approach so rare? What's the downside?
It needs a competent and hard working manager who also has time to do it.
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.
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.
This is what they pay people to say on websites like Hackernews/Reddit, etc so that people like you and I start repeating it.
* 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.
* Rampant spying in Microsoft's products is at an all time high.
And it's not going anywhere.
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...
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.
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.
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 :)
Good point, though.
>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.
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.
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).
Whatever you choose, it stops being an effective metric the moment you begin to use it to gauge performance.
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.
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.
I wish I had made it up to tweak your nightmare but it is reality at quite a few sucky companies.
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.
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.
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.
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.
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?
if you are a significantly stronger programmer than they are AND 'some' time is 'alot' of time.
This is a pretty good Quora answer, all things considered.
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.
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
And I'd stay for my own reasons, until not.
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 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?
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".
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.
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 people when they don't meet expectations is fine, but 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.
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.
Learn or learn not. There is no fail.
MSFT was in the 10% camp and are still in recovery.
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.
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.
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.
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."
Amazon has this same problem.
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.
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.
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.
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 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.
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?
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.
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.
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.
* 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.
I assume the use of 'scaffolding' here, means an average programmer who through personal skills, raises the performance of the whole team.