What async-first actually means for your working day

See how an async-first team handles messages, feedback, handoffs, and meetings—and decide whether that working rhythm suits you.

When the day gets away from you

It's 9:00 a.m. You open your laptop, ready to tackle something important.

But first, there are messages to answer. Someone wants a quick call. A colleague needs your opinion on something. There's a meeting at 10:30, another at 2:00, and a steady stream of notifications in between.

By 5:00 p.m., you've been busy all day. You've responded to everyone, attended your meetings, and kept up with the conversation.

But the work you actually wanted to accomplish? That's still waiting.

This is the problem that async-first working tries to solve.

What does async-first mean?

Async-first means organizing routine work so people can contribute at different times. Done well, it gives you room to finish something before answering the next message. You still collaborate, ask for help, and meet people; you have more choice about when to respond.

The 37signals Guide to Internal Communication puts it simply: “Real-time sometimes, asynchronous most of the time.” The aim is to give people time to think and respond, with immediate attention reserved for genuine emergencies. Communication remains part of the job; each new message does not have to interrupt the work already underway.

In practice, that changes how you start the morning, handle requests, and leave work for the next person. The team's agreements determine how much room you have to concentrate—and what you need to do to give colleagues the same room.

Your morning starts with context

Now imagine starting the same day on an async-first team. You open the shared project page and find an overnight update: what changed, what needs your input, and who owns the next step. You can catch up without asking a colleague to repeat a conversation.

That only works if people leave usable context. A chat message saying "we changed the plan" is less useful than a link explaining the new plan and why it changed. GitLab makes this expectation explicit in its handbook: conclusions from offline conversations should be written down.

37signals describes daily written check-ins about completed work and Monday updates about the week ahead. Colleagues can read them when they need context. A short update can save you from reconstructing yesterday’s work through a string of messages.

Your first task is to distinguish information from action. Read the updates relevant to your work, note any requests with deadlines, then choose what to work on. You should not have to keep scrolling just in case someone made a decision between two GIFs.

You know when a reply is due

Async communication needs an agreed response expectation. Without one, the sender cannot plan and the recipient cannot confidently disconnect.

In his guide on asynchronous communication, Doist founder Amir Salihefendic describes a 24-hour response expectation at Doist. Other teams set different windows to suit their work.

The details affect your day. A window measured in working days lets a routine Friday request wait until after the weekend. An expectation of replies within an hour gives you much less room to step away or concentrate. Clear rules for leave and blocked work help you batch ordinary replies without leaving people stranded.

Core hours and scheduled coverage still shape your calendar. If your team requires afternoon overlap, you need to be available then even when most discussions happen in writing.

You have time to stay with a difficult task

Imagine three hours to work on a proposal. In one version of the morning, a call splits the time in two and notifications keep pulling you back into other conversations. Each return to the draft begins with finding your place and remembering what you were trying to say.

In another version, routine messages can wait until the end of the block. You have time to follow an idea, discover where it falls short, and revise it. The calendar contains the same three hours, but you have a better chance of taking the work somewhere.

That is the practical benefit of protecting attention. It depends on colleagues being able to trust that you will reply later, and on you being able to trust that ordinary messages can wait.

You write a request someone can answer later

Suppose you need feedback on an onboarding email. A message saying "Can you look at this?" leaves your colleague guessing about the task and its urgency. Give them enough context to respond:

I'm choosing between these two onboarding emails. The goal is to explain the first setup step. I recommend option B because it gives the instruction earlier. Could you check the wording by Thursday at 15:00 UTC? The draft and customer context are linked here. I'll work on the help page while I wait.

Your colleague knows what to review, why it matters, and when you need an answer. You can both keep working without arranging a call.

That extra care takes time. Fewer interruptions come with more writing, documentation, and decisions you need to make independently. Feedback may arrive tomorrow even when you would find it useful now. You may thrive with that autonomy, or prefer working through ideas in a quick, spontaneous conversation. The trade-off matters when choosing a team.

Waiting is something you plan around

If a colleague will answer tomorrow, you need useful work you can do today. Identify dependencies early, request reviews before the deadline, and agree who decides when the input window closes.

Before you finish for the day, leave a usable handoff. For the onboarding email, leave the draft, any unresolved questions, your recommendation, and who should act next in one place. "Ready for review" is helpful only when the reviewer knows what kind of review you need.

A review deadline also needs someone responsible for the decision. If a colleague misses the window, you need an agreed way to proceed or get help. Otherwise, a quiet afternoon can turn into a day spent waiting.

Some conversations need a call

A stuck conversation, sensitive feedback, or an unclear problem may deserve a live discussion. GitLab's handbook explicitly describes situations where synchronous communication is more appropriate, including resolving disagreement and debugging when the context is not yet clear enough to write down.

After the call, record the outcome where the work lives. Otherwise, the people who missed it have to reconstruct the decision.

Urgency also needs its own route. A service outage might trigger a call to the person on duty, while feedback on a document waits in the project discussion. If you cover incidents, interruptions are part of that shift. Outside it, a clear handover lets you return to your other work.

Would this rhythm suit you?

Think back to that unfinished task at 5:00 p.m. An async-first team should help you protect time for it while keeping colleagues informed. In return, you need to explain your thinking, request input early, and leave the next person enough to continue.

If you are considering a role, ask a future colleague to walk you through yesterday: how much uninterrupted time they had, when they checked messages, what they waited for, and why they joined a call. Confirm response windows, required hours, and urgent coverage. That gives you a working day to compare with your own preferences. If you are weighing an offer, use our questions to ask before accepting a remote job to cover the wider expectations too.

Sources and further reading

For the broader argument for calmer work, start with It Doesn’t Have to Be Crazy at Work (2018), by Jason Fried and David Heinemeier Hansson. Their earlier books REWORK and REMOTE offer further reading on how businesses and remote teams work. You can find all three on 37signals’ books page. The communication guide above shows how the company puts its ideas into daily practice.

Frequently asked questions

How is async-first different from remote work?

Remote work describes where you work; async-first describes how you coordinate with colleagues. A remote role can still require frequent meetings and immediate replies.

Does async-first mean no meetings?

No. Calls can help with sensitive conversations, disagreements, and problems that are difficult to explain in writing. An async-first team uses them selectively and records the outcome so colleagues can catch up later.

Is async-first a good fit for a first remote job?

It can be, with clear onboarding and reliable access to help. A named person for early questions and regular check-ins can make the independence easier to manage. Waiting a day for every small clarification can make starting out frustrating.

Does async-first mean you can work whenever you want?

No. Async-first reduces the need for everyone to work simultaneously, but it does not necessarily eliminate fixed schedules, core hours, or deadlines. Some jobs still require scheduled coverage or real-time availability.