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

121–130 of 136 posts

Re: Google Engineering Management Mistakes

#121

Post by sdizdar »

I think the problem is much more general. It seems like the underlying problem is that technology companies have idea to divide people into two categories: manager and individual contributors (developers). And then rank them into levels.

This might work for non-tech companies, but I think that is wrong approach for tech companies. One of the key problems is that big money is in "management career path", thus very smart young people which are unable or not willing to go into management will leave to start their own companies.

For example, if you look around you, you see that your fellow colleges and managers are quite different. Some of them are "mentors" (people who like to mentor), "intrapreneur" (people with weird ideas), "fire-fighters" (people who are good in fire mode), "coordinators", etc.

I'm not sure what is the solution. Maybe something like mash up structure where person who is deciding on ones bonus and raise is not his/her manager.

Re: Google Engineering Management Mistakes

#122

Post by sriramk »

btilly wrote: post #54
plinkplonk wrote: post #2

"Stack ranking system was harmful:" whoa! I didn't know Google practiced stack ranking. There is a lot of unnecessary stress generated at Microsoft due to this[1]. I would have thought the Google folks would be wise enough to avoid it. As for ".... SVP response: “If you wanted to get promoted for these non-engineering tasks, move into management" heh! How big company ish is that? The best way to join Google these day…

There are many, many ways to set up a stack rank system. People that I know who have worked at both Microsoft and Google far prefer Google's system. That is not to say that they find Google's system perfect. Just significantly preferable to Microsoft's version. As a Google employee I am not at liberty to discuss what the differences are.

That's interesting. I'm guessing these are Microsoft employees who quit before the perf review system here at Microsoft was basically changed from scratch 3 years ago?

Re: Google Engineering Management Mistakes

#123

Post by sriramk »

sdizdar wrote: post #121

I think the problem is much more general. It seems like the underlying problem is that technology companies have idea to divide people into two categories: manager and individual contributors (developers). And then rank them into levels. This might work for non-tech companies, but I think that is wrong approach for tech companies. One of the key problems is that big money is in "management career path", thus very sma…

I actually think this is one of the places Microsoft has done very well in over the years. I don't think used to be the case a decade ago though but the IC career path is as lucrative/supported now as the management path. One can choose to be a Anders Hejlsberg/Dave Cutler as much as one chooses to be a Steven Sinofsky.

Re: Google Engineering Management Mistakes

#124

Post by othermaciej »

piaw wrote: post #106
othermaciej wrote: post #83

He says offhand that Google is a better place for engineers to work than Apple, but as far as I can tell, Apple makes none of these five mistakes.

I know several Apple and ex-Apple engineers. Let's just say that the environment isn't even comparable. Google wins hands down. One of my friends at Apple had to file for an information request so that she could debug a problem that spanned multiple layers of abstraction. A Google engineer faced with that kind of inanity would just quit.

I've also heard complaints from Google and ex-Google people that wouldn't come up at Apple. Examples: - Launching a hard-to-understand product and providing it with scant marketing support, so it promptly goes nowhere (when Apple launches a product we are committed to making it a success). - Central hiring leads to o way of knowing what kind of project you will end up working on, and high risk that it will be infrastructure grunt work which is not respected by the culture.

Does internal secrecy suck more or less than those kinds of things? I dunno. I would not be so bold as to make a claim either way without firsthand experience of both environments.

Re: Google Engineering Management Mistakes

#125

Post by btilly »

sriramk wrote: post #122
btilly wrote: post #54

Earlier quoted context omitted.

There are many, many ways to set up a stack rank system. People that I know who have worked at both Microsoft and Google far prefer Google's system. That is not to say that they find Google's system perfect. Just significantly preferable to Microsoft's version. As a Google employee I am not at liberty to discuss what the differences are.

That's interesting. I'm guessing these are Microsoft employees who quit before the perf review system here at Microsoft was basically changed from scratch 3 years ago?

I've heard comments from people who were at Microsoft for a long time. I don't know the specific timelines of the people involved, and so can't tell you what time period their comments specifically referred to.

Re: Google Engineering Management Mistakes

#126

Post by loewenskind »

tptacek wrote: post #3

Wow, this is one of the coolest things HN has found in awhile. It's remarkable how, time and time again, formal incentive compensation schemes are shown to cause more harm than benefit. I started paying attention when Joel Spolsky called it out 6-7 years ago, and then read Peopleware (an excellent book) which reiterates the point (and calls it "teamicide"), and then read the Harvard Business Review article ("Why Ince…

Incentives are one of those things that people just want to be true (like e.g. "one true soul mate") and do everything they can to reject any and all evidence that contradicts this belief.

Re: Google Engineering Management Mistakes

#127

Post by loewenskind »

shrikant wrote: post #35
plinkplonk wrote: post #7

Earlier quoted context omitted.

