Valve Employee Handbook
cdn.flamehaus.com
cdn.flamehaus.com
As Gore grew, it was apparent that this structure did not work with more than a couple of hundred people. So now, teams are limited to about 200 people (approximately Dunbar's number). I imagine Valve will run into this social limit as well once they grow well beyond their current 260 employees.
Given that Gore still exists, has 9000 employees and is profitable after 60 years is testament that such a structure can work for small as well as larger organisations over a longer period of time.
I first learned about this organisational structure in Malcolm Gladwell's book The Tipping Point. There are multiple descriptions online, here's one that seems interesting: http://ecgi.ssrn.com/delivery.php?ID=61902009302412510712411...
The interview process was amazing, took 6 hours at a white board, multiple teams drilled me on all the various languages I claimed to know and then some business teams grilled me on my thoughts about the industry.
The passionate side of me really wanted to work for them but the pragmatic side of me made it clear I would have to work for considerably less than I was making open market. To make things worse my next position literally was almost double the salary Valve offered me.
I was just last night joking with my wife that when I want to settle down maybe I should try and go back through the process with the understanding it will most likely be 1/3 of my current salary.
I love working in my passion but as I always tell people the people at the grocery store still want me to pay for my food.
I try to balance passion and pragmatism and if I need some crazy passionate project I take on a side project on the weekends for some open source project etc.
I will passionately bust my ass for 12 hour days if I'm paid properly.
It's less about greed and more about not being taken advantage of while someone else gets rich off of your back.
Like anything, there's a reasonable-middle as to the salary requirements for an individual.
Startups are exciting and fun, but their success is gauged by a single metric - money. When startups get acquired there are endless congratulations on this very site. And rightly so, the owners should be rewarded for their work.
In the end I guess you're right. I don't belong at a startup as an employee making 1/2 my salary. I either need adequate pay and/or an equity stake to work at one.
My biggest flaw is I'm not a 501 programmer and I will accidentally choose an opportunity that lights my passion but doesn't pay my bills. I've done that in the past and to be clear it was very painful and soul crushing and something I do not want to repeat again in my life.
I know more than most people that more money will not make you happy.. I've been in tech for 30 years and I've had all sorts of levels of compensation, failures and successes. Always the differentiators have been: The people I work with, the passion I feel for the problems we are trying to solve and the acknowledgment I get for my contribution.
Money is just a version of acknowledgement but clearly not the most soul fulfilling type. The respect of my peers and the opportunity to learn and work on solving big problems are much more rewarding. But to do all those things I need to pay my bills and put some away for my later years when I wont have the same earning power.
Income Equality at work.
To be fair, you do seem like a talented person and I'm sure you are excelling at your current and past positions, but maybe you just aren't a good fit for Valve since they don't need more SVP level decision makers.
What you're saying and what Valve says are two very different things. The handbok didn't just gloss over the compensation bit - they go into detail about proper compensation due to contributed value etc.
Edit: Just looked at your linkedin. You sure do have an interesting combination of skills.
Then again, I'm a programmer. They seem very intent on collecting the absolute top of the market for game programming talent. For the record, I love Valve but am happy in LA.
But now I wonder how they decide what to offer new hires, based on this process.
"[Team leads are] keeping the whole project in their head at once so that people can use them as a resource to check decisions against"
There are more than a few things in here which, if true, turn common ideas about management on their head (or rather just shoot them in the head). What's exciting is that they reflect how work actually gets done. Shouldn't that be our organizing principle?
I think what makes startups so effective is that they naturally work this way at first. But then, typically, bad ideas about how one is supposed to "manage" and "scale" kick in and stifle the thing. This document is interesting as a conscious strategy for not being stifled. Valve's success lends it credibility, and the fact that Valve is not a startup makes it more interesting, not less, because it's so unusual.
With this and the recent Michael Abrash blog post, I get the feeling that Valve is putting a bit more attention into making themselves attractive to developers. Frankly, I think it's working.
They liked my game ideas in my blog (I even predicted Steam's Big Picture mode) and I got a call from Greg Coomer, but ultimately I never got an interview because I didn't have the experience and hadn't shipped any real profitable products. It was a really nice reality check though. It made me realize where I am in life and where I need to go. So thank you Greg.
Also, they play the "Portal - Still Alive" song when you're on hold.
As they mentioned in the handbook, Value's revenue per employee is the highest in the world.
Source: http://www.forbes.com/forbes/2011/0228/technology-gabe-newel...
Originally uploaded to http://cdn.flamehaus.com/Valve_Handbook_LowRes.pdf Handbook courtesy of Valve
So, they shared it on purpose and are not trying to disguise it as a "leak".
Most egregious example of double-speak ever?
Also, being evaluated by what you deliver and by your peers isn't too bad, considering the alternative is possibly a non technical boss that may never understand what you do.
I try to work with co-workers as if they were friendly clients. I think this leads to good product launches and results.
This is double speak because it is saying one thing explicitly and exactly the opposite meaning is implied.
In other words - we are all equal (there is no hierarchy), but some are more equal than others (there is a hierarchy) - if you get what I'm saying.
In my experience it's really difficult to use material from Github or 37signals, for example, to start a constructive conversation on work practicess at your own company. Half of the team might dismiss it as a self-promotional, patronizing PR fluff piece, while the other half might gobble it up and fail to rationally weigh the pros and cons. And everyone gets this vague unpleasant feeling of being told that they're inadequate - like a 15-year old girl watching a weight watcher commercial.
The "we have no structure" culture is disingenuous. I don't buy the idea that most of the employees at valve don't want to dominate all the projects and their coworkers. It is exactly the same anywhere. You can't simply say 'we don't have managers' as obviously only certain people are going to have power of budget and final hiring decision. Only certain people can sign documents. Only when employees can expense anything they want and hire anyone they feel should be hired would a "no managers" description be appropriate. You might say that this would never work, but it does work if each employee is given assistance or investment to spin off a new organization at any time, hire anyone, and spend money.
Now, this might surprise you, but working on cool projects can be its own reward. Your utility metric is flawed.
"I don't buy the idea that most of the employees at valve don't want to dominate all the projects and their coworkers. It is exactly the same anywhere."
Did you perchance get your worldview from anime? Really? This might also surprise you, but a lot of well-functioning folks don't care about petty politics as much as doing cool stuff.
Everyone is entitled to their opinions. My opinion is people that say they don't care about monetary rewards are bullshitters. After all, if you have enough money you can work on any project you want.
"a lot of well-functioning folks don't care about petty politics as much as doing cool stuff."
A lot of people SAY all they care about is doing cool stuff. People employed at a company to earn money are not these people (but they see if people will buy it anyways). Denying that you're playing politics is politics 101.
Well, not Half-Life 3. To do that, you have to take a job at Valve.
I'm pretty sure I don't want to dominate my coworkers, so I find it easy to believe there are others who don't want that either. In fact, a coworker who wanted to dominate me would be a highly unpleasant coworker.
"Co-" means "together". There are other forms of human relationship besides master/slave.
Anecdotally, I dislike telling people under me what to do, let alone "dominating" them. I much prefer working with people who are self-directed individual contributors. I would not want to hire anyone that I thought matched your description, and if I found out that they did, I would fire them when I saw any clear evidence of it.
Fishbowl— The conference room by the lunchroom. The one with a bigglass wall. Don’t let the name throw you—we don’t actually use it as a fishbowl! Except, of course, on Fishbowl Fridays, where we fill it up with tenthousand gallons of putrid saltwater so that all the manta rays and sharks will have something to breathe while they fight to the death. You won’t seeit in your list of benefits, not because it isn’t fun, but because it is illegal.
In general this sounds like the natural structure for pack animals, where you join a pack and no one anoints a power structure, but it becomes clear very quickly who is "alpha", "beta", etc. IMHO it sounds like it possibly could be a very stressful situation.
I suspect it doesn't work perfectly, but what does?
How well does it reflect what actually goes on at Valve?
Darn good question.
I'm having a hard time picturing how this would work for accounting or systems administration.
People tend to lower themselves to the preconceptions others have of them. It can be very convincing.
Point taken.
So .. I thought about it. If Valve were to hire me [1] I can see myself attaching to the systems admin role and liking it a great deal. It's what I do, what I like.
I do wonder how they make it happen for back office jobs that are not glamorous or especially fun but absolutely must happen.
[1] Hey, Valve. I'm not currently in the market, but I am a damn fine systems administrator. Drop me a line if you're interested.
"Whatever group you’re in, whether you’re building Steam servers, translating support articles, or making the tenthousandth hat for Team Fortress 2, this applies to you."
I suspect much of it is done by those of sub-employee status. But that's just a guess. Perhaps someone who actually knows will fill us in.
Is there a pattern about theese things, and what way of managing a software company works best?
EDIT: Also, Half-Life is the best game ever.
You can move around as you wish if you're a Real Googler. The Real Googler Line used to be Senior SWE; now it's somewhere between Senior and Staff. Staff are Real Googlers, and Seniors who are likely to make Staff are Real Googlers, but Seniors who are perceived as having plateaued are not.
If you're not a Real Googler, 20%T will be perceived as slacking off, and you're going to have a hard fight to get a transfer. Generally, it's hard to transfer unless you've had a recent promotion, so if you're not going to get promoted based on your current project, you might as well leave.
Why do tech companies think that hitting a plateau is a bad thing? Someone who's not going to further advance and who is productive and happy should be allowed to remain happily churning stuff out, with no pressure to hit the next ranking, or be ousted, or be unable to move.
(I've seen some demotions at my company, which was basically recognition that "Okay, we want to keep you, and in the past we had to promote you to do that because of the fucked-up stuff that HR was forcing us to do. Here, have a lower position, and you get to keep your salary.")
In a company with 30,000 employees, some people are going to be unhappy. But the vast majority of people I interact with at Google are very happy. The biggest problem I face is the five minute wait for someone to make me a latte.
I think Google made several mistakes. First, the language issue. C++ is undoubtedly the right language for some of the work, but their language policy leaves a lot to be desired. A lot of systems that should be in a language like Scala or Python are in languages like C++ or Java. The problem isn't "bad languages", because C++ is not always bad; it's a very small language whitelist and an arrogant dismissal of "Other Languages" that goes up to the top. By the way, Python is nearly deprecated in production. It's used for some projects (such as Google's code review system) but generally the only people using Python for their day job are managers who still code, and then if their ideas take off they make other people implement them in C++. In reality, Google's mainly a C++/Java shop, with Java tolerated in the context of acquisitions.
A limited language white-list, coupled with a willingness to produce huge programs without modularity (Google's codebase is one monolith) produces something like this: http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol... . This wasn't written about Google, and it's probably much less true of Google than of typical enterprise Java shops, but Google's not immune to the illnesses of the large-program mentality.
Ok, this sounds a bit like a religious war, but I think it's generally true that shops using Java and C++ for almost all of their development will very quickly get past the point where one person can have an independent impact-- especially on a 20% basis-- unless that person has above-normal political favor and can always end up on the right projects. Hence, politics. That said, Google was always a C++ shop at heart, and it didn't go to crap until late in its trajectory, so there has to be a lot more to the story. You can't really blame this on languages, or the culture would never have been good.
What I've heard is that the real change came in 2006-9, which is when Google hired a lot of executives from companies like Intel and Oracle, and they tracked a lot of shitty culture into the place. For example, "OKR" is an Intelism. This explanation sounds very plausible. What I was able to see, even in the short amount of time that I was there, was a top-down effort to concentrate power back in the hands of executives, at the expense of engineers. This would have been a creeping campaign, but Google+ turned it into a war.
The language issue was a "tyranny of past success" mistake. In 1998, using C++ for a high-performance service was the absolute right choice. In 2012, C++ still has a place but most new development should be in a language like Scala or Clojure.
The bigger mistake Google made was that it hired a bunch of executives from other companies and didn't tell them to wipe their feet off. So they polluted the place with horrible culture.
Finally, Google+. I don't want to get into too much detail there, but I'll mention that 90+ percent of engineers hate, if not the Real Names policy, the draconian enforcement of it. I don't think RN itself is the source of all the anger-- for some it is, but a lot who are on the bandwagon are mad about other things. I think it's a touch-point for a general sense of engineer disempowerment.
That said, Google is a huge company. If you end up on the right project, it's a really great place to be. I know people who've been there for 5+ years and couldn't be happier there, and there are a lot of cool projects the company is doing (although most of the good work is in MTV; I'd avoid applying to any other office). It has a lot to do with where you land and what alliances you're able to make in order to get the things you need.
Maybe a nuclear power station, as we currently design them, requires very rigid procedures. But that probably also reduces internal information flow, punishes people for noticing problems, and so on. So perhaps that's really an argument against nuclear power as we know it.
McDonald's isn't designed the way it is because people are stupid. It's designed to maximize returns on capital investment. Workers are made to be interchangeable, and the product is uniform and predictable. For 300,000 years, humans self-organized to take down caribou or whatever to make our own dinner. Is it really likely that we need a system like McDonald's to get a burger made?
It's not about getting any burger made, it's about getting a McDonald's burger made.
I make a pretty fine burger, myself. And my own bread, for the buns.
But if you want to deliver a consistent product across thousands of stores for a reasonable price, you need standards, managers, guys behind the counter performing to task and standard. So you can walk into a restaurant in Bangor or in Spokane and know what you're getting.
Yet .... I can't deliver a home-cooked burger without the same structure McDonald's uses.
I get my meat from a butcher who gets it from some other guy and so on on back to Bossie in the pasture. That's one thing out of hundreds of bits that make up daily life.
We all of us depend on millions of others doing things to task and standard just to exist - it's baked into the bones of our society.
I don't think you can just get rid of it without building a system to take it's place.
See also Marshall Brain 'Manna'.
Conceivably, yes.
But I don't see it, or not real soon. Automation even in a controlled environment is tricky, and random customers are _random_. You have people there to handle exceptions, which are many.
My knowledge of it is purely based on <a href="http://www.amazon.com/Joy-At-Work-Revolutionary-Approach/dp/... book</a>, which was written by a co-founder who was later deposed. (The book goes into that story but tldr is company prospers, economic crisis hits, company suffers along with all other energy companies, CEO is blamed, fired and replaced with more conventional executive.)
But to give you a sense of core techniques, IIRC pretty much all staff - incl power plant maintenance staff - had major expenditure authority but before they could make any major decision they had to consult with at least two other employees. As long as they could demonstrate that they had done that, it was assumed that they had made a reasonable decision.
First, it makes people hate each other. Anyone who comes up in the bottom half is going to be looking immediately to move to another group simply because he ended up in the bottom half. And if someone ends up near the bottom and ends up with no bonus or on a PIP, he's going to be spending the next few months trying to figure out who screwed him, which creates this whole side game that has nothing to do with actual work.
Second, it encourages people to work on the projects that are most visible, which are not always the most valuable.
Third, it creates a general atmosphere of distrust. People are constantly watching their back for others who might screw them in the peer review process.
This is an outsider's view and a microgripe, and I think a lot of the ideas in that book are good ones. I just saw the words "stack ranking" and knew I had to speak up. It's seriously not a good idea. If someone's going to get whacked, it should happen for a real reason, and not because that person ended up in the bottom 15% because only a couple people knew what he was working on. Maybe he was working on something important but unglamorous. I've seen that kind of shit happen all the time with stack-ranking systems.
Managers get a bad rap, but good managers (possibly 10-20%) are worth their weight in gold. Bad managers are disastrous. No managers is rarely an option. "Flat" organizations tend to devolve into young-wolf conflicts and evolve their own unofficial hierarchies. In fact, young wolves are more dangerous than managers; because young wolves' positions of influence are unofficial and therefore unsafe, those around them are direct competitors and they have more incentive to attack. Managers rarely sabotage their own reports, because they have the safety of being a level or two higher. Young wolves frequently do this to people who are technically same-level but haven't been around as long or had as much of an opportunity to establish themselves, but whom they perceive as long-term threats. If nothing else, you need good managers in place to prevent young-wolf conflicts.
The problem with traditional management, though, is that people promotions are pull-based (i.e. people get promoted by conning the top guys) rather than push-driven from below. The result is that people get promoted based on social climbing rather than real leadership, and managerial incompetence sets in very quickly.
I'd get rid of "performance" reviews. The word is loaded, and most workplace conflicts have nothing to do with performance. I've worked in elite companies, so this observation may be unusual, but I've seen maybe 20 people get fired in my career, and only one was for performance. The others were personality conflicts or other reasons. Dressing these issues up as "performance" issues just makes everyone angry.
Instead of reviewing "performance", which is code for "dressing up how I like you as something more objective", there should be a review along two axes: Skill and Impact, which are much more objective. I came up with a half-decent (IMO) scale for assessing software engineering skill here: http://michaelochurch.wordpress.com/2012/01/26/the-trajector... . The difference between 1.5 and 1.6 may be hard to assess, but that between a 1.5 and 1.8 is pretty much objectively visible.
Here's the kicker: these numbers are public. It shouldn't be "sensitive". Management ought to have the balls to say, "we think this person has Skill 1.7 and Impact 1.8 and here's why." What is kept private are reviews more than 12 months old, so that peoples' trends aren't visible for everyone to see. The other thing that deserves to be private (because it is somewhat sensitive) is assessment of a person's potential, but that's not what formal reviews are for. That should be handled informally, in any case.
Ok, now as for how the reviews occur... as I said, the problem with traditional management is that selection occurs on a "pull" rather than "push" basis. So instead of people having "managers", they choose sponsors who are typically more senior (although at the very top levels where "more senior" is hard to find, peers will do). Sponsors keep track of their reports' growth and advocate for them during the review process. The difference is that a sponsor relationship can be terminated at any time, by either side, without requiring anyone to exit the company, and that an employee can (and should) have 2-3 sponsors.
This system allows people to "vote with their feet". If someone's not a good sponsor, people move away from him.
What happens if someone has no sponsor? If you have no sponsor, you go before upper management yourself during review time. You advocate for yourself. If you can effectively communicate what you have done and what you will do, then you may advance. If you can't, you'll stagnate. (The purpose of the sponsor is to be an intermediate advocate with a better understanding of what the company and its management value, but there's no reason a person can't be allowed to advocate for himself.) Of course, if someone can't get a sponsor for a period of months, that's a sign that this person might need to leave.
Is that a young wolf, a social climber or a sponsor?
The key to any of this "flat organization" stuff is to keep the organization small enough that you can either keep out nasty personalities, or prevent them from burrowing into the org.
A true peer-to-peer system of n people has a communications graph which is a K_n (complete graph on n nodes). Each node must monitor communications from n people, and there are O(n^2) edges. That can't scale. But for small n it isn't bad - the distance between two nodes is 1.
A tree has n-1 edges, and most nodes only need to communicate with 3 other nodes. The distance between 2 nodes is log(n) so communication costs aren't disastrous.
We love trees in computer science, the only reason we don't love them in management is because our personal experience leads us to compare O(1) communication costs (in a K_n) with log(n) communication costs (in a tree).
Sort of the way torrents work, in fact: there's a pool of seeds and peers - which might have thousands of members - but your client is only exchanging data with maybe a few dozen at any given time. But since each peer has its own slightly different set of connections, data anywhere in the system can still propagate to the entire system.
I suppose it would be an interesting problem to figure out, given n nodes, with each node having a minimum of x and a maximum of y edges per node, and a maximum of z edges per path, what the minumum total set of edges would be to ensure that there exists a path between any two nodes.
I think a flat hierarchy necessitates 'adhocracy', but from a cultural and operational standpoint, I'd expect them to mutually reinforce each other quite well.
As a more traditional manager, I have to consider salary adjustments for my employees. What Valve seems to be doing is to let everyone consider salary adjustments for (half) of the team.
And since the rankings appear to be averaged out, one vindictive co-worker isn't likely to screw you over.
>it creates a general atmosphere of distrust.
Alternately, it creates a culture of responsibility. You want to do well in stack-ranking, so you're going to do your best work.
Finally, 50% of any group are below average. I honestly wouldn't mind being considered "the dumbest guy in the room" if I got to work at a dream company. See the following quote from Moby Dick:
>And there is a Catskill eagle in some souls that can alike dive down into the blackest gorges, and soar out of them again and become invisible in the sunny spaces. And even if he for ever flies within the gorge, that gorge is in the mountains; so that even in his lowest swoop the mountain eagle is still higher than other birds upon the plain, even though they soar.
The only large (200+) private-sector company where I've worked is Google, where their stack-ranking/Perf system had some serious problems.
The first was a 5% cut-line. If you were in the bottom 5% of the Perf stack, you ended up on a PIP. Who usually ends up here? Some were objective underperformers, who'd been coasting for years, in some cases running at less than 1 CL per month. Most, on the other hand, were junior people on underperforming teams-- and of course, those junior people had the least to do with that team's underperformance, but they were poorly established so they got the shaft. That's how most layoffs actually work: junior people who landed on the least effective teams. It's not atypical, but it's dysfunctional.
By the way, PIPs have nothing to do with "improving performance". They exist to make it easy to fire people without severance. I actually think PIPs are imbecilic, because I'd rather cut a 3-month severance check and separate cleanly than keep a fired employee in the office for 1 month, but that's another rant. PIPs make the finance department happy (look at what we saved on severance payments!) but piss all over morale and make the manager's life hell, to say nothing about what they do for the PIP'd employee.
At Google, a PIP is effectively permanent. Even if you pass the PIP, you become damaged goods and can't transfer. It sticks around on your permanent record until you leave.
Which brings discussion to the second problem with Google's system. It sticks around forever.
When these types of systems get rotten is when they start getting in the way of peoples' transfers. It means that the people who really should be moving to other projects can't get on to them because no one wants to take a chance on that guy who was an "objective underperformer" in Q4 2005.
So, to come around to your point, I agree that if the rankings are only used to adjust pay, there's not much harm done. Unfortunately, it's rare that data collected is only used for the stated purpose. If these numbers start damaging peoples' ability to choose their own projects, it can become nasty quickly.
Is there actually some relation between your story and Valve?
I think the "wither away" bit is probably actually the truth. Let's say you're consistently ranked in the bottom and stick to projects that don't add value to the company. Since stack-ranking determines compensation, someone who costs the company money probably gets salary decreases. After a while, an underperforming worker could make more money in a different company, and they take the hint.
Of course, since Valve is dedicated to hiring the right people, they probably don't hire too many duds. Talented people who just don't fit in probably just update their resume and go somewhere else.
This discussion is the HN equivalent of the prospective employee/er who pays lip service to "culture" but is really only interested in salary.
(1 local WIP commit per month really would be slacking off!)
People that only write one CL a month have probably written a fairly large amount of code, but are being blocked on reviews. When I see a review for more than 100 lines of code, I immediately think, "I'll do this later" or "Oh good, I'm only CC'd on this review; ignore." If the person doesn't have anything else to work on, this blocks him until I feel like diving into 1000 lines of code I've never seen before. Conversely, if I got one 30 line CL every day for a month, I would probably immediately review each, turning the one-CL-a-month guy into a 30-CLs-a-month guy with the same amount of code.
(Also, you just made CLs sound like yet another metric that can be gamed by the appropriately cynical employee. Ouch.)
That said I do vastly prefer smaller CLs because the review process goes so much better.
That was not my experience at Google. Not all people turn to hate when learning how they are valued by others. There's certainly disappointment.
it encourages people to work on the projects that are most visible, which are not always the most valuable.
Some types of work at Google are undervalued, but it's not related to visibility.
Third, it creates a general atmosphere of distrust.
I think it creates a more pleasant atmosphere. People learn that being an asshole can hurt come review time.
Honestly, I don't know why his comments always seems to get voted up. I assume they're voted up by people who have not read the previous exact-same rants...
[1]: http://news.ycombinator.com/item?id=3790656 [2]: http://news.ycombinator.com/item?id=3784685 [3]: http://news.ycombinator.com/item?id=3702761
The only way to really refute what mchurch says is to post evidence of his work from when he was at Google, but that's a massive violation of his privacy, so nobody is going to do that. The only thing to do is dismiss his argument with vague statements like, "no, that's not true", which nobody is going to believe when compared to his well-written rants.
If you want to know the full mchurch story, I suggest you get a job at Google. Then you will have enough information to decide whether or not mchurch's rants about Google make sense.
C.f. "Why are manholes round?"
http://www.amazon.com/Would-Move-Mount-Microsofts-Puzzle/dp/...
Not necessarily, but 50% are below the median.
Yes, language is ambiguous. However, people arguing over the clarity of the above statement is just nerdy pedantry.
Not necessarily. The numbers could all be the same.
For example when I worked at BT the PRP was done - then to make the figures work out with the the increase in pay quanta - the figures where fiddled in secret meetings.
It also leads to people playing the game - for example to help with passing his board one of my colleges at BT made that his goal and play'd the game - but as my boss ruefully commented "he hasn't done any real work for 6 months".
I have also heard of mangers having quotas of people to give bad apr's to to force them out - one rather grim story from a friend who commented "well our unit has 2 people with terminal cancer so they where put down as cat 4's"
The problem is that stack ranking on an individual level puts the employee focus on themselves instead of the team and the company. All employees should be focused on doing what's best for the company as a whole and not what's best for themselves. Stack ranking sets up the exact opposite situation.
If there are poor employees on the team then speak with them, put them on corrective action, etc... If you already have a team of great performers, ranking them will only work to align their goals differently from the company and that can lead to all sorts of problems.
Objective, across-the-board incompetents are very rare. Generally, companies that are well run are going to have very few people (at lower levels) who actually should be fired. Oddly, the levels at which firing 10-30% of people make sense are the managerial levels where people almost never get fired (and if they do, they get huge severance packages that include outplacement assistance).
Most hiring mistakes are bad matching, not bad hiring. The right person was brought on and put in the wrong place. So the correct solution is to pivot: help the person find a transfer to a more appropriate team.
In very small companies, this may not be an option. If there's only 1 project, and you hire someone who's a bad fit for it, you have to fire him, because there's nowhere else to put him. But companies at that size generally don't have HR departments or company-wide stack-ranking.
Maybe at google. But objectively bad hires are not uncommon in general.
I've met 5 times as many unethical people as incapable people. Easily. The unethical people should be fired once found out, but that's a given. The problem is that unethical people are usually impossible to spot until after they've screwed you.
Then again, we are probably talking about programmers/devs in this thread, who are used to being commoditized. That is not a good thing.
This sounds a lot like stack ranking except it was top down. This was, by far, the best system I have ever seen for handling a difficult and often unpleasant process, and I think making it work across levels versus top down would only improve it. Incidentally, I only found out about this process once I made manager -- but I had consistently been in the top band for my entire time at AC despite having a senior colleague trying to screw me.