4 ms·
It's frustrating that this thread seems to be focused so heavily on people sitting around resting and vesting. Having been inside Google (and multiple other FA
by potatolicious 4y ago
It's frustrating that this thread seems to be focused so heavily on people sitting around resting and vesting.
Having been inside Google (and multiple other FAANGs) this is generally untrue, and focusing on this element of the problem misses a much larger productivity problem:
Most engineers at Google aren't "sitting around doing nothing", they are very busy shipping projects that do not matter. Their days are filled with doing work that will not move the needle on any metric that matters to the company, but they are far from idle.
The misallocation of labor is a far bigger problem than said labor slacking off, and management must own it.
Google doesn't need their engineers to fly into startup mode, work 12 hour days, or never surf Reddit on company time. Their labor is severely under-utilized because they are assigned to zero/negative-impact projects or duplicative projects (hey, somehow you gotta ship 5 chat apps at the same time, right?)
Part of the problem is that Google's upper management refuses to engage with the product at all. Entire orgs are given very broad OKRs like "increase DAUs by 10%" without virtually no guidance as to what features management is interested in. Authority to ship features also rests close to the leaf nodes of direct line-managed teams. The expectation is that teams are entrepreneurial and invent features, implement them, and ship them all without direct upper management involvement.
The result is a bunch of bad product that doesn't do anything positive for the company, were never soberly evaluated by upper management prior to building, and would never have passed the smell test if it did. This, above all other factors, is why Google produces so much product that it then has to scrap. This is the main cause of Google's low labor productivity - not because people are sitting around drinking coffee and eating free food - but because they are assigned to projects that do not pass muster, and there is an almost-comical aversion to validating product ideas before they are implemented.
The single biggest thing Google can do to improve its labor productivity isn't cracking down on slackers, it's forcing its management to actually engage with product definition so entire orgs don't burn years on things that don't matter.
- clusterhacks 4y ago>Their days are filled with doing work that will not move the needle on any metric that matters to the company This, 100%. I think this simple observation reverberates across the entire software engineering field and at many (most?) non-FAANG companies as well. I am not confident there is a real solution to the problem of making sure people only work on things that matter. Medium to small organizations seem to struggle with having management even understand what "good" product looks like or how to optimize for that outcome.
- potatolicious 4y agoYeah, I think it's massively under-discussed that product management quality across the industry is generally very poor. There are multiple manifestations of this but the main factors IMO are: how involved is management in the product? How good is your product definition process and talent? For big companies the problem tends to be more the former. Product management talent tends to be solid, but upper management is checked out of the process and instead overly focused on non-product areas of the company. Product management functions (PMs + engineers) tend to be flying alone with low external guidance. For small companies the problem tends to be the latter. Product management is deeply enmeshed with upper management (because what else would upper management be doing at that scale?) but they are bad at it. Both result in shipping the wrong product. For startups shipping the wrong product is deadly, but for large profitable companies they can keep shipping bad product for years. IMO this is where Google is at - they fundamentally do not have the institutional capacity to ship great product. My impression (which is a few years old now since I left Goog) is that management understands the problem exists, but seem to believe that they can fix it by iterating on the product management process, but in a way that does not require SVPs and VPs to directly engage with product. I fundamentally disagree with this premise - it is not possible to ship product in a coherent manner with a surface area this large unless the most senior levels of management directly engage with product management. And ultimately poor product definition and prioritization is an order of magnitude greater source of low labor productivity than any kind of individual-level slackage.
- spacedcowboy 4y agoFWIW, I don't think this is the case at Apple. I sit in with the product manager as they get grilled by VPs and SVPs. They get damned hard questions - mainly the short ones ("why", "what if" and "how", and to a lesser extent "when" and who") and part of my job there is to provide data for their cover. I've given demos to SVPs before, and it's not a pleasant experience, I'm very happy to leave it to the PM. Sometimes my job is to gently point out to an SVP that his/her assumptions are wrong, but most of the time I stay out of the way. The PM puts together the slide-deck (usually with help from engineering management) and the PM presents it, though (s)he can call on others for expertise for specific sections. PM's have to be very good at defending the direction they want to take the company in, and the top brass are scarily good at coming up with the hard questions, even when those questions are very domain-specific. In any event, (S)VPs at Apple are very invested in what the company does, when it will happen, what the consequences are, and why we're doing X. Directors and Managers are the ones responsible for execution, and the concept of a DRI is very very important in Apple culture.
- strongpigeon 4y agoThis resonates strongly with my experience at Google as well. Specifically in ads, you got the feelings that none of the product leadership used the product or tried to drive a direction for where the product should be going. The end-result was full-on Conway’s law (every team having their own separate pages), weird overlaps between a bunch of things (P-Max, Smart and App campaigns) and no real goals except maximizing metrics such as $$$ and # of campaigns using automation. Of course, when Google Ads is the only way to buy ads on Google Search, revenue will go up regardless of whether Google Ads is a good product. Advertiser will go through any hoops if those ads make them money. But then revenue goes up, the leadership pats themselves on the back for a job well done, plays musical chair a bit and let the product turn into an even bigger pile of mush.
- UweSchmidt 4y agoIt must be a different eponymous law: https://en.wikipedia.org/wiki/Godwin%27s_law https://en.wikipedia.org/wiki/Godwin%27s_law
- strongpigeon 4y agoHah, my bad. I meant Conways’ law
- chocolatemario 4y agoI feel that in real terms, you are absolutely correct. Big tech companies consciously over-hire and throw away work with impunity knowing it will not hurt their bottom line. Denouncing employee productivity like this just seems like an excuse to trim some fat indiscriminately during economic downturn instead of attacking the root of the problem as you suggest they should. They obviously should try to fix the wasted work problem, but that is undoubtedly more difficult than overprovisioning your workforce and dialing back during times of economic duress.
- deleted 4y ago[deleted]
- celestialcheese 4y agoSeriously - the misallocation of resources in areas of Google is insane. And then there are niches of the Google Cloud product that are seemingly woefully understaffed, or just negligent in their maintenance. I was a gcloud customer for years, happily using the App Engine Flexible for a PHP apo. It wasn't perfect, but it did it's job autoscaling and managing a decent sized consumer app. For years there wasn't much like it in PHP land where you could get away with doing very little sysadmin/cloud arch and get the features they offered. But then support just _stopped_ around 2 years ago. The official docker images are still stuck on PHP 7.3 and there has been no updates or support for nearly 18 months in upgrading to 7.4, 8.0 or 8.1.. [1] AppEngine wasn't some vaporware at gcloud, it was one of the OG products, yet their perfectly fine letting it just rot and officially support a version of PHP that's a year outside of security patches. I was spending nearly $80k/yr on that product + the rest of the cloud spend that comes from tying yourself to a cloud vendor. But this issue was so bad that I invested the time migrating off appengine and google cloud to another vendor. There are people internally assigned to this, but either complacency or lazyness or poor focus the details cost them a customer. 1 - https://github.com/GoogleCloudPlatform/php-docker/issues/530 https://github.com/GoogleCloudPlatform/php-docker/issues/530
- antipaul 4y agoYour mention of “upper management” engagement in decisions seems counter to what I hear all the time, about an (upper) management philosophy of “getting out of the way” to “empower” “people close to the ground” and “delegate decision making” And yet, I am with you: shouldn’t the top (smartest?) people be closely involved “in the weeds”? It seems like “design dictators” [from another comment] and such could actually make the org’s products a lot better. Which seems to be the philosophy at Apple: “experts leading experts” – as a reply here says, and the article in [1]. Thoughts anyone? [1] https://hbr.org/2020/11/how-apple-is-organized-for-innovation https://hbr.org/2020/11/how-apple-is-organized-for-innovatio...