Engineering Team Structures

Why haven't we seen this play out in programming teams?

I share the same experience.I would even go further and say that when you have clearly set boundaries between teams in functional terms it goes bad. Like "backend/frontend", "dev/qa", "dev/ops" ,"engineering/business".For me the most effective thing that I see are cross-functional product teams that have their own goal to ship things and all roles within that team.Unfortunately not all software can be built that way and there i

what does this say about their internal teams working on the same thing?

haha, this explains. somehow the Teams team does not care, or the product/ops team is organized in a rigid way, hard to make some changes even the dev feels the inconvenience.

Perhaps because interoperability of a team is more important that one dev?

Things is: different teams/products/companies/... require different processes. There is no one size fits all.

Different teams work on different things.

In some companies teams are not divided in a way that follow technical faultlines, but rather after "product owners" so that the only valid divison lines are exteral facing superficial aspects.E.g. think a car company where you are not organized as "engine team" and "transmission team", but rather "sedan team" and "SUV team", and the engine and transmission just need to happen somehow.The microservices fad and "every team own their ow

I think maybe it has to do with having "product teams." There is no worry that we'd collapse if our EE or crypto experts left, we've got many more, just not on this team. And having one product per team is not typical except for specific "products" I happen to be involved in, for both practical (this software is written much differently than anything else for many reasons) and historical (this team at one point worked on a similar in some ways, completely different

You're not wrong, this is an issue! It's far from ideal, but it's also not unusal. Probably depends on team size and seniority as well.