Development Teams in Scrum are supposed to be cross-functional, with all the skills as a team necessary to create a product increment. Often the team looks very cross-functional, yet seems to be unable to create what’s needed, even though all the required skills seem to be present. What could be going on? One of the possible answers lies in the ecosystem of the teams.

Does the team work in total isolation, without inputs from outside the team? Probably not. Can they change everything, without something outside of their field of responsibility breaking? Probably also not.
No one would want to be responsible for the workings of a business critical software API without having a clear definition for it, yet the ways teams interface with other teams are often very vague.
This vagueness results in a lot of communication just to figure out who can fix problems or whether something can actually be changed at all. Often it’s even hard to see who is responsible for something. A common sign of needless vagueness is indeed that the conversations revolve more around the ‘who/whose’ than around the ‘how’. The result is an organizational Big Ball of Mud. It’s possible to sort it out this situation out, but without a conscious decision, often responsibilities get hashed out only relating to the situation at hand.
It can be helpful to look at ways the team interacts with other teams and stakeholders as a system with multiple APIs. Some of these interfaces are actual APIs, which are defined together with another team that is running a related system. Some of these are tools or processes for interaction, such as the way a ticket system is used between the teams. Conversations take place, but thanks to clearer expectations and responsibilities, they are now more action-oriented.
However, taken too far this robs the organization of the chance of discovering and learning totally new approaches. Sometimes existing interfaces, in software or in division of responsibility, benefit of review where the current boundaries are questioned critically. Often the team will also have one or more relationships where the shared mutually owned ground is a powerhouse of creativity and value.

The relationship with some of the stakeholders, e.g. the relationship of the development team with the Product Owner in Scrum, are often best close, interactive and symbiotic. That way there is room for revision of the requirement based on what the development team knows about the cost of the implementation and on the other hand ideas can also flow upstream for further discussion on the business side.
There are maybe no hard and fast rules for choosing what kind of an interface a team should ideally have with another team. As a starting point for experiments, however, we can maybe use the following: The more trusting the relationship, the more flexibly interdependent it can be. The less trust, more distance, or the harsher the consequences of failure, the better a more clearly defined will work.
Depending on the teams involved, they might be able to renegotiate their interface on their own. When trust is low, the renegotiation requires mediation from a trusted outside party, who can especially help with dividing the areas of responsibility. Though this takes time and effort, the time saved cumulatively in the long run can easily be worth it.