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.
Comments
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.
Sorry, but what does any of that have to do with what happens at Valve?
Is there actually some relation between your story and Valve?
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.
Very carefully selected workers managing themselves. Not just any workers.
I didn't see anything in the handbook about PIPs.
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.
What's interesting about this is that it connects the ranking mechanism to the (seemingly unrelated and far more significant) hiring/firing mechanism.
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."
I have the same question. If they addressed it, I missed it. You know what, though? Your facetious suggestion is intriguingly sensible.
What's a CL in this context? (Maybe this is obvious, but I haven't seen the acronym before!)
ChangeList. A commit, in Git terminology.
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.
Thanks for the clarification.
(Also, you just made CLs sound like yet another metric that can be gamed by the appropriately cynical employee. Ouch.)
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.
Closer to a feature branch, in practice.
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.
If he's wrong, say he's wrong and how. Comments like this have negative value: they just turn the issue into a soap opera.
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...
[1]: http://news.ycombinator.com/item?id=3790656 [2]: http://news.ycombinator.com/item?id=3784685 [3]: http://news.ycombinator.com/item?id=3702761
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.
C.f. "Why are manholes round?"
Interestingly, Microsoft was actually one of the more prolific early-adopters of these techniques, back when PageRank was just a gleam in Larry's eye.
http://www.amazon.com/Would-Move-Mount-Microsofts-Puzzle/dp/...
First, it makes people hate each other.
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.
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.
I take everything I read anywhere on the Internet with a grain of salt.