[potatolicious]

This is it exactly. I'm a Xoogler also and you've nailed it on the head - honestly while there are many other narratives about Google they mostly feel like distractions to this core problem.

Google's management and leadership tenure is very short relative to other companies and the org structure is intensely unstable relative to peer companies. I lost count of how many "5 year plans" I went through that was summarily reset 1.5-2 years in because there was a leadership reorg.

Google has no product strategy for two reasons:

- leadership generally is much more interested in org-building than products. The nitty gritty of products is left to leaf node teams that have wide latitude to decide what gets built. This is great for individual autonomy and getting ICs promoted, but it's bad for products.

- any leader with an actual product strategy has no time to actually build it. It's practically guaranteed that the winds will shift and they'll be out, to be replaced by the next manager with their own vision and the need for a near-total reset.

I'm at a company now where leadership tenure is shockingly long (at least by Google standards) - and you see the payoff: multi-year strategies actually get built, actually pay off. Reorgs happen but is generally infrequent, and when they occur they are close to leaf node teams - rather than the wholesale "we're replacing all critical leaders" type that happens a lot at Google.

[jay_kyburz]

I've been reading this whole thread and playing my favorite game called "If I were CEO of Google this is what I would do differently"

It must be incredibly difficulty to evaluate how well people are doing, and how valuable peoples work is when only one or two departments make any money and everything else indirectly supports that work.

How do you reward people for doing boring maintenance work on existing products? How do you give people the time to build the products, but also keep them happy and well paid enough to prevent them being poached?

How to reward a talented engineer who's job it is to add some small feature to a massive product like Maps or Docs?

I can't help but think I would explode the company into thousands of tiny startups each managing themselves and their own budgets, staff, and salaries, and literately pay bounties for every little feature I wanted implemented. There is no ladder to climb, only bounties to claim.

[JohnFen]

> How do you reward people for doing boring maintenance work on existing products?

Maybe start by hiring people who don't find maintenance work boring? I've known tons of excellent engineers who very much prefer maintenance work.

[potatolicious]

This seems unlikely to work and in fact probably exacerbates a bunch of issues:

- it's impossible to collaborate across org boundaries. If each org has their own budget/staff/salaries and their sole source of income are claimed bounties, there is no incentive to contribute one iota of work that isn't related to a bounty they can claim. You can of course split bounties but a) then you have interminable fights about the exact way bounties should be split, and b) the meta-game likely still rewards only pursuing bounties that one's org can achieve by themselves, causing orgs to refuse to collaborate.

- orgs will become more and more short-term focused since claiming bounties is critical to survival. A smaller bounty that can be claimed in 4 months is better than a larger bounty that can be claimed with 2 years of work. This is extra true if the orgs compete with each other - your odds of being pre-empted is lower with a 4 month bounty than a 2 year bounty, where you can burn a ton of work only to get beat by another org. The meta-game will almost certainly heavily favor fast small features rather than long-term work, and will absolutely preclude self-disruption type projects that are both time-consuming and risky.

You can, of course, insert some layer of managerial judgment into this to offset the meta-incentive flaws in the system - so you can force investment in long-term projects and force inter-org collaboration, etc. But at that point you've replicated a traditional corporate structure, just with "bounties" in place of "promotions".

But most importantly a bounty-based system doesn't solve the core problem here: who makes decisions about the company's products?

In a bounty-based system like you describe, there would be some kind of central cabal that issues bounties - in essence determining what products and features should be built. But then you have some pretty obvious issues:

- does the central cabal know enough about the product domains to be the most qualified to make these determinations? Or will the products suffer because the cabal doesn't understand the product's domains deeply enough to make smart decisions about it? Does it not make intuitive sense that the people building the product knows more about it than a group of far-removed decision makers? How do you consider the views of those who are closest to the product and most keenly aware of its tactical needs, in balance with the views of those who are furthest, but have more inter-product and strategic knowledge?

