The Meeting Cadence Is the Org Chart
By Mark Cohen
When people hear "distributed team" they often picture one large communication problem
Time zones
Video calls
The awkwardness of a room split across continents.
A structured meeting cadence, run properly, essentially functions as the org chart. If you want to know how a distributed team actually makes decisions, start with looking at its meetings and meeting cadence before you look at its reporting lines on paper. And if you want to understand an existing team this is a good place to start a review.
In my most recent iteration, we ran seven recurring meetings across our global delivery teams, and each one exists to solve a specific failure mode rather than to fill a calendar.
1: The 1:1 Meeting
The 1:1 between a regional lead and their counterpart in the delivery center is the back-channel. It exists so an issue can surface (and potentially be resolved) as an informal conversation before it has to become a formal escalation. This meeting should be weekly, or at least fortnightly.
2: The Leadership Sync
The weekly leadership sync, thirty to forty five minutes with both team leads and the product owner(s), exists to keep priorities and blockers visible across the whole group rather than sitting privately in one region's head.
3: Daily Standups
Daily standups, kept to fifteen minutes, exist purely to keep work visible and blockers named early. Standups were initially created as "stand-up" - standing meetings - to ensure nobody got too comfortable. They are not open-ended discussions, they should be very focused on progress, plans for today, and raising issues or blocker for resolution. The resolution is not done in the standup. All that is done is the naming of the issue and deciding who's going to be tackling it.
4: Product / Domain Knowledge Sessions
Then there is the meeting many teams skip - and it is one that matters for a distributed team specifically: a weekly (at least) product and domain knowledge session, an hour to start, where the team that has been running the product walks the newer team through how it actually works and why.
Every engineering role we move into a delivery centre arrives with strong technical skills within weeks. Product knowledge (how a system was actually built and why) takes months to establish. Business domain knowledge, the industry specific logic that only comes from years of dealing with real customers, takes longer still. A weekly session compresses knowledge transfer more than any onboarding document ever will, because it puts a live person in front of the gap in real time, alongside the person who can help them understand how to proceed.
5: Sprint Retro's
A fortnightly retrospective closes the loop on what is and isn't working, structured around three questions (taken from traditional Scrum):
What went right
What went wrong
What should we do differently.
6: Leadership Check-in
A leadership check-in brings the senior sponsors into the room to reinforce that the transition still matters to people above the day to day, and to catch organizational obstacles the working teams can't clear themselves. It works because those sponsors show up to support the meeting and let the working teams run it. This should start weekly, and can drop to monthly over time.
7: IT and Operations Sync
An infrastructure alignment cadence, between IT, DevOps and engineering leads on both sides exists because the fastest way to lose trust in a new team is a production incident nobody was aligned on how to handle. With ensuring monitoring, alerting, and response and escalation channels are in place, then operate this meeting on a regular cadence to ensure that this is all working as expected. This meeting is to address issues that existing processes did not catch, to ensure that the same problem does not occur twice.
Each of these meetings is solving for a specific way distributed teams quietly fail:
Silos that never get broken down, or new silos that emerge due to geographic- (or human-) disconnect
Expertise that never gets transferred
Priorities that drift apart without anyone deciding they should due to comms failures
Infrastructure risk that nobody owns because it sits between two teams instead of inside one, or ownership changed without adequate knowledge transfer, hand-over or ownership
We shouldn't treat the cadence as a rulebook. Teams should adjust it to their own needs, and I am always deliberate about ending meetings early the moment there's nothing left to discuss. But the underlying principle doesn't flex: if you cannot draw the meeting cadence of a distributed team on a whiteboard, you don't actually know how that team makes decisions. You just know what the org chart says on paper, and the org chart is usually the last thing to catch up to how the work actually happens.