Keep your teams to max 10 people (counting the PO). Allow them to self-organize. Treat each other internal team's project the same way you'd treat an untrusted open source dependency. Ignore the article above. Thank me later.
Team A strongly depends on Team B's product to the point where their deliverables are impacted by Team B's, how do we collaborate in this case?
Team B depends on Team C's internal platform, how does this teams collaboration differ from Team A and Team B's situation?
Team D has a sub-team working on a highly complex sub-system (real-time ledger for example), this sub-team is growing, how should Team D interact and work with this sub-team?
Team E needs help from the SRE team with reliability and observability issues, how should these teams best work together and collaborate?
My point is, in all these situations, how these teams interact and collaborate will be subtly different based on the situation at hand. A "one size fits all" method of team dynamics simply won't work optimally in every situation. This is what books like Team Topologies are trying to help with.
A similar question arises from a team that depends on Qt for their GUI. How does a team solve any issues it might have coming from Qt? If you can answer that question, do the same internally.
If you are in a situation that does not work like this, you don't really have 2 teams, you have 1 dysfunctional team and no amount of buzzwords will help you.
EDIT: Also I work for a large enterprise company where these issues were identified :). If you have two teams, you have two projects, period, or you have 1 highly dysfunctional team. I've seen all the issues with Team A not being able to deliver because they depend on Team B which has 6 month release schedule.
The problem here is one of expectations. Team A should not be expected to deliver things that depend on things Team B has not yet delivered. How stupid is that even? The solution is to not ask for stupid things or realize that you're being stupid and adjust. "Hey higher management, we can't release because these guys have 6 month releases and we need their partial results now". Maybe higher management should listen?
Your "just let teams self-organize" is frankly too simplistic to cover the real-world complex environment of different team structures and roles.
How a data platform team works with stream-aligned teams is highly different from say how an enabling team, like a centrally reporting SRE team, works with stream-aligned teams. Or how a complex subsystem team (complex ml model) works with one specific team vs a team building something like "batch processing cluster self-serve/as-a-service" which can be used self serve via many teams.
Every situation requires different levels of communication, forms of communication, e.g. do you occasionally embed engineers in another team? Do you do some comms "in person"/sync versus all comms are async via Github Issues etc. Does the other team bring people to your standups or other similar meetings.
I would 100% that for certain combinations of teams, having people from one team embed in another team is massively, massively helpful, in other situations it sucks! For some teams, only relying on an API and async updates surrounding that API (requests to the api) is all the collaboration that is needed.
My point is that there is no "one size fits all situations" model here. And as someone with a lot of real-world experience in building teams and now running large Engineering orgs myself, I've seen this done well and badly many times.
That is a much harder problem, I agree. For that one I have no solution since it's not a problem I've tried to solve or seen solved.
Perhaps the article sheds some light on this more complex situation but unfortunately it's so drenched in confusing buzzwords that I cannot derive any knowledge from it. Maybe the book is a better source, I'll see if I can get my hands on it.
I think the best part to take away from the book are the pieces around cognitive load and how it can affect teams adversely if the team has too many "topics" or different major projects, and use that principle to break apart large teams. Then the remaining work is just looking at how those new teams communicate and collaborate in an effective manner.
If a team is consistently ignoring the issues posted by another and causing issues in the overall project, that's up to higher management to resolve and reprioritize things. Higher-management needs to collaborate and prioritize issues across teams, as their "own" team, since they should have a higher level overview of the project.
To make it a bit more concrete, lets say you have 10 teams of 10 people, each managed by a manager. Each of those teams is an independent "project". The 10 managers themselves form a team that has to ensure those independent projects form a coherent whole by organizing amongst themselves and prioritizing tasks across teams accordingly.
EDIT: this split can work (albeit poorly) at up to 3 levels deep, so ~1000 employees total on a "big project". If you can't make do with that many, you're screwing up somewhere, but 100 should be enough IMO.
What I'm talking about is different, it's not just 10 managers that "have to talk", it's 10 managers in the same team with the same goal. They just happen to each coordinate another 10 person team. I haven't really seen that done anywhere, but I've seen some chair shuffling that approximated it. Would love to see it taken to the logical conclusion.
Please let’s not confuse the record of a conversation with the conversation itself. I’ve seen tracking tools used in this way and it easily turns dysfunctional.