←back to thread

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

238 points aml183 | 7 comments | 15 Nov 24 19:17 UTC | HN request time: 0.724s | source | bottom

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 #
1. 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 #
2. caseyohara ◴[19 Nov 24 21:46 UTC] No.42188440[source]▶
Slack and evergreen are not mutually exclusive.

Asynchronous communication is largely a cultural concern, not a technical one, and completely compatible with Slack. Just give people permission to treat Slack as an async tool and remind them they don't need to be present there every minute of the day.

Where I work, we encourage people to close Slack when they need to focus or simply don't feel like being present. There's no expectation that a message gets an immediate response, even if the person is online.

replies(1): >>42188510 #
3. 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 #
4. 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 #
5. oDot ◴[19 Nov 24 21:54 UTC] No.42188510[source]▶
While this is generally true, is how I recommend to treat Slack, and how I treat it myself, the reality is that its nature is neither here nor there.

It's true that if you treat it just right, you're going to get an async tool. However, you want tools that are naturally like that. There are many foods I can fairly easily cut with a spoon, yet my experience is much better using a knife.

The mere fact you have to encourage to close Slack means it is used for something it shouldn't. Use evergreen communication for most communication, then use Slack only when you need it, which will be much much less.

Slack is also terrible at history preservation, see my reply to a sibling comment.

6. sanderjd ◴[19 Nov 24 22:49 UTC] No.42188923{3}[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.

7. mushufasa ◴[19 Nov 24 23:29 UTC] No.42189191[source]▶
zulip is like a version of slack but designed for evergreen communication