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