3 ms·
Correct. Also, engineers are promoted "confirmationally" (meaning, after they're performing at level X) and managers are promoted "aspirationally" (when people
by michaelochurch 12y ago
Correct. Also, engineers are promoted "confirmationally" (meaning, after they're performing at level X) and managers are promoted "aspirationally" (when people think they should be able to reach level X). Google prides itself on promoting only confirmationally, and engineers like it that way because it's more meritocratic. The problem is that product people and management still get aspirational promotion, and that's a huge leg up.
Over time, they advance a lot faster than we do. We have to take on above-level responsibilities (which is politically dangerous, because people start to wonder if you're neglecting your at- and below-level job duties) to advance. They don't.
- ryandrake 12y agoThis is a really good point. As someone who wrote software for over a decade, then moved to the business/management side, I can tell you that on the business side (and to a lesser extent, in engineering management), there is far more opportunity to "punch way above your weight class". In fact, many places expect you to.
- nostrademons 12y agoProduct people and management - at least at Google - are still promoted confirmationally - you get formal management responsibilities when you've been a tech lead for a year or two and have exhibited the qualities (concern for other peoples' careers, ability to delegate, humility, emotional stability, ability to see multiple perspectives, commitment to Google and its values) that Google wants to see in its managers.
- michaelochurch 12y agoConfirmational promotion may be true for the first leap into the management ladder, but not after that. Aspirational promotion makes sense for management, since it's really about social status rather than achievement anyway. concern for other peoples' careers, ability to delegate, humility, emotional stability, ability to see multiple perspectives, commitment to Google and its values You don't really see these among the people in power. Stack ranking? Secret "calibration scores"? Closed allocation? Blind allocation? People getting PIP'd for having 20% Time projects?
- nostrademons 12y agoIt's interesting how you and I can see the same facts and interpret them completely differently, perhaps because I know the reason for these practices and also don't have an axe to grind about how they've personally affected me. Stack ranking is there to smooth out mistakes in your manager's judgment. One of the big problems I saw in the promo process is that people who quietly help out a lot of other people but don't work on their manager's pet projects will get overlooked by their manager at promo & calibration time. Stack ranking is there to counteract this: if you have helped out lots of teams, you will appear high on many other peoples' stack ranks, sometimes even higher than your manager, and promo committees take this into account when considering promotions of people who don't have their managers' blessing. And it generally works, too: I was promoted on the strength of peer recommendations (I had quite low calibration scores, largely because I've never really cared what my manager thought of me), and I know several other friends who were as well. Calibration scores are there to prevent the problem where a manager games the promo system by giving super-awesome assessments to all of his reports. He has every incentive to do this: it raises his own prestige within the organization to have a "super high performing" team (even if it's only high-performing because he set the goalposts low), and engenders loyalty from his reports. Calibration forces him to justify his scores to his peers, all of whom have an incentive to inflate their own reports' scores relative to him. Closed allocation does suck, but in my experience Google didn't actually have closed allocation. If you had a solid track record and a team willing to accept you it was remarkably easy to transfer to a different department. Blind allocation is a consequence of Google's "hire for the company, not for the team" practice, which is a way to prevent empire-building and keep the hiring bar high. When teams do their own hiring, every manager has an incentive to take a marginal candidate, because his team is probably overworked, and one mediocre employee is better than zero employees. Over time, this would make the whole company mediocre, which is why Google has instituted a uniform hiring bar across the company. Blind allocation is an unfortunate side-effect of this; most people would rather know which team they're going to (actually, if you're in demand by multiple teams, you can get this - I spoke on the phone with my eventual manager before accepting my offer letter), but that's hard when you're not interviewing with one particular team. I have never seen anyone get PIP'd for having a 20% time project, and I had like a dozen 20% projects during my time at Google, one of which became a major open-source project (and ultimately consumed like 50% of my time). I have seen people get PIP'd for not doing any useful work on their main project, but that's because you're hired to do a job and you better do it.