"Fully async" is a phrase that gets used loosely. Some teams mean "we don't require people to be online at the same time." Others mean "all decisions are made in writing." Others mean "we don't have any synchronous meetings." These are very different commitments with very different infrastructure requirements. Before a team commits to a fully async operating model, it needs to answer a specific set of questions about what it actually means and what it will take to make it work.
The questions below are not abstract. Each one corresponds to a structural decision that will determine whether the async transition succeeds or quietly reverts to synchronous patterns within six months. Teams that can't answer most of these aren't ready to go fully async — they're ready to try, fail, and conclude (incorrectly) that async doesn't work.
1. What does "fully async" actually mean for your team?
Define it concretely before committing. Does it mean zero standing meetings? No expectation of real-time response in any channel? Decisions made only in writing? Each of these is a different commitment. Most teams that say "fully async" mean some hybrid — async-default with specific exceptions for incident response, hiring panels, or 1:1s. Naming the exceptions up front prevents the team from drifting back into synchronous patterns under the cover of "we never said we couldn't meet."
2. What is your maximum acceptable decision latency?
Async decisions are slower than synchronous ones by definition — you trade simultaneity for inclusion and considered responses. If your business or product requires decisions made within hours, fully async won't work for those decisions. Be specific: which categories of decisions can wait twenty-four hours? Which can wait a week? Which can't wait at all? The async model only applies to the categories where the latency is acceptable.
3. Do you have shift-end records or equivalent declared state?
Without a daily mechanism for every engineer to declare current state, fully async work degrades into status anxiety. People can't tell what others are working on, whether something is blocked, or whether a decision has been made. The shift-end record is the minimum infrastructure for async work to function. If your team doesn't have this habit, build it for two months before declaring yourselves fully async.
4. Who has authority to decide what — explicitly?
Async work amplifies authority ambiguity. In synchronous teams, ambiguous authority gets resolved in real time through conversation. In async teams, it produces stalled decisions and parallel divergent work. The authority map needs to be explicit, written, and recently reviewed before async becomes the default.
5. What's your escalation path when async doesn't produce a decision?
Some decisions can't resolve asynchronously — they require real-time conversation to surface disagreement and converge. You need a defined off-ramp: how long does an async discussion run before it triggers a synchronous meeting, and who decides to trigger it? Without this, async discussions either drag on indefinitely or quietly resolve to the loudest voice's preference.
6. How will you onboard new engineers?
Async onboarding is harder than colocated onboarding because the absorptive learning that happens through proximity doesn't exist. New engineers need a richer set of written artifacts — architectural docs, decision logs, recent shift-end records — and a designated context contact for the questions the records don't answer. Without this, your async culture becomes inaccessible to anyone who joined after it was established.
Put a context layer under your distributed team.
StandIn gives engineers a 60-second wrap at the end of every shift. The next shift wakes up knowing exactly what to pick up — no standup required.
Request early access7. How will you handle incidents?
Incident response is the canonical exception to async. You need a clear protocol: when does an alert convene a real-time response, who is expected to be available, and how is the transition from async-default to sync-for-incident triggered cleanly? Teams that try to handle incidents asynchronously make slow recovery decisions and lose customer trust.
8. How will senior leaders stay connected to the team?
The risk: senior leaders in async teams become disconnected from operational reality because they don't see the day-to-day texture of work. They miss morale issues, emerging conflicts, and capability gaps. The mitigation is deliberate: leaders need a discipline of reading shift-end records, occasional async retrospectives focused on team health, and a clear path for engineers to raise issues that don't fit standard channels.
9. What synchronous moments will you preserve and why?
Even fully async teams benefit from a small number of synchronous moments — quarterly offsites, weekly 1:1s, occasional pairing sessions for hard problems. Name them explicitly. The rule is not "no synchronous" but "synchronous is the exception, with a clear reason." Teams that try to eliminate synchronous entirely often lose the relational glue that holds the team together.
10. What's your written communication standard?
Async work depends on writing quality. The implicit standard "write clearly" is insufficient — you need norms about structure (where do decisions live?), length (when is a long-form doc required vs. a quick Slack message?), and response expectations (what's the SLA for a tagged message?). Without these, async communication becomes a frustrating guessing game.
11. How will you handle disagreement?
Disagreement resolves quickly in synchronous conversation through real-time back-and-forth. Async disagreement either resolves slowly through careful written exchange or doesn't resolve at all and curdles into resentment. You need a protocol: how does a disagreement get raised, how long does the async exchange run, and when does it escalate to a real-time conversation? Teams that don't define this often end up with chronic unresolved disagreements that surface as morale issues.
12. What overlap do timezones actually require?
"Fully async" doesn't mean "zero overlap." Most teams benefit from one or two hours of daily overlap for the rare conversations that genuinely require simultaneity. Calculate your team's available overlap based on actual timezone distribution and decide how to use it deliberately. Teams that pretend overlap doesn't matter often discover they've structured themselves into a team that can't make hard decisions together.
13. How will you measure async health?
You need leading indicators: are shift-end records being written consistently? Are decisions being recorded? Is the average time-to-decision within acceptable bounds? Are new engineers becoming productive on the expected timeline? Without measurement, async drift goes undetected until a major failure forces a synchronous emergency response.
14. Are your tools async-friendly?
Tools optimized for real-time use — heavy Zoom dependency, Slack-as-primary-system-of-record, calendar-driven coordination — actively undermine async work. You need tools that support deep writing (Notion, Linear, GitHub), persistent decision artifacts (decision logs, ADRs), and structured context transfer (shift-end records, handoff digests). The toolchain has to match the operating model.
15. What's your reversion plan?
Going fully async isn't permanent. Some teams discover after six months that the operating model doesn't fit their work. Plan the test: what would tell you it's working? What would tell you it isn't? When would you assess? A trial period with explicit success criteria is healthier than declaring async permanent and then quietly reverting under pressure.
Frequently asked questions
How long does it take to actually transition to fully async?
The infrastructure changes (shift-end records, authority maps, decision logs) take four to eight weeks to become habit. The cultural shift — stopping the reflex of scheduling a meeting whenever something is hard — takes six months to a year. Teams that expect faster transitions usually underestimate the cultural piece and revert when the first hard problem doesn't resolve asynchronously.
Should small teams (under five engineers) go fully async?
Usually not worth the investment. Small teams can coordinate effectively with light synchronous touchpoints, and the infrastructure overhead of fully async work is significant relative to team size. Async-default — with a few standing meetings — is often a better fit for small teams. Fully async pays off most clearly in teams of fifteen or more across multiple timezones.
What's the single highest-risk reason for async transitions to fail?
Leadership demands async outputs while continuing to operate synchronously themselves. If executives schedule meetings, expect rapid Slack responses, and make decisions in real-time conversations, the team learns that async is theatrical — the real work still happens synchronously. Leadership behavior is the load-bearing variable. If leaders don't adopt the async patterns, the team can't.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.