Ask HN: How do you communicate in a remote startup?

Slack / IM often, don't demand a response instantly though, async & remote go hand in hand.

Put important stuff in email not slack/IM

Have a company wiki

Prefer video calls for alignment

Write to each other often, spend time crafting written narratives, 1-pagers, amazon 6-pagers etc. to share ideas, make people read them, use google docs or ms word online and get comments inline in the document using those tools, follow up on video calls to confirm alignment.

Gitlab has a handbook for this stuff, they are a 100% remote business and very open about their practices: https://handbook.gitlab.com/

consider personal readme's if your team is a bit larger (example): https://gitlab.com/swiskow/swiskow

> Put important stuff in email not slack/IM

I personally think important stuff should be in public slack/teams/whatever channels. I pretty much never use email for any communication; the amount of spam I get, even on my work email leads me to ignore basically all email notifications I get. If I really need someone to see some information, it goes in slack. Email is only used for external communication, and even then if both orgs use slack we just create an external channel instead. I get crap for this on HN every time it comes up but I just can't stand email as a communication medium

a wiki is much better than google docs IMHO as the later quickly becomes an unmanageable dumpster fire. I like mediawiki a lot since most people are familiar with it from wikipedia and linking to yet-to-be-created pages encourages participation.

Nothing team-related should be in email. It's a horrendous place to hide data - worse than even than slack private channels.

Agreed on the broad points. Personally I found simpler wiki systems to be worth it because you'll spend less time making stuff work and less time debugging because it's less complex. MediaWiki, at least from my experience with -pedia, the OpenStreetMap wiki, and others, is that it's complex and slows down to a crawl for hours~days if you bust the cache by making a change to a central template. DokuWiki runs smooth without needing to concern oneself with caches at all—but, of course, is less versatile if you have a 10'000-people organisation and need advanced features for managing all the information (we don't; it works great for us). I'm sure there are also other great options besides DokuWiki, especially if they use a markup language everyone already knows like Markdown instead of some custom syntax only used on your wiki. Another consideration: GitLab, Gitea, and friends iirc all didn't have page locking when I looked at those options ~2 years ago, so you overwrite each other's changes without noticing. Anyway, just some thoughts on implementation details. Wikis are definitely the way to go as compared to a set of documents on a drive!

Only because we've ruined our email with automated systems that are way too trigger-happy on notifications. I think I've received atleast a thousand-fold amount of mail from JIRA that someone has clicked on something, compared to actually useful, actionable requests.