Live data from Hacker News

Google Engineering Management Mistakes

docs.google.com

71–80 of 136 posts

Re: Google Engineering Management Mistakes

#71

"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…

I was thinking the same thing ('oh man, i bet a Microsoftie could have created the same deck back in the mid/late 1990s...')

Re: Google Engineering Management Mistakes

#72

Earlier quoted context omitted.

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…

It sounds like your manager actually suffered a bout of insanity or was a thief.

I'm guessing thief. It's where the incentives lead.

Re: Google Engineering Management Mistakes

#73
post #46

Earlier quoted context omitted.

Losing all of your stock options or having something else taken away is not a negative case for incentives, it's an example of a disincentive , which also has an effect. They aren't the same thing, and you can tell because you don't know how well you'd be working if you never had the options in the first place (and hadn't been denied them or otherwise been treated unfairly). One of the reasons you don't see many foun…

Well I think I'd also turn down most jobs that said, "We'll pay $150k/year with no further financial incentives ever". Unless my goal was simply to to do as little work as humanly possible, yet still collect a check, I'd be hardpressed to work there. And if I did, despite non-financial that exist in the world, I really don't think you could get me to work more than 40 hours per week.

Are you really saying that you wouldn't work more than 40 hrs per week for money that makes you put in extra hours?

The thing is that there's a huge number of talented people out there who will put in extra hours because the work is interesting, or they feel that if they don't, they're letting the team down.

In fact, the really really talented developers seem to care less about money (after a nice base-line), and more about the work / team. Or, other obsessive (and useful) qualities make them unable to say no to work, etc.

So, who would a company prefer to hire? Obviously, the qualified person who would work for free, because it's their passion.

Interestingly, $150k/yr is a lot more than I've ever made, but that's neither here nor there.

Re: Google Engineering Management Mistakes

#74
post #59

Earlier quoted context omitted.

You can give a peer bonus of $200 to any individual with their manager's approval (which is very easy to get). They encourage giving peer bonuses for when someone goes the extra mile on something, but very few engineers initiate giving a peer bonus. After tax, it's about $100, hence the "I can poop $100" bit.

Is "close to 50%" the going marginal tax rate in general? I calculate ~30% federal + ~10% California + possibly ~6% social security & Medicare to get that number; did I miss anything? (current grad student with a marginal rate a lot closer to 20%, haven't had the joy of full-on taxes yet)

there is increased withholding on bonus pay, some of which you get back with your tax return.

Re: Google Engineering Management Mistakes

#75

Earlier quoted context omitted.

"Curious, why does he end the presentation saying that a tech ladder is bad?" From the blog post which provides some context to the presentation ( http://piaw.blogspot.com/2010/10/facebook-and-google.html ), "Many consider Google's #1 mistake to be having a tech ladder in the first place. I covered that topic in my post on Promotion Systems ( http://piaw.blogspot.com/2010/04/promotion-systems.html ) , so did not feel…

Interesting, as historically the problem has been quite the opposite. If you go back not that far most devs simply had a flat position in the org. There were no Distiguished Engineers or even Architect titles. You were a programmer. Of course people started to get upset because the only way they could advance in the company was to go into management. A corporate VP can make $250k/year but a programmer never could. Ma…

@ken jackson, are you in a position to share what you would consider to be a good definition of what 'the next level' or promotion might look like?

Is it something specific to the individual, or something more general?

I've found it extremely challenging to write a light weight tech progression ladder, that is flexible enough to still be of use on a week by week basis for a specific individual and general enough to provide comparison across teams.

Any thoughts much appreciated (my initial stab can be found here http://fragile.org.uk/2010/09/how-to-appraise-a-developer-pa... it also explains why, despite this thread, I have a need for a tech ladder).

Neil

Re: Google Engineering Management Mistakes

#76

Earlier quoted context omitted.

Well I think I'd also turn down most jobs that said, "We'll pay $150k/year with no further financial incentives ever". Unless my goal was simply to to do as little work as humanly possible, yet still collect a check, I'd be hardpressed to work there. And if I did, despite non-financial that exist in the world, I really don't think you could get me to work more than 40 hours per week.

Are you really saying that you wouldn't work more than 40 hrs per week for money that makes you put in extra hours? The thing is that there's a huge number of talented people out there who will put in extra hours because the work is interesting, or they feel that if they don't, they're letting the team down. In fact, the really really talented developers seem to care less about money (after a nice base-line), and mor…

Are you really saying that you wouldn't work more than 40 hrs per week for

If there were no other financial incentives, absolutely. I have no problem saying, "No" to work. I bust my butt doing 100 hour weeks so that you can ship Mario Halo World and make $500M opening weekend, I deserve to be compensated. Even if I love the work, I can spend that 60 hours per week that you're not paying me to work on something else I love.

It's one thing to be RMS and working on your lifes passion for free. It's another thing to, as an employer, expect to ask someone to forego tucking their son in for the next 6 months, because you need to make $200M, but will not compensate them at all. I don't doubt there's people that will volunteer to do it out of some sense of passion or loyalty, but it won't be me.

I know what I'm worth.

Re: Google Engineering Management Mistakes

#77
post #48
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-...

I had a lot of respect for GE until not that long ago, but I think that after things like these (http://accounting.smartpros.com/x67325.xml) we shouldn't take this company very seriously. They're just crooks like the rest of Wall Street.

Re: Google Engineering Management Mistakes

#78

Earlier quoted context omitted.

Interesting, as historically the problem has been quite the opposite. If you go back not that far most devs simply had a flat position in the org. There were no Distiguished Engineers or even Architect titles. You were a programmer. Of course people started to get upset because the only way they could advance in the company was to go into management. A corporate VP can make $250k/year but a programmer never could. Ma…

@ken jackson, are you in a position to share what you would consider to be a good definition of what 'the next level' or promotion might look like? Is it something specific to the individual, or something more general? I've found it extremely challenging to write a light weight tech progression ladder, that is flexible enough to still be of use on a week by week basis for a specific individual and general enough to p…

The way I've done it, although I really don't think its optimal, is to do it on a very individual basis w/ no formal guidelines. What I've found useful is to make all roadmaps publicly available, except for sensitive inforamtion. And then calibrate it upwards. So you as a manager, review with your manager your directs roadmap. You don't have to do this sync up often, but just enough so they can say, "Hmm... Tim's level 3 is doing much more impressive stuff, we probably need to sync up on this". And of course, with everything public you can get feedback from anyone at anytime -- but this happens less often than you might think.

In a big company this will probably lead to discrepencies across orgs. But honestly that probably happens anyways.

Re: Google Engineering Management Mistakes

#79

Earlier quoted context omitted.

Well I think I'd also turn down most jobs that said, "We'll pay $150k/year with no further financial incentives ever". Unless my goal was simply to to do as little work as humanly possible, yet still collect a check, I'd be hardpressed to work there. And if I did, despite non-financial that exist in the world, I really don't think you could get me to work more than 40 hours per week.

Are you really saying that you wouldn't work more than 40 hrs per week for money that makes you put in extra hours? The thing is that there's a huge number of talented people out there who will put in extra hours because the work is interesting, or they feel that if they don't, they're letting the team down. In fact, the really really talented developers seem to care less about money (after a nice base-line), and mor…

And regarding $150k/year, saw your profile and you look young (although maybe you're not). Like it or not, you'll make more as you get more experience. Maybe that's reverse ageism, I don't know, but seems to be a fact of life, even in software, which is more meritocratic than most industries.

Also it appears you do game development. Unless you become a rockstar or do the next Angry Birds as a solo dev, you'll tend to get paid less than the industry average -- at least that's how it has been historically.

Re: Google Engineering Management Mistakes

#80

Earlier quoted context omitted.

@ken jackson, are you in a position to share what you would consider to be a good definition of what 'the next level' or promotion might look like? Is it something specific to the individual, or something more general? I've found it extremely challenging to write a light weight tech progression ladder, that is flexible enough to still be of use on a week by week basis for a specific individual and general enough to p…

The way I've done it, although I really don't think its optimal, is to do it on a very individual basis w/ no formal guidelines. What I've found useful is to make all roadmaps publicly available, except for sensitive inforamtion. And then calibrate it upwards. So you as a manager, review with your manager your directs roadmap. You don't have to do this sync up often, but just enough so they can say, "Hmm... Tim's lev…

That's interesting, I do like the personal approach, but I'm not sure I see how you know to say, 'okay you've progressed enough that you can now call yourself a Senior Software Developer'

Ideally, I think I'd prefer not to have to assign labels at all (for the very good reasons outlined in this thread), but in practice I've found this not to be practical.

Post reply on HN