- besides the problems of the cabal knowing what should be built, how does the cabal know what can be built? It is entirely possible for the cabal to issue bounties that are unimplementable (give me a system that can diagnose cancers with a 0% error rate!). Besides the challenges of a highly centralized product org knowing what the market wants, they would have little way of knowing what is expedient or efficient for the company to achieve.

Again, you can insert some layer of managerial judgment into this to offset the problems here, but again you'd end up replicating a traditional corporate structure.

[hintymad]

I actually don't believe 5-year plan would work. Great products are built, not planned. A plan to keep management patient for 5 years, though, will work better. In AWS, a newly launched service will not seek profitability but user growth for at least the first two years, if not three. And then the GM of the service needs to pursue profitability and margin, while keeping user growth healthy. That said, product features are planned on a 6-month basis, and GMs have have moving target of profitability as market conditions often change.

[potatolicious]

Agreed, in part - and agreed with the other poster here that great products are both.

Google tends to suffer from the worst of both worlds: an over-abundance of 5-year plans that do not offer sufficient interim value to justify their continued work.

Part of this is bad projections - Google projects are often highly-ambitious multi-year affairs with some interim checkpoints like growth rate, but those numbers are usually poorly estimated, poorly sourced, wildly overly optimistic, and don't actually pan out. So when the team inevitably whiffs the checkpoints by a wide margin entire products get shut down. This is at least one of the larger causes of the leadership churn I described above.

But yes, if your idea is that you can have a 5-year budget to go do [insert big ambitious thing] and management won't cry about it, that's a fantasy.

That said, the opposite is also not a great way to pursue a product - which mostly rests on the theory that pursuing near-term improvements repeatedly naturally wins.

In reality you want a mixture of long-term strategy with short-term tactics. Product teams that are too heavily in one direction fail for it.

[pg_1234]

To bring it back to the CEO question.

This is because they have a "caretaker CEO".

Google wa sitting on a massive cash cow, so they appointed someone who would just keep it ticking over.

In the face of an existential threat, like ChatGPT, they need someone who can actually drive innovation. Not innovate themselves, nobody expects a CEO to do that, just create a culture which has a hope in hell of rising to fend off challenges to the empire.

They don't have this.

That have a CEO who is only capable in "good times" ... along with most of the company.

Faced with sufficient adversity, they will need a CEO who can succeed in the face of adversity.

[potatolicious]

Ehh, I would not be hasty in blaming things on Sundar as a "caretaker CEO". My impression has been that this inability to ship started well before Sundar's reign, and goes into a core belief that the company has been built around since its early days.

The problem with Google is that far too much product authority is devolved into leaf node teams. But this isn't a quirk of Sundar's leadership, this is practically a shibboleth built into the DNA of Google itself. The idea is that autonomous teams of very smart people, given maximum freedom to pursue what they think is necessary, produces the best products.

This is one of the fundamental buildings blocks of Google and long pre-dates Sundar as CEO. And it is the thing that is failing.

What we're witnessing is IMO a repudiation of the idea that if you take smart people and "free range" them, they will spontaneously invent world-changing products. FWIW, I think the strategy has been clearly failing for a long time - the only product that came out of this system was Gmail. Quite literally everything else at Google that has survived the test of time was acquired (see: YouTube, Maps).

I think Sundar may end up taking the fall for being caught flat-footed, and surely as CEO he should rightly shoulder some of the blame, but Google's problems far pre-date him. It's also why I don't think the triumphant return of Larry and Sergey will necessarily fix things - they're the ones who instituted the system of autonomous teams.

[umeshunni]

The terms "Wartime CEO" and "Peacetime CEO" come to mind.

https://a16z.com/2011/04/14/peacetime-ceo-wartime-ceo/

[hintymad]

Yeah, my statement went too far. I was just trying to emphasize that many aspects of a product will emerge from iterations, therefore 5-year plan sounds a gross waterfall model. That said, some planning is needed.

[JohnFen]

> Great products are built, not planned.

Great products are both.

[Infinitesimus]

What company are you at now?

[pschuegr]

What company are you at now, if you don't mind me asking?