This all sounds nice but it's missing the concrete details and that's the most important part. "Build into core values wanting to create a culture where the end-user is the priority, not individual advancement up the ladder" Is there any non-exploitative way to interpret this? The only thing worse than wasting my time on features for promo rather than users is working overtime to make more money for those with signif…
The Google incentive mismatch: Problems with promotion-oriented cultures
81–90 of 613 posts
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#82Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#83Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#84serious question here - how does Apple deal with this problem ? Apple also survives on big bang releases - the next iphone, macbook pro, etc etc. But also is famous for not abandoning old phones. iphone 6 was still receiving updates in Dec 2021. so how does Apple manage this dichotomy ? or is the company level yearly release completely wipe out the need for individual "hard problem" solving ?
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#85Former Googler here. This person has correctly identified that a key reason why google sucks is that people very often... > choose between doing what’s best for users or what’s best for their career But the root cause isn't that people want to get promoted. It's that Google promotes people for the wrong reasons. Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving US…
You're rewarded/measured on two metrics - breadth and depth
- a depth metric - leadership in your own specific project team where you add features.
- a breadth metric - you've demonstrably shown that you've gotten other teams outside your own to contribute to your project effectively. Additionally and perhaps more importantly you must show that you can act in a supporting role on multiple other projects outside your own core project. Supporting other projects outside your core project include signing up for triage support, updating documentation, improving testing, etc. without frustrating the primary maintainers.
IMHO - focusing on depth as the only way to technical career progression leads to feature creep, ball of mud codebases with high barriers to entry and silo thinking.
Would be curious if/why this is controversial.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#86Quoted post unavailable.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#87In other words, "hire people who want to work hard for the founders at the expense of their self-promotion".
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#88Former Googler here. This person has correctly identified that a key reason why google sucks is that people very often... > choose between doing what’s best for users or what’s best for their career But the root cause isn't that people want to get promoted. It's that Google promotes people for the wrong reasons. Put very simply, the problem is that Google promotes people for "solving hard problems" not for solving US…
Another example of this is their OKR system. If you meet all your quarterly goals at Google, that's not a success. In fact, you're frowned upon for not setting your goals high enough. Their whole management process encourages people to chase after impossible goals, and literally discourages people from getting things done.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#89Quoted post unavailable.
Re: The Google incentive mismatch: Problems with promotion-oriented cultures
#90I used to manage engineers at another large tech company and this was a big problem. There was nowhere near enough big projects to get everyone the evidence they needed for promotions. As a result we ended up doing two things a lot: 1) over-engineering a feature that should be simple into something with architectural significance (e.g. a new set of services that could have just been a feature in an existing service)…
> 1) over-engineering a feature that should be simple into something with architectural significance (e.g. a new set of services that could have just been a feature in an existing service) Ideally this gets people fired, not promoted. Google explicitly calls out "solutions to hard problems are easy to maintain" on its ladder, for example. People can fail to identify these cases, but the intention is to promote based…
I've seen real bugs that bounce around for months, each time to someone who looks decides it isn't in their code and points to someone else: eventually we tell one engineer to solve it an a few weeks latter she traces it down through many different layers to figure it out. I've seen other cases where a great engineer spent weeks fixing bugs only slightly more complex a misspelling. In the end what counts it the quality of the product not the effort put into it.