Live data from Hacker News

The Google incentive mismatch: Problems with promotion-oriented cultures

warp.dev

81–90 of 613 posts

Re: The Google incentive mismatch: Problems with promotion-oriented cultures

#81
post #8

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…

Why combine two problems working overtime without compensation and promotion focused culture?

Re: The Google incentive mismatch: Problems with promotion-oriented cultures

#84

serious 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 ?

Does Apple even promote on solving "hard" problems?

Re: The Google incentive mismatch: Problems with promotion-oriented cultures

#85
post #43

Former 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…

At least in my own small company - I'm hoping to promote the concept of the T shaped technical leader ladder.

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

#88
post #72
post #43

Former 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.

Missing OKRs always seemed a little weird to me. It strikes me as a lack of vision and makes the numbers and goals chosen seem very arbitrary.

Re: The Google incentive mismatch: Problems with promotion-oriented cultures

#90
post #5

I 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…

Do they consider fixing easy bugs are hard problem? Should someone ignore a bug report "The is not spelled teh?" until it has bounced around unsolved for months on end, then spend 2 weeks "investigating" to show that it is a hard bug?

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.

Post reply on HN