The Frequency

My rule of thumb is brutal in its simplicity: anything that involves disagreement, ambiguity, or emotion has to happen live. Everything else has to happen async. The cost of running this rule strictly is the cost of deciding upfront which bucket a meeting falls into; the payoff is most of your team’s calendar back.

The live category, for us at Dynaris: kickoffs of new projects with unclear scope, decisions where there’s real disagreement and the data doesn’t break the tie, performance feedback in either direction, and any conversation involving customer churn, sensitive HR matters, or compensation. Those four buckets get a real meeting because tone, hesitation, and follow-up questions matter, and async chews through them in 10x the time with worse outcomes.

The async category, which is everything else: status updates, project planning where the work has been scoped, design reviews where the prototype is concrete, code reviews, hiring debriefs after the structured interview, and the vast majority of “can we hop on a quick call” requests. We default async, and the burden of proof is on the person requesting live time to explain why this specific moment falls into one of the four live categories.

The single standard that kept flexibility high without hurting connection or delivery is what I call the “Loom-first” rule. If you would have called a meeting, your first move is a 5-minute Loom or written doc explaining the problem, your proposed answer, and the specific decision you need from people. If after that the thread can’t reach a decision in 24 hours, then you call the meeting. About 70% of the time we never call it because the doc surfaced the answer.

The boundary that matters most for connection: protect a single weekly live moment per team that is unstructured. Ours is a 30-minute Friday “show and tell” where people share something they shipped or learned. It’s optional, low-pressure, and it’s where culture actually transmits. Async works for productivity, but humans need at least one place to see each other being themselves.

Running a fully distributed team across multiple continents forces you to be very deliberate about when you actually need people in the same moment. The question I ask is simple: does the outcome of this conversation depend on reading the room, building trust, or making a decision together in real time? If yes, it happens live. If the goal is sharing information, gathering input, or refining something already drafted, it can be async.

The one standard that has kept flexibility high without hurting connection is our weekly whole-company call. Everyone joins, regardless of time zone. We handle company business briefly, then we play a trivia game or do something that lets people laugh together. After that, people share photos from their weekend in the chat. That last piece sounds small but it does a lot. You get to know people as humans, which makes async collaboration feel warmer and faster throughout the rest of the week.

What we found is that you actually get more face-to-face time in a remote-first setup than you do in a physical office, because there is no hallway barrier to jumping on a short call. People are available for spontaneous video catch-ups all day. The live moments feel more meaningful because they are chosen, not accidental.

The underlying principle is this: protect synchronous time for what only synchronous time can do. Async handles the rest. When you hold that line, flexibility stays high and connection does not suffer.

I usually separate work into two buckets: collaboration that benefits from live energy, and work that benefits from uninterrupted thinking time. Brainstorming, conflict resolution, onboarding, and project kickoffs tend to work better live because tone, speed, and alignment matter. Status updates, documentation reviews, and routine approvals are almost always better asynchronously because people can respond thoughtfully without constant calendar pressure.

One boundary that helped a lot was creating “decision windows” instead of expecting everyone to be online all day. For example, teams knew there was a shared overlap period for fast discussions and approvals, but outside that window people had flexibility to structure their workday around deep work or personal commitments. That kept responsiveness reasonable without turning remote work into permanent surveillance.

What surprised me most was how much team connection improved when live meetings became more intentional instead of constant. People engage better when they know a meeting actually needs human interaction, not just attendance.

Most of the year, my team is fully remote. We’re spread across cities, time zones, and different rhythms. And honestly, that works. But there’s one thing I refuse to do async: setting direction.

Every quarter, we get the whole team together in person for two days. We fly people in. We use someone’s home or a local venue. And we do the work that simply cannot happen over Zoom.

Here’s why. There’s an old psychology experiment called the lottery ticket study. Researchers split people into two groups. Group A got handed a lottery ticket with a number on it. Group B got to write their own number. Mathematically, the odds are identical. But when researchers tried to buy the tickets back, the people who wrote their own number demanded five times more money.

Five times more committed. Just because they wrote it themselves.

That’s what happens when you let people participate in setting direction versus handing them goals. And that participation requires live interaction. It requires reading the room, debating in real time, watching someone’s face when they disagree but haven’t said it yet. You can’t do that async.

