Async Communication

We're remote and spread across time zones. That means most of our communication is async, and it only works well if we're deliberate about it.

The root problem with bad async communication isn't the tools - it's that people communicate the same way they would in person, where you can ask a follow-up question immediately. In writing, a message that requires three follow-up clarifications wastes three times as much time as one that was clear from the start.

The default: write it down

If you've made a decision, write it down. If you've changed direction on something, write it down. If you figured out why something isn't working, write it down.

Not every thought needs to be documented - but decisions and findings that affect other people's work should be captured somewhere findable.

The goal is that someone who was on holiday last week can get fully up to speed without a 30-minute sync call.

When to use each tool

Linear - for work

Tasks, bugs, feature requests, sprint items. If something needs to be done by someone at some point, it's a Linear issue. That's the rule.

Linear is also where customer feedback and feature requests go. If you're on a support call and a customer asks for something, log it in Linear before you forget.

Don't use Linear for discussions or questions. Use Slack for that.

Slack - for conversation

Real-time questions, discussions, quick updates, social. The key word is public channels. If you're discussing something that others might need context on later, put it in the relevant channel - not a DM.

DMs are appropriate for:

• Truly personal matters (feedback you don't want to share publicly, sensitive situations)
• Quick personal coordination ("Can we move our call 30 minutes?")

DMs are not appropriate for:

• Work questions that others might have too
• Decisions that should be visible to the team
• Anything you might need to find again later

The cost of unnecessary DMs is invisible information silos. The person you DM isn't the only one who needs to know - and they won't remember to tell everyone else.

Google Drive - for documents

Anything that's a working document, a contract, a report, or a record belongs in Google Drive. Not in Slack. Not in email. In Drive.

When you create a document, make sure the sharing settings are right - by default, share with the team, not just yourself. And make sure that you create the documents in shared drive, not your personal drive.

GitHub - for code discussion

All code review and technical discussion related to a specific piece of code lives in GitHub. Don't move code conversations to Slack - the context gets lost, and it's harder for the next person to understand what happened.

Email - for external communication only

We don't use email internally. If you receive something work-related over email from a teammate, reply in Slack or Linear and note that email isn't our internal communication channel.

How to write a good async message

Lead with the action, not the context. People scan before they read. "Can you review the PR for the webhook fix?" is better than three paragraphs explaining the background before getting to the ask.

Be specific about what you need. "Thoughts?" invites a 30-minute discussion. "Does this approach look correct to you, or are there edge cases I've missed?" invites a specific answer.

Include the context someone needs, but not more. Don't assume someone knows what you're referring to. Include a link. Name the thing. But don't write a novel for a simple question.

Explicit about urgency. If something is time-sensitive, say so. "Whenever you get a chance" and "Need this by EOD" require different behavior from the reader.

Tag only the necessary people. Ask yourself who really needs to read or answer your message. Make sure you only tag them.

Response expectations

Not everything needs an immediate response. The norm at Hardal is:

• Slack messages: respond within the same business day unless marked urgent
• Linear comments on your tasks: respond within 24 hours
• Support tickets: see Customer Support for SLAs

You don't need to be always-on. Turn off Slack notifications when you need focus time. Let people know if you'll be unavailable for an extended period.

Meetings vs. async

Before scheduling a meeting, ask: can this be done async?

Things that can often be async:

• Status updates
• Sharing a decision you've already made
• Asking a question with a clear answer
• Getting approval on something low-stakes

Things that genuinely benefit from a meeting:

• Resolving a real disagreement
• Making a decision that requires back-and-forth discussions or exploration
• Onboarding someone new to a complex topic
• Sensitive conversations (performance, personal issues)
• Meeting someone for the very first time

If a meeting ends without a clear output - a decision made, a question answered, something agreed - it probably should have been async.