←back to thread

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

238 points aml183 | 3 comments | 15 Nov 24 19:17 UTC | HN request time: 0s | source

We are a remote company. Everything is going well. No plans to be in person, but I’d say we can do a better job at communicating. Any tips or articles to read?
Show context
why-el ◴[19 Nov 24 17:21 UTC] No.42185886[source]▶
I learned the following:

- Everything public in Slack. Create a fun-sounding moto that discourages DMs. Even if a DM happens, and the back and forth resulted in a consensus, share that consensus in a public channel (which makes it searchable).

- Record your team meetings, preferably with software that can AI-summarize. Folks on vacation / leave can get the rundown easily.

- Encourage the sharing of solutions to various problems (technical or otherwise) in Slack. If a developer is stuck, and someone helped them in a huddle or a pairing app, share the solution afterwards (again, makes it searchable). Discourage the over-sharing of screenshots (of your application and other things). Again, not searchable. If one must be shared, describe it. For instance, many devs share a picture of a stack-trace. Not super helpful for others. Grab the text and dump it to Slack.

- Have a good pairing software setup, unblocks for when Slack back and forth is too tedious. I like Tuple (tuple.app).

- Connect your issue tracker to Slack, if you use one, makes creating issues easy. Linear does this well.

- If feasible, have your team meet in person, cadence up to you, but at least once. Meeting the people in real life humanizes them more. I know it sounds silly to say, but it's very true in my experience. Your people will seem even lovelier.

replies(17): >>42186106 #>>42186307 #>>42186329 #>>42186525 #>>42186829 #>>42186914 #>>42187317 #>>42187945 #>>42187974 #>>42188264 #>>42188551 #>>42188809 #>>42188843 #>>42188885 #>>42190285 #>>42193704 #>>42194033 #
oDot ◴[19 Nov 24 20:53 UTC] No.42187974[source]▶
I'd say avoid slack as much as possible. Use evergreen communication:

https://www.emergencyremote.com/emergencyremote#h.vvx9who9kf...

replies(3): >>42188440 #>>42188443 #>>42189191 #
1. sanderjd ◴[19 Nov 24 21:47 UTC] No.42188443[source]▶
How is this incompatible with (or even, different from) using slack? It is asynchronous and preserves history...
replies(1): >>42188477 #
2. oDot ◴[19 Nov 24 21:50 UTC] No.42188477[source]▶
History preservation is not just about continued existence, but also about discoverability. Other forms of communication (issues, project planners, and email lists) are much better for the latter.
replies(1): >>42188923 #
3. sanderjd ◴[19 Nov 24 22:49 UTC] No.42188923[source]▶
Arguably...

I honestly don't even see the argument for why this is true of email lists. I went from an email-list-heavy environment to a slack-heavy environment, and both have been pretty equally good/bad for this.

I do think issues, project planners, design documents, etc. are better for discoverability, but they are also, in my experience, far less complete a history of what's been going on, than whatever the primary communications platform is.

There has been a lot of useful work that gets done in the cracks between the planning and work tracking artifacts, every place I have worked. I think you can either make that persistent and discoverable, despite it being super noisy, or just lose all the context on it altogether.