14 Reasons Your Async Team Keeps Falling Back to Meetings

Most teams that commit to async work hit a six-month inflection point where meetings start creeping back onto the calendar. Each individual meeting has a good reason. The cumulative effect, six months later, is a team that has rebuilt most of the meeting overhead they were trying to eliminate, with the added confusion of now being neither fully async nor fully synchronous. The team has the worst of both worlds, and nobody can quite explain how it happened.

The fourteen reasons below are the most common ones we see. Each is real — these aren't strawmen — and each has a treatment that doesn't require reverting to the meeting. If your team is recently asynchronous and starting to drift, recognizing the patterns early lets you address them without rebuilding the meeting culture.

1. Async discussions don't converge on decisions

A discussion runs for three days in Slack or a Notion comment thread. People raise concerns, others respond, but no decision emerges. Someone eventually says "let's just hop on a call" and the call resolves in twenty minutes what three days of async couldn't. The team learns that async is good for ideation and meetings are good for decisions. This is half right — but the fix isn't more meetings. The fix is named decision-makers who close async discussions with an explicit ruling, even if not everyone agrees. Discussions don't converge on their own; someone has to close them.

2. Senior leaders prefer meetings

The team is committed to async. The VP isn't. Their preferred mode is the synchronous conversation, and they call meetings whenever they want to discuss something. The team can't refuse, so the meetings accumulate. The async commitment dies upward — junior engineers maintain async habits among themselves, but every interaction with leadership is synchronous. Address this directly with leadership: the team's async model only works if it's followed at every level.

3. New hires don't know the async norms

The team adopts async successfully. Then they hire three new engineers in a quarter. The new engineers come from companies with meeting cultures and reflexively schedule meetings to discuss things. Within months, the calendar is full again. Onboarding needs to explicitly cover async norms — "we discuss in writing first, we use meetings only when X conditions are met" — and senior engineers need to model the behavior visibly so new hires absorb it.

4. The team confuses discussion with decision

Async is bad at discussion in the sense of rapid-fire exploration. It is excellent at decision-making in the sense of considered deliberation. Teams that haven't learned the difference often schedule meetings because "we need to discuss X" — when what they actually need is to write up the trade-offs and have a named owner make the call. Discussion is a means; decision is the end. Async works for the end even when it's clunky for the means.

5. Time-sensitive decisions accumulate

A genuinely urgent decision needs to be made in two hours. Async can't deliver in two hours. So the team has a meeting. This is appropriate — some decisions are genuinely urgent — but the threshold for "urgent" tends to drift. Within months, "urgent" means "the manager wants an answer today." Be specific about what counts as urgent enough to warrant a synchronous meeting, and audit it monthly: how many "urgent" meetings actually needed to be urgent?

6. Conflict surfaces poorly in writing

Two engineers disagree about an approach. The disagreement is real and substantive. In writing, the disagreement reads as adversarial; tone is lost; positions harden. After a few exchanges that feel worse than they should, someone schedules a call to "resolve it like adults." This is real — text is bad at conflict for psychological reasons that don't go away because the team committed to async. Build a norm: when written exchange starts to feel adversarial, take it to a short call. The call isn't a defeat of async; it's a tool for the cases where writing is genuinely the wrong medium.

7. Decisions require alignment from too many people

A decision needs input from eight stakeholders. Getting written responses from eight people takes a week. Getting them in a meeting takes an hour. The team starts calling meetings whenever consensus is needed. The fix is to reduce the number of stakeholders rather than reduce the latency of getting their input. Most decisions that "need alignment from eight people" actually need one decision-maker and seven informed stakeholders. Naming the decision-maker shrinks the coordination problem.

8. The team values social connection

Async coordination is efficient and lonely. Engineers miss seeing each other. They schedule meetings partly for the social benefit, even though the meetings are dressed as work. Address the actual need: schedule a weekly team coffee, a monthly remote happy hour, occasional in-person offsites. The mistake is bundling social connection into work meetings, where it makes the meetings longer and provides thin social benefit. Separate the two.