So our quarterly offsite has four components. One: reviewing strategy and metrics. Where are we, where do we need to be. Two: team building. We run our own leadership games so people see each other’s work. Three: identifying the biggest lever for the next 90 days. What’s the one problem we need to solve? And four: a hackathon. We pick a problem and solve it together that afternoon. Cross-pollination. The kind of collaboration that doesn’t happen when everyone’s in their own silo on Slack.

The boundary that kept flexibility high: Everything routine is async by default. Status updates, progress reports, simple information sharing. None of that requires synchronous time.

But anything that needs debate, decisions where you have to read the room, complex problems that require real back-and-forth, conflict, relationship-building? Those are live.

The test I use: Does this need to be a conversation, or can it be a memo? If people need to react, push back, build on each other’s thinking in the moment, do it live. If they just need to absorb and process, write it down.

Remote work isn’t about eliminating in-person time. It’s about being ruthless about which moments actually need it.

Live and asynchronous collaboration differ primarily based on the required emotional nuance of the task and the required levels of agreement for completion. In particular, any task requiring a high degree of resolution through collaborative problem solving; resolution of interpersonal conflict or building consensus around a strategic direction should be conducted in person. There is a significant risk that using asynchronous communication (such as email) for these purposes can produce ambiguity as a result of lag time in response and also lacks the benefit of non-verbal communication. Conversely, tasks that require only the transfer of information, status updates, or initial creation of documents should only be done asynchronously. Using in-person meetings for simply providing status updates is an operational burden on high-performing teams. If all you are trying to accomplish is the transfer of information, you should do so in a manner that allows you to preserve the recipient’s focus on their work by using a searchable and documented thread.

To achieve high flexibility while also ensuring successful delivery of work, we have developed a “Core Overlap Window” approach instead of requiring synchronous availability for the entire work day. The development of a set time period (4 hours) during which members of the team will be “reachable” removes the friction of scheduling across geographically dispersed teams while providing a large uninterrupted block of time for team members to perform work. The result is a regular cadence that respects the need of individuals to achieve a “flow” state while ensuring that team members remove collaborative bottlenecks quickly and consistently. Flexibility is therefore turned into a well-defined and intentional asset and a team’s ability to build connections through productive and meaningful live interactions is also enhanced due to reduced fatigue caused by constant and low-value opportunities for connection.

I run a fully remote consulting practice and have worked remote for over a decade, so this is a question I get asked a lot by clients setting up their first distributed team.

My filter is simple. If the moment requires real-time judgment, it goes live. If it requires real-time information, it goes async. Decisions, hard conversations, conflict, and creative brainstorming need synchronous time because tone and back and forth matter. Status updates, project handoffs, weekly reports, and “FYI” messages should never be a meeting. Most teams get this backwards and burn their calendars on updates that could have been a Loom or a shared doc.

The one boundary that has kept flexibility high without hurting delivery: default async, opt in to live. Meaning, no recurring meeting survives unless someone can name the decision it produces. Standups, weekly syncs, status check-ins, all of it has to justify the live time. We replace them with a daily written async update and protect two synchronous windows per week for the things that actually need a room.

The result is fewer meetings, more deep work, and the team still feels connected because the live time we do keep is high quality, not performative. Flexibility holds because people can shape their day around their life, not around someone else’s calendar invite.

The standard that’s kept our team’s flexibility high without hurting connection or delivery is locking the entire business to one time zone, regardless of where anyone actually lives.

We’re a fully distributed web agency with team members in Costa Rica, the U.S. East Coast, and India. We’ve had people in Mexico, Argentina, and Virginia at various points over the past decade. Early on, I learned that the fastest way to create confusion in a distributed team is by letting everyone speak in their own local time. So we don’t. Every calendar invite, every deadline, every conversation happens in Eastern Time. Nobody has to wonder whether I’m talking in my time or theirs. There’s one clock, and it’s the business clock.

Once that’s locked, the question of what has to be live versus async gets simple. Almost nothing has to be live. Our India team has one standing weekly call at a time that works for both sides. The U.S. team and I communicate asynchronously throughout the day. Client kickoffs, scope conversations, and anything where tone or judgment matters happen live. Status updates, code reviews, and most internal decisions happen in writing, in our project management system. Nothing is urgent unless we’ve defined it as urgent, and we’ve defined what “urgent” actually means, so the word doesn’t get abused.

