Start with the coordination problem
I would use a Scrum of Scrums when multiple teams share an outcome and their dependencies cannot be handled effectively inside each team’s normal conversations. The goal is not to make every team report to a larger meeting. The goal is to resolve coordination problems that cross team boundaries.
Before adding the meeting, I would map the dependency, decision, or risk that requires a cross-team conversation. If there is no recurring problem to solve, the ceremony may be unnecessary.
Make the conversation actionable
I would ask representatives to bring only information that changes another team’s plan: a dependency that is late, an interface that needs agreement, a risk that needs escalation, or a decision that has a clear owner. I would keep the discussion focused on what happens next.
I would record decisions and owners, then route detailed work back to the teams. The representatives need enough authority and context to coordinate, but they should not become a permanent reporting layer between teams and stakeholders.
Inspect whether it helps
I would review whether the meeting actually reduces blocked work, duplicate effort, or surprise. If it becomes a status roll-call, I would change the questions, reduce the cadence, or replace it with a more direct collaboration pattern.
My bottom line
I treat a Scrum of Scrums as a temporary or evolving coordination mechanism, not proof that an organization is scaling well. The Product HQ technical product manager certification can help build this delivery fluency, and the Product HQ newsletter offers more guidance.