Async by default: a playbook for the non-linear workday
"Async by default" means communication and decisions happen in writing, on each person's own schedule, and a meeting is the deliberate exception rather than the baseline. The non-linear workday, where people split their day around their lives instead of 9-to-5, is what that policy makes possible. It comes after the policy. Grant the schedule before you build the policy and you don't get autonomy. You get always-on work with worse boundaries.
One thing up front: none of the sources behind this piece measures whether switching to async improves productivity, retention or burnout. What is measured is the cost of the synchronous default. Everything below about how to run an async team is practice that well-documented companies describe, not proven effect. Where a number is measured, I say so, and where a claim comes from a vendor, I say that too.
Remote is not async
Most teams that went remote didn't change how they coordinate. They moved it onto video calls. Steve Glaveski's summary in HBR (2021) is that companies "simply took their offices online, along with the bad habits that permeated them."
Stanford researcher Jen Rhymer puts it more bluntly: "I think it is important to note that remote and async work are not equivalent" (BBC Worklife, 2021). They are two separate decisions, and teams routinely make the first and believe they've made both.
The habit that moved over best was the meeting. Perlow, Hadley and Eun (2017) surveyed 182 senior managers. 71% said meetings are unproductive and inefficient, 65% said meetings keep them from completing their own work, and 64% said meetings come at the expense of deep thinking. These are self-reports from a narrow group, so read them as directional. They're still enough to act on. (I've made the case against mandatory in-person work elsewhere. This piece is about what to do once you're distributed.)
Step 1: Give every decision a written home
The first thing to build is boring and non-negotiable: every decision has a written home and a link. GitLab runs its handbook as "the single source of truth in the organization," and its operating rule is "Provide maximum context in discussions and document the outcomes in the most appropriate location" (GitLab, 2021).
Kraken describes the payoff: "a product spec drafted in Portugal gathers structured comments overnight from engineers in Brazil and risk partners in Singapore" (Kraken, 2026). Nothing in that sentence happens in real time. A document moves, and three time zones contribute without anyone being online together. A call would have shrunk the input to whoever could attend.
The same record pays off again at onboarding. GitHub's workforce "was 70% remote before the pandemic," and its then-COO Erica Brescia said new hires "can easily follow the context around decisions that have been made prior to their start" (BBC Worklife, 2021).
Step 2: Set reply windows, not availability
This is where most async rollouts quietly fail. Flexible hours with no reply norm means being always on, because there's never a moment when it's legitimate to be unavailable.
The norm to write down is a reply window. Coursera gives the range teams use as anywhere from "as little as an hour" to "a whole business day". What matters is that your team picks one and publishes it. X-Team adds two rules: "Designate a time when you'll reply to people and simply don't open Slack or your email client until then," and "Don't ask important questions about your project a few hours before its deadline."
The second rule is aimed at the person asking, and it's the one that gets broken. A question fired off four hours before a deadline overrides every norm you just wrote, and nobody experiences it as a boundary violation. It feels like urgency.
The cost of interrupting is measured, though not the way it's usually quoted. Gloria Mark's observational research, described in an interview with Gallup, found that interrupted work was resumed on average after 23 minutes and 15 seconds, with about two other tasks done in between. That's the time until people return to the task, not how long they take to "recover". Each interruption tends to set off more work, so the thing to reduce is the number of interrupts, which is exactly what a reply window and batched replies do.
Kraken writes the boundary down even though its product never stops: "Crypto markets never close, but that does not mean Krakenites need to stay online around the clock" (Kraken, 2026).
Step 3: Write down when to meet
Synchronous time isn't waste. It's the wrong tool for most tasks and the only tool for a few. Decide which is which once, in writing, instead of renegotiating it every time someone proposes a call.
The GitLab handbook says: "Create a workplace culture where meetings are a last resort, and ensure that unavoidable meetings can be contributed to asynchronously." Brescia names what should stay live: "Teams will still want real-time communication to make decisions, do creative brainstorming, and build relationships with their colleagues" (BBC Worklife, 2021). Rhymer's question is the one to ask of every recurring meeting: "What are the things we really need to do synchronously?"
Here is a starting rubric. It's built from what these companies say they do, not from a tested theory, so adjust it to your team:
| Situation | Default |
|---|---|
| Status, progress, handoffs | Async |
| Specs, designs, RFCs | Async, with a set comment window |
| Decisions with a clear owner | Async, recorded in a decision log |
| Open disagreement, design negotiation | Live, then a written summary |
| Brainstorming | Live or a written round, then converge |
| Conflict between two people | Live |
| Relationships, onboarding a person | Live |
| Incidents | Live, with a running written log |
Kraken also runs its in-person time on purpose. It holds an all-company gathering and says plainly: "We do not gather to re-create an office" (Kraken, 2026).
Step 4: Run the rituals in writing
Recurring meetings follow the same logic as decisions. In the GitLab post, IssueTrak's team reports that "Sprint planning meetings are much shorter now because the team can just look at the 'Ready for Sprint' board." The board doesn't sit alongside the meeting; it replaces part of it. (The same post says IssueTrak "reduced their monthly costs by 80%". That's savings from consolidating tools, not a productivity number, and it's a vendor's customer story.)
The GitLab handbook explains why teams resist this: "Routine is a common suggestion not necessarily because it is good, but because it is tradition." An async standup that just copies the live standup into a channel is that tradition on a new tool. Write updates against the board, and send only real blockers to a live conversation.
For engineering teams, Okoone suggests separating core work from peripheral work and moving code review to written comments with a consistent format, instead of synchronous walkthroughs.
Step 5: Only then, the non-linear day
GitLab's definition is plain: "A non-linear workday means that you can move between work and non-work time on an asynchronous schedule - without needing to account for PTO (paid-time-off)" (GitLab handbook). Its example day runs from 6:00 am to 9:00 am, breaks, then picks up again from 3:00 pm to 8:00 pm.
That only works because of the four steps above. Without a written reply window, a split day is a liability: either you're offline during hours your colleagues can't know are yours, or you're never offline at all. Job van der Voort, co-founder of Remote, argues for dropping fixed hours (HR Executive, 2024). It's a coherent argument, but note that Remote sells remote-employment software, and the case only holds once the writing policy is in place.
GitLab adds its own caution, which is worth more than any testimonial: "breaking daily routines might not be productive for everyone."
Where async breaks
The skeptic's case is strong, and parts of it are on the record. Rhymer: "Remote and especially async work is an important option, but not a great fit for everyone; it is a mode of work that has trade-offs." The same BBC piece notes that "a surprising amount of burden falls on the worker to stay up to date and in touch with their organisation." Psychologist Kristen Shockley says async "gives people more autonomy in how they work, and with that comes more responsibility," and suggests it might even lead to more employee monitoring (BBC Worklife, 2021).
Burnout is the baseline you're starting from. Microsoft's 2022 Work Trend Index found that 48% of employees and 53% of managers report burnout. That's across all employees, not remote workers. The popular version, "half of remote workers reported symptoms of burnout" (as Okoone puts it), turns a work problem into a remote problem. Adding documentation load to a workforce already at that level needs a guard.
The guard with data behind it is recognition. Gallup and Workhuman found that employees who strongly agree they get the right amount of recognition are 73% less likely to report being burned out "always" or "very often". It's an association from a survey, not a cause, and Okoone's "90% less likely" overstates it.
Finally, performance reviews have to match the policy. Kraken: "Managers cannot rely on visual cues of activity, and performance is evaluated on output, clarity and follow-through" (Kraken, 2026). If your reviews still reward being visibly online, no async norm will hold.
Where AI helps, and where it's oversold
Transcripts, summaries and search make the written record cheaper to produce and easier to find. That helps Step 1 directly. The strongest claims for it come from vendors, though. A sponsored diginomica Partner Zone piece by an Atlassian executive argues "When teams do async work well, they naturally create better documentation". Its figure that 72% of meetings are ineffective is from Atlassian's own survey, and its "20,000 hours" saved is a customer story about Atlassian's own product.
Glaveski's caution applies here too: "digital tools are only as effective as how effectively you use them" (HBR, 2021). A searchable archive of meetings nobody needed doesn't fix the meetings.
A checklist for next week
- Name the place where decisions live. One link per decision, linked from the thread that produced it.
- Publish a reply window, somewhere between an hour and a business day, and hold it in both directions.
- Define "urgent" with one channel and one rule, and make clear that a deadline doesn't make a late question urgent.
- Copy the when-to-meet rubric into your team docs and point to it the next time someone proposes a call.
- Audit one recurring meeting with Rhymer's question, then convert it to writing or cancel it.
- Move one ritual to writing this sprint, such as standup or sprint planning, not both at once.
- Check what your performance reviews reward. Fix visible-activity incentives before writing another norm.
- Make recognition a habit. It's the one burnout guard in this material with data behind it.
Because none of these sources measures the outcome, measure your own. Before and after the change, track cycle time, the time from proposal to a recorded decision, interruptions per person per day, and protected focus blocks per week. That before-and-after is the evidence this material can't give you.