Live data from Hacker News

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

news.ycombinator.com

91–100 of 290 posts

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

#91
post #90
post #81

Earlier quoted context omitted.

if i know a colleague is uncomfortable to speak in a group i can collect their ideas in person, and share it with the group, but ideally the protocol should be public. so create a public chat group with only the two people joining. if the issue is that the person is afraid to speak up because of being ridiculed for their ideas, you have a culture problem that needs to be adressed. if the shy person is new, addressing…

I appreciate your insight (and all other commenters). > if the shy person is new > if the issue is that the person is afraid to speak up But that's my whole point: it's not always "fear". I'm talking about character. Personal preference. Or "people/character colors" or "16 personalities" or some other names it had. Enforcing a strict way to communicate and bashing exceptions (which is my way of phrasing the original…

not being willing to speak up is not a personal preference. being an introvert is not a preference.

it can be a deep seating discomfort, that comes from negative experiences to speak up in the past. sometimes it is so deep that they are not even aware of it themselves.

i was that person. i had no friends in school until i entered university. every negative reaction was a setback. fortunately my experience was mixed and i did have positive reactions too. i learned public speaking as a scout leader for example. otherwise i'd be a hermit now.

people like us need more positive experiences. especially when joining a new team. to allow us to slowly change our preference.

and even introverts need to accept that they need to cooperate with others, and that requires sharing their ideas. or they should find a different line of work.

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

#92
Me personally:

- do my best to avoid chat stuff like Slack, yes even to ping someone before calling, it's more disturbing than useful. Mails are the way to go, much more structured so well searchable and reconstructable as needed, when needed. Doing so force people to communicate a bit more properly in written form instead of wasting time;

- a home office, meaning a room, with relevant environment (low noise, etc) to been able to talk out loud not having to wear headsets and alike, I do not care much if it's a VoIP phone classic call or something else, simply the point is being hands-free all the time, with good enough mic I can move a bit keep talking issueless;

- trying to keep a wiki, which is a VERY HARD task because when you start it's empty so there is no point in going there and after some times many pages became a bit or totally outdated and there is no easy way to bind them to what they document so to get "automatic alerts of not anymore current pages"... It's still useful because it's the sole document culture vs oral tradition enabler that most people know enough to casually use.

Aside an INTERNAL CRM-alike might be of help to being able to get some infos about a contact calling you every time he/she call (including personal stuff like birthdays who help socially).

Doing more often does not work. Most non-tech people still refuse the idea of tickets and tasks to be established/picked, assignments and reassignments rules etc try to push them outside very specific technical landscape in general is worse than giving up on them. Seriously.

That last paragraph is the biggest issue IMVHO: most tools we have are simply rigid and annoying, so most people use them badly nullifying any potentially positive outcome. To be short: more free text, more comms, less rules works regularly better, if you still manage to avoid exaggerations.

Onboarding is the hardest part: if normally docs are bad in general those to "get start with us" are the worse, essentially nonexistent or if present totally useless. In the end even in IT most people do not know how to work with IT tools and paradigm, and tend to be unwilling to learn.

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

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

The amount of strictness or enforcement behind the word "discourage" in "discourage 1:1 communication" in the parent post is open to interpretation.

What you have is people using a tool for different objectives, and when their chosen behavior hinders your objectives things seem out of whack.

I'm against shoving an eye of sauron communication hose down people's throats. I simply give my constructive feedback after the fact. E.g. when someone dm's me I say, "so-so is waiting for this to be done for their thing, so mention this part in the channel." or "the other team would need to know this for a refactor, so add this info to the wiki." If someone feels the need for dm'ing for some psychological safety so be it. But the cost of that safety is additional communication overhead for filling in gaps that the person should be ok with. And the people that value the psychological safety they gain usually don't object or have no grounds to object to a duplication of communication to fill those gaps when someone points out those gaps exists.

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

#94
I have found that the key to running remote teams is cadence, communication, and connection. This is more difficult with a remote team, so you need to be much more intentional. Remote teams that are not connecting tend to focus solely on work and miss the purpose behind everything you do.

Here is a simple cadence: hold all-team group meetings to share core values, mission, and to keep the vision in front of the team. Next, create smaller groups if you are managing a larger team, and encourage introverts to participate alongside extroverts to build relationships within the team. By doing so, the team will work harder and even help each other as a cohesive unit. While it takes effort to build, it is worth it.

The final step is communication, which we all know is vital. With a remote team, you sometimes have to over communicate since there are no casual water cooler chats or coffee breaks to connect informally. This requires a time investment to develop, but the return is a longer-lasting team with minimal turnover. It's worth the effort to build a great remote team.

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

