What Working Remotely from Dubai Taught Me About Async Collaboration

In 2022, I moved from Kerala to Dubai to join Nathan Digital. The team was small but distributed, with designers in one time zone, backend developers in another, clients across the UAE with their own schedules. It was the first time I couldn't just tap someone on the shoulder to ask a question.

That forced me to develop communication habits I now consider essential, regardless of whether the team is remote or co-located.

The Documentation Default

When you can't ask a question in real-time, you either wait hours for a response or find the answer yourself. The second option only works if the answer is written down somewhere.

I started documenting everything:

• Architecture decisions. Not just what we chose, but why. "We use Nuxt for SSR because the client requires SEO indexing for product pages" is more useful than "We use Nuxt."
• Setup instructions. Every project got a README that a new developer could follow to run the project locally in under ten minutes. If a setup step was missing, the first person to discover it added it.
• API contracts. Before building a feature, I'd write a brief document describing the endpoint, the request/response shapes, and the edge cases. This replaced synchronous meetings where the backend developer and I would negotiate the API shape in real-time.

The investment was significant, roughly an hour of writing for every few hours of coding. But the payoff compounded. Three months in, I was answering questions by linking to existing documentation instead of explaining the same thing repeatedly.

Async Communication Rules

Write the full context in the first message. Not "hey, quick question" and then wait for a response before asking the actual question. One message with everything: what you're trying to do, what you've tried, what's blocking you, and what you think the answer might be.

Bad:

"Hey, got a minute?"

Good:

"I'm implementing the product filter on the catalog page. The API returns categories as nested objects, but the filter UI expects a flat array. I'm thinking of flattening them in the API response rather than on the frontend. Any concerns with that approach?"

The second message can be answered asynchronously. The first one requires synchronous back-and-forth.

Default to written communication, escalate to calls. Text is searchable, referenceable, and available to anyone who joins the project later. Calls are faster for complex discussions but produce no artifact. My rule: try text first. If three messages don't resolve it, hop on a call. After the call, write a summary of the decisions made.

Use screenshots and recordings liberally. "The button alignment is off on the filter panel" is ambiguous. A screenshot with an annotation is not. For UI issues, I record a 30-second Loom showing the problem rather than describing it in text.

Time Zone Overlap

With team members in IST, GST, and occasionally European time zones, we had about four hours of overlap. Those hours were sacred, reserved for discussions that genuinely needed real-time interaction. Everything else was async.

What worked in the overlap window:

• Code review discussions where back-and-forth was expected
• Sprint planning (kept to 30 minutes, not more)
• Pairing on complex bugs

What moved to async:

• Status updates (replaced by brief daily written updates)
• Feature specs (written documents with async comment threads)
• Code reviews themselves (reviewed on your own time; discussion in the overlap window only if needed)

What I Brought Back

After eighteen months in Dubai, I moved to remote work for my current role. The habits persisted:

1. Write before talking. Even with co-located teammates, I draft proposals before meetings. The meeting becomes a discussion of the written proposal, not a brainstorming session that produces no record.
2. Make decisions traceable. When a decision is made in a call or chat, I summarize it in a persistent location (PR description, project doc, or code comment). Future developers shouldn't need to dig through Slack history.
3. Respect async time. Not every message needs an immediate response. I batch my communications. Check messages three times a day, respond in focused blocks. The rest of the time is uninterrupted work.
4. Context is kindness. Every message, every PR description, every commit message. Include enough context that the recipient can act without asking follow-up questions. The five minutes you spend adding context saves the other person thirty minutes of confusion.

The Surprising Benefit

The biggest gain from async-first collaboration wasn't efficiency. It was quality. When decisions are written down, they get more scrutiny. When proposals are documented before discussion, the discussion is better informed. When code reviews happen thoughtfully rather than hurriedly in a pairing session, the feedback is more substantive.

Synchronous communication feels faster. Asynchronous communication is better. The trade-off is worth it.