There are a lot of good ideas in here, but stack-ranking is a terrible one.
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.
As long as stack-ranking is only done to adjust compensation, I don't really see the problem.
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.
A lot of people interpret average as meaning "mean". Really average is a stupid ambiguous word that should never be used. Be clear: say mean or median, but never average.
If it's only used for compensation, I agree that it's not such a big deal. Getting a 10% year-end bonus instead of 20% is not exactly "getting screwed".
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.
I suspect that people are interested in an article about Valve's culture not (just) because they'd want to work at Valve, but also to take its good ideas and use them elsewhere. I think talking about how one of those ideas worked well or poorly at another company fits perfectly with this discussion.
It seems foolish to "take" one small part of the thing and try to "use" it elsewhere, while ignoring the massive difference that dwarfs all the others: workers managing themselves. That's what's important and new here, and that, supported by the fact that Valve has been so profitable, is what we ought to be talking about.
This discussion is the HN equivalent of the prospective employee/er who pays lip service to "culture" but is really only interested in salary.
I don't understand how Valve could implement a PIP. How do they even fire people? Is it just your team shuns you and then you end up with nothing to do, so if you don't figure out something yourself, you wither away and are culled by the wolves/robots?
>Is it just your team shuns you and then you end up with nothing to do
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.
To quote Valve's handbook: "This is one downside of
the organic design of the company—a poor hiring decision
can cause lots of damage, and can sometimes go unchecked
for too long. Ultimately, people who cause damage always
get weeded out, but the harm they do can still be significant."
Thanks. Presumably if we're talking about 1 CL / month this is more like a feature checkin to the release branch, rather than individual working commits given the context?
(1 local WIP commit per month really would be slacking off!)
CLs become one perforce commit, but their lifetime is more like a git branch. I try to keep CLs under 100 delta lines. (In contrast, I try to keep git commits around 10 delta lines.)
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.
I haven't heard anyone besides mchurch cite number of CLs as a productivity measure. Lines of code sometimes, but not CLs. Sometimes it's just not worth it to break a large, cross-cutting change up into small chunks.
That said I do vastly prefer smaller CLs because the review process goes so much better.
Wow, I'm surprised that google would work like that. Did they actually tell you that you'd get fired if you were in the bottom 5%? I assume you must have been there back in 2005/ 2006 to have seen someone who was an objective underperformer in Q4 2005 but was still allowed to work there. Maybe things have changed since then?
As with all mchurch comments, you need to take it with a grain of salt. He was with Google for less than a year and has been extrapolating his short experience into a generalization of the company.
I think the problem is he comes here every couple of weeks and writes almost the exact same rant [1][2][3]. People are tired of point-by-point responses because they know he'll just be back a couple of weeks later and write the exact same thing again.
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...
His comments get upvoted because many readers of HN are looking to hate Google for some reason, and he writes a verbose "damning" description of Google's internal politics that makes Google seem very hate-able. Good writing + what you want to hear = instant upvote.
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.
I don't think people want to hate Google; I just think they're attracted by the controversy. It's like the faster-than-light neutrinos. People weren't interested because they hate Einstein, but because it's some apparently new information that contradicts what they previously thought to be true.
I'm interested simply because Google seems highly influential in the new-school tech sector management. These collections of anecdotes feed into the folklore wisdom held by managers.
As someone who started at the same time as mchurch, and observed what happened on the google-internal mailing lists, the full story probably shouldn't be shared online without his consent.
The problem with stack ranking and PRP is that its subject to capture by groups with in a company that will manipulate it for their own ends - which end up being counter to the longer term aims of the company and share holders - the HR director gets a bonus for managing the pay quanta down but the company loses 10x performers.
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"
Stack ranking comes out of a couple ideas. One is that it's important to always be bringing on new people with a fresh perspective. If no one is leaving the company it's hard to do that effectively, although normal attrition can usually take care of this. Two, it's management admitting that they have hired the wrong people at some point and have dead weight. Of course management never wants to say they screwed up, but if every hire was a perfect hire then there were be little reason to try and remove people.
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.
To be fair to Valve, it sounds like you're talking about rank-and-yank, which is not necessarily the same thing as stack-ranking. I made the same mistake in my response: assuming that stack-ranking meant that those who come up in the bottom get PIP'd or fired. That's not strictly true. However, most stack-ranking systems end up as de facto rank-and-yank.
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.
> 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.
Maybe at google. But objectively bad hires are not uncommon in general.
In "objectively bad", I'm talking about competence.
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.
Well, I don't think hierarchy is prima facie evil. Conceptual hierarchy is how people think. The problem with human organizations (and "managers" and the bad rap they get) is that hierarchies are easy to corrupt by aiming at the top, and that they usually promote the wrong people-- social climbers instead of leaders.
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.
It's also worth noting that heirarchy, at least in principle, is a very efficient method of communication.
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).
Peer-to-peer is only O(n^2) if every node is always connected to every other node. But Valve's organization seems to work by creating much smaller sub-networks on an ad-hoc basis, so that at any given instant, each node is only actually connected to a small set of other nodes. Instead of a hierarchical system which would have each sub-network be permanently defined with clear boundaries, and create a network-of-networks to coordinate them, this method ensures coordination among the sub-networks by relying on most nodes being a part of multiple sub-networks and having a slightly different set of connections, such that there's an overall mesh that does actually connect every node in the graph, directly or indirectly.
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.
There are efficient network structures that are not hierarchical and are not trees. Trees have horrible single point of failure characteristics, where one bad node kills an entire branch.
To be fair, they also have the opposite quality wherein one great person can positively affect an entire tree. Many great companies have been built by a great leader positively affecting hundreds or thousands of people.
Does a young wolf always create conflict? For example, it is possible to avoid conflict and form a lot of influence by playing kingmaker. You do not need to sabotage others of similar technical abilities to you by attacking them directly, you can instead heavily exert yourself in producing massive value to their competitors. This is more stable as it's without conflict. It is the silent death to those that compete with you individually, and a way of finding allies.
Is that a young wolf, a social climber or a sponsor?
That's the way that things work in many political organizations like party committees.If you have the power to create kings, you have the power to destroy a king.
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.
It's not a complete answer to your critique, and I don't have any experience working with stack-ranking, so I'm not sure the following is true. But: it seems like the worst problems of stack ranking might come from not having good people doing the ranking. In other words, it's a system that would be a complete disaster if used in a normal organization full of normal people. But Valve strives to be (and, I think it may be fairly said, is) neither. True?
Back in my days at Andersen Consulting, annual reviews were done by getting everyone at manager or higher level to assess everyone they had worked with over the preceding year and the nature and duration of the working relationship. This weighted your ranking. Within seniority levels, every person's scores were then calculated, sorted, and then assigned to one of five bands which determined raises.
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.
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.