Live data from Hacker News

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

news.ycombinator.com

221–230 of 290 posts

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

#221
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…

Async PR reviews are an absolute nightmare. Very simple conversations take forever. Reviewers will see something that’s not an actual problem, just something they are confused about and leave a comment rather than approve, and then your PR is blocked for a minimum of most of the day while you want for them to see your response. I just approve any PR that doesn’t have obvious issues now.

Meanwhile if you have a call to discuss it or do it in person, you can rapidly answer any questions and get the reviewer to fully understand what they are looking at.

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

#222
post #209
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…

I'd say avoid slack as much as possible. Use evergreen communication: https://www.emergencyremote.com/emergencyremote#h.vvx9who9kf...

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.

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

#223
post #209
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…

I'd say avoid slack as much as possible. Use evergreen communication: https://www.emergencyremote.com/emergencyremote#h.vvx9who9kf...

How is this incompatible with (or even, different from) using slack? It is asynchronous and preserves history...

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

#224
post #12

If you're in similar time zones, try https://www.gather.town/ ? I've used it for remote conferences, and I like its 2D UI. Real sense of space there.

We've had great success with Gather. Organic conversations happen a _lot_ more often than when we only used Slack. We still keep Slack for async communication.

We have a decent spread of people across the introvert-extrovert band and we don't set concrete expectations on camera on or spending time in common areas - but both are encouraged.

I'm surprised how well it works. We've been using it for almost 2 years now, I think.

Our company is about 15 people.

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

#225
Some tricks I learned from the masters: -No scheduled 1:1s (Brian Cheskey & Jensen Huang). 1:1s isolate conversations, clog up calendars, and slow things down as people queue stuff up. They also can end up being reverse theraputic where people who come in happy end up finding things they aren't happy about. If you have 30 direct reports and do 30 weekly meetings, that's 15 hours a week burned. Finally, discussions and decisions should be made with all relevant people present.

-Quarterly Offsites where you actually work together in the same room, not strategy sessions. Don't try and come up with strategy during offsites. Get a big hotel conference room in a cheap city (Vegas, Montreal, Orlando) with good internet and sit everyone side by side. Fly in Monday morning, leave Friday afternoon. Do this once every three months for the full team. You get a full week working together. It's better do to longer sessions (like a week) less frequently than shorter sessions (like 2 days) more freuqently. This gets you really synced up with everyone.

-Sunday night executive meetings (Tim Cook does this). Sorry but if you're a startup and you're trying to build something awesome you should expect your leadership team to meet Sunday nights. Audio only phone call is fine.

-Audio-only by default. This doesn't mean "camera off"; that's an awkward format. It means being in a position to have fast, quick audio conversations enables the spontaneous collaboration lost from the physical office in remote work. Audio-only is also more palletable for working late hours. Who wants the camera on at 11pm? But you're willing to voice chat for a sec to work on something. You want to set things up to be able to work around the clock.

-Weekly all hands. Do it closer to the end of the week. I like Thursday afternoon because it tends to maximize attendance. This one's from Skip Schipper, former head of HR at Cisco.

-Make people do live demos in a stage or theater type setting. Make it kind of workshoppy, where there's real-live feedback in realtime as people do stuff. This one's from Steve Jobs.

-AI Meeting Sumamrization is great but you need to make sure its surfaced in a way that the releavant people can get to it.

-Do not pack your calendar with back-to-back video calls. The sign of strength is "calendar zero", not calendar filled up.

-Music. People who listen to similar music tend to get along and bond best. I learned this one from Douglas Hofstader.

-Encourage people to come find you immediately if they need anything. This is the big, fundamental problem with remote. You get stuck, you stop. You must must must get people to take the extra step to proactively find each other so they can keep working at maximum speed.

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

#226
post #209

Earlier quoted context omitted.

I'd say avoid slack as much as possible. Use evergreen communication: https://www.emergencyremote.com/emergencyremote#h.vvx9who9kf...

How is this incompatible with (or even, different from) using slack? It is asynchronous and preserves history...

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.

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

#227
post #12

If you're in similar time zones, try https://www.gather.town/ ? I've used it for remote conferences, and I like its 2D UI. Real sense of space there.

This would be insanely disruptive to me and I think most of my team. There are much better ways to handle this like using gitlabs handbook. To me this is the equivalent of having to be on camera all day. Am I idle if my avatar hasn’t moved or interacted with something in game?

Not everything is out to get you. Gather doesn't have any automatic idle detection.

I doubt Gather would work well for a large company where there is less trust between individuals - maybe that's the scenario you're imaginging it in?

It works well in our small company where trust is implied by being here and we have few concrete expectations. In practice it's no different than being signed in to Slack.

You have the option to mark yourself as away or to passively lock your desk area so people have to knock to come in but this status isn't apparent unless someone comes by.

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

#228
post #209

Earlier quoted context omitted.

I'd say avoid slack as much as possible. Use evergreen communication: https://www.emergencyremote.com/emergencyremote#h.vvx9who9kf...

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. Ther…

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.

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

#229

Use Roam( https://ro.am/ ) It's like being in a office while being remote and really helps with that zoom fatigue and actually let's you have a HQ and drop into colleagues offices.

I really, really love Roam for the synchronous work, but it is reeeally not helpful for asynchronous, which IMO is absolutely critical as soon as you’re working on something of moderate complexity spread across 2+ timezones.

We ended up switching to Campsite (campsite.com) which is brilliant except for the synchronous stuff (calling). Calling exists, it’s good, their recording feature is great, but the general “smoothness” of hopping in and out of calls on Roam is absolutely unrivaled.

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

#230
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…

I think "everything in public" is actually bad advice. Not everyone is comfortable saying everything valuable that they have to say, to a large audience. It is very intimidating to ask questions in a channel with a lot of members. "Too bad, get over it" is not the optimal answer.

What I do believe is good is to encourage things to be public by default, and to encourage people to be stingy about what they make private.

I think a good balance is:

1. Private DMs with your manager, for sure. This is no different than why managers should have a set schedule of closed-door 1:1s with their reports. Sometimes there is awkward stuff to discuss with managers, and there needs to be a venue for that.

2. Private group for small "leaf node" teams. This is IMO the best place to share "I'm sick today" or "I'll be on vacation on these dates". In my experience, people prefer to share this kind of stuff with a smaller group, and I think that is reasonable. This also gives newer or otherwise more insecure team members a less intimidating place to ask questions they're worried are dumb.

3. Pretty much everything else public.

YMMV of course, but personally, I've seen problems from both too-private and too-public cultures.

Post reply on HN