"Stack ranking means that if you have a group of 20 people, during each performance review cycle the group manager is expected to rank them from 1 to 20, and the company distributes bonuses and promotions accordingly. That just seems completely asinine." Worse, there is often an associated ideal distribution ("the curve") with fixed ratios for "exceeds expectations", "below expectations" and so on and managers are un…

I was in a place that decided to give out bonuses to my team (consisting of 3 members and a leader) in the following way: 1. Allocate fixed amount to give out per team 2. Have team leader's manager determine how that pie would be shared between team leader and us 3 team members. 3. NOT have 360° feedback 4. Incorporate team leader feedback on team's performance into this decision I'm not sure what type of HR schmuck…

This kind of nonsense is why I became a consultant. I get my bonus every day now and I don't have to do any go through the "performance review theater" anymore. If they really have a problem with me then don't renew my contract. It's simple and honest, just how I like it.

Re: Google Engineering Management Mistakes

#128

Post by JabavuAdams »

kenjackson wrote: post #114
JabavuAdams wrote: post #97

Earlier quoted context omitted.

Your observations re: gamedev are correct. Actually, I can't really stand working for other people, so I'm doing a startup. Now I work almost all the time I'm awake, and I make 0 dollars. Hmm. So, what city do you live in? Does your employer have EDIT> I should point out that the highest-paying jobs I've seen advertised for non-management devs in Toronto are around 100k. Architects are like 120k. Then again, a detach…

I live and work out of two houses and offices. One in Seattle and one in SF. Less than 100 people. I used to be a consultant... if you've never done it I recommend all devs to spend some time doing it. The listed salaries in ads are just for where to start negotiations at :-) In any case, if your start up does well, but not so well that you can retire like Brin & Page (exit w/ say $3-5M) you'll find that higher payin…

> I couldn't tell from your page (or I just missed it), what does your start up do?

I'm developing an online, subscription-based game for PC and Mac.

> I used to be a consultant... if you've never done it I recommend all devs to spend some time doing it.

The problem I see with consulting is that to be really good, you need to care more about the client's project than your own stuff (or at least act that way). This is a problem for me, since (non-retirement) money is not a significant motivator.

This is also true of customers, of course, but there's a bit more leeway and leverage there.

> The listed salaries in ads are just for where to start negotiations at :-)

Very true.

> In any case, if your start up does well, but not so well that you can retire like Brin & Page (exit w/ say $3-5M) you'll find that higher paying offers tend to come a fair bit easier.

Interesting. When I reach that range, I won't be accepting offers -- I'll semi-retire. I'd probably work at building a personal submarine like Nautilus UC3 ($200k), doing AI research, building robots and making art.

You mention SF and Seattle. For comparison, in Toronto, you can get a beautiful house in an elite uptown neighbourhood on the subway line, starting at around $650k. If you move to the 'burbs, the size/price ratio just improves (but why would you want to live in the 'burbs :)

Re: Google Engineering Management Mistakes

#129

Post by endtime »

othermaciej wrote: post #124
piaw wrote: post #106

Earlier quoted context omitted.

I know several Apple and ex-Apple engineers. Let's just say that the environment isn't even comparable. Google wins hands down. One of my friends at Apple had to file for an information request so that she could debug a problem that spanned multiple layers of abstraction. A Google engineer faced with that kind of inanity would just quit.

I've also heard complaints from Google and ex-Google people that wouldn't come up at Apple. Examples: - Launching a hard-to-understand product and providing it with scant marketing support, so it promptly goes nowhere (when Apple launches a product we are committed to making it a success). - Central hiring leads to o way of knowing what kind of project you will end up working on, and high risk that it will be infrast…

I'm sure having the trains run on time is nice, but I have to concur with piaw - from the people I've talked to, Apple sounds like a remarkably stifling place to work.

Re: Google Engineering Management Mistakes

#130

Post by gaius »

kenjackson wrote: post #64
kscaldef wrote: post #62

Earlier quoted context omitted.

> "This is where you're at today. To get to the next level, this is what you need to do. With your help we've put together this plan for your next 3-6 months. You'll finish up A, make sure B gets deployed. C gets checked-in with QA sign off. Do this w/o ticking anyone off or being a general jerk and that looks like Level XYZ" "Sorry, corporate priorities changed. A and B were cancelled and C was put on indefinite hol…

That does happen, and when it does you adjust. It's not like your report is about to checkin everythign all at once, he's about to click Commit, and then new marching orders come down just before he presses the button. Presumably when A gets cancelled, he comes by and says, "A just got cancelled" (or you tell him, depending on how news flows). "This was part of my plan for this cycle, how can we adjust the plan?" And…

Not if your annual targets have already been entered into SAP HR and the system won't let them be modified outside of the appraisal period, and required yes/no answers to them in the next appraisal period for it to do ranking calculations.

Basically if you have a formal appraisal process at all you're trapped in a machine.

Post reply on HN