The piece I’ve held firm on is that I absorb the time zone gaps. If an early call with India is needed, I’ll take it. If a client wants a late East Coast meeting, that’s mine. As the owner, the flexibility burden is my job, not the team’s. When that gets pushed down to employees, they quietly burn out, and you don’t find out until they’re halfway gone. The norms aren’t about tools or platforms. They’re about who carries the burden of flexibility.

For us it really comes down to two things: where the team is in its lifecycle, and what kind of activity we’re talking about.

On team stage: when people are still getting to know each other and we are still learning about them, we do more live activities. Even a remote version of mob programming has been part of the mix in earlier phases. When the team matures, async allows for better focus. And even in mature teams, when you go through a reorganization or crisis phase, you’re basically back to square one on the live side. The trust that makes async work resets when the team dynamic changes.

On activity type, our clearest rule is: no meeting without an agenda. If you can’t articulate what needs to happen on that call, it probably shouldn’t be a call. Meetings are for discussion and decisions, not for information people could read on their own. We ask people to prep individually before joining (we’ve been using Claude Cowork for this lately, making sure everyone gets debriefed on the same information before a meeting, and it’s been super helpful), and then the live time goes toward actual alignment.

Decompression and team building can be async (sharing memes, anyone?) but there is so much richness in doing live activities from time to time (we are really distributed geographically, but if we can even get together at one location, it gets really special). Training we keep self-paced, and then we get together not to go through theory but to talk about implementation and brainstorm how to squeeze whatever we are learning even more.

Flexibility stays high when the live time you do protect is actually worth protecting.

I’d argue the decision isn’t really about live versus async. It’s about who pays the cost of synchronisation.

Every live meeting transfers the cost of one person’s question or update onto the calendars of everyone in the room. Sometimes that’s the right trade. A senior decision, a hard client conversation, a cross-team alignment moment. Often it isn’t. Someone wants a quick answer and the easiest path for them is to drag five people into a thirty minute slot.

The norm that’s worked is a small bit of friction in the other direction. Booking a live session for more than two people requires a written reason and a named outcome. Booking async, the default, requires neither. That asymmetry shifts behaviour quickly. People discover that most of what they thought needed a meeting actually needed a three-line message and an hour to wait.

The connection point looks after itself if you’re deliberate about it. We do one short weekly call with no agenda where people just talk about what they’re working on and what’s annoying them. That’s where the team feeling comes from. It’s not the same thing as productive collaboration, and confusing the two is why so many remote teams either feel cold or drown in meetings.

We make collaboration live only when delay would create rework or weaken trust. Everything else should be written down and handled async.

In software projects, the moments that need people in the same call are usually discovery, sprint or milestone planning, scope tradeoffs, architecture decisions with several possible paths, demos, and conflict resolution. These are moments where tone, questions, and fast clarification matter. A written comment thread is too slow when the team is deciding whether to cut a feature, change an integration approach, or move work between milestones.

Status updates, technical notes, design feedback, QA findings, and most task clarification can happen async. We work with Scrumban on many projects, so the board, task descriptions, acceptance criteria, and comments carry most of the daily context. That lets developers protect focus time while still giving managers and clients visibility.

One boundary that helped us is simple: live meetings must produce a decision, not just information sharing. If the purpose is only to report progress, it goes into the tracker. If a meeting is needed, it has an owner, a concrete question to answer, and a short written summary after it. This keeps flexibility high because people don’t have to join calls just to prove they’re working. It also protects delivery because important decisions still happen with the right people present.

My advice is to separate connection from control. Remote teams don’t need more meetings to feel connected. They need clear written context, predictable live rituals, and fast escalation when a decision is blocked.

We set a strong boundary around response expectations. Flexible work only works when people are not trapped in constant urgency. We made it clear that no one needs to reply immediately unless it is business critical. Messages are meant for thought and not for interruption and any deadline must be stated upfront.

This boundary protected focus and made flexibility real instead of just words within teams. People stopped reading silence as disengagement because expectations were clear. Managers planned better and documented work more clearly over time. Team members had more time for deep work and delivery improved as urgency became rare and accountability stayed strong especially in hybrid settings overall.