No wonder Google lets many services languish. With a system of promotion based on launches of new products/services/features there is no personal incentive to make things work long term. It seems like the person who redesigns the gmail categories for the nth time would get a promotion, but someone who followed up on bug reports, maintenance and stability patches years later wouldn't.
Support is just as important as innovation. There's no point in having great ideas if they aren't maintained. Google doesn't seem to get this...
Speaking from experience, I see everyone from the team leader to the interns tackling bugs on my team at Google. Furthermore, the engineer with the highest level on my team has done a tremendous amount of refactoring and maintenance work over the course of the past year. Clearly this is just anecdotal, but from what I've seen an engineer who took the initiative to improve performance/stability or significantly refactor old code would have just as good a chance of promotion as an engineer churning out new features.
Former employee here. I had a very opposite experience. New features were key for promotion. Performance/stability tweaks or bug fixes would only add to your promotion chances if they had a demonstrably large impact.
I wasn't at that level but this was super true for L5-L6ish engineers or above. Yes they had to tackle bugs, but they weren't getting to L6 unless they led an effort for a big feature within a project, or L7 unless they launched a project with a solid impact.
Management made efforts to give more weight to refactoring, but it seemed like a token effort. Refactoring was thankless unless it was a truly gargantuan change.
Working at google was great, but the engineering incentive structure is far from perfect.
I'm a PM and feel this is the case as well. I've seen massive migrations as one type of 'maintenance' wrapped as a launch that led to promotions, but generally the best way to go about it was join a rapidly growing project (G+) with user-facing impact.
I see you're getting downvoted for this, but the only thing that's wrong with it is that you're a bit late on the schedule. If you go back to the 2011 era it was absolutely true.
I wanted to say "As someone who got promoted in 2011, I can concur", but technically I got promoted about 3 months before I integrated my project with G+.
Perhaps - it's hard to say. (The project was Google's Authorship program.) The product would've been a very different one without it. We had designed a federated system that worked at the level of the Web and let any website serve as an identity provider. In theory, this was going to change how the web worked, and that change would also be accessible to other search engines and spiders. We didn't accomplish that. The request to make it only work with G+ basically involved restricting that system so that one of the URLs must be "plus.google.com".
OTOH, this did subsequently simplify the system a lot, and enabled follow-on features that wouldn't have been feasible under the original design. Our original design defined an author as a clique of webpages that all linked to each other using rel=author|contributor backlinks; defining a primary key is challenging in this situation, because you have to carry along the identity of the clique throughout the system. Requiring G+ let us key everything to an author's Google login, which then opens up the possibility of other systems using that data easily. It let us display the author's profile picture (which was the primary "boon" to get authors to participate), and connect their works to their G+ profile so they could easily advertise everything they'd done. It helped in marketing and using the product, because basically nobody outside Google (and only like 4 people inside Google) actually understood the author-closure stuff.
Understand, also the historical context behind this. 2011 was the year of "Open systems lose." Android (the open-source operating system) was playing catch-up to iOS (the closed one), and arguably only caught up because they were willing to close off much of it. Facebook had used GMail's "download contacts" feature to populate their own social graph, and then systematically cut off every attempt to crawl their own, also disallowing users from exporting their friends list to Google. OpenSocial had been trying to gain adoption for 3-4 years and failed so badly that Google+ was necessary. OpenID was dead-on-arrival, and Facebook Connect was taking over the web. Google had just sunk two years into providing real-time search of Tweets, only to have Twitter pull the plug on the deal and sink the project.
So in hindsight, it's difficult for me to say that the execs made the wrong call. I was kinda ambivalent at the time - I wasn't pleased, but I could see the reasons behind it and agreed to help out with the implementation. A number of my teammates were furious and quit the project, moving to other departments.
The stack ranking element is also open to abuse and capture by outsiders i.e. only so many L3 to L4 slots available in any cycle as some hr been counter is getting a bonus for reducing the pay quanta.
It was even worse at British telecom where there might be only 20-25 MPG 4 (L4 or r 5 in google terms) slots every 18 months or so for all of Systems Engineering (a division with more employees that goggle has now) - competition to just get past the paper sift to an actual interview as brutal.
Its interesting my boss said well if you get an interview we think you can do the job its just deciding who gets a promotion or not
Regarding the bean counters, keeping promos down doesn't help their budgets as much as you might think. The bonus you get for "exceeds expectations" brings you approximately to the "meets expectations" total compensation of the next level up.
Or so I've been told anecdotally ... personally I have yet to be promoted or experience a bonus cycle where I hit exceeds...
This was true and a very big problem for a while. I started seeing improvement around 2011/2012, when promo committees started valuing grungy maintenance & refactoring tasks more. It is still harder to get promoted doing maintenance work than high-profile launches, but the gap has narrowed significantly.
Possibly not coincidentally, this was also the beginning of Larry's "More wood behind fewer arrows" push.
In my experience it helps if you can demonstrate the impact of your maintenance work. "Cleaned up the configuration" is worth something. "Improved the configuration to make a certain class of misconfiguration, which has caused several outages in the past, impossible" is worth much more.
IMHO impact is really what matters most. I think where some people go astray is they rewrite a block of code but fail to convince the committee that there was a real, tangible benefit to the company in doing so. I don't believe this is a problem with the promo process- I think you get better engineering outcomes when people can justify the impact of their work. (People like to rewrite things, even things that don't need to be rewritten!)
It would be fantastic if customer reviews were included in the peer review process, because there have been a number of times where things were launched for Google Apps customers that became a major cluster, or which actively strove to remove heavily used features, or which otherwise broke many companies' processes & use cases.
This would be challenging to do fairly. Visual redesigns are almost always received negatively because they force users to learn a new UI, but they are very necessary because otherwise your product starts looking very dated compared to competitors, which prevents non-consumers from adopting it. On the other side, niche features are usually received very positively because it's easy to make a product that suits every user's needs when you only have a few users. (This is behind YC's advice to "do things that don't scale" when you're small.) Internal refactorings and cost/performance improvements aren't user-visible at all.
What's good for the customer isn't always what's good for Google as a company. Usually when Google has done things that piss off a lot of users they've been alerted by significant internal feedback that users will be pissed off, and done it anyways for other reasons. (The one exception I can think of was Buzz, which was beloved internally and reviled externally.)
Here's a specific example from last week. Last week, Google royally f'd up the release of the new Login Challenges interstitial, which wasn't supposed to be presented to SSO domains but was. This caused much consternation, especially since because this was primarily a consumer-focused feature, there was no advance notice given to Apps domain admins.
This ties into the second big problem re: Apps administration and Google's product roadmap / release process: there is almost no correlation between feature requests Apps admins make and their mapping onto a product roadmap. Additionally, for features or new services that are kept secret as a business strategy, even Apps admins don't get any advance notice. The first we see them is when they are released to production. It is entirely unclear what the relationship is between Bill Hippenmeyer's team, the actual PM & Apps product engineering teams, and the Google Enterprise Connect team, and by all outward appearances there is almost no strong link whatsoever.
So, regardless of how Google handles things on the consumer side, those behaviors adversely affect paying customers ... and when you are paying millions of dollars per year (as an alternative to paying Microsoft or IBM millions of dollars per year) that's a big turn off. Google is far more opaque re: roadmap than traditional vendors.
(I'm not bashing all things Google, just this one thing. I'm still a huge fan. :) )
This problem isn't limited to Google. Everyone remembers the creator, nobody cares about the maintainer. There's a reason why software developers in general earn more than QA.
A lot of mgmt philosophies used in the corporate world attempt to recognize this structurally. But it rarely reflects in the pay packet. Banks for instance are an exception and maintenance and BAU staff are generally paid the same as developers.
My current client see productisation and day to day running and ongoing maintenance as the hardest part of a project (as much to internal structural failings as anything else).
Is there any company where churning through a list of bugs and maintenance projects will get you further in the long term than launching new things? Hacker News generally praises "ship it" culture, where experimentation and measurement is prioritized as the way to succeed. This is considered a good thing in most places and the incentives are not unique to Google.
Consulting. Not a longterm in the company thing, but there is money in coming in and cleaning up others messes and get them on a path that can be maintained.
For myself - I've got projects I've helped as above. I'm not a maintenance/sustaining kind of guy, but many companies gamble on a "make it work now" scenario and then need help after the fact to bring it back to reality for long term support.
It's not sexy, I don't do it often, but if someone has an interesting challenge to get from X to sustaining, I'm happy to hear and maybe work something out biz wise.
"Hacker News generally praises "ship it" culture, where experimentation and measurement is prioritized as the way to succeed."
HN has a VC/startup focus. Maintainable code means a lot less to a quickly growing (and possibly pivoting) startup because fast growth almost always outruns the maintenance burden.
On the other hand poorly written and maintained software can drown a normal business. These companies typically have 20-30% margins and so even doubling the cost of maintenance can remove any profit.
It is general problem, many companies do the same mistake. Programmer willing to do those needed useful maintenance things is penalized by a.) having less exciting buzzwords on cv, b.) having lower salary, c.) having less interesting work.
This is why the supposed meritocracy, promotions, and market economy of effort is a sham at corporations. In the real marketplace, support makes income happen. If a person is the owner of the company and does the necessary support, they reap the profits. But employees are not owners and corporations are not fair. The idealized marketplace is where everyone is their own corporation and the real marketplace determines exactly how rewards are allocated. In the real marketplace seemingly dumb ideas and banal work are both rewarded greatly if they have true value. In the corporate environment that will get you stuck in a career-ending dead-end job.
Totally agree with you
Plus the game is further rigged in favor of the corporation
>If you want to get promoted, just start acting like someone at the next level up.
Imagine 5 people working their ass off to go to the next level only 1 gets promoted
But company gets more throughput for free
FWIW, the entrepreneurial market is the same. Just s/company/customer/. You have lots of firms all competing for the customer's business, but only one will get the contract.
>I literally work to pay for rent and food. Sorry if this bums you out.
You spend a third of your life working, if you're only doing it for the money then I feel you're quite literally wasting your life. It doesn't particularly "bum me out", but I do feel sorry for people like you.
Please consider the following scenarios, all of which are things that really happen.
1. The best-paid job you can get pays just barely enough to keep your family in decent conditions. So you take that job, for the money. It costs 1/3 of your life, but the benefit is that your spouse and children get not to starve or live in squalor. Wasted?
2. You give a substantial fraction of your income to charities that save the lives of desperately poor people in Africa. You take a well-paid job, for the money. It costs 1/3 of your life, but the benefit is that every year you're working one more poor African gets to live instead of dying.
3. You have a choice between a job you like pretty well, and a job that's merely OK but pays a lot more. You take the well-paid job, for the money. It costs 1/3 of your life (or, more precisely, 1/3 of your life is somewhat less satisfying than it could have been), but the benefit is that you retire at 50 instead of 60 and have an extra decade of (according to taste) leisure, or working for the public good rather than for money, or starting your own business with the security of knowing you won't starve if it fails, or whatever.
All of these involve working "for the money". The only one of these people I'd feel sorry for is the first -- and not (as in your remark) because s/he is making a tragic mistake, but because s/he is in a difficult situation where no course of action is satisfactory.
Cool, maybe you can share your trust fund with me. Maybe if my startup fails I can go live with your family members since I will have lost my life savings.
Google's system is promotion-by-committee. It ends up having the same pros and cons as any committee-based system. On one hand, it avoids the kind of egregious mistakes and crimes that occur when too much power (i.e. to promote others) is vested in individual people (e.g. managers). On the other hand, committees are risk-adverse and will shy away from controversial actions. People who do good work following expected patterns get promoted. People who do controversial work, or who don't fit into an obvious mold, will have a tougher time, as a committee that can't come to agreement will default to no action.
Hmm, not sure I exactly understand the question. But I think the answer is probably "no". Cap'n Proto's design came mostly out of someone asking me one day whether two processes could share a protobuf object via shared memory, without serializing and parsing. I found the question interesting enough that I kept thinking about it and that eventually evolved into a design. My reasons for leaving Google had nothing to do with any of this, but gave me a well-timed opportunity to work on it.
I actually primarily quit to do sandstorm.io, and did Cap'n Proto more on a lark, although it turns out to be really useful infrastructure on which to build Sandstorm.
The only problems are when your boss doesn't pay attention and recognize the step up, or when they actively ignore it because you've taken some of the stress of their job and they are averse to potential change/risk if they promote you.
Then you take the fact that you're outperforming your title to another company that will recognize it.
Job-hopping (done within reason) is entirely underrated. Your salary will rise at a dramatically faster rate than if you stuck around one place, your responsibilities too, and best of all you get to learn how things are done across the industry.
The most interesting part of this piece for me was that the peer feedback isn't anonymous. I can see this leading to some uncomfortable situations, but I can also seeing it be a net positive. Getting honest feedback (unrelated to performance review) from one of my senior peers at Groupon was a very beneficial for me.
Am I the only one that finds it odd that (according to the article and comments) the compensation is tied tightly to levels, but the mean salary for each level is considered secret? So you get to know how you "compare" in terms of "performance", but not how much Google actually values you as an employee? Is this just an aspect of "if you generate revenue we pay you more"?
That is, nobody is going to say, "You're only an L4, therefore you can't work on this project."
Someone said exactly that to me when I was at Google. That's kinda how closed allocation works.
What I always tell people: If you want to get promoted, just start acting like someone at the next level up.
At any company, that's the quickest way to get fired. Getting into a turf war with someone with a much higher title? Not a good idea. To be honest, if I were to do Google again, I'd have kept my head down and said "Yes, sir". It can do a lot for your career to work there, but it's not a place where you can safely overperform.
However, there is a way to provide private feedback that can only be seen by your manager; in my experience this backchannel is rarely used.
"Yes, I realize that a murder count of 2,500 in a city of 1 million is horrifying. But look on the bright side. That means there were 997,500 people who were not murdered last year."
Managers take all of your reviews as input and determine a performance rating, which is a score in one of five buckets to indicate how well you're doing overall.
As of 2011, you actually get a score between 1.0 and 5.0. Almost everyone is between 3.0 and 4.0. The buckets are very large. "Meets Expectations" is everything from a 3.0 (acceptable for new hires, but damning if you've been there for a while) to 3.4 (slightly above average). If you're in this bucket, you don't know if you've been marked as a loser (and rendered unable to transfer) or are getting 65th-percentile ratings. You can literally waste 18 months on a loser project only to find you can't transfer because your boss gave you 3.0's.
These scores are also calibrated against other managers across the organization, to prevent managers from biasing their scores -- an individual manager can't game the system.
That's a nice way to present stack ranking. Each boss gets a finite number of calibration points and has to pick who does well and who doesn't. If he gets a crappy allotment and desperately needs to use all his points to promote the guy who'll do a startup unless bumped, you could get stuck with a (career-ending) 2.9.
----
The important thing to remember about Google's promotion process is that it's bicameral. Manager-assigned calibration scores are one component. Peer reviews are another. You need both to advance at Google. Google provides multiple paths to failure, not multiple paths to success. If your manager likes you and gives you 4.0+, you can still get dinged for lack of visibility. On the other hand, if your manager is giving you shit for calibration scores, all the peer review in the world won't get you out of the muck. I've known many Googlers to damage their careers by playing their manager but not the crowd, or vice versa. You need to play both games at the same time.
(dead man's switch: Discussing perf with you on hackernews is going to be a waste of time, I'll personally pay you $10K USD [or EFF, if you refuse] if I respond).
An "occasionally misses" expectations is by no means career ending. It's just a warning sign. It's not by itself a fireable offense (as an aside, even being fired by Google won't ruin your career, a friend of mine with a bad manager at Google got fired. He ended up pre-IPO at Twitter, and he is definitely doing well). I had an occasionally misses as L4. For me, I took it as implicit permission to get more attention from my manager. I'd bring problems to him sooner and make sure to be less stuck, including burdening him with more mundane problems I was having, and giving him more status to make sure I was moving in the right direction. I quickly hit meets, and I eventually hit L5.
Someone (or actually 2 people) said things akin to "You're only an L4, therefore you need to be working on this part of the project." Both were newly L5.
I told them "That is not how we do things at Google. If you believe what I'm working on is not useful, communicate what the priorities are for the project and I will pick something that is both interesting to me and helpful for you. If there is nothing on this project that fits into that category, I will find a new project."
In both cases, they looked abashed and backpedaled.
This is what an L5 would do. Try to work directly with the people involved to figure out a compromise solution, and if that fails, exercise other options. And sure enough, I was promoted fairly soon thereafter.
Anyone who has a particularly strong opinion (coupled with strong evidence) is likely full of crap, since it just recently rolled out across the company. By the end of the year it'll be more clear what the long-term effects are.
"If you want to get promoted, just start acting like someone at the next level up. Eventually they'll realize you're not being paid enough and will promote you."
--This sounds really bad. Like a slave trying to move more bricks to show slave-owner that he is not being paid enough.
When this was explained to me by a friend that works there recently, my immediate thought was "Oh. I guess that takes care of the Peter Principle." What incentive does a company have to move you from a position you are competent and useful in to a potion you are incompetent and useless in?
"I [think] I am already doing the work of one grade above me... at Facebook."
Is more often the case. It's interesting to see folks who act on that thought and find out they were mistaken. A manager of mine once quipped "The grass is always greener somewhere else, but sometimes that is because it's astroturf."
For a while, this was a really good way to become a millionaire. Then Facebook IPO'd and we had to settle for "I'm already doing Larry's job...for a startup."
Pretty much all companies have levels. Even if it's not something as set in stone as Google's 1-11, or Microsoft's 59+, there's almost always some sort of differentiator, from something as small as "Senior" or "Junior" to denote experience.
The levels don't work like that, as the blog post describes. They basically count for paygrade and job title, and that's it.
At Google you were basically expected to make all the decisions you had good information on, and you had access to a lot more information than people did at most companies. I launched the [blink tag] easter egg by socializing my ideas around a few peers who said "Cool idea, go for it", implementing it in my spare time, getting a code review, and then e-mailing PR, legal, and Amit saying "Hey, I'm planning to launch this easter egg in a couple weeks, any objections?" I had approval powers for putting stuff up on google.com myself, so in theory I could've launched it with just one other person's code review, but if you launch without approval and things blow up you (and your peers) will never ever be able to do cool stuff again, so it's a nice courtesy to keep the execs in the loop. (Although this rule has been bent before - [do a barrel roll] was launched without any execs' knowledge.)
Those points were covered in Matt's previous two articles on the subject.
But Matt is writing primarily for Researchers who leave academia for industry. They are a special class of people who tend to be more.... experienced with pushing back against management to achieve their research goals. However, the same idea applies equally to motivated low-level engineers who want to get things done.
> Especially, when junior can't report or discuss ideas with the manager, who can make decisions
Why do you think having levels prevents junior people from discussing ideas with their managers? Everybody has the chance to discuss anything with their manager at the weekly one-on-one meetings which are being held with people of all levels. Also, like the post says, your level determines your compensation, but not the potential impact you may have on a project. Nobody's going to actively prevent you from working on something because you're "not senior enough".
Sure, but that still doesn't explain it. Under the hierarchy, Junior would still be peers with Senior, and they would be under a manager. It's not like each person can only have one person under them.
>If you want to get promoted, just start acting like someone at the next level up.
This is the most ridiculous thing companies make u do
I start acting and working like a CEO will I become one ?
No I didn't down vote you, but in my experience that is exactly correct. If you start acting like the CEO you will eventually become the CEO. The tricky bit though is that often times people don't really know why the CEO acts as they do. And that is partly because there is information available to the CEO that isn't available to just anyone, and partly because the CEO is often balancing problems and opportunities that aren't necessarily visible to those outside their direct reports.
One of the first things I try to impress upon new managers is that their job is not about telling people what to do, rather their job is about getting the most done with the people they have on the most important parts of the problem. They have to take the whole set of possible things that could be worked on, and figure out the important ones to invest in. Sometimes the importance comes from being or staying competitive, sometimes the importance comes from keeping things alive long enough to get to the next milestone.
U live in a more idealistic world than I do
There is no point climbing someone else"s organized corporate ladder with 10 levels when u can do ur own experiments :)
Don't want to be an old man filled with regret on level 3 or 6
Oh boy. A google career thread on HN. I look forward to measured and thoughtful discussion. Definitely not going to be sidetracked by multi-paragraph rants from some familiar names. No, not this time.
Support is just as important as innovation. There's no point in having great ideas if they aren't maintained. Google doesn't seem to get this...