Live data from Hacker News

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

news.ycombinator.com

141–150 of 290 posts

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

#141
post #75
post #39

Earlier quoted context omitted.

When we tried it, gather.town set an awkward expectation that team members had to stand at their virtual desk, otherwise they weren't _actually_ online / working.

That tracks. To me, gather.town is an attempt to replicate office dynamics in a remote setting. In an office, being AWOL is looked down upon. I can see how gather.town builds the same expectation. In my experience, this expectation gets set either way. Whether that be a green light on slack or having your video on for all calls.

I used a 3d-world collaborative environment in a remote company once, and the only effect I noticed was that it brought the awkward parts of the physical world into the digital world. Where do I position myself? Where do I "sit"? Should I "sit"? Is this the right room? What's the "physical" location I'm supposed to be in?

It was like those flash/java-applet 3D navigation interfaces for websites that were semi-popular for a few years, way back: cute, but just made everything slower and harder.

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

#142
post #123

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 vario…

Agree with the above, except:

Sharing solutions in slack works until stuff becomes impossible to find.

Using confluence or some type of team documentation feature can help with that stuff. Better yet, keep it very low effort to add docs there, so people can copy paste important (long lived) messages there.

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

#143
post #123

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 vario…

> Create a fun-sounding moto that discourages DMs

Death

Message

or (slightly different)

Dead

Message

(as in dead on arrival)

Whether that's fun, I'll leave that up to you! ;-)

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

#144
post #30

Make conversations public by default. If you use Slack, make team channels, project channels, announcement channels etc. all public. Discourage 1:1 and private communication unless really necessary, especially for engineering topics. This single change will have an immense impact on overall company culture.

I found this can have negative consequences for more timid employees, junior hires or new joiners. People dont like sounding stupid in public, especially not in front of people they dont know. No matter how much of a safe culture you instil, human nature tends to prevail here and you get the loudest personalities being the the users of those public channels whilst others either dont ask those important questions or s…

Then these employees should use it as a growth opportunity. If you want to be effective at work you need to accept you'll be uncomfortable at times.

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

#145
post #30

Make conversations public by default. If you use Slack, make team channels, project channels, announcement channels etc. all public. Discourage 1:1 and private communication unless really necessary, especially for engineering topics. This single change will have an immense impact on overall company culture.

> Discourage 1:1 and private communication unless really necessary, especially for engineering topics. Working at an established org right now, where the team is still remote first. I tried suggesting this, but got pushback and the team actually settled on the opposite. For example, they want any optional changes (e.g. suggestions) in pull requests not to be left as comments but discussed in private which 90% of the…

> they want any optional changes (e.g. suggestions) in pull requests not to be left as comments but discussed in private which 90% of the time means calls.

This sounds like a hellish existence to me, tbh.

I'm not saying that either my preference or these folks' preference is objectively correct, but I am saying that I don't think I could work in this sort of environment long-term.

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

#147

One thing people miss about remote work is that it's inherently transactional. Show up to a meeting, get or give what's needed, then go back in your hole. This is nice but for many people the lack of genuine social interaction is a killer. A few jobs ago we set up Donut (donut.com) to set up a couple 15- or 30-minute 1:1s per week and tried to stick to the rule that we weren't supposed to talk about work, just chat a…

I cannot relate to the notion that interactions over the Internet must be sterile and non-social. It's like reading someone assert that 2+2=5. My brain breaks trying to process it and starts contorting to figure out how it might somehow be true from some off-kilter perspective when it straightforwardly isn't.

I'm not sure where you read that but it certainly wasn't in the comment you responded to.

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

#148
post #32

Earlier quoted context omitted.

I think you can read between the lines of the OC. They obviously meant social interactions in remote environments are inherently transactional. You never make a zoom call just to say hi to your coworker when your mouse moves past the icon, but you might say hi if you walk past their desk.

> but you might say hi if you walk past their desk No. I would never interrupt someone's flow for a "hi". What an insane take. Those like you, interrupting us for a "hi" and throwing us off a good thought process when you "walk by", is one of the main things which make us all want to work remotely, far from you, protected by a need to have a purpose for your "hi".

After reading your comments I have decided if I'm ever a recruiter I'm going to say "we're like a family" on every communication just to weed out folks like you.

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

#149
post #123

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 vario…

Great list. Add a few..

1. Meet in person every quarter. Fly people into the HQ if there is one. If not just rent meeting place.

2. Have a well written handbook like Gitlab that explains how your company works.

3. Onboarding program - remote onboarding sucks. Do onboarding in person (if you can) or assign an onboarding buddy if you can’t.

4. Slack Is Great But (SIGB) - teach people that they don’t need to read everything. Many people get overwhelmed. Great engineers don’t read everything nor should they. Let everyone know that it’s a shared brain or knowledge source - and it’s ok to turn it off to focus.

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

#150
post #30

Make conversations public by default. If you use Slack, make team channels, project channels, announcement channels etc. all public. Discourage 1:1 and private communication unless really necessary, especially for engineering topics. This single change will have an immense impact on overall company culture.

> Discourage 1:1 and private communication unless really necessary, especially for engineering topics. Working at an established org right now, where the team is still remote first. I tried suggesting this, but got pushback and the team actually settled on the opposite. For example, they want any optional changes (e.g. suggestions) in pull requests not to be left as comments but discussed in private which 90% of the…

Here's some arguments in favor of public comments and conversations:

- Public communication about pull requests encourages knowledge sharing, not just between reviewer and reviewed, but anyone reading. It stores this knowledge sharing long term, so that any future reader can read up on the context and back-and-forth done to get to the chosen solution.

- Meetings are transient. Unless someone takes minutes or a recording/transcription is made and shared, it means the communication in that meeting will be duplicated when it has to be shared elsewhere.

- While I do think the author and reviewer share responsibility for the code in question, merging should be done by the author so that they know when it was merged and can jump in if something goes wrong. That said, in an ideal world it shouldn't matter who hits the merge button, and in fact, something should be automatically merged if it's approved and the pipelines are green, but that's uncommon.

I'd take notes if you ever notice waste from e.g. private / unrecorded meetings, or if someone has to repeat things said in a meeting; take it to a manager and hint that there is a lot of waste.

But ultimately, don't make it a hill to die on. I dislike people going "hey can we do a call" as well - I'm usually busy / elsewhere / focused on something, and there not even being a hint on what it's about is aggravating. The person asking it clearly believes their time and attention is more important (as in "I need feedback on this now"). Sending people that link (after ignoring them for X amount of time after sending a "hey") is passive-aggressive, but educational. Ultimately though, it should be higher-ups that encourage a culture and the etiquette of asynchronous communication.

Post reply on HN