by Rat Race Rebellion September 20, 2026
Remote work gives you location autonomy. Async work gives you time autonomy. They’re related but they’re not the same thing, and a job listing rarely tells you which one you’re actually getting.
The word “remote” tells you where the work happens. What it doesn’t tell you is when. That question – when do I actually have to work? – is less often answered in a listing and less often asked in an interview.
“Async-friendly” and “flexible schedule” are the phrases companies use to signal that the when is also negotiable. The problem is that these phrases have the same ambiguity problem “remote” does: they sound like a commitment but describe a spectrum wide enough to include almost anything.
At one end: a company that defaults to written communication, documents its decisions, treats meetings as an exception rather than a default, and trusts that an offline employee is working rather than absent. At the other: a company where all-hands calls are fixed on the calendar, Slack pings carry an implied five-minute response window, ad hoc “quick chats” interrupt deep work throughout the day, and “flexible” means you can occasionally move a meeting — but the meetings still exist.
Both of those companies might describe themselves as async-friendly.
What async actually requires
Genuine asynchronous work isn’t a policy. It’s infrastructure. The difference between a company that supports async and one that performs it shows up in a few specific places.
The first is written communication as the default. In a truly async environment, the written record is where work lives – not merely a summary of what happened in a meeting. Context and decisions are documented so that someone in another time zone, or offline for a day, can understand what happened without having to ask around. When writing is a supplement to conversations rather than the primary medium, async is a description of preference, not of how the company actually operates.
The second is meeting discipline – specifically, what requires one. In an async-first environment, a meeting has a reason to be synchronous: discussion, debate, relationship-building, or a decision that genuinely benefits from real-time conversation. Routine status updates and information sharing don’t automatically become calendar events. The question isn’t how many meetings a company holds but whether the default for getting information to people is a call or a document.
The third is explicit response-time norms. Async depends on everyone understanding that offline doesn’t mean permanently unreachable, and that the expectation for an urgent request is different from a routine one. Companies that have built async into how they work tend to have written norms around this – something like “non-urgent Slack messages within 24 hours.” When response expectations are left implicit, employees often have to infer for themselves how quickly they’re expected to respond, which can undermine the flexibility async is supposed to provide.
The fourth is whether core hours exist. Some async teams still require overlapping availability for part of the day, particularly across time zones. That’s not necessarily a contradiction but it materially changes how much schedule control the job actually provides. A four-hour daily overlap window is a very different version of “flexible” from a company where employees largely set their own working hours. For job seekers who need flexibility around caregiving, school schedules, health needs, or a second role, that distinction matters.
How “flexible” becomes inflexible
One fixed daily standup doesn’t necessarily make a company synchronous. But synchronous anchors accumulate. A 9 a.m. standup, a midday team meeting, a few “quick chats,” and an expectation of rapid Slack responses can leave very little meaningful control over the workday — even if every one of those practices sounds reasonable in isolation. All-team channels where messages pile up and generate real-time replies signal a culture where presence is tracked informally. An onboarding process built entirely around scheduled calls rather than written documentation tells you something about how the company communicates when it’s not trying to impress a new hire.
The clearest indicator is what happens when someone is offline. A company with genuine async infrastructure should be able to describe specifically how work continues when a team member is unreachable — how decisions get communicated, how context gets preserved, how someone catches up after a day out. If the honest answer is “people ask around” or “they catch up at the next standup,” that’s useful information about what flexibility actually looks like there.
What to ask in an interview
Don’t ask whether the company is async. Ask how work happens when people aren’t available at the same time. Three questions that get past the “we’re very async here” talking point.
What’s the expectation for responding to a non-urgent Slack message? The answer -nand how specifically it’s given – tells you more than any policy statement. A company that has thought carefully about this has a concrete answer. One that hasn’t will give you something vague about culture and trust.
How do you make decisions when the relevant people are in different time zones or offline? A company with functioning async infrastructure can describe the process specifically: a written proposal, a comment window, a documented outcome. One that hasn’t built that will describe getting everyone on a call.
How does someone get up to speed when they miss a meeting? If the answer involves checking in with a colleague or waiting for the next sync, decisions are being made in real-time and documented afterward, if at all. If the answer involves a recording, a written summary, and a place where decisions live, that’s a different operating model.
The Bottom Line
“Async-friendly” in a job listing is a starting point, not a guarantee. Like “remote,” it tells you something – there’s at least an acknowledgment that not everything needs to happen in real time. What it doesn’t tell you is whether the infrastructure to support that actually exists.
The remote job gets you out of the office. The async job gets you out of the meeting. They’re both worth having, and they’re not the same thing. Finding out which one you’re actually being offered is worth a few direct questions before you accept.