[potatolicious]

+1 on this. Spent 4 years at Google including spending time as a TLM. Left around 2020 so my impressions may be a bit out of date. I spent time in both the Geo and Search PAs, and IMO Google's biggest problem is listless senior leadership.

Google's orgs tend to lack product vision - there's a lot of abdication to front-line teams to ideate, come up with their own ideas, and ship features. My VP-levels were AFAIK only dimly aware of what we were shipping and largely seemed only concerned with the people-management side of the org. There was a lot of focus on morale, promo tracks, effective team composition, and other topics to the near-total exclusion of anything about the products we owned.

Contrast with where I am now where the VP-levels I meet with on a regular basis have nearly encyclopedic knowledge about the products they own. What a breath of fresh air.

The net result at Google was that we shipped a lot of features ourselves with little guidance from upper management. A lot of stuff would get killed opaquely because senior management changed their minds about some overarching strategy. The level of high-level turnover at Google didn't help matters - every incoming new VP or Director would wipe the slate clean for their own multi-year plan, and then get promoted/demoted out of the position before it went anywhere. Rinse and repeat with the next senior leader.

Senior leadership was also naive and credulous when it came to major new initiatives. To get any kind of product idea past leadership (to the extent they engaged in the product process) the PMs would have to project wild metrics that didn't stand up to one iota of scrutiny, but was frequently just accepted. I strongly suspect this is part of why Google kills so many projects - it demands insane metrics to approve major initiatives, PMs dutifully submit said ludicrous projections, upper management credulously accepts it, and then of course the real numbers are nowhere close, and whole projects die as a result.

I feel very firmly that Google as a company needs a reckoning at the top levels if it wants to be a company that has any product credibility.

[JohnMakin]

This is the exact kind of fantastic, in-depth, objective review of leadership that would fit perfectly on glassdoor, only to be immediately removed.

[danaris]

The thing is, I don't think that the basic idea there—senior management being primarily concerned with making the organization work well for the people in it, with the people further down the ladder being the ones directly in charge of the products—is inherently a bad or unworkable one.

It just requires the senior leadership to openly acknowledge that it means they don't own the products, and shouldn't be the ones making decisions on them, at least not without extensive discussion with the people in the organization that do own the products. That includes decisions to kill off a product, for any reason other than a dire emergency.

The problem, as is so depressingly common, is that being higher up in the org chart makes them believe they are better, smarter people, who always know best. So they make decisions without getting the right information, and very frequently for the wrong reasons.

[potatolicious]

I pretty fundamentally disagree, though of course I don't think your argument is unreasonable for a smaller product.

For companies where products are relatively small and largely disconnected from one another I think your approach can work - senior leadership is largely concerned about maintaining the organization while explicitly delegating product ownership to team leads below.

The problem is that this falls part really quickly once the products reach a certain feature scale, and in fact attempts to do this is IMO responsible for a lot of the product incoherency in a company like Google.

For example, when I was there, there were multiple features that launched on Android Maps but never on iOS Maps. This was an example of shipping the org chart - the Android Maps team came up with the feature and shipped it, and the iOS team was separate and uninvolved.

Of course shipping one's org chart is not an exclusively Google problem and is very common - but it's a fundamental consequence of delegating product ownership downwards. The ownership of the Android and iOS apps were necessarily separate because of the sheer size of these products and their teams, and there is no effective way to coordinate between them.

Sure, theoretically everyone can play nicely and talk to each other and sell each other on how great of a feature it is - but realistically that just doesn't work. The coordination overhead between teams when there is no high-level forcing function is extreme and grinds work to a halt. In reality what you need is a VP or Director-level to say "we need this on both OSes, prioritize shipping this feature on both ends".

And that... definitionally breaks the notion of downward product delegation.

[danaris]

Mmm, I'm not saying I entirely disagree—I haven't worked at Google, or any organization of that size—but it seems to me that part of the problem here is not simply "shipping the org chart", but rather the fact that the org chart is poorly, well...organized.

Why should Google Maps be completely separate products for Android and iOS (and, potentially, web)? If you have one product, with...I dunno, something like multiple release teams? handling the different platforms, surely that helps to pool knowledge and maintain (rough) feature parity?

And honestly, I think think this focus on each product being its own entirely separate island is a big part of what's wrong with Google in general—it seems like it contributes to the pointless proliferation of mediocre messenger apps, for one thing.

[potatolicious]

> "Why should Google Maps be completely separate products for Android and iOS (and, potentially, web)?"

There are multiple reasons for this, but the most important one for this discussion is pretty simple: because of the number of people required to staff it.

You need to carve team boundaries somewhere - there are inherent limits to how many people a manager can manage, and how big of a team a single tech lead can effectively run. You can't have a standup with 50 people, and there's no coherent way for a single leader to track tasks across 100 people, but that's the kind of staffing required for products of this size.

A product like Maps is expansive - it covers anything from searching for places, walking directions, real-time driving directions, data ingestion, data quality, reviews, busyness indicators, recommendations, photos, street view, transit statuses, indoor navigation, etc etc. And that's a very cursory overview of what the app does. It naturally requires a very large number of engineers to create and maintain.

So out of sheer scale you must divide the team into some kind of structure. A floating pool of hundreds of engineers is clearly not feasible. So the question is how?

There are multiple schools of thought here: dividing by frontend platform is one way. Other companies divide functionally (i.e., the street view team owns street view across all platforms), but while there are pros and cons to each of these approaches, you can't escape the same fundamental premise: you have a lot of separate teams that need to coordinate.

And how those teams communicate, coordinate, and ship together is the job of the Director and VPs.

> "I think think this focus on each product being its own entirely separate island is a big part of what's wrong with Google in general"

Agreed! But this is another reason why you need to have Directors/VPs that are actively engaged in product (and in fact whose primary duty is to product) - they are the right level of abstraction where inter-product integration is decided. They are the ones responsible for making sure these products work coherently together and do not appear (or function) as islands unto themselves.

[spondylosaurus]

Having worked under a Google-bred product leader in the past... this explains a lot about the way they ran things.

By the time they left our org, our products were in the same shape (or perhaps slightly worse) as they'd been before this person came aboard. All of the PMs they'd hired ended up leaving not long after, in part because they were essentially yes-men and had no one to say yes to anymore.

[fatnoah]

Interesting. I spent time at another FAANG, and the product teams were very, very, very strong...among the best I've worked with. It was the Engineering leadership that was essentially invisible. I managed a team of 12. They knew the names and faces of every PM that intersected with our work (including the Director & VP), but none could name anyone in the Engineering hierarchy beyond my skip level. In my case, the above description of VP levels applied (IMHO) to the Engineering leadership, much to the same detriment.

[qohen]

every incoming new VP or Director would wipe the slate clean for their own multi-year plan, and then get promoted/demoted out of the position before it went anywhere. Rinse and repeat with the next senior leader.

Ah, the "bungee boss" -- straight out of an old Dilbert cartoon:

https://web.archive.org/web/20090122103825/http://dilbert.co...