News for hackers. Stuff that matters.
Re:Google Engineering Management Mistakes by kenjackson on Wednesday November 03, 2010 @12:19PM (#1865298)
Curious, why does he end the presentation saying that a tech ladder is bad? Is the idea that they should have a management ladder, but all engineers are at the same level? That sounds like a recipe for disaster.
Re:Google Engineering Management Mistakes by plinkplonk on Wednesday November 03, 2010 @12:35PM (#1865360)
"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 the need to belabor the point."

A snippet from the promotion systems post

"What if I tried to design a promotion system to piss off as many employees as possible? What characteristics would it have?

- No pleasant surprises. In other words, you can only be disappointed if you didn't get a promotion, you can't be pleasantly surprised by a promotion.

- Create unhappiness by dependence on scarce resources. In other words, gate promotions based on scarce resources so that even people who would otherwise be qualified could become disgruntled through no fault of their own.

-Eliminate accountability from people who make the promotion decisions (e.g., through a committee). That way, promotion decisions can seem arbitrary.

-Ensure that promotions are competitive races between all qualified candidates. This ensures that people who manipulate that packet in such a way as to have the best looking packets will win over people who are trying to get feedback and improve, which is supposedly the point behind all these feedback systems.

When I looked at Google's promotion system through this lens, I was very impressed. It seemed as though the system was designed to create disgruntled employees out of people who might otherwise be perfectly happy. And note that the ex-Googlers I interviewed were people who benefited from the system, as in: they were very well respected and were hence ranked highly. They were people who couldn't care less what their ranking was, yet they disliked the system anyway, purely because they thought that having a ranking system actually had a deleterious effect on the exchange of ideas."

There is a follow up post (http://piaw.blogspot.com/2010/05/promotion-systems-redux.htm...)

A snippet

"My spies at Google tell me that my essay on promotion systems drew a reaction on a Google mailing list that I didn't read even back when I was employed at Google.

I did get a few interesting responses. I won't post them here, but I'll address what a few points:

Someone.....pointed out that the real compensation at Google was much more dependent on raises, stock and bonuses, so the promotion system didn't matter. But that's not true at all! First of all, there was a level-based salary cap, and people did hit them. So at some point, you have to get promoted if you want your salary to keep going up. Bonuses were based on salaries, so those don't go up if your salary doesn't go up. Secondly, even if it was true that options and bonuses was all that mattered, then you just validated the claim that eliminating the engineering ladder wouldn't hurt productivity at all!"

I've found Piaw's posts to be very worth reading, even if you don't end up agreeing with him. Many gems on his blog.

Re:Google Engineering Management Mistakes by kenjackson on Wednesday November 03, 2010 @12:59PM (#1865454)
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. Maybe if you single handedly implemented Google you'd get a $50k bonus that year, but your base salary is still $80k/year. And maybe you get a 15% pay raise for your great contribution.

And when everyone is a "programmer" it is more apparent than even now that everyone is a replaceable cog.

It sounds like the Google promotion system is just bad. Since technical ladders don't have human resource bottlenecks (you can't make everyone the dev manager, but you can promote everyone to Level 4 SWE) you really should have very clear guidelines as to what constitutes a promotion.

When I've managed it looks like this: "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".

Every week we talk about his/her progress against the plan. There's no pleasant surprises, but there's also no big disappointment. If you're not getting a promotion we've known about it for a while, and we're usually both not happy because I've made it clear that something is not going well.

Notice, there's no competition against other employees or any other such race. With that said, there are cases where there is little or no money associated with the promotion, but surprisingly this is often not a concern.

Re:Google Engineering Management Mistakes by kscaldef on Wednesday November 03, 2010 @03:47PM (#1866201)
> "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 hold. Sure, you did great work on D and E, but those weren't part of your stated goals for this year. Oh, and by the way, there was a re-org and the manager who promised you a promotion isn't your manager any more."

Not saying you personally do that; it sounds like you're a pretty good manager. But I've seen this pattern many times, and know a lot of other people who have experienced it.

Re:Google Engineering Management Mistakes by kenjackson on Wednesday November 03, 2010 @04:16PM (#1866309)
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 then you discuss giving him proper credit for work on A until it was canceled, and then break down what his new priorities look like.

Or, "I just started work on D, how does this fit in the plan?" "Currently it doesn't, but lets get it in there".

There should be very few things that happen that would be so important that they'd be worth discussion in a promotion that you don't communicate about within a day or two of it first appearing on the radar (if not hours).

The last issue of a reorg is the one that is toughest to deal with. I would talk to their new manager, layout their plans, etc..., but there's no guarantee that the new manager will have the same philosophy.

Being a manager is hard work. And frankly, I'm largely done with people management. It's the hardest job I've ever had, bar none. But its important, and I think some of the problems noted in this article are things good management training can deal with.

Re:Google Engineering Management Mistakes by gaius on Thursday November 04, 2010 @09:46AM (#1868811)
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.

Re:Google Engineering Management Mistakes by megablast on Wednesday November 03, 2010 @09:13PM (#1867184)
You are right, it is not 100% perfect so therefore it should never be used, and we should keep using the much more broken system we have now.
Re:Google Engineering Management Mistakes by neiljohnson on Wednesday November 03, 2010 @05:18PM (#1866559)
@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 by kenjackson on Wednesday November 03, 2010 @06:12PM (#1866749)
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 by neiljohnson on Wednesday November 03, 2010 @06:30PM (#1866803)
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.

Re:Google Engineering Management Mistakes by VladRussian on Wednesday November 03, 2010 @08:47PM (#1867121)
>Notice, there's no competition against other employees or any other such race.

there is. Limited promotion and salary increases pool.

Re:Google Engineering Management Mistakes by rdouble on Wednesday November 03, 2010 @01:36PM (#1865627)
If you just want to do interesting work, an issue with career ladders is that little interesting work filters down to the people at the bottom of the ladder. This becomes a catch 22 for rookie employees. It becomes difficult to level up, because you're never working on anything that will wow your reviewers. In fact, the reward for excelling at boring but necessary tasks is often being stuck on those tasks forever. Thus begins the cycle of churn and lowering of hiring standards.
Re:Google Engineering Management Mistakes by nostrademons on Wednesday November 03, 2010 @11:22PM (#1867527)
There's a very curious effect at Google that the most interesting work goes to interns. The least interesting goes to heroic senior engineers who've taken it upon themselves to clean up Google's codebase.

This is as it should be, I think. Actually, I've noticed an almost direct correlation between the quality of a Tech Lead/Manager and his willingness to do the boring stuff and pass off the interesting, challenging tasks to his subordinates.

Re:Google Engineering Management Mistakes by dpritchett on Wednesday November 03, 2010 @12:36PM (#1865363)
Career ladders are wishful thinking and an easy way to undervalue contributions. They imply that professional development largely occurs along a single axis rather than multiple ones.

Who's worth more, Peter Norvig or Marissa Mayer? What about an overachieving SWE I vs an mailing-it-in SWE III?

Re:Google Engineering Management Mistakes by clr on Wednesday November 03, 2010 @01:04PM (#1865481)
The worst part about career ladders at Microsoft was that it put people who were great engineers but terrible, terrible managers in positions of authority, because there was only one advancement path. When I left,they were just starting to create a career ladder for individual achievers, because they had finally realized this. I don't know if it actually ever happened.
Re:Google Engineering Management Mistakes by bmalicoat on Wednesday November 03, 2010 @04:23PM (#1866334)
Dunno when you left, but you can go up many levels as an IC currently.
Re:Google Engineering Management Mistakes by pyrhho on Wednesday November 03, 2010 @01:24PM (#1865573)
Additionally, poorly structured career ladders can to lead to "Promotion Until Incompetence", where people are repeatedly promoted until they are unable to warrant another promotion. Thus, everyone is stuck at a level of mild incompetence.
Re:Google Engineering Management Mistakes by rhizome on Wednesday November 03, 2010 @02:24PM (#1865834)
AKA "The Peter Principle."
Re:Google Engineering Management Mistakes by pyrhho on Wednesday November 03, 2010 @04:25PM (#1866346)
Thanks! I could NOT remember of the name for it!
Re:Google Engineering Management Mistakes by kenjackson on Wednesday November 03, 2010 @01:02PM (#1865471)
Who's worth more, Peter Norvig or Marissa Mayer?

Who's paid more? Who has the better title?

Who's worth more a very strong CTO of Google or an overachieving SWE I? Presumably with title comes responsibility befitting the title.