#96
post #91
post #90

Earlier quoted context omitted.

I appreciate your insight (and all other commenters). > if the shy person is new > if the issue is that the person is afraid to speak up But that's my whole point: it's not always "fear". I'm talking about character. Personal preference. Or "people/character colors" or "16 personalities" or some other names it had. Enforcing a strict way to communicate and bashing exceptions (which is my way of phrasing the original…

not being willing to speak up is not a personal preference. being an introvert is not a preference. it can be a deep seating discomfort, that comes from negative experiences to speak up in the past. sometimes it is so deep that they are not even aware of it themselves. i was that person. i had no friends in school until i entered university. every negative reaction was a setback. fortunately my experience was mixed a…

I'm afraid we speak of different things completely. I'm referring to personality differences and how to allow each personality to be part of the team. You speak of dealing with bad past experiences or maybe even trauma.

My point was that you should not and can not change other people's personality. You should make sure understand reasons of why others might not embrace same methods. And some advice in this thread ignores that. It's actually a source of frustration for many, not being understood on such basic level, while nothing is wrong with you.

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

#97

Earlier quoted context omitted.

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

The amount of strictness or enforcement behind the word "discourage" in "discourage 1:1 communication" in the parent post is open to interpretation. What you have is people using a tool for different objectives, and when their chosen behavior hinders your objectives things seem out of whack. I'm against shoving an eye of sauron communication hose down people's throats. I simply give my constructive feedback after the…

> The amount of strictness or enforcement behind the word "discourage" in "discourage 1:1 communication" in the parent post is open to interpretation.

Realistically, if the team decides that synchronous communication and not keeping too much of a historic record works best for them then I guess that's it, it's up to them to deal with that long term, since I'm just a colleague and it'd be counterproductive to try and change everyone's mind. If I did something like that, I'd probably just come across as a bit of a jerk.

You can show people the benefits of a particular approach but whether they accept that those are benefits (e.g. looking at a pull request of mine from 2-5 years ago that shows context for why a certain change was done a particular way, has images of benchmarks, descriptions of other factors to consider etc.) is up to them. Same for synchronous communication: to them, being able to call someone and have a conversation might be easier and more productive than the alternatives, they might just be unbothered by context switching or interruptions... somehow.

Though one could probably argue that some practices (like version control and CI/CD, for example) are objectively good to have, regardless of personal preference, for the sake of the development landscape not looking like The Wild West. How far that might extend, however, I have no idea.

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

#98
post #96
post #91

Earlier quoted context omitted.

not being willing to speak up is not a personal preference. being an introvert is not a preference. it can be a deep seating discomfort, that comes from negative experiences to speak up in the past. sometimes it is so deep that they are not even aware of it themselves. i was that person. i had no friends in school until i entered university. every negative reaction was a setback. fortunately my experience was mixed a…

I'm afraid we speak of different things completely. I'm referring to personality differences and how to allow each personality to be part of the team. You speak of dealing with bad past experiences or maybe even trauma. My point was that you should not and can not change other people's personality. You should make sure understand reasons of why others might not embrace same methods. And some advice in this thread ign…

i know what you mean. my argument is that a personality difference that is so strong that it prevents you from participating in a group discussion must be caused by trauma.

group discussions are a requirement in our industry. if not wanting to talk to people is a mere choice then you should be looking for a job where you don't have to talk to people.

in my understanding, having difficulty or even just discomfort to talk in a group implies trauma. and they deserve any help we can offer. but if there is no trauma and they simply can't be bothered to make an effort to accommodate the group, then why should i make an effort to accommodate them?

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

#99
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?

Hi again. I agree, this isn't for everyone.

But I have worked at very small startups where you're all in one room (talking 10-20 people) and it was a kind of "lightning in a bottle" environment that I've been trying to figure out how to recreate for years, especially now that I work remote.

I think in a small, high-trust group like this it could be fun. Agree that once you get to a certain size this is almost guaranteed to be misused.

(I'm not affiliated with the product or anything in this space, just someone who wishes there were better ways to approximate that vibe remotely when desired.)

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

#100
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.

Basecamp is incredible for this.

Encourages grouping people by projects, with all communication on a project being public.

All activity on a project listed in one place.

Catching up with work takes minimal effort, including when someone goes on vacation or leaves the team. All it takes is skimming through the project.

Slack is built around chat with high has its limitations when applied to the context of a longer term project.

Post reply on HN