An organisation runs nine stream-aligned teams, a platform team of five and an enabling pair. Each stream team holds a standing weekly 90-minute sync with every other stream team it integrates with, which currently means fourteen standing pairs, plus a weekly architecture guild. Senior engineers report 9 to 11 hours a week in cross-team meetings and every interface is described as "agreed in the sync" rather than written down. Review this. What would you remove, what would you change and what would you leave alone?

What is actually required

Two teams need a high-bandwidth channel while the interface between them is genuinely unknown. That is what a collaboration mode is for, and it is supposed to end. A standing sync that has run for a year is not collaboration; it is a human integration layer standing in for an interface nobody wrote. The tell is in the stem: the interface exists only in the meeting's shared memory, so the meeting cannot stop.

The arithmetic is worth doing out loud in the review. Fourteen pairs at 90 minutes, two teams each, is roughly 42 person-hours a week of senior time, about one full-time engineer, before preparation and context switching. Nine teams could in principle form 36 pairs, so this structure is already most of the way to everyone talking to everyone.

What I would remove

The pairs where the interface is now stable and the sync exists to confirm it. For each, the removal has a price of admission: write the contract down, add a consumer-driven contract test to the provider's pipeline, and publish a change calendar. Delete the meeting on the day the test lands, not before. Typically four or five of fourteen go this way inside a quarter.

The one change that matters

Convert mode by mode, and give every remaining collaboration an end date and an exit artefact — an interface document, a test, or a service the consumer can call without asking. A collaboration with no end date is an architecture decision made by calendar invitation. Cap the number of standing collaborations each team may hold at two, and make exceeding the cap a decision someone has to take rather than a thing that accumulates.

What I would leave alone

The guild, if it owns the deprecation calendar and the contract-test standard, because something has to hold the cross-team rules and that is cheaper than a central architecture team. The platform team's office hours, which look like a meeting and are actually the X-as-a-service mode working as intended. And the two pairs that are genuinely mid-discovery.

How I would argue this in the review

Not as a meeting-hygiene complaint. Bring three numbers: the 42 person-hours, the count of cross-team interfaces with no written contract, and the lead time for a change that crosses two teams against one that does not. The second number is the one that moves people, because it says the organisation's interfaces live in people's heads and will leave when they do.

Common weak answers

• "Reorganise the teams." A reorg leaves the interfaces unwritten and resets the shared memory, which is strictly worse for roughly two quarters. Write the contracts first; the structure is then arguable on evidence.
• "Cut the meetings to 30 minutes." This treats the symptom. The same decisions get made with less context, and the first production incident caused by a misunderstood interface restores the 90 minutes.
• "Appoint integration owners." A named human is still a human interface. Choose it only as a stopgap with a date by which the contract exists in the repository.