Asynchronous collaboration

Asynchronous collaboration lets people advance shared work without being available at the same time. It works when a request carries enough context to act on, people know when input is needed, and the outcome is easy to find later. It does not rule out meetings.

Asynchronous work is especially useful when colleagues are spread across locations or time zones: people can read, think and contribute without waiting for everyone to be online together. Treat asynchronous and live communication as tools for different situations, not competing doctrines.

Pros and cons of asynchronous collaboration in Australian teams

Give each exchange a purpose

An update tells people what changed; a request asks someone to act; a proposal invites input before a decision; a decision tells affected people what now applies. Say which you mean so readers know whether to acknowledge, review or change their work.

For a request, include the issue, the relevant working record, the action needed, the person responsible and the deadline. State what to do if that person cannot respond. Keep background where a colleague joining later can see it.

Make messages understandable to someone who missed the earlier conversation. State relevant background and explain unfamiliar terms or assumptions instead of relying on a chain of private exchanges. This reduces the need for colleagues to reconstruct what happened before they can contribute.

Give work and outcomes a clear home

Use conversation to draw attention to a question and discuss it. Keep current task status in the team's project record, working text in its document, and approved decisions in a maintained place affected colleagues can reach. The products matter less than knowing which record is current.

A message saying “the brief is approved” can alert the team. It should identify the approved brief and who confirmed it. If the decision changes, update the maintained record and tell people acting on the earlier version. Check that intended readers can open it.

Agree on timing and escalation

Agree when people normally read routine updates, when requested input is due, and how to raise an urgent issue. Include a date and time zone wherever a deadline could be misunderstood. A message sent outside someone's working hours should not silently create an immediate-response expectation.

For urgent work, name the person or role monitoring the route, a backup, and what the sender should do if neither responds. Review the arrangement when working hours, staffing or the work changes.

Use live discussion where it helps

Written updates suit information people can read and act on at different times. Use a live discussion when urgent work is blocked, participants interpret the same material differently, or written rounds have failed to settle a decision. Give it a question and a decision maker. Afterwards, record the outcome and actions for people who were absent.

Sensitive conversations need an appropriate audience and channel. Share only the resulting work decision that others need to carry out.

When to use asynchronous vs. live discussion

Communicate openly and respectfully

Treat asynchronous communication as the normal starting point for work that does not need an immediate, shared answer. GitLab describes using public issues, merge requests and Slack channels to keep communication open and transparent across a fully remote company. A shared, visible discussion gives colleagues joining later the context they need without everyone being present at once.

Write assuming the reader has good intentions, and keep disagreement about the work rather than the individual. GitLab’s communication guidance asks people to communicate respectfully and professionally, consider different perspectives, and take responsibility for what they write. These habits matter especially when readers cannot rely on facial expression or tone of voice to interpret a message.

Do not let a fast channel turn every message into a demand for immediate attention. Moula notes that reacting straight away to non-urgent email can interrupt focus and productivity. Make clear whether a message needs action now or can wait for the agreed working rhythm. Avoid treating silence outside that rhythm as a failure to collaborate.

Make the team agreement shared and revisable

Agree the team's communication norms together rather than assuming one person's habits suit everyone. Atlassian describes working agreements as shared norms for how a team communicates and collaborates, including across multiple time zones. Record the agreed expectations in a collaborative document team members can revisit, rather than relying on informal explanations newcomers may miss.

Invite people to say which conventions help them contribute and where unclear expectations create friction. Atlassian reports that 74% of employees who ran its Working Agreements Play felt empowered to speak up about changes that could help their team work better together.

Revisit the agreement when people join the team, after a reorganisation or when the work changes. Check whether the norms still support the team’s actual locations, working patterns and collaboration needs, and adjust them when they do not.

Review the team's conventions

When a handoff stalls, check whether the request lacked context, an owner or a realistic deadline, or whether the outcome was hard to find. Change the convention that caused the problem. A recurring reporting meeting, a decision record and response expectations each need more specific rules. The team-wide agreement gives those rules a common starting point.