Async Work Skills That Get Remote Hires Promoted

This is the skill most people underestimate when they land their first international role. Getting hired is a separate problem, covered in how to get a remote job with a US company. This article is about the year after.

In short

• Distributed teams run on artifacts, not presence. Your writing is the performance review.
• Four artifacts carry most of the weight: the update, the decision record, the handoff, the documented process.
• Good async writing is low-context: it assumes the reader has none.
• Meetings are not banned, they are expensive — and knowing when to call one is itself an async skill.
• All four artifacts can be produced without permission, which makes them the fastest way to become visible.

Why async is the real job

Remote work is not a location arrangement. It is a change in how information travels. In Buffer's 2023 State of Remote Work, a self-selected survey of 3,000 remote workers, 74% said their company operates across multiple time zones and 62% said their own immediate team is spread across them. That is the condition you are working in: for a meaningful part of every day, the person who can answer your question is unavailable, and you are that unavailable person for someone else.

GitLab, which runs over 1,500 team members across more than 65 countries, publishes its handbook openly. Its all-remote guide opens with a remote manifesto — a set of preferences that reads like an unwritten job description for anyone joining a distributed company:

• Writing down and recording knowledge, over verbal explanations.
• Written processes, over on-the-job training.
• Public sharing of information, over need-to-know access.
• Asynchronous communication, over synchronous communication.
• The results of impact, over the activity put in.

The last one is the promotion mechanic in a single line. Activity is invisible when you are remote. Impact only registers if someone can see it — which usually means you wrote it down.

GitLab's communication handbook adds the technique: use low-context communication by being explicit, provide as much background as possible, and make sure the conclusions of offline conversations are written down. It also warns against the opposite failure. Its own guidance notes that async-only has a failure mode: threads fork, context drifts, and nobody knows who decided what. Async is a default, not a religion.

The four artifacts

This is MitHub's framework for the first year in a remote role. Produce these four things consistently and your work becomes legible to people who never see you.

1. The update nobody has to chase

A status update exists to remove work from your manager's day. If they have to reply "and what about X?", the update failed.

Four lines, published in the same place every time:

Moved:    Shipped the lead-routing rule for the 3 southern branches.
Blocked:  Waiting on CRM admin access from IT (asked Tue, no reply).
Need:     Eric — can you approve the field mapping in the doc? 5 min.
Next:     Error alerts on the intake workflow, done by Thursday.

Three rules make it work. Put the ask in its own line with a name on it. Say how long the ask will take. Never write "no blockers" when there are blockers you have decided to absorb — write them and say you are absorbing them.

2. The decision record

The most expensive thing on a remote team is a decision that has to be re-litigated because nobody wrote down why it was made. A decision record is five lines: the decision, the date, who decided, the options rejected, and what would make us revisit it.

GitLab's handbook has a phrase for the discipline behind this: say why, not just what. A decision without its reasoning is a rule that people will quietly break the first time it is inconvenient.

Where to put it matters as much as writing it. A decision in a chat thread is lost in a week. Put it in the document that the work lives in, and link to it from the thread.

3. The handoff

A handoff is what turns a time-zone gap from a delay into a relay. When you stop work mid-task, leave a note that a colleague can act on without you:

• State: what is done, what is half-done, what is untouched.
• Where: exact links — the branch, the table, the workflow, the row.
• Risk: the thing most likely to break, and how to tell.
• Decision needed: the one call you'd like made before you're back.

GitLab's guide to asynchronous and non-linear working describes team members picking up work by relying on low-context documentation created by colleagues in other time zones. That only functions if the handoff is written for a reader with zero context — including the version of you who returns nine hours later having forgotten everything.

4. The documented process

The first time you do something, you learn it. The second time, you should be following your own written version. The third time, someone else should be able to run it.

A process doc that gets used has: the trigger (when to run this), the steps in order, the exact place each step happens, the check that proves it worked, and who to ask when it doesn't. Anything else is prose.

This is also where async skill turns into leverage. A documented process can be automated; an undocumented one cannot. That progression — do it, write it, automate it — is the bridge between remote employment and systems work, and it's the core idea in build systems, not just tasks and process mapping before automation.

The 30-second async test

Before you send any substantial message, run it through four questions. This is the check we teach at MitHub, and it takes half a minute.

The fourth question is the real one. Most people write messages that are the opening move in a dialogue. Async writing is a closing move.

When to break async and call a meeting

Async as an absolute is a trap. GitLab's own meetings guidance starts by asking whether the meeting is necessary at all and whether the outcome could be achieved asynchronously — and then, if it is necessary, sets standards that are themselves async work: review participants' time zones, nominate a DRI to host in a reasonable local window, send the invite 72 hours in advance (24 hours minimum) with a link to an agenda, mark non-essential participants as optional, share slides and recordings beforehand, and avoid using valuable synchronous time to present.

Four situations genuinely justify the interruption:

1. Disagreement that has survived two written rounds. Threads converge slowly; thirty minutes ends it.
2. Trust that hasn't formed yet. New relationships need faces.
3. A problem too fuzzy to write down. If you cannot articulate the question, you cannot ask it asynchronously.
4. Something urgent and irreversible. Money, customers, production.

Everything else is a document. Knowing the difference — and being able to say "I think this is a doc, here it is" — is itself a senior behavior. For deciding what deserves your synchronous hours at all, see the Eisenhower matrix for knowledge work.

A 30-day plan to build the habit

A worked example — imagine you just joined a distributed team:

• Week 1. Publish a four-line update every day in the same channel. Ask your manager once: "is this the right level of detail?"
• Week 2. Write one decision record for a decision you made. Link it from the thread where the discussion happened.
• Week 3. End two days with a real handoff, even if nobody picks it up. Notice what you had to look up to write it — that's the context your team is missing.
• Week 4. Document one recurring task as a process someone else could run. Ask a colleague to follow it without your help, and fix whatever they get stuck on.

At the end of the month you have roughly twenty updates, one decision record, two handoffs and a process doc with your name on it. That body of artifacts is also the raw material for your next case study and your next interview — see remote job interview questions for how to reuse it, and proof of work vs credentials for why it beats a certificate.

Key takeaways

• On a distributed team you are evaluated on artifacts, not availability.
• Write low-context: assume the reader has none, and include the why.
• The four artifacts — update, decision record, handoff, process doc — are all producible without permission.
• Run the 30-second test before sending: could this work if I disappeared right now?
• Async is a default, not a rule. Knowing when to call a meeting is part of the skill.