[why-el]

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.

[patrickhogan1]

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.

[crystal_revenge]

Worked remote most of my life. Quarterly meetups are exhausting for people that didn't sign up for travel for their job. Many people doing remote work do so because they have a lot of responsibilities at home and benefit from being able to work around family, pets, etc.

However, my experience is the difference between 0 in person meetups and even 1 per year is astounding. I was at one company that didn't have in person meetups for years and when they finally did the company culture changed (for the better) over night. The difference between 1 per year and 4 per year is negligible barring the fact that the latter makes me start to dread meetups rather than enjoy them.

[whiplash451]

Agreed. The sweet spot in my experience is twice a year but your point is very valid. Once a quarter, sustained, is heavy on personal lives.

[diggan]

> 1. Gitlab somehow statistically tracks public / DMs. Haven’t implemented at my startup but if anyone knows a simple way to do - please let me know.

If you use Slack, I think the admin panel already contains the number of messages in channels VS DMs. Long time I last saw it myself, but I think it was missing a breakdown on how many members of the Slack received the channel/"public" messages (as not everyone is part of every channel, 2 member channels vs 200 member channels for example), maybe it looks different now.

> 5. Slack Is Great But (SIGB) - teach people that they don’t need to read everything. Many people get overwhelmed

I think this happens when Slack is the "source of truth", because the ephemeral feeling it gives since it's a chat ultimately. If you instead use a wiki/whatever to actually collect things that are important, there is less stress about possibly missing out on important things. Make summaries by week/month and it'll be even easier for people to catch up easily, which means even less stress :)

[patrickhogan1]

Thank you! I'll check out the Slack admin panel! I removed that item from my main message because I was concerned some people might misinterpret "tracking" as something invasive (e.g., reading messages). What you're describing is exactly what I'm looking for—just the stats—to support public disclosure and knowledge sharing.

[Buttons840]

The "source of truth" and the place you post dank memes and ask what people are doing for the weekend--those shouldn't be the same place. Slack is not a good "source of truth".

[mozman]

Slack is meant to be addictive. I only use the web client and modify it with tampermonkey

All notifications disabled and I only read when pinged. davison updates are the only mechanism allowed.

[j33zusjuice]

How the hell do you get by with that? I’m jealous. I’ve gotten pinged by my fucking EVP for not responding to questions in chat fast enough (non-critical, too!). At least no one gets on me for missing emails. I don’t even read those.

[diggan]

> How the hell do you get by with that?

You have a company policy that allows that. For example, if anything is decided in Slack, it has to be "codified" somewhere else, like a wiki. Then you'll be able to justify not reading through all messages.

[aen1]

Meeting in person >1 hour away is difficult for people in many life circumstances. And if there are constant meetings, it either strains families or makes the person who can't make it feel left out

[ravishi]

Yeah. Once or twice a year should be fine, I would say.

[7k5kyrty45]

>Meet in person every quarter

What benefit would you see in doing this? The only thing I've heard is some consider it nice to be in close proximity to others, but that doesen't really sound like a business reason

[j33zusjuice]

Quarterly would be a gross misuse of budget, imo. I think there’s tremendous value in physically meeting your team—-I can’t quantify it, but I can feel it—-so once a year is good, to me. Maybe twice if one is business and one’s a party or something.

[setsewerd]

Seconding this. My team meets annually for several days, at a conference that gives us plenty of social time together in the evenings.

As you said it's hard to quantify the value, but anecdotally I notice it most in 3 (distinct but somewhat overlapping) areas:

(1) Overall morale - everyone enjoys work more when you have a good relationship with your coworkers, so people are willing to do more than the bare minimum. People approaching burnout feel more enthusiastic about work afterwards. (2) Everyone is more inclined to help each other out with tasks outside of their routine but within their skillset, reducing bottlenecks. (3) Similarly, you develop a better sense of each other's personalities and skillsets in a way that's much more difficult when remote, so communication is more efficient, and collaboration more effective due to that increase in understanding and empathy.

