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.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).