9. Async reviews are perceived as slow

An async design review takes three days; a synchronous review takes an hour. Engineers prefer the synchronous version because the feedback is faster. But the synchronous version also produces shallower review — only the things the reviewer thinks of in the moment. The fix is to set explicit async review SLAs (reviewers respond within twenty-four hours) and to invest in better written documents that surface the real questions for reviewers. Done well, async reviews are slower in wall-clock time and higher in quality. The team has to value the quality enough to tolerate the latency.

10. Critical context isn't in the records

An engineer needs to discuss something with a teammate. The relevant context isn't documented anywhere; it lives in the teammate's head. A synchronous conversation is required because there's no alternative. Each instance is a sign of declaration debt — the context should have been declared at the moment it was created, and wasn't. Over time, this should reduce as declaration habits mature. If it isn't reducing, the underlying habits aren't sticking.

11. Async tools don't fit the team's workflow

The team is trying to coordinate complex multi-system work in Slack threads. Slack is poorly suited for this — threads are linear, hard to search, and not persistent. The team's frustration with async is partly a frustration with the tool choice. Tools designed for async coordination (Notion docs, Linear, GitHub discussions, dedicated decision logs) work much better than overloading Slack. The tool choice matters as much as the habit.

12. Managers manage by meeting

A manager whose previous mental model of management was "regular check-ins" struggles in async environments. They schedule weekly syncs with every direct report; they hold team meetings for status they could read in records; they treat their calendar as their primary work output. The shift required is significant: management becomes reading and writing rather than scheduling and attending. Some managers make this transition; some don't. The team's async commitment depends on managers doing the work.

13. The team hasn't established a decision SLA

Without a defined decision SLA, async discussions run indefinitely. People raise concerns, the discussion broadens, no closure happens. Frustration builds, someone schedules a meeting. The fix is a clear SLA: every async decision discussion has a defined deadline at which the named decision-maker rules, whether or not consensus has been reached. Twenty-four to seventy-two hours for most decisions, longer for major strategic ones. The deadline focuses the discussion.

14. Meetings are easier to schedule than to refuse

Someone proposes a meeting. Nobody wants to be the person who says "let's do this async instead." The meeting happens by default. This is a coordination failure — the team has agreed on async but the meeting-default lives on in individual habits. The fix is explicit: every meeting proposal gets a brief justification ("here's why this can't be async"). Most meetings can't survive the justification step.

The pattern

The fourteen reasons share a common shape: each represents a moment when the synchronous option is more convenient in the short term and the async option is better in the long term. Teams that drift back to meetings are doing so one rational short-term choice at a time. The corrective is structural — explicit decision-makers, clear SLAs, named exceptions — rather than willpower. Willpower fails. Structure holds.

Frequently asked questions

Is it healthy to have any standing meetings on a fully async team?

A small number of recurring meetings is fine — typically weekly 1:1s, quarterly planning sessions, and occasional retrospectives. The principle: meetings are appropriate when relationships or alignment require face time, not when status or coordination could be done in writing. Most teams find their standing meeting count drops by 70-80% when they make this distinction rigorously.

How do you handle stakeholders outside engineering who prefer meetings?

Negotiate format on a case-by-case basis. Some cross-functional moments genuinely benefit from synchronous conversation — initial scoping with product, executive reviews, customer feedback sessions. Others (status updates, alignment check-ins) can be made async even when the stakeholder prefers meetings. The pattern: protect the engineering team's async working hours; accept synchronous overhead at the boundaries where it's genuinely required.

What's the leading indicator that your async culture is sliding?

Track meetings-per-engineer-per-week over time. A team that committed to async should see this number drop and stabilize. If it starts climbing, the slide is underway. Catch it at +15% and you can address the specific patterns. Catch it at +50% and you've effectively rebuilt the meeting culture and the async commitment is symbolic at best.