You have six teams building one product and they keep blocking each other. How do you coordinate the dependencies, and what do you make of frameworks like SAFe?

Reduce before you coordinate

The instinct almost every candidate reaches for is a coordination mechanism — a scrum-of-scrums, a dependency board, a weekly sync. Those have their place, and they come second. A dependency you have coordinated still costs you a queue, a handoff, a negotiation and a delay; a dependency you have removed costs nothing forever. So the first question is always why six teams cannot each ship a change alone.

Usually the answer is that the teams were cut along technical layers or along the org chart. A front-end team, a services team, a data team and a platform team guarantee that every customer-visible feature requires four teams to move in sequence, which is a structural decision producing what looks like a communication problem. Re-cutting towards streams of value — each team owning a slice of customer journey end to end, with the authority to change every layer of it — eliminates the majority of these dependencies rather than managing them. This is expensive, slow, involves people's identities and reporting lines, and is still the highest-leverage move available. Saying so, while acknowledging the cost, is the difference between a scaling answer and a meeting-scheduling answer.

Where a shared component genuinely must exist, change the mode of interaction rather than the schedule. A platform team that takes tickets and delivers in its own Sprint creates a synchronous dependency on every consumer. The same team publishing a self-service API with documentation and a versioning policy creates none — consumers proceed without asking. Where that is not yet possible, an internal open-source arrangement, where the consuming team writes the change and the owning team reviews it, converts a queue into a review. The pattern generalises: prefer a contract to a conversation, and a conversation to a queue.

Coordinating what is left

Some dependencies are irreducible, and these want mechanism rather than goodwill.

Make them visible in one artefact. A simple grid of teams against the next few Sprints, with each cross-team dependency drawn as an arrow from the producing team's Sprint to the consuming team's, exposes the two things that matter: which arrows point backwards in time, and which team is the source of a disproportionate number of them.

                Sprint 12          Sprint 13          Sprint 14
Payments        Auth API v2  ------> consumes ID svc
Identity        ID service        ID svc delivered  <-- arrives one Sprint late
Mobile                             needs Auth API v2 (blocked by above)
Platform        env for Mobile

That picture is worth more than the status meeting it replaces, because it converts "we are blocked" into "Identity delivers in 13, Mobile planned for 13, therefore Mobile slips or Identity is resequenced — decision needed this week, by the Product Owner." Every dependency should carry a producing team, a consuming team, a date and a named person on both sides. An unowned dependency is a surprise with a scheduled arrival.

Three other mechanisms earn their keep. One ordered backlog with one accountable prioritiser for the product is a precondition rather than a nicety; with six backlogs, a cross-team conflict has no forum in which it can be resolved, and it will be settled by seniority instead. A shared cadence, meaning aligned Sprint boundaries and a common Definition of Done across teams, so an integrated increment is possible at all. And continuous integration into one trunk with automated tests, because the deepest form of cross-team coordination is finding out within an hour that two teams' changes are incompatible, rather than at an integration phase. Teams that integrate daily need far less talking than teams that integrate quarterly, which is why organisations with weak engineering practice end up buying heavy coordination processes to compensate.

Finally, sequence to eliminate rather than to manage. If Mobile needs Auth API v2, the useful move is often to have the two teams build the interface together in week one, agree the contract, then stub it — so neither waits, and integration is a verification rather than a discovery.

An honest assessment of the frameworks

SAFe organises multiple teams into an Agile Release Train of roughly fifty to a hundred and twenty-five people, aligned on a common cadence, planning together at a two-day PI Planning event every eight to twelve weeks, with a Release Train Engineer facilitating and explicit roles for product management and architecture. It is the most widely adopted scaling framework in large enterprises, and the reasons are not cynical.

Where it genuinely helps: PI Planning is the strongest single intervention in it, because it puts every team in one room and forces cross-team dependencies to be identified, negotiated and owned in two days rather than discovered over a quarter — most organisations have no other forum where that happens. It gives executives a legible structure, and legibility is what buys permission for teams to work iteratively at all. It provides vocabulary and defined roles for coordination work that large organisations were previously doing badly and informally. And for a genuinely large programme with real technical interdependence, an aircraft system or a core banking migration, that structure is doing necessary work.

Where it adds process without flow: the quarterly planning increment is a large batch, and committing a hundred people to a plan for ten weeks reintroduces exactly the long feedback loop that iterative delivery existed to shorten — teams then defend the PI plan against learning, which is the failure mode to watch for. The role and artefact inventory is large enough that organisations adopt the structure and skip the practices, and SAFe without continuous integration, test automation and small batches is a reorganisation with new job titles. It is also frequently adopted as a way of preserving the existing management hierarchy while claiming a transformation, since the framework maps comfortably onto layers that a genuine change would have flattened. The commercial certification apparatus around it tends to reward compliance with the framework over improvement in delivery. And it does not address the structural problem in this question: a SAFe implementation over layer-cut teams coordinates a very large number of dependencies extremely diligently.

The alternatives are worth having a view on. LeSS keeps one Product Owner, one Product Backlog and one Sprint across up to eight teams and scales by subtraction rather than addition, which is intellectually cleaner and demands considerably more organisational change, since it explicitly removes roles rather than adding them — that is precisely why fewer enterprises choose it. The Spotify model was a 2012 description of one company's arrangements at one moment; Spotify staff have since said publicly that they do not work that way and never intended it as a framework, so a candidate presenting squads and tribes as a methodology is quoting a snapshot as scripture. Team Topologies is not a scaling framework at all but is more useful than any of them for this question, because its whole subject is designing team boundaries and interaction modes to minimise the coordination load.

The defensible position, and the one interviewers are listening for, is that no framework reduces coupling. Frameworks make coupling visible and give you a forum in which to schedule around it. If you install one without changing team boundaries and engineering practice, you have bought a very thorough process for administering the problem you already had.