Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Engineering Management Mistakes

docs.google.com

Post reply on HN
Print view View original

131–136 of 136 posts

Re: Google Engineering Management Mistakes

#131

Post by gruseom »

LiveTheDream wrote: post #69
gruseom wrote: post #51

Earlier quoted context omitted.

I would challenge this. Let's replace your trivializing phrase "a 'thank you' from your boss on the company newsletter" with just recognition , which obviously can take many forms. We have evidence, cited in this thread, that recognition is generally more satisfying and motivating than financial rewards are (at least those produced by formal incentive plans). What evidence do you have that this effect only holds "at…

I left "a certain threshold" undefined on purpose, because it varies from person to person. The point is that the reward must be meaningful to the person being rewarded , otherwise it is much worse than no reward; the person will become cynical, demoralized, and unmotivated. The main problem is conflicting valuations of the work in question, which holds true whether the the payment is money or recognition. Who is to…

My evidence, like the evidence in this thread and the presentation, is just personal experience.

On the contrary, I was referring to the work of Dan Pink and others on the science of motivation, which was mentioned elsewhere in the thread.

I don't usually discount personal experience but this is one area where the empirical findings are surprising. A pretty important one, too, considering the implications for good organizations and happy lives.

Re: Google Engineering Management Mistakes

#132

Post by kenjackson »

VladRussian wrote: post #88
kenjackson wrote: post #30

This also reminds me of a paper I had submitted in the past. Randomly promoting people is more effective than using merit: http://arxiv.org/abs/0907.0455

do you know of any research on randomly electing people in the government offices? I believe it would also be much more effective.

In the US we've been doing this for years.

Re: Google Engineering Management Mistakes

#133

Post by matwood »

rhizome wrote: post #48
matwood wrote: post #15

Earlier quoted context omitted.

I once worked at company that employed a lot of hourly wage type people. One exec wanted to stack rank each group of wage employees each month and fire the bottom 25%. I tried to explain to him the negative morale effect that would lead to lower performance across the board, the fact any employes who were decent would just leave on their own, and there is a significant training cost for each new employee that he was…

This is what Jack Welch did at GE in the 80s, firing 10% of management every year. It's not universally derided as an HR/Management policy. I mean, it's pretty much the entire premise of the TV show "The Apprentice," no? Pro: http://www.cogmap.com/blog/2009/11/12/force-ranking-to-fire-... Con: http://www.missionmindedmanagement.com/where-jack-welch-got-...

Maybe I missed it, but your 'pro' article doesn't link to the study that is referenced. I would like to see what kind of work the people were doing who were tossed. For example, in my experience most companies have way too many middle management. In that scenario it makes sense to cut no matter what so go ahead and use some performance metric (and definitely don't wait a year to do it).

Then you have rank and file employees are are actually doing the work. Even in a relatively low skill position the company might have to put in 1-2 months of training to have an employee functioning. Unless the employee is completely horrible (in which case they should be fired anyway, and if this keeps happening hiring practices should be analyzed), from a cost standpoint it makes more sense to coach them to do better rather than remove them.

In higher skill positions it makes even less sense to just cut the bottom unless the bottom is doing very poorly. In that case they should have been cut prior to ranking. Where I work now we don't expect someone to get fully up to speed until they have been in our codebase for 3-6 months. If we constantly ranked, fired, and hired again we would only have a few good people at the top end doing all of the work and simply churning money on the bottom end. We might find a superstar who displaces the top, but does that mean you want to fire your previous tops? They were doing fine, and presumably still are, until the superstar showed up.

Again, I have no problem with ranking people or with firing people for poor performance. The problem is picking an arbitrary line and firing people who fall below it even if their raw performance is acceptable.

Re: Google Engineering Management Mistakes

#134

Post by piaw »

afterburner wrote: post #119
jfb wrote: post #44

It's funny how you could take "Google" out of that slide and put "Apple" in it and it would be almost word-for-word applicable. Or maybe it's not funny. Too, I recognize that this author of this presentation spent time to make it public, and sharing this sort of information is always welcome, so moaning about the format might seem a little rich. But in the glorious tradition of the internet, I'ma gonna bitch about it…

Honestly, this sounds like the problems at any largish engineering company. At least the nice thing about Google is that they're openly discussing it, and sort of scientifically at that. At other companies, you just resign yourself to politics being more than 50% of the equation, and the company slowly goes to hell in between increasingly rare and brief spurts of innovation.

I don't think Google openly discusses it. At least, certainly if there was such discussion I wasn't privvy to it. I only felt free to post these thoughts post Google.

Re: Google Engineering Management Mistakes

#135

Post by afterburner »

piaw wrote: post #134
afterburner wrote: post #119

Earlier quoted context omitted.

Honestly, this sounds like the problems at any largish engineering company. At least the nice thing about Google is that they're openly discussing it, and sort of scientifically at that. At other companies, you just resign yourself to politics being more than 50% of the equation, and the company slowly goes to hell in between increasingly rare and brief spurts of innovation.

I don't think Google openly discusses it. At least, certainly if there was such discussion I wasn't privvy to it. I only felt free to post these thoughts post Google.

Ah, well then same as everywhere then. :) I suspect the large proportion of very smart and/or very competitive employees might also result in more gaming of the system than elsewhere.

Re: Google Engineering Management Mistakes

#136

Post by jacques_chester »

nostrademons wrote: post #113
jacques_chester wrote: post #85

Earlier quoted context omitted.

An insight gleaned from Donna Meadows is that profit is not the purpose of a company's existence. Profit is merely survival, it's what facilitates the company staying "in the game". Her view is that the purpose of companies is to grow .

That observation was made by Peter Drucker, fairly soon after WW2. Profit is the cost of continuing to do business; it's necessary to ensure that you are allocating your efforts efficiently, but is not the intrinsic raison d'etre of a corporation. His view was that the purpose of companies was to serve a social purpose. The purpose of Google is so that people can find information. The purpose of Microsoft is so that…

Thanks for correcting me.
Post reply on HN