Its interesting to hear that such discussion, about starting with teams ahead of structure can happen.
In order to benefits from agile in large scale you have to empower independent teams, which means substantial change in architecture to decouple interlocked parts, and heavy automation on build/test/deploy lines.
Why change architecture — because you should be able to change small parts of systems without impacting others, but across multiple boundaries that usually are present in current architectures (consider opening account in bank, you need to change front end, back end, product catalog, core system and DWH — small change but in all parts).
Why use heavy automation? In order to allow small teams to test and then deploy small chunk of changes without invoking all the rituals of large release management.
And last but not least you should have only roles with Real Goals
- To add value to clients
- To add value to company (which is ultimately got from clients)
Which means that teams should be structured along the value streams. There should be no place for any other types of goals and KPI.