Live data from Hacker News

Google’s Quest to Build a Better Boss

nytimes.com

21–30 of 40 posts

Re: Google’s Quest to Build a Better Boss

#21

"Once they had some working theories, they figured out a system for interviewing managers to gather more data, and to look for evidence that supported their notions." Oops. That's called confirmation bias. http://www.sciencedaily.com/articles/c/confirmation_bias.htm http://www.skepdic.com/confirmbias.html Did they also look for evidence that cast doubt on their notions? Looking for both kinds of evidence, and evaluat…

Oops. That's called confirmation bias.

Not to say that you've simply 'confirmed' your suspicion of confirmation bias, but it could just be sloppy reporting.

Re: Google’s Quest to Build a Better Boss

#22
post #17

Earlier quoted context omitted.

http://www.nytimes.com/imagepages/2011/03/11/business/201103...

I notice they have no bullet points listed under "Help your employees with career development." I wonder if this means they feel obligated to mention it but don't really want to encourage it (because developing your career will often mean leaving) or if it just means they don't know how. Or maybe it's supposed to be so obvious that it doesn't need explanation.

Probably the opposite, making sure that the employees can figure out what they want to do with their career, and know how to get there without leaving the company is a good retention tool.

Re: Google’s Quest to Build a Better Boss

#23
It is very difficult to measure the quality of each manager on these eight effective habits in an objective manner. What is the opinion of this group, about, google people rank algorithm(ratings from good performers carry higher weight and vice versa) to rate employees within the company.

Re: Google’s Quest to Build a Better Boss

#24
post #2

Microsoft learned this lesson a long time ago. In the old days of MSFT, the saying was that BillG believed that everyone's manager needed to be a better coder than him/her. The company learned eventually that the best engineers do not necessarily make the best managers and engineered the IC/manager split-career path that exists today. P.S I like how Google is finding out they're just the same as pretty much any other…

It may be a coincidence that Microsoft was dramatically more successful in those old days than it eventually became.

Re: Google’s Quest to Build a Better Boss

#25
post #2

Microsoft learned this lesson a long time ago. In the old days of MSFT, the saying was that BillG believed that everyone's manager needed to be a better coder than him/her. The company learned eventually that the best engineers do not necessarily make the best managers and engineered the IC/manager split-career path that exists today. P.S I like how Google is finding out they're just the same as pretty much any other…

Being there in the old days, I really liked two things.

1) Any question I had, someone could either give me the answer, direct me to the book (yeah, that long ago) that had the answer, or do the back and forth so I could figure out the answer with the knowledge I already had.

2) Rip the sh*t out of my code in a way that, while humiliating, made me a much better programmer.

You went in thinking that you're the smartest kid in the room, but while I was there, the mean IQ was 132. It was a place with a bunch of smart _adults_ who also had a significant amount of knowledge and experience, and very few hoarders of that information. After all, how can you show how smart you are if you keep quiet when someone is wrong? My niches were that I had K&R memorized (that's really embarrassing now, but "actually, free(NULL) is legal," beats a full house) and my proof of concept client code made its way into SDKs.

Joel Spolsky talks a lot about the same time era, basically Microsoft pre-Internet. Many of us ex-MSFTies idealize it to a certain degree, but that's fine–take and keep the good and drop the bad. Many of us are engineering leads/CTOs/flounders elsewhere, and the rigor present in the hierarchy of ability-to-execute helps to excel in other companies or industries.

But most of us secretly would like to go back to a few thousand nerds in a rainy forest and hack products all day. :-)

Re: Google’s Quest to Build a Better Boss

#26
post #4

So, apparently Google found that of their 8 characteristics-of-good-bosses, technical excellence was the least importance. Fair enough. But note that this is looking at a sample of technically excellent bosses ! So, e.g., Bock is quoted as saying: "In the Google context, we’d always believed that to be a manager, particularly on the engineering side, you need to be as deep or deeper a technical expert than the people…

The article actually said that technical excellence was important, it just said that it wasn't as important as some of the people skills. I can't really see Google dropping technical competence as a qualification for managers. I've heard that from 2005-2007 (before my time), Google brought on a bunch of non-technical managers from other companies, and the result was a pretty uniform disaster. Most of those managers a…

Reverse-engineering from the article, the original statistical result was probably something like, "Variations among managers in technical skill account for very little of the variations among managers in performance reviews."

One way to get that result would be for technical skill to be unimportant. Another way would be for the variations in technical skill within the sample to be much smaller than other relevant variations. Given that (según the article) the managers were selected for technical skill, but not for the other qualities, it seems almost certain that this was the case.

This might sound like a bug that could be avoided by better statistical analysis techniques, but it's really not. You really want to know what causes the actual variations in performance in your sample, not what could conceivably cause variations in performance. Surely there are hundreds of things that would cause even bigger variations than what's in your actual sample — you could have managers who kill all their employees, or managers who are interned incommunicado in Guantanamo, or managers who obsessively turn every project into an investigation of fluoride contamination of their precious bodily fluids, or managers who are actually undercover headhunters from a competitor trying to steal away all of your best talent.

