4 ms·

if that's the case, it doesn't explain why Google's software and product quality has been declining steadily.

tmp_anon_22 4y ago
User opinion is one of many success metrics that Google tracks but it isn't the most important one. Up until the recent recession their stock performance indicated that their product quality has been doing just fine.
- yakak 4y ago
  That's not a valid metric. Every effective monopoly has a climbing stock price while it's product quality is declining, this is why they have such a terrible time when there's finally a market upset, they can have decades of bad practices to overcome just to stop their descent.
- mikymoothrowa 4y ago
  Come on! Showing 4 more ads per video on YouTube would boost their stock price while making me hate YouTube PMs even more
kansface 4y ago
> if that's the case, it doesn't explain why Google's software and product quality has been declining steadily. Why do you assume that poor products are poor products chiefly because of code?
- xmprt 4y ago
  The discussion here isn't about code. It's about quality of engineers hired. If their software and product quality is steadily declining then that says something about their team. Perhaps they are incredible coders but don't have good business skills or "customer obsession".
  - kansface 4y ago
    > If their software and product quality is steadily declining then that says something about their team. My understanding is that Google internal politics are completely dominated by their promotion process [1]. I view the outcome of google products not as the result of poor hires, but the inevitable consequence of the organization's incentive structure. If pay (doubling or tripling) is dependent on launching new stuff, your best people will ship new stuff! If pay does not go up for maintaining old stuff, it will not be maintained. If pay does not go up for improving old products, old products will not be fixed. It doesn't matter which people you plug into that system, you will always get the same results. 1. https://news.ycombinator.com/item?id=31262428 https://news.ycombinator.com/item?id=31262428
nostrademons 4y ago
[Disclaimer: Two-time Googler here, obviously speaking only for myself.] Sure it does. Collaborative software development is a low-pass filter, not a high-pass one. If you put 100 people on a team and tell them to develop a product, the product quality will track the least controversial ideas, not the best. With more people, the set of uncontroversial ideas gets progressively smaller, and trends toward the features that nobody really cares about because those are the only ones that don't provoke strong emotional reactions. The simple fact that you added more people is what made the product shitty, not that the people were incompetent or poorly-skilled. I've been in design discussions where we've had a room full of incredibly accomplished people, folks who've written major open-source projects or launched consumer products with billions of users, and the eventual decision was more brain-dead than anything that any one individual in that room could've come up with. And everybody knew it too, but you don't want to piss off highly intelligent and accomplished people, so you make the decision that everyone can kinda live with rather than the one that will wow users. The lesson here should be "Don't hire unless you absolutely need to", not "Google hires stupid people."
- mountainriver 4y ago
  Yeah this is so true, I’m experiencing this at my current org. Does anyone have advice on how to avoid these pitfalls?
  - com2kid 4y ago
    Don't put 100 people in a room. Put 4 or 5 in a room max. You need a feedback loop to sanity check features some how, but you also need vision and the courage to release stuff that not everybody wants. Every good product I've worked on has had team members who thought the newest features were stupid. Too bad, you aren't the target audience, get over it. Accept that you'll be releasing features that are either wildly liked or hated. You are going to be hitting both ends of the bell curve more often this way, embrace and accept it.
  - jupp0r 4y ago
    Put some potential users of the product in the room. Show them mockups. Iterate. Get user feedback. Repeat.

User opinion is one of many success metrics that Google tracks but it isn't the most important one. Up until the recent recession their stock performance indicated that their product quality has been doing just fine.

yakak 4y ago
That's not a valid metric. Every effective monopoly has a climbing stock price while it's product quality is declining, this is why they have such a terrible time when there's finally a market upset, they can have decades of bad practices to overcome just to stop their descent.
mikymoothrowa 4y ago
Come on! Showing 4 more ads per video on YouTube would boost their stock price while making me hate YouTube PMs even more

kansface 4y ago

> if that's the case, it doesn't explain why Google's software and product quality has been declining steadily. Why do you assume that poor products are poor products chiefly because of code?

xmprt 4y ago
The discussion here isn't about code. It's about quality of engineers hired. If their software and product quality is steadily declining then that says something about their team. Perhaps they are incredible coders but don't have good business skills or "customer obsession".
- kansface 4y ago
  > If their software and product quality is steadily declining then that says something about their team. My understanding is that Google internal politics are completely dominated by their promotion process [1]. I view the outcome of google products not as the result of poor hires, but the inevitable consequence of the organization's incentive structure. If pay (doubling or tripling) is dependent on launching new stuff, your best people will ship new stuff! If pay does not go up for maintaining old stuff, it will not be maintained. If pay does not go up for improving old products, old products will not be fixed. It doesn't matter which people you plug into that system, you will always get the same results. 1. https://news.ycombinator.com/item?id=31262428 https://news.ycombinator.com/item?id=31262428

nostrademons 4y ago

[Disclaimer: Two-time Googler here, obviously speaking only for myself.] Sure it does. Collaborative software development is a low-pass filter, not a high-pass one. If you put 100 people on a team and tell them to develop a product, the product quality will track the least controversial ideas, not the best. With more people, the set of uncontroversial ideas gets progressively smaller, and trends toward the features that nobody really cares about because those are the only ones that don't provoke strong emotional reactions. The simple fact that you added more people is what made the product shitty, not that the people were incompetent or poorly-skilled. I've been in design discussions where we've had a room full of incredibly accomplished people, folks who've written major open-source projects or launched consumer products with billions of users, and the eventual decision was more brain-dead than anything that any one individual in that room could've come up with. And everybody knew it too, but you don't want to piss off highly intelligent and accomplished people, so you make the decision that everyone can kinda live with rather than the one that will wow users. The lesson here should be "Don't hire unless you absolutely need to", not "Google hires stupid people."

mountainriver 4y ago
Yeah this is so true, I’m experiencing this at my current org. Does anyone have advice on how to avoid these pitfalls?
- com2kid 4y ago
  Don't put 100 people in a room. Put 4 or 5 in a room max. You need a feedback loop to sanity check features some how, but you also need vision and the courage to release stuff that not everybody wants. Every good product I've worked on has had team members who thought the newest features were stupid. Too bad, you aren't the target audience, get over it. Accept that you'll be releasing features that are either wildly liked or hated. You are going to be hitting both ends of the bell curve more often this way, embrace and accept it.
- jupp0r 4y ago
  Put some potential users of the product in the room. Show them mockups. Iterate. Get user feedback. Repeat.