This is interesting and nicely explained. I can't help but think that these models are the reason so many software products aren't properly optimized. The org structure heavily influences HOW things are built, and it seems that unless the org is a GM model with nicely defined apps for each team, then the product is split arbitrarily across teams, and the engineering becomes a mess because you have to patch everything together.
For example, one team takes care of users building profile pages, user widgets, etc., while another team builds the checkout experience that includes building user related features. That makes a lot of sense from the business side, but not so much from engineering side where software is abstracted based on function and other technical matters. The main issue is that ignoring these technical abstraction increases complexity and creates problems in the long run which require full rewrites of the codebases. It definitely impacts business, just not in a way that can be easily demonstrated in the short term.<p>It's almost like whoever is structuring the company's org model needs to know how to code and implement algorithms and data structures at the org level so that it aligns with what the teams are doing.<p>I wonder if there is a mixture of the two org models, or perhaps another model, that would allow engineers the ability to properly abstract the product, while business can still manage and connect it to the key metrics. I read how Valve (Steam) had some kind of model where contributors could switch teams easily and work on whatever they were interested. Not sure if this is still done, but I'm thinking some level of self-organization across the org could benefit the quality of the product while reducing the overhead in managing and structuring the org.