Cosma Shalizi has an excellent post about the pitfalls of multivariate statistical analysis at http://www.cscs.umich.edu/~crshalizi/weblog/520.html; although he's talking about genetics, it's very likely that what he's saying applies to Project Oxygen as well:

To see why gene-environment interactions matter, consider one of the best-established links between genetic variations and intelligence, phenylketonuria. This is a recessive genetic disease which interferes with the normal metabolism of the amino acid phenylalanine. If someone with one of the defective forms of the gene for phenylalanine hydroxylase consumes too much dietary phenylalanine, it leads, among other problems, to serious mental retardation. Under suitable diets low in phenylalanine, however, they grow up mentally normal. Assigning shares of this effect to the genes and to the environment is exactly as sensible as trying to say how much of the fact that a car can go is due to its having an engine and how much is due to their being fuel in the tank. The best the usual biometric model could do here would be to predict that having the gene always reduced intelligence, as did consuming phenylalanine (which would be bad news for makers of artificial sweeteners); the fact that it's the combination, and only the combination, which is a problem would be missed, and the predicted size of the effect would be badly wrong. … So while everyone piously says that genes and environments interact in development, they typically use models which assume that they do so only in trivial ways, and hope that any actual interactions are small enough to be treated as noise.

(So if these simple linear models are so bad, why does everybody use them? Because they have fewer parameters than more complicated models, which means that they're not as prone to overfitting. It's easy to construct a nonlinear multivariate statistical model with more parameters than you have managers in your company, which will discover correlations no more meaningful than the fact that people whose initials are "BHO" are far more likely to currently be the president of the United States than people with other sets of initials.)

Re: Google’s Quest to Build a Better Boss

#27
post #25
post #2

Microsoft learned this lesson a long time ago. In the old days of MSFT, the saying was that BillG believed that everyone's manager needed to be a better coder than him/her. The company learned eventually that the best engineers do not necessarily make the best managers and engineered the IC/manager split-career path that exists today. P.S I like how Google is finding out they're just the same as pretty much any other…

Being there in the old days, I really liked two things. 1) Any question I had, someone could either give me the answer, direct me to the book (yeah, that long ago) that had the answer, or do the back and forth so I could figure out the answer with the knowledge I already had. 2) Rip the sh*t out of my code in a way that, while humiliating, made me a much better programmer. You went in thinking that you're the smartes…

> but while I was there, the mean IQ was 132

Only 132? Are you serious? How did the IQ-105 people get hired, and what were they doing — opening envelopes in the mail room?

Re: Google’s Quest to Build a Better Boss

#28
post #26

Earlier quoted context omitted.

The article actually said that technical excellence was important, it just said that it wasn't as important as some of the people skills. I can't really see Google dropping technical competence as a qualification for managers. I've heard that from 2005-2007 (before my time), Google brought on a bunch of non-technical managers from other companies, and the result was a pretty uniform disaster. Most of those managers a…

Reverse-engineering from the article, the original statistical result was probably something like, "Variations among managers in technical skill account for very little of the variations among managers in performance reviews." One way to get that result would be for technical skill to be unimportant. Another way would be for the variations in technical skill within the sample to be much smaller than other relevant va…

Right, I'm saying that the managers in charge of interpreting this data are undoubtedly aware of this effect, and so they're looking for those effects besides technical skill. It's like every Google manager already has an engine (they took care of that problem several years ago), now what can they do to make sure that there's always gas in the tank?

Re: Google’s Quest to Build a Better Boss

#29
post #27
post #25

Earlier quoted context omitted.

Being there in the old days, I really liked two things. 1) Any question I had, someone could either give me the answer, direct me to the book (yeah, that long ago) that had the answer, or do the back and forth so I could figure out the answer with the knowledge I already had. 2) Rip the sh*t out of my code in a way that, while humiliating, made me a much better programmer. You went in thinking that you're the smartes…

> but while I was there, the mean IQ was 132 Only 132? Are you serious? How did the IQ-105 people get hired, and what were they doing — opening envelopes in the mail room?

Mean IQ, so if we assume IQ is normally distributed and there're a few people with IQ > 170, that'd imply that the bulk of people have IQs in the 125-130 range. This seems eminently believable to me.

Re: Google’s Quest to Build a Better Boss

#30
post #25
post #2

Microsoft learned this lesson a long time ago. In the old days of MSFT, the saying was that BillG believed that everyone's manager needed to be a better coder than him/her. The company learned eventually that the best engineers do not necessarily make the best managers and engineered the IC/manager split-career path that exists today. P.S I like how Google is finding out they're just the same as pretty much any other…

Being there in the old days, I really liked two things. 1) Any question I had, someone could either give me the answer, direct me to the book (yeah, that long ago) that had the answer, or do the back and forth so I could figure out the answer with the knowledge I already had. 2) Rip the sh*t out of my code in a way that, while humiliating, made me a much better programmer. You went in thinking that you're the smartes…

This is still largely the case at Google today.
Post reply on HN