[lanstein]

s/Slack/Zulip

[stavros]

Seconded, Zulip's model is fantastic. It makes it a breeze to catch up or coordinate.

[wellthisisgreat]

Zulip is amazing

[o999]

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

I was recently surprised to find it is actually searchable in slack, apparently Slack OCRs the screenshots and even photos of text and you can find screenshots in the results if the keyword can be found in them.

[MisterKent]

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.

[rglullis]

Yes, I think I mentioned this before: we had similar issues on our team and I was tasked with improving intra- and inter-team communication.

The solution we adopted was to create a Confluence space for each team, and any question on Slack would have to be in the form of "Where on Confluence can I find the information about <thing I need to learn>?"

This very quickly made all team leads responsible for documentation and for keeping things up-to-date. If no page about <thing I need to learn> existed, then the lead would have to create the minimal page even if just to answer the question on Slack and respond with the Confluence link. Once you have the link, people would use the comment page to ask for clarifications/details, and we would "resolve" the comments as soon as the page was updated.

Maybe it's because I am big fan of wikis, but to me this worked quite well.

[jandrewrogers]

The biggest problem with Slack, by far, is that it is effectively ephemeral. An enormous amount of valuable content in Slack quickly becomes undiscoverable for all practical purposes. This creates significant challenges if history matters and this only gets worse as the number of people on it grows. In every organization I've participated in where Slack is the central "everything box", they had to invent parallel processes and systems so that things don't get lost in Slack.

Slack should be treated like the super-IRC that it is, it is poorly designed to be the nominal system of record that people try to use it as.

[crystal_revenge]

I hear people say this all the time, but at multiple jobs in the past Slack has acted as my own internal Stack Overflow.

Whenever I got a weird build issue, or some error that was related to internal code, I would just search Slack and the majority of the time I would get the answer I was looking for, provided that answer was a problem in the past.

Likewise I've found Slack search invaluable when it comes to remembering conversations I had with someone months ago.

Beyond just search, I've seen teams have lots of luck with task specific channels for major projects. It keeps the chatter low and the information high.

Ultimately I think my favorite thing about Slack is that it is a pretty good de facto internal knowledge base (better than poorly maintained confluence pages for sure).

[wingerlang]

Same here. Slack provides answers way more often than Confluence. I tend to write conclusions to threads or discussion in a somewhat keyword heavy manner, simply so that I know I can search for it in a year or two.

[organsnyder]

> Meeting the people in real life humanizes them more. I know it sounds silly to say, but it's very true in my experience.

I've found once per quarter to be the sweet spot. It builds up so much trust.

[oDot]

I'd say avoid slack as much as possible. Use evergreen communication:

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

[caseyohara]

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.

[oDot]

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.

[sanderjd]

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

[oDot]

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.

[sanderjd]

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.

[mushufasa]

zulip is like a version of slack but designed for evergreen communication

[dangerlibrary]

My slack profile, for years, has had a volcano emoji and the words "DMs are lava. Don't touch the lava."

It doesn't actually stop people from DMing me, but it does soften the blow a bit when I immediately move technical/product conversations out of DMs. (Obviously anything personal or sensitive stays private)

[m0rphling]

I get that a lot of people see Slack as a panacea for all communications, but too often it ends up a dumping ground for anything and everything for which searches might not be as effective over time. Also, that data in Slack can and will be a liability risk to you when it comes to data privacy, compliance, and any litigation hold requests. Do understand that larger organizations (especially FAANG) will purge slack conversation data after a certain period of time for these reasons.

Finally, I feel DHH's article on group chat still provides valid criticisms and recommendations to retain your sanity and prevent the feeling of FOMO: https://signalvnoise.com/svn3/is-group-chat-making-you-sweat...

[mettamage]

> 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! ;-)

[7k5kyrty45]

>Record your team meetings, preferably with software that can AI-summarize

If the summarizations are trustworthy it sounds like a good idea, however I've yet to see a reliable AI-summarizer that doesen't result in very high costs when wrong assumptions are made because of invalid or downright sabotaging summaries or generated documentation.

I believe minimizing the synchronized time people need to spend together in any task is best; have the least meetings possible while blowing away obstacles with as few people as is necessary. You can save an unbelieveable amount of unproductive time people would be locked in meetings they don't belong or contribute to.

[dyauspitr]

I think having long discussions in slack is a huge waste of time and adds a tremendous amount of overhead. Usually something that a 10 min call can achieve takes hours over slack.

[emmelaich]

Don't rely exclusively on async communications. It can be a huge time waster.

Have your team in vidcon regularly, scheduled.

Whether for strictly work or social doesn't matter. If social, leave a big window of time that people can come and go anytime they like without explanation.

You can even leave a camera running in each location for a while just for the occasional hello / wave. (Just make sure the camera is marked as and understood to be live)

[aen1]

Totally disagree. For introverts, "everything public in slack" means that I would rather not say something than have 50 people see my thoughts/rants/silly questions in public

[neilv]

Are you sure that's introversion, rather than shyness or insecurity? The answer might help with the solution.

[eddd-ddde]

Agreed, you are collaborating with a team, if you are not comfortable sharing thoughts how are you gonna be comfortable sharing _code_.

[bezier-curve]

There's also such a thing as oversharing context with people that are already burdened with a lot of context related to their own tasks. Splitting off into private conversations helps keep irrelevant members from context switching.

[saxelsen]

From my experience working remotely for 2 years, this can be accomplished by starting a thread with a descript title and posting the body (with the context) inside the thread. Just like reading across a bunch of article headlines on HN.

For ongoing discussions about a topic, start a channel and perhaps prefix it "temp-" to indicate that it's a temporary channel.

[pasc1878]

The issue is what is best for the company. If a person is not asking or answering questions then they are not a valuable member of the team.

Keeping stuff secret and hidden does not help the project. If your team is 50 you are probably not the only one asking the question and several people would be able to answer the question, limiting to one just annoys the one you asked if they are busy and someone else is not.

[lomereiter]

IMO the actual difference between introverts and extroverts is that the latter use @here and @channel a lot more frequently

[nickstinemates]

In addition - promote face to face meetings via zoom/google meet/discord/?, ideally on-the-fly meetings created in the open so others can join based on the topic.

[AlotOfReading]

You also need a way to go from code->team's Slack channel if you want to eliminate DMs. I can easily DM the people who maintain a file from the info in the git log or the CODEOWNERS file, but I can't look up the slack channel they share without writing a slack bot and talking to IT.

[sanderjd]

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.

[sarchertech]

Yeah there are plenty of things that shouldn’t be said in a public. Problems that haven’t been verified yet, ideas that haven’t been through etc…

If your company is big enough there’s bound to be someone above you who will hold you to the first version of an idea you threw out or who will freak out about something that may not really be a problem.

[crystal_revenge]

> Yeah there are plenty of things that shouldn’t be said in a public.

It is worth pointing that one of the value adds for any company using Slack is that nothing is private. Anyone with an admin role can read any conversation, DM or otherwise, and this is considered a good thing since it allows the company visibility into employee communications in cases of illicit activity.

What's odd is very few teams I've been on have made this fact very clear. Which reminds me a bit of Dr Strangelove when the doomsday machine is kept a secret for a birthday surprise. The entire point of being able to monitor private comms is as a deterrence. Employees are less like to send a message that might be considered inappropriate in the first place if they know they're being monitored.

[sarchertech]

Last I heard only Workspace owners could read messages and they have to request access from slack.

They could also export messages and give anyone they want access to the resulting dump I suppose.

[j33zusjuice]

I didn’t realize how important meeting people IRL was until I didn’t meet my team at my last job. I felt like an alien or something there. It sucked. A year and a half in, they planned a meeting, then fired me right before it. ¯\_(ツ)_/¯ Place was lame anyway. Adtech is the devil’s work.