[abhayb]

All infra teams eventually become platforms. All product teams eventually become experiences. When viewed negatively this is called scope creep. I don't know what it's called when viewed positively but I expect the word "holistic" to be used unironically.

Org charts that ship a platform are default stable because everybody it a team or group is doing approximately the same things. Growth is less uncomfortable, advancement feels more objective, and individual developers are relatively interchangeable.

But what if a company needs to change? Now the stable org chart resists that change. By rejecting requests from client teams that are responsible for a new set of objectives. This recurses. One layer of platform can simultaneously be moving too slowly for the layer above and too quickly for the one below. Shear forces tear it apart and the organization finds itself with n (3 < n < 6) fewer platform engineers.

[user5994461]

In my experience having a formal platform structure helps tremendously to roll new solutions. When the platform officially provides something, everybody in the company can make use of it right away. Unlike the pet project that's being pushed by a random manager.

Breakthrough can be pushed by rolling a second library/framework/platform. Like AWS ELB and ALB. Then developers can adopt the later if it's so much greater, but they won't because it's 90% of the same and who wants to work on migrations?

Large organizations are fundamentally split apart. First part of the org wants A and B. Second part wants B and C. The developer team next floor is rolling their own thing to do C and D. All while features A and C are incompatible so it's impossible to satisfy everyone. There is no solution to resolve internal conflicts (except maybe reducing a large company to 20% of its current workforce).