never gonna join the mice race
The Google incentive mismatch: Problems with promotion-oriented cultures
571–580 of 613 posts
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#572Earlier quoted context omitted.
Yeah from what I've heard you ideally want to hit 70-80% of your OKRs, and people game it to make sure they fail at one or two so they don't get accused of being "too easy".
One of the most hilarious things I've ever seen was the head of Google Plus loudly sharing his "1.0 OKR" regarding social adoption at TGIF. It was about that time folks got suspicious and some long-termers found out Vic was lying about adoption rates.
Oof. Is that really why he got canned. I'd always assumed Gundotra just made too many enemies during the period where L&S empowered him to do whatever it takes to win in social, and when he didn't win, he had burned too many bridges to stay. Lying about adoption is something I didn't hear before.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#573Earlier quoted context omitted.
Yeah from what I've heard you ideally want to hit 70-80% of your OKRs, and people game it to make sure they fail at one or two so they don't get accused of being "too easy".
I've never seen or even heard of anyone throwing their OKRs to avoid the appearance that they were too easy. In fact, you rarely hear about another team's grading of OKRs at all. Plenty of teams inside Google also set OKRs expecting/hoping to hit 1.0 so it wouldn't be at all surprising to see lots of 1's/near 1's on teams.
That culture came straight from Larry and Sergey. When I was there they would say at TGIF explicitly that if you score 1.0 they'd get suspicious because maybe you were setting goals that were too easy. Guess what, nobody ever got 1.0
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#574I've seen one case at Google where a Manager was going for promotion, in part based on some metrics claiming the product usage increased a lot. Someone found that the metric was broken and was overcounting, but the report chain was explicitly told NOT to fix the bug until the manager gets promoted. This was kept broken for months. He did get promoted to L7 (senior staff), since the metrics were very positive, even th…
Eh I saw worse than that. The last team I was on at Google before I left had metrics that for years genuinely got better, and these were real metrics users cared about, they weren't gamed or irrelevant (related to spam detection). Each quarter our manager would go to his managers and present the team's latest success. He'd show the metrics and say how they'd improved from last time. Praise would come down from on high. As time went by this little ritual become almost formalized, because said manager kept re-using the same presentation slides each time, just adjusting the numbers. And the praise was always the same. Morale was good.
One day, the metrics stopped going up. In fact they went down a bit.
What happened? The manager went to his manager and gave the exact same presentation, in which somehow the metrics were still great news and the team was still executing really well. And his managers didn't notice. The praise came back, just the same as it always did.
At that point me and one or two others on the team became very cynical and lost motivation, because we realized that nobody who influenced our careers seemed to have noticed what was really happening. Celebrating an endless series of utopian success stories, regardless of truth, was more important than tackling reality.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#575Earlier quoted context omitted.
I have been using git logs and cvs logs to see who does what, across hundreds of developers, since 1997. I don't understand how people, managers, claim to not be able to figure it out. And if people are doing work in an engineering organization that isn't backed by commits to some durable and versioned system, that is a huge red flag. They should probably not get promotions till they automate and make their work flow…
There is so much more to engineering than slinging code into the repo. Using commit logs as anything other than a superficial note of trivia is absolutely terrible for anything but the most junior engineers.
There is more to software engineering than just version control logs, but those artefacts should be accessible in the system somewhere, be they documents, diagrams, meeting notes, system logs (for software releases), etc.
There should be some way for a manager to see what someone has accomplished by the artefacts they have left on the company systems.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#576Earlier quoted context omitted.
I’ve openly stated that I want my retirement job to be an SWE3-ish role somewhere. High enough to have interesting, somewhat challenging work, but with negative desire to climb the ranks any further.
Can confirm, it’s a great choice. Step one, convince a FAANG/MAGMA to let you work remote at the same salary level you already have. Step two, move to an extremely cheap cost-of-living area. Step three, avoid promotion at all costs, and just fix bugs. Provide value, but _never_ get promoted. Every year come review season, talk about how your goals for the next year are to improve latency/perf/whatever. It doesn’t hav…
The demand for “reliably and undramatically accomplishes needed tasks” far exceeds the supply.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#577Earlier quoted context omitted.
> I guess you could switch the process to "promo after N years of not being fired at your current level" but that seems even worse. Ex googler here, and when I was there 4 years ago this was true of L3 and L4. My entire team was L3's and L4's. We spent literally all of our time on projects with no meaningful impact on the company, but that made for promo packets. 6 engineers focused on rewriting the form to input cre…
> 6 engineers focused on rewriting the form to input credit cards on YouTube for 3 years. Can you explain how this gets them promos? I feel like a promo-focused culture would result in 6 engineers creating a new server-side rendering framework so that they can improve credit card input rendering speed - possibly equally useless, but much more work.
> result in 6 engineers creating a new server-side rendering framework so that they can improve credit card input rendering speed - possibly equally useless, but much more work.
We didn't create our own, but we did migrate our codebase to a new server-side rendering framework twice in my time there.
Also, nobody on our team ever got promoted.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#578Earlier quoted context omitted.
>it is in fact the case that getting new stuff done is the only way to benefit the company I spent a few weeks just refactoring 6k lines of code into +- 300 lines on my current job. If my company was run by you, the best course for me woould have been leaving that mess around. Which would have led to either the same refactoring under far more stressful time constraints, or even more shit code by applying a band-aid i…
> Also, there are loads of features that were far easier to implement after the refactoring. Congratulations, you have demonstrated the value and made it easier to do something. As someone who has gotten promoted 2 times (and soon to be 3) primarily off of tech debt reduction and infrastructural improvements that don't themselves do anything, but drive future productivity, of course I think this is valuable. This kin…
>it is in fact the case that getting new stuff done is the only way to benefit the company
>[work that will] drive future productivity, of course I think this is valuable
These 2 aren't compatible. Seems like you've walked back on the former from this last reply.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#579Earlier quoted context omitted.
Reducing latency is mostly easy to measure, has directly understandable implications, is likely (and understood to be likely) quite difficult to pull off on a product like maps. It's basically a perfect promo packet project. The example given by the author - fixing lots of tiny features in sheets - is the opposite. Difficult to measure, lots of little and difficult to explain implications, sounds kinda easy - many in…
I disagree. Add a couple of these features, put them behind an experiment flag, and inspect metrics that matter. What usage are they getting? Do users in the experiment use the product more frequently? And for longer periods? If not, perhaps feature parity with Excel is not the highest impact project, despite the feature requests. If you are finding it hard to come up with measures that show impact towards your orgs'…
I guess this works for explicit features, but might not work for omissions, especially the tiny features and bugs.
Small annoyances might add up, and the GP's point is that this incentive system doesn't reward those who try to fix them. Unless... somebody's deranged enough to keep known and fixed bugs in a customer facing product behind an experiment flag to see how a small percentage of unlucky users would react...