Cross tribe prioritisation

In the so-called Spotify model there should not be a high dependency between squads, let alone tribes. It relies on having a system architecture which facilitates this decoupling.

The Nexus model encourages teams to self-organize in order to manage their dependencies, where they exist and cannot be further minimized. Having an appropriate architecture is one of the controls which allows them to do so. It isn't just about prioritization, and it will often be necessary to first de-scale essential capabilities so they are brought within a team.

Well, to begin, from what I understand of the tribes model each tribe should be self-sufficient.  The goal of the tribes system was to remove dependencies and allow a tribe to build and deliver.  Granted they use the phrase "be autonomous but don't suboptimize" (I think I got that right).  But they do their best to eliminate cross tribe consistencies instead of making a process to deal with it. 

But in your reality it seems that your organization has chosen to have a slightly different model.  I would suggest you look into Nexus or LeSS for examples of how to deal with this. Pay attention to their Planning/Sprint/Review/Retrospective cycles. Neither is going to give you an exact answer but both will have some parts you may be able to use and adapt. You could always look into SaFE but that is really big framework and would take some considerable effort and time to adopt. All of these scaled frameworks were created to help with problems like you are encountering.

Ultimately this prioritization across tribes is going to fall on the Product Owners to deal with.  Since the order the product backlogs, it will be up to them to make sure that cross team PBIs are ordered properly to ensure the tribes are delivering the correct value for the organization.

David,

The general consensus is tribes have a good degree of autonomy, and therefore generally self-sufficient.

A high dependency across tribes

is likely symptomatic of a structural issue.

Taking a step back, isn't this a general question on dependency management, Spotify or not? Of course, ideally there shouldn't be any significant dependencies between tribes (or even squads), but in reality it is usually unavoidable.

In the Scaling Agile @ Spotify paper (PDF), page 6 describes steps they took to manage this. The periodic dependencies survey sounds like a good idea to surface the issues squads are facing, as well as the on demand scrum of scrums to discuss these issues. Recall the 'individuals and interactions over processes and tools' value in the Agile manifesto. If the dependencies and misaligned tribe missions cannot be resolved through regular interaction, then in my opinion it's time, with survey data in hand, for senior management and/or tribe leads to get involved to resolve this. It may require 'reprioritisation, reorganisation, architectural changes or technical solutions' (quoting from the paper).

It's worth bearing in mind Conway's Law. Quoting partly from Conway's law,

If the parts of an organization (e.g., teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble...

There is also the Inverse Conway Maneuver:

The 'Inverse Conway Maneuver' recommends evolving your team and organizational structure to promote your desired architecture.

I have had a somewhat similar experience in an organisation I used to work for. There was an operations team separated from my scrum teams by more than 5 time zones, and there were issues with dependencies with the former. Long story short, the organisation decided to hire operations engineers to co-locate with my scrum teams, and it worked great. There wasn't a problem with independent or misaligned missions, but it is an example of reorganisation to alleviate dependencies.