- 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.
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.
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.
> 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 :)
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.
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".
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.
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.
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
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
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.
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.
> 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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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)
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.
>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.
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)
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
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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'm at a company now where we are trying to do this but the CIO/CEO keep weighing in on EVERY conversation where they disagree with the approaach. The whole reason we are having the open conversation is for ideation and good communication but when a high level person comes along and says "well thats not the way I would do it" everyone decides to go back to 1:1s, direct messaging, and calls so as not to document anything publicly in feat of being called out by the higher ups.
Quick note that if you're actively working around the CEO on a regular basis, you need to stop and find another job. Or possibly replace the CEO but that's a high stakes low probability of success endeavor.
What's happened here is precisely why communication should be public, it's revealed a real problem in the company you're at.
I've been on teams exactly like this, but the problem isn't public channels, it's "leadership" not knowing how to let go and trust their teams. Doing more work in private is the negative consequence of this bad practice, but I assure you this issue will eventually cause problems no matter how clever people are in avoiding public conversations.
And startups that are on the path to long term success will have leadership abandon this type of butting into every day communication very early in their growth. A good C-level must learn the build teams that can scale beyond their individual interventions. You literally cannot grow beyond a 30 person organization (and survive) if this much intervention is required.
Incredible. Every point of data shows the highest compensated members of a firm doing the least work / being the most harmful to productivity lmfao. Wonder what the takeaway here is
I don't think this would be such a problem if people were comfortable challenging the CIO/CEO. So maybe that's the cultural aspect that needs to change on the exec's behalf?
Private team channels sound like a good compromise
Also someone with good standing in the company to politely point to the CTO that it's not his job to give his 2c at every conversation in slack (typical behaviour of people coming from the technical side)
I was going to say the same thing. Had this setup at my last job and the CEO would chime in with irrelevant, outdated, not feasible, or already considered ideas. We'd then have to spend time communicating and explaining the shit we had already been talking about for the last month or whatever. It was incredibly frustrating because it gave a public impression that our team was either incompetent or combative. It was gross.
I find it very dangerous when you have some technical people who moved upwards into non-technical roles still being involved in technical discussions.
Their words carry a lot of weight, yet they have no idea about the actual context of the work being done.
Sometimes this is useful and a fresh perspective from an experienced colleague can unblock things, but more often it stifles discussion and discourages the juniors from thinking freely.
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 seek back channels anyway
I think this is something that can really be mitigated by more senior people modeling good behavior.
For example, as a principal engineer on a new project or working on something I wasn't familiar with, I'd go out of my way to ask things along the lines of "Hey, this might be a dumb question, but I'm new to X so could you explain how I do ..." I think this goes a long way to building up a culture of psychological safety on a team.
Hamfisting an ideology to human nature just doesen't seem to work no matter how nice the end result could be. People don't generally do uncomfortable things unless they are forced to, take for example literally anything else in life; entire fields of professions exist because we don't like cleaning thing X or Y
Yeah, I'd agree you want a healthy balance of 1 on 1 and group conversation. A quick aside is one thing, and if it is a question that should lead to documentation then documentation should be written for it instead of just assuming someone is going to search through a year+ of slack messages in some public channels.
Even in person, not every conversation is good to be had in front of the large group for a variety of reasons.
> 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 time means calls. They seem to dislike discussion threads in Slack and want meetings for things instead. I’ve also noticed things like the person who reviews a pull request being the one who has to merge it and essentially take responsibility for it, versus just giving approval and the author merging it and making sure everything is okay after CD.
I’m very much the opposite and prefer to have things in writing and like asynchronous communication. But when it is written messages, usually people either ask for a call or just do “Hey.” I actually made this a while ago hah: https://quick-answers.kronis.dev Either way, people also really seem to dislike writing README files, or all that many code comments, or making the occasional onboarding script or introducing tooling to do some things automatically. I don't get it.
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.
> 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.
If I could magic-wand my own company, I would 100% aim to hire folks who are extremely comfortable with written communication. Asynchronous, written communication is 1000% more productive than meetings imo, and makes the organization's knowledge indexable and permanent.
> 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.
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.
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.
> I’ve also noticed things like the person who reviews a pull request being the one who has to merge it and essentially take responsibility for it, ...
I worked on some teams that had that and it wasn't bad at all. In the end, what's on the main branch is everyone's shared responsibility (...was our thinking).
It encourages real PR reviews, where the reviewer is paying attention to the changes, spend time on the review until they understand what is happening and why, and when they feel comfortable, they merge it as if the PR were their own. It doesn't sound efficient, but in the end it means you always have a backup person to turn to in case there is an issue, and we mainly only had "exotic" bugs.
This only works with the right team and leadership. It was completely normal to say "yesterday morning I spent half the day reviewing that PR".
OTOH, I was also on a team where PR approval means someone scrolled through your changes in 1 minute and didn't find anything blatantly wrong, go ahead and merge and hope for the best. This team broke the main branch in a significant way 2-3 times a week.
My experience (being fully remote for over a decade) is that it's extremely distracting to have all discussions public. It creates a lot of noise and it's very hard for people to not get drawn into conversations that doesn't directly affect them. It's definitely good to have finished conclusions available for everyone, but the "sausage making" is more distracting than useful.
Of course it depends on the size of the team we're talking about.
It depends on your self-discipline as well, as in, leave Slack or whatever alone for X hours a day, leave channels that aren't important, and if the volume is higher than you can manage in a reasonable time, Slack has AI powered summarization tools nowadays which are pretty decent. Ultimately though, your attention span and information management is your own responsibility, nobody else will filter it for you.
It helps to have lots of channels that specialise. I was effectively remote for 15 years (I was in London other in US).
`
If you are concentrating then you don't notice the chats, unless they are made urgent. When your focus has finished look at the channels that are nearest your speciality or sub team.
How to find comfort for and include characters that don't like the spotlight? At least not during early phase/brainstorming.
I've worked with many great people that hate to handle things without their usual group first, and will stall until a reasonable approach can be presented. Which means creating shadow communication process - the more you push for "discouraging 1:1" the more they will hide.
What your organisation did with such "incompatible" people, relate them until the team left likes how they work, or were there better ideas?
In my experience, most of the time this can be solved by resetting expectations. Once people learn that asking basic questions won’t open them up to mockery, things move a lot smoother for everyone.
After all, a culture on 1:1 communication has a lot of downsides. The same question gets asked repeatedly, replies don’t become searchable, the same people (usually the most experienced) end up being constantly tapped for answers
That's key, it has to be considered safe to ask questions. Anyone mocking or showing contempt to another on a channel would be immediately reprimanded in private by managers at my company.
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 the problem can be as simple as having the new team member do pair programming sessions with everyone on the team, so that they can get to know everyone better, which will make them more comfortable to speak up. maybe their previous job had a bad culture that influenced their behavior.
those pair programming sessions can also help you identify if there are particular people that cause problems by being intimidating in some way to others. sometimes pair programming can even fix those problems, by allowing the two to get to know each other better and learn to respect each other. that doesn't always work though, and care must be taken that the person who is "afraid" to work with the "bully" is not forced to an interaction they are not comfortable with. if the discomfort is that high a more cautious approach is needed. especially if the person afraid is a long term team member.
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 comment) will work for some, but will also create an artificial leash for others. I think it's too strict and to generic to try to just implement it by force. Yes, whole team should be available to see details, be able to participate, but why enforce that on such a low level as forbidding 1:1 talks...
From my recent experience, aside of excluding many personalities, it kills a lot of inertia that spontaneous prototyping and brain storming needs.
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.
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.
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?
There was nothing that drastic in my original comment. I'm speaking of differences that are present in all of us, not extremes.
See those 16 personalities or character colors tests I referred to. (although I'm not saying these are good, just illustrate well what level of differences I'm speaking of)
those differences should not prevent you from speaking up in a group. not wanting to speak up when you have something to say is something drastic that needs to be addressed.
No one is inherently "incompatible". It's mostly the environment influencing their behavior. There needs to be a culture where everyone feels comfortable speaking up and working outside silos, and that is always driven by management and senior eng leaders. For example do junior engineers get constructive criticism on a bad idea or design or are they yelled at and penalized? If the latter, of course everyone will think twice about being open.
And even then you can only do so much. If someone really doesn't want to participate then, well, it's on you to decide how to deal with that.
I’d want this as much as I used to enjoy open floor plan at the office… Discouraging 1:1 and private communication in my experience would actually have 100% opposite effect of what you are describing. This is equivalent to discouraging pair-programming which while may not be everyone’s cup of tea many find extremely productive
I’m with you, then again Best Practices mean best for your work environment, not all. I’m currently making sure to cultivate an environment where my staff are comfortable sharing information openly. Not all of my people are comfortable announcing things to the group and want to bounce things off me or other supervisors. Sometimes you have to meet people where they are at. Like establishing the vision and just keep making sure you’re moving towards it.
you bring up a good point. what matters is the forum where decisions are made. you can talk about ideas in private. but the ideas need to be brought up in the group before any decisions are influenced. especially if the private conversation is with a team leader. if a team leader hears an idea in a private conversation they should ask that person to repeat the idea in public. but also they should discourage team members to specifically approach them to bring ideas. that is what is meant by discouraging private conversations. of course you can talk in private, but if the idea is not repeated in public then it is as if it was never talked about
While Slack - if you pay for it - permanently stores all communications and makes it archivable, it's also ephemeral and anything said more than a day ago is effectively gone. They do have an AI summary tool to catch up though, if you pay for it, which is alright.
To me the difference is in the affordances and mental model.
Basecamp - groups all communication, assets, participants, tasks in a project space. I open the project which establishes context for everything and everyone. This predefined context makes short efficient communication very powerful.
It’s incredibly simple and sophisticated at the same time - allowing grouping activity by people projects tasks etc.
The ephemeral nature of chat-centered systems makes me incredibly nervous about missing things or being unable to find them.
This contributes to stress and notification fatigue, especially when bombarded with alerts from every channel. Some will turn off notifications entirely or disengage to maintain focus on their workload.
I'm struggling with this at my current job: nobody communicates about anything in asynchronous channels, doesn't want any form of daily synchronous meeting (e.g., standups), and won't agree to ad hoc meetings outside of our 1 hour once per week meeting. So lots of decisions and work get done in vacuums, which cause errors in various systems that would have been easily caught and addressed if someone just said "hey, I'm changing this column name from X to Y". So, just to say that the counterfactual here isn't "no stress because no notifications"-- it can be more stress from failed coordination.
There are in betweens here, with the major one being threads in slack. Everyone gets notified about a single message at the start of the thread, but does not get notified for any subsequent discussion. Any interested party can read more and participate as needed. For someone like me (a leader on paper but not really in practice), I'd read all the message and look for dependency or similar problems, but for others they may not need to.
And that's fine. You're not expected to stay online and respond at all times, that's the antithesis of asynchronous communication. Just reserve a block of time per day to catch up - like you would with emails - and go through things then. Only leave notifications on if they're addressed to you specifically.
Teams badly fucks this up by not providing normal-ass chats that aren't private ephemeral-ish groups. Their "teams" only have these weird announcement-oriented chats with terrible UX and visibility for ordinary chat activity, so you end up having to do everything in meeting-tied chats (created by the meeting, not the other way around) or ad-hoc group chats.
You can fake it with lots of manual "pinning" but that relies on everyone agreeing which chats are primary and should be pinned so they don't start splitting messages over other chat rooms, then you still end up with things like chat for one basic topic being split across multiple meeting-chats that all have the same membership or (worse) just slightly different membership.
It's as if they designed the tool to make effective remote work hard—but this also (like most things that make remote work worse) makes using it in an in-office context worse. It's just flat-out bad.
♫ ♪ ♬
It was the dark of the moon
On the sixth of June
In a Kenworth, pullin' logs
Cabover Pete with a reefer on
And a Jimmy haulin' hogs
We was headin' for bear
On 'I-1-0
'Bout a mile out Shakey Town
I says, Pig Pen this here's the Rubber Duck
And I'm about to put the hammer down
♫ ♪ ♬
I can appreciate the thinking here, but it not ideal. Different details are relevant to different people. And async is inefficient for many situations. Yes publish findings/results, but overcommunicating has a cost.
Better to create different channels (sync, async, 1:1, broadcast), provide guidance and trust workers.
It's not necessary about trust, or relevancy. I believe motivation is contagious, and making communications hearable/visible for all most of the time can be beneficial because of this.
... and soon with this type of setting you will arrive at siloing the information. Having all communication public in the channels comes with its cost but everything is as transparent as it can be. Important distinction is that you get to choose if the detail is relevant for your work or not. And not your manager or whoever.
I'm sure there's features here or in progress where you'll be able to ask for an AI summary of all the recent discussion and decisions made on different topics.
Slack / IM often, don't demand a response instantly though, async & remote go hand in hand.
Put important stuff in email not slack/IM
Have a company wiki
Prefer video calls for alignment
Write to each other often, spend time crafting written narratives, 1-pagers, amazon 6-pagers etc. to share ideas, make people read them, use google docs or ms word online and get comments inline in the document using those tools, follow up on video calls to confirm alignment.
Gitlab has a handbook for this stuff, they are a 100% remote business and very open about their practices: https://handbook.gitlab.com/
Only because we've ruined our email with automated systems that are way too trigger-happy on notifications. I think I've received atleast a thousand-fold amount of mail from JIRA that someone has clicked on something, compared to actually useful, actionable requests.
a wiki is much better than google docs IMHO as the later quickly becomes an unmanageable dumpster fire. I like mediawiki a lot since most people are familiar with it from wikipedia and linking to yet-to-be-created pages encourages participation.
Agreed on the broad points. Personally I found simpler wiki systems to be worth it because you'll spend less time making stuff work and less time debugging because it's less complex. MediaWiki, at least from my experience with -pedia, the OpenStreetMap wiki, and others, is that it's complex and slows down to a crawl for hours~days if you bust the cache by making a change to a central template. DokuWiki runs smooth without needing to concern oneself with caches at all—but, of course, is less versatile if you have a 10'000-people organisation and need advanced features for managing all the information (we don't; it works great for us). I'm sure there are also other great options besides DokuWiki, especially if they use a markup language everyone already knows like Markdown instead of some custom syntax only used on your wiki. Another consideration: GitLab, Gitea, and friends iirc all didn't have page locking when I looked at those options ~2 years ago, so you overwrite each other's changes without noticing. Anyway, just some thoughts on implementation details. Wikis are definitely the way to go as compared to a set of documents on a drive!
I personally think important stuff should be in public slack/teams/whatever channels. I pretty much never use email for any communication; the amount of spam I get, even on my work email leads me to ignore basically all email notifications I get. If I really need someone to see some information, it goes in slack. Email is only used for external communication, and even then if both orgs use slack we just create an external channel instead. I get crap for this on HN every time it comes up but I just can't stand email as a communication medium
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 about whatever. A replacement for break room chatter, not Yet Another Meeting. It didn't always work very well but when it did, it was great.
Some of the best conversations I had were with an autistic SRE who spent his first month telling everyone how autistic he was in case we needed to know. He did better virtually than he would have in person - lack of eye contact due to camera angles, maybe? So yeah, this has value even for you neuro-atypical, "I don't need chatter, just code" types.
> This is nice but for many people the lack of genuine social interaction is a killer.
Emphasis mine.
This difference of what people consider genuine or not, some people even including the medium itself in their definition of "genuine", sounds like another possible cultural difference that must be kept in mind when communicating with others.
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've got friends who work great over chat. Beyond keeping up the conversation just like someone would irl, the choice or lack of a smiley, the lengths of messages, sentence capitalisation and punctuation, timing of messages and read markers or typing notifications... everything combined works the same as nonverbal communication: how they are feeling, are they busy or can I interrupt, are they at their desk or on the move... It's not that different to sitting across from them
Other people, though, don't work this way. A few aren't as familiar with computers so the cues are hidden under a layer of technical struggles; others simply don't seem to communicate well by text. As colleagues, you're somewhat forced to make it work and so the success rate is much higher than with friends in my experience (probably by saying things more explicitly and less nonverbally), but it can still be a damper and make conversations transactional and sterile
Especially if you had a disagreement or misunderstanding with someone you're not very familiar with, the more-universal nonverbal IRL communication is easier to pick up on than their digital cues. Calling is a decent middle ground but requires synchronicity (often worth it, of course)
The internet doesn't need to make things sterile, but for many people, it does seem to, so I can understand what the person means even if it isn't my only experience
> 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.
"Inherently"
It's simply the premise on which the entire post is based.
All work (in-office or remote) is inherently transactional. If I am in an office, I have to pretend to have genuine social interactions with people. Social bonds made between colleagues have will happen organically. No in-office mandatory fun.
I never pretend that co-workers are my friends. I just understand they are co-workers and treat them as such. so then if I was forced to have mandatory socialization and fun I would quite despise it. if I wanted to interact with them, I would reach out and schedule one-on-ones as would happen IRL
I think that you can have genuine social interactions remotely, but that it takes a certain kind of person. Most people, even most younger ones IMO, just aren’t accustomed to interacting with people online via chat. But people who are eg prolific Reddit/twitter/etc users, or heavy users of discord/IRC/chat-heavy MMOs do really well IME (and yeah, a lot of these people are neurodivergent). You also probably either need to be really passionate about your work or have some kind of common interest to chat about to build a genuine connection, and not to be so shy that you self-censor yourself (/have a culture that doesn’t force people to self-censor).
Video calls are nice but I personally think they’re functionally the same as meeting in person. The biggest difference between remote vs in-person work is how you interact with people outside of formally scheduled meetings (eg showing people how to do something or casually conversing with them). Regular “hang out” meetings can’t fill this role, you really need something like chat IMO.
At prior jobs I’d say usually only 5-10% of people I came across directly at work were “good at chat”. If you could figure out how to filter for these people when hiring you could run a remote company very well, and have a strong culture and sense of community.
Remote work feels a lot like Reddit. I don't actually know any of these people I work with, I just have very shallow interactions with them. I started coming in to the office after years of remote work and its unreal how much more social and friendly it is. People who I would hardly have more than the most transactional of chats with on Teams are now sharing their personal lives freely.
I'm Gen Z so remote work has been most of my work history. I'm just genuinely shocked at how much more effective and fun it is to work with people in person.
Donuts are okay, I've used it at 2 different companies now, but I inevitably find myself disabling it after 2-3 months on the job, usually when I start getting repeats. Maybe it would be okay if you could silently veto who you got paired with. No offense to some of my coworkers but I groan when paired with someone who isn't very conversational where I know I'm going to have to shoulder the burden of finding something to talk about.
ALL work is transactional. I solve your problems, you pay me money.
I have family and friends for "social interaction" and "meaning". I do not seek that from a job, nor do I want a job that claims to provide it.
Any recruiter that tells me "our company is like a family" gets a reply that says "so i can cry on your shoulder in case of a bad breakup, and you'll help me move furniture?" and then gets blocked.
This is such a simplistic take. There is a huge gulf between "We are a family" saccharine corporate BS and "I am a cog in the machine. I am forced to make conversation. Hello Coworker How Do You Do" robo-employee mnemonic.
Personally I prefer to work with people who have a sense of humor, self-awareness about the importance (or lack of) of our work, have some interesting things to talk about it, can be surprising, etc. They don't have to be my best friend ever but I don't want to be bored.
The "we're like family" phrase can mean many different things in the work environment, so don't read too deeply into it.
That being said, it's often a sign of poor management; managers will use "we're like family" instead of addressing problems that they need to address. It can create a very stressful situation if you're a high performer, because the expectations and handholding quickly get unreasonable.
(The song "Surface Pressure" from Encanto explains the situation exactly.)
For example, I once worked with a manager who used the "we're like family" excuse when incoming tickets were incomprehensible and missing critical information. He was just copping out of his job, which was to set processes and make sure new employees knew the processes. Instead, his expectation was that I would handhold the organization through the ticketing system.
> 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.
Love it, love the spite, but you will actually legitimately lose people who don't want to join a cult. If you wouldn't drive me to the airport for free, then we're not family, sorry. Save that term for, like... people who aren't paid to spend time with you.
there is nobody in my family on whose shoulder i can cry except my wife. the friends that i have where i can do that i all met through work.
and yes, coworkers have helped me move too.
"we are a family" is still a warning sign though.
it could mean that the team is a tight knit group that a newcomer will have difficulty to break into, especially an introvert.
or it could mean certain expectations towards each other that i would not understand or be comfortable with because i have not experienced any family like that
so instead of rejecting the idea i would ask some questions to find out what they mean by that.
What becomes apparent very quickly outside the imposed rigidity of a physical office is that different individuals and different roles all have different optimal communication patterns. And people can get really fussy if they aren't getting the structure/tools/freedoms/whatever that they feel they need.
And so the answer to your question is ultimately much more idiosyncratic than you're hoping it to be. Whatever answers you find here, take them as inspiration for things to try out rather than specific things to do.
With that said, effective communication patterns tend to naturally snowball, so if you can start getting people feeling connected and collaborative, you'll find that they'll naturally keep that up and build on it.
But you are going to need to throw some spaghetti at the wall to see what your team needs in order to get that process started.
Try to reduce the number of required sync meetings in favor of async alternatives. For the required sync meetings, make sure there is a rock solid agenda and EVERYONE knows what is expected from them going in. Make sure the meetings cover meaningful material and helpful to all attendees. Encourage everyone to speak up and contribute. If you find certain individuals not contributing or not prepared, proactively have a conversation with them outside the meeting to reset expectations.
For async communication, it can still be helpful to set specific windows of time for things to get discussed. Example, Mondays 9am-Noon ET we review/discuss sprint goals. I like to record short videos with Loom to kick off discussions like this. Make sure to center these types of communication around specific tools, e.g. JIRA, Confluence, Google Docs, etc. Make sure the discussions convert to traceable decisions in your tooling.
Responsibly. Which means as short as possible, visible, to the point, and with clear indication of urgency.
And as the currently top comment says: make your messages public by posting them in the right Slack channels. I had a former colleague literally sabotaging me -- he thought he was getting fired because I was hired, and quickly hated my guts apparently -- by not responding to my Slack DMs which I used to bring a bit more details that I felt could be too much for the channels (logs, error messages from CLI tools etc). I could not progress on important tasks for a few weeks because of him.
After he pulled this stunt twice, I simply started posting in our team's channel where executives are also present. He never dared to delay a response ever again for as long as I was there during the contract.
It's sad that it sometimes comes to this but work is work and I am paid to deliver, not to develop endless empathy towards childish insecurities that result in a literal sabotage of my work.
Use Google docs. Ideally, everything or as much as possible should be public and accessible to anyone on the team. Especially planning and scheduling documents. Each meeting should have an agenda attached to the meeting on the Calendar. Each meeting should be transcribed and then summarized using Gemini.
Minimize the unsearchable communication tools, like Slack and Discord, though these tools are fantastic for casual conversations. Everything possible should be done to minimize notifications from Slack/Discord. In fact, minimize interruptions as much as possible to maximize the asynchronous benefits of working remotely.
On the development side, everything should be code reviewed before merging to main, as this helps spread knowledge and increase the signal:noise in written communications.
On the business side, all customer meetings (many of which should use GMeet), should be transcribed and summarized so the developers and other folks can be as close to the customer as possible.
Meet in person as a whole company AT LEAST once per year, perhaps 2-3 times. This can get expensive. As the team learns each other, the frequency can reduce. During periods of employee growth, increase the frequency.
Read "Remote" and other books by the Basecamp team.
we also use Google Suite. Google Doc's [] task button is very helpful. We use a single to-do list for the team, which helps keep everyone on the same page
Figure out how to have some kind of face-to-face relationship. This could be an annual all-hands trip, or otherwise take a week to fly out and spend time with the person you work with.
You learn A LOT about each other when you interact face-to-face. I once worked with two developers in India, and assumed that the shy one was just so-so, and the talkative one was brilliant.
After some deep day-long conversations, and a few day trips, I realized my assumptions were completely wrong: The shy one was shy, and the talkative one spoke before thinking.
---
More recently, I started work with a hybrid team. I live 60 miles from the office, but it's brutal commute. I go in once a week.
I've also met someone who was so different in real life, not their funny and exuberant selves at all, that I had trouble seeing them the same way when we later met back online. This wasn't work-related but a formerly multi-year friend I met in a video game and talked to daily about anything and everything. It was a strange experience for teenage me, but so this can go both ways (nearly all of my "first IRL meetup" experiences were good, though). If someone is great in online communication, I wouldn't say that there is a reason to meet up unless both parties want to. But you're probably right that, for a company, you need to decide to invite everyone or not to have this type of meeting. You can't exclude some of them so the point is probably moot
For the meetups my company does, one thing I like a lot is that we mix it up. Different countries, different settings, different events. Beyond that not everyone enjoys the same environment, the change itself also makes it interesting and creates talking points. People share more tips or explore something together because nobody is already familiar with the place and/or activity
Since I haven't seen this yet in the comments, a startup I worked at in a previous company set up Discord channels for small teams, and it by far replicated the closest to "folks are sitting next to each other in the same room" experience that I've seen before.
I see lots of advice here about documenting everything, discouraging 1-1 conversations, etc., and while I agree with that up to a point, this advice can also drastically slow you down if you require a level of formality for everything. The thing that was nice about having Discord channels is that if I needed to get a quick explanation about something, I could ask quickly without needing to schedule a meeting, etc., and everyone else in the channel can listen in (if desired). Discord also has good "deafen" features, so if you're heads down and don't want to be bothered it lets people know.
Again, I think this only works well with about ~8-10 people max per channel, but that's about the optimal max size for project teams anyway in my opinion. I highly suggest you try it if you haven't - when I first tried it I thought "How is this any different from Slack Hurdles?", but the small usability improvements in Discord made it feel to me like it approximated the in-person work experience much better than Slack (note we didn't use Discord as a complete replacement for Slack, just for small "working group" teams).
First, we use Missive to integrate email and chat. This way everything's in one place, properly threaded, and we can easily discuss emails internally in context. Much much better than GMail + Slack.
Second, I run video chat office hours twice a week (Tuesday/Thursday). Anybody can drop in to discuss anything — or not, if there's no need. This lowers the activation energy for "in person" discussions that otherwise might not get scheduled and promotes async work the rest of the time.
Third, regular company offsites! Even a few days a year is good.
I've always liked to make bug reports (called issues this century it seems) the center of gravity for task-oriented organization communication. Unfortunately there isn't an obvious best in class solution available but github is usually not too bad. Or the issue system we dare not name (rhymes with era). Communication about non-task-focused subjects in Slack. No DMs unless for palace intrigue. Don't much care about meetings except for socialization. Nothing gets done in meetings but it's nice to shoot the shit once in a while.
Edit after reading other comments: no team private slack channels. Super annoying.
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.
First off learn to relax. breathe. Just because people aren’t constantly communicating doesn’t mean nothing is happening.
Learn to embrace long pauses in video calls. Learn to accept that a response to a message sometimes takes several minutes or even an hour to come through.
You said everything is going well. Okay, so what’s the problem then? The amount of communication currently happening clearly must be sufficient, otherwise things would not be going well. Right?
Video calls. If you aren't having at least one video call a day something is probably wrong. Configure it such that starting a video call takes no more than 4 clicks.
Have a company-wide General/Coffee chat where people talk about arbitrary things. It's better if this chat has history which expires in 24 hours.
Write lots of short documents -- especially for designs. Review them much like you would review code. This can be as simple as Markdown documents in your repository using your normal code review tool. Ensure all documents are listed in a single easy-to-find index of some sort.
> If you aren't having at least one video call a day something is probably wrong.
Depends on how you work? A video call every day would be too much for me, but two a week seems alright. I'm also not a fan of daily meetings in person either, though.
Agree with the occasional relaxed "coffee chat", and having a repository full of good documentation, but...
>If you aren't having at least one video call a day something is probably wrong.
That seems excessive to me, especially if everyone is also staying connected via chat, emails, etc. Weekly meetings are about my limit, considering I also have work to do, meetings with external stakeholders, ad-hoc meetings, etc.
At least one video call a day is more about socialization than work; chat and email doesn't really strengthen psychological feelings of connection to the team. Regularly putting a face to the nickname is important.
I consider small meetings (say <10 people) within the team, ad-hoc or otherwise, to count against the once a day minimum. It doesn't need to be a purely social call to be effective.
Different people want different levels of socialization attached to their job duties. If the meetings are a requirement, having them daily is too much for my taste and is more likely to strengthen my psychological feelings of being annoyed.
In any case, not having a daily meeting does not mean something is wrong, as the parent poster stated.
> It's better if this chat has history which expires in 24 hours.
This sounds fun to have a b.s./watercooler chat channel. It'd be cool if Slack had that feature but I wonder if that's a non-starter for corporate reasons.
Workspace Owners and Org Owners can adjust retention settings for public channels. Private Channels and DMs can also be set by members if allowed by admins.
Note that not everyone likes being filmed. I somehow find it quite different to meet irl compared to being on camera, perhaps because then I can observe what they're looking at. Video calling is like being on stage. (I don't mind being on stage much, just like how video is not a big deal either, but the feeling is similar)
it is insane that we can have face to face and even video meetings that are not logged, but we can't have text based chats like that? what if we meet on IRC? should that be illegal without a bot to log the conversation?
Sadly, I'm sure that the only reason that face to face meetings are not logged is technical capability more than anything else. The law just hasn't metaphorically noticed yet that those can all be recorded to. It's still on the pricy side at the moment. (Don't forget not every business is a tech business that still reasonably expects 20%+ profit margins.)
I often bang on the fact that laws made in the 20th century are often written against an implicit background of what is physically possible that people underestimate, like, the number of laws that people nominally break every day but are impossible to enforce because we don't all have an assigned police presence assigned to us. We should not casually assume that once we acquire the capability to enforce these things that we should. Another example of this is that while I understand the drive to document what a company is doing, we need a certain amount of ability to speak to each other off the record, even in a corporate environment. Yes, it is used to do bad things, but we are humans, we need that slack, and it is used to do good things too.
“Slack” under the law is quite an interesting concept. “Inherent logistic pseudo-discretion” might make me think less about a friendly guy smoking a pipe, but it has some disadvantages, too.
I’m interested by the fact that you and I could travel to Nebraska and whisper to each other in a cornfield in ways that violate the law left and right. Why is this not a huge problem? Because inherent in the logistics of getting there is a presumption that most law enforcement will use their discretion not to care.
Is cornfield-whispering becoming more powerful as other comms get weaker? Is it becoming less powerful as fewer of us choose to go to those lengths? Interesting stuff to consider in the golden age of surveillance.
The friendly guy smoking a pipe was merely ahead of his time. If we are flinging ourselves into an AI-driven total surveillance state we're all going to miss slack more than ever. Hopefully if anyone survives the AI-driven total surveillance state will eventually realize that with the degree of control it has it doesn't have to crack down on literally everything just because it can.
in the culture series iain banks paints an optimistic picture of an AI driven idealistic utopian post scarcity society where nothing is secret, from the AIs at least.
some of the ideas seem to be that in post scarcity many crimes become meaningless, and that the AIs keep your privacy.
well, it depends on the country. in germany this kind of surveillance is illegal unless ordered by a judge, and there is a high bar to get that order. even at work recording of conversations is generally illegal to protect employees privacy. however i think logging of text chats and storing emails is legal. and i believe some people want to make it mandatory.
it is a constant back and forth between both sides.
earlier i have made the argument why written communication should be treated just like the spoken one:
My vague understanding of the related laws is that as long as the company has a consistent retention policy and is under neither a court order to increase retention nor retaining records for specific incidents as part of policy, that a short retention period is fine.
I expect legal would actually be happy about shorter retention periods since it makes their job easier. HR of course wants infinite retention periods because it gives them a bigger stick, but universally longer retention is not the only way to address those desires.
I've accidentally made it work extremely well in the past with Discourse[0] (not Discord). It was meant to record decision making processes, but it ended up replacing almost all of our async communications. Messaging was used only for emergencies. I've since left the company and never tried it again due to different cultures in my following companies.
In addition to all of the management, communication, and team building strategies mentioned here, I've got a shameless plug for a product I've been building with a fully remote team of ~30 people over the past four years: https://katmaitech.com/
In person collaboration is best, but for a fully remote company and geographically distributed team I think we've built the next best thing.
Many of us are on camera all day, others pop on just for scheduled meetings. But with the mix of working styles we've managed to maintain a pretty healthy culture, where we can have some of the spontaneous interactions that are so important.
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.
This is what my last, 6 person, startup used, and it was really helpful. It lowered the barrier to having a quick discussion, since you could see if someone was at their "desk" or busy in a meeting.
Also you can see if other teammates are having a discussion or co-working in a common area, which made for some ad-hoc co-working sessions.
I'm surprised at all the positive mentions of gather town. It just looked like a childish gimmick to me? I was tempted to log in and make some jokes about the pool being closed but I didn't want to out myself like that at work.
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.
Gather is great. I think it lowers the barrier to chats just enough to make it more organic. In particular I find it's really great if you're having a 2-3 person conversation and realize someone else would be really valuable to add. You can just glance at their desk and see if they're available, "wave" to them, etc.
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.)
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.
> This would be insanely disruptive to me and I think most of my team.
> There are much better ways to handle this.
Hi! You could probably turn this from a low-effort rant into a productive comment by removing the first 2 lines of your comment and expanding the last one into something informative.
I have worked with several companies and collaborating across vastly different time zones...and the thing that seems to work best is some central document repo/wiki. Sure, group chats help, 1:1 chats help, email helps...but for institutional knowledge, or even info that needs to be passed across time zones, i find it helps to "dump" info in a central place that everyone knows to look at like a doc repo/wiki...and a chat becomes too ephemeral, plus as new messages get added very critical info gets pushed down...and if a chat platform allows to "pin" some critical info, then you just pivoted to need a doc repo/wiki of some sort.
I will also add that if the info to be conveyed is less than institutional knowledge, and it more about "what's status of a project?", that too, can best be posted in some sort of succicnt dashboard...which can live somewhere in an appropriate place in your doc repo/wiki. Again, i will state again that ephemeral platforms like chat have their place, but there's nothing more powerful to ensure EVERYONE everywhere in your org knows what's up, what's happeneing, and/or how to get help to keep moving forward on all efforts.
Huge bias here as I work for Figma, but multiplayer collaborative editors like Figma do wonders.
We run nearly everything out of a figma or figjam file. Retros, planning, etc. There's something really nice about being able to see everyones cursors at once, and feeling like you're collaboratively creating something. Presos and slide decks often feel very one-direction from a data flow perspective, which becomes problematic for remote-only roles.
Against what is mentioned in other comments I suggest that all the information and discussion should happen in your documentation platform. Confluence, notion, even Jira.
While slack seems like popular suggestion, its not made to keep structured information and what happens is that you have some discussion in slack, some discussion in a meeting that was not recorded and then, in a best case scenario, some conclusion in Confluence. This is a bummer because a lot of information was lost, specially the logic behind a decision. It would be far better if the discussion happened in writing within the comments section of the document. Now all the context is in a single place and searchable. Plus its possible to add to it somewhere in the future, so the document base doesn't necessarily grow with time.
The most important thing to me about remote communication is making time for "coffee catchup" to chat about non-work things.
We literally sit down with a fresh coffee for 5mins just as we might when crossing paths in the office. Find common topics among colleagues to shoot the breeze - football, video games, cars, etc.
Soon you'll have cross-team relationships with people who might never work directly together.
If you find yourself constantly trying to explain stuff visually, invest on a graphics tablet. Even a "cheap" <100 EUR goes a long way.
As for the "whiteboard", just opening Excalidraw when you need it is very low friction in my experience. Google Jamboard and Miro were okay-ish, I guess, but for me the simplicity and responsiveness of Excalidraw is still better.
I've integrated draw.io into our Confluence. We can now create inline diagrams right in the page being edited. Resulted in higher quality documentation, with a lot more diagrams for even mundane things. I generally work in pictures, so it's great for me.
But I do agree, excalidraw is great. I recon its an importan skill to be able to confidently and quickly whip up a diagram while in a call. I worked with an engineer who preferred MS Paint, but he was really good at it, and it resulted in him explaining tricky concepts really elegantly.
Use video chat for meetings (encourage camera on but don't require it - management should lead by example)
Be kind. Reach out using other forms of communication (like snail mail) if you want to encourage each other with thank you notes, etc.
Use some kind of shared wiki for long term 'shared ownership' documentation. Don't be afraid to lead by example. Don't be obtuse. Give visual examples of processes, technical components, etc.
Lean into visual examples everywhere you can (screenshots, mock-ups, diagrams, etc).
In video chat, screen share and encourage use of annotations when discussing things. (Zoom has this feature and it's awesome)
Use an agile cadence. Encourage people to share questions / concerns at story grooming sessions (which should be regular). Also encourage feedback at retrospectives (which should also happen regularly). Managers should lead by example in blameless retrospectives and lean into positive feedback.
If you're a team of all dudes (or any one thing), you have a blindspot with perspective. You should rectify that.
Actually do something when people don't reply to their peers.
Even at companies that aren't "remote", there are people who will simply ignore emails and messages. You're forced to go nag their manager or escalate to yours to get them to respond.
Effective communication in a remote startup requires clear tools and processes. Use platforms like Slack or Microsoft Teams for real-time messaging, and schedule regular video calls via Zoom or Google Meet to stay aligned. For task management, tools like Trello, Asana, or Notion can help keep everyone on track.
One thing I've found useful is to have deliberate google meet calls when having planning discussions or firming up decisions.
I set up the recording and transcription and then up front we define the problem and what we want the outcome to be. Afterwards I give the transcription to ChatGPT and get it to summarise the content, decisions, etc and add that to our documentation with a link to the recording.
This helps you stay on the same page and also gives context to people who werent present about what has been discussed and decided.
Distributed startup founder here. We love Figma, keep in touch with Gather.town, and have been very happy with Flat.app for keeping us from Asana/Slack hell.
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.
Be honest about people not showing up and say it's not ok. Hours need to mean something. If there is a block of 4-5 hours a day where everyone (that has a dependency on each other) is available, this is key.
Anything less and you'll have people just enjoying a day at the park (without the laptop).
Communicate in startups by keeping messages clear, concise, and action-oriented, using tools like Slack or Notion for collaboration. Foster transparency, regular check-ins, and a feedback culture to ensure alignment and adaptability.
I find Discord clunky, speaking as both a gamer (perhaps I'm getting too old for this) and employee who used it with a customer. What does it do that nothing else does, or where is the friction lower in your experience?
A little bit on the softer side, but It's good to encourage a feeling that you can just say something publicly even if it might make you sound slightly naive, because it's WAY more common that everyone else actually has the same misconception or bad assumption. People tend to do that once, someone makes a rude comment about them not already knowing, then they pretend to know things from then on. I think that has to come from the top by example. People will emulate sounding like the highest up person they're interacting with on a project or in a meeting.
- 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.
Don't assume people know how to communicate. Provide education material, cultural backgrounds, descriptions of things to avoid. Incentives that are aligned with good communication.
For example:
- Chat discourages thought.
- Chat burries decisions.
- Brainstorming and ideation vs reasoning.
- Brainstorming, ideation and reasoning vs preferences and biases (CEO weighs in)
- Documentation vs works in progress.
- Proposals vs time to consider them.
- Bike shedding.
- stupid forum formatting.
etc
etc
etc
Current social media is shockingly poor training for good communication.
WhatsApp is very common for smaller simpler projects, and I'm pretty happy with it.
My main communication related complaint is when it just doesn't happen at all.
Plans change and nobody tells me so I work on cancelled features, only one person actually knows what's happening and they're busy so you don't want to ask them about every detail, minutes are not taken at meetings.
I also would prefer calenders be managed better. Google shared calendars are amazing, I'm sure there's something similar people like for bigger projects where some people use apple... But nobody seems to really see the need for anytime like that.
We have a weekly "all people's" meeting every Monday morning - high-level wins for the past week and fires for the coming week, touching on OKRs, high-level direction, then each department goes through what they're working on/wins/fires. A bit of back-and-forth and "how was your weekend" at the beginning. Runs about 45-60 minutes. It's invaluable in keeping everyone on the same page and in the loop at a medium level of detail. (Not too vague, not into the weeds.)
If the items in this meeting were put into a shared document, not only would you stay on the same page, but you would have a searchable history, which becomes valuable as time moves forward. What really triggers my red flag here, though, is that "standing meetings" are one of the worst offenders as far as useless meetings go. Instead of forcing everyone to sync at a specific time, if you put these updates in documents or emails, you allow for more asynchronous consumption, and you don't affect the flow of individuals, especially if you have multiple time zones.
Regular group discussions (not standup) are important. My team meets 30-60 minutes four days a week to discuss technical details and long term strategy.
It plays two important roles
1. establish rapport between team members
2. gives known space for issues. Leads to Better balance of focus time and group convo
This is the most important meeting of the day. Create doc to people can add things to the agenda. Managers job is to keep the meeting relevant, efficient.
Outside of that. Devs encouraged to pair together separately for troubleshooting.
1:1s are critical early on. DO NOT CANCEL THEM. And keep them relevant
> My team meets 30-60 minutes four days a week to discuss technical details and long term strategy.
Long term strategy needs to be decided on four times a week? Each instance taking ~10% of the working day's time? I expect I'm misunderstanding you but I'm not sure in what way
Slack. Weekly meetings (encourage but not require camera on). Annual in-person retreats.
Don't be afraid to small talk and goof off just a little (in a way that's respectful to your colleagues). Allowing people to be more themselves fosters better working relationships IMO, of course with the expectation that anything public facing is done with professionalism.
If you're asking a question (whether 1:1 or in a group setting), frontload as much context as possible. Always give:
- some minimal description for the problem you're trying to solve
- what you've tried already, and why it hasn't worked
----
Bad:
> "Hey! Does anyone know how to use X"?
...time passes...
> "Sure, I can help with that. What are you trying to do?"
...time passes...
> "I'm trying to do Y."
...time passes...
> "Okay, sure. You can set it up like this."
...time passes...
> "Oh, I already tried something like that actually, and it didn't work."
...etc., etc., etc.
----
Good:
> "Hey! I'm trying to use X to do Y as a part of feature Z. I already tried A and B, and they didn't work for <reasons>. Could someone help me out?"
> "Oh, yeah, that's a known problem with A and B. We can get around that by setting up X this way. Since you're working on feature Z, you might also want to consider..."
1. gather.town
2. Zulip (nuances of design much better than other chat systems for remote work specifically)
3. the 'latent energy' is going to be lower when people aren't eating lunch together and rubbing shoulders. you have to bring the energy to an empty room all the time when working remote. this also has to be exemplified by founders. doesn't mean loudness but instilling a sense of urgency etc.
Still some warts, truthfully, but the core of it is just better for finding information and structuring things.
Integrations are also easier.
Definitely one of my more controversial additions to my company, but the pure volume and quality of conversations would he impossible otherwise. You would be required to wade through a lot of irrelevant dialogues otherwise.
On the softer side, I found remote work to be painfully dry the past few years so created a small Slack extension to add color / life / levity to internal communication. Collect team quotes & images, make memes. It's added a lot of joy to teams, especially eng teams.
At Zed, we use our native collaboration to make sure we get a lot of synchronous time together. We also use it to do design review as we're coding a feature, letting us skip code review all together!
Check out gumroad public youtube channel, they publish all their internal meetings and call with board members. I think its powerful to have public communication however they proudly talked about remote work and now going in person.
Get used to the idea that someone isn’t necessarily there when you message. Try to predict when you’ll need to talk to someone and send the message with the info you need.
Document. Everything. Confluence needs to become your best friend. You and your colleagues rely on this information to keep up on things they might miss.
When you’re planning work, especially with lots of uncertainty, optimise to be inefficient. It’s better to start with 20-person calls at the start of a big project and cut them down later than to have 3-person calls and realise you missed critical people 2 weeks before your target date.
On the flip side, once you know what you’re doing, keep your status checks lean. Invite only the leads you need and write down the outcomes to share with the wider team.
Be willing to change your communication habits as you grow. A weekly all-hands is fine for a 10-person startup. It’s a monumental waste of time when you have 200 people across 5 departments.
Discourse (not Discord chat, but the threaded forum software) is a much better choice than chat like Slack. All meetings and discussions/decisions should have a thread for them, even just a placeholder, and posts to document conclusions or next steps or rationale or whatever.
Have a company wiki.
Have anyone who can’t touch type learn to do so, on the clock, as priority 1, before anything else.
If you can’t type a lot and quickly, you will resort to speaking instead, which isn’t convenient to consume and isn’t indexable. Strongly discourage calls and synchronous communications in general.
Not sure if it's been mentioned here, but The Async-First Playbook by Sumeet Moghe (Thoughtworks) is a great book that summarises a lot of what people are saying in this thread and adds more.
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.
I worked for multiple companies remotely and the thing that worked the best for me was:
- Everyone must be connected to Discord in an audio room.
- Encourage pair programming.
- Record every meeting make them available to everyone.
- Log every decision in a central place, easy to browse and discover.
- Meet regularly (IRL) with you colleagues.
By far the most important point is always being on Discord. You can quicky jump in someone's room and feel very connected to your teammates. Obviously, like in a real office, don't disturb someone if it can be managed asynchronously.
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.
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.
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.
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.
> 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 :)
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.
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".
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.
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.
> 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.
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
Yeah. Once or twice a year should be fine, I would say.
>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
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.
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.
s/Slack/Zulip
Seconded, Zulip's model is fantastic. It makes it a breeze to catch up or coordinate.
Zulip is amazing
> 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.
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.
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.
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.
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).
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.
> 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.
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.
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.
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.
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.
zulip is like a version of slack but designed for evergreen communication
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)
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...
> 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! ;-)
>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.
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)
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
Are you sure that's introversion, rather than shyness or insecurity? The answer might help with the solution.
Agreed, you are collaborating with a team, if you are not comfortable sharing thoughts how are you gonna be comfortable sharing _code_.
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.
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.
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.
IMO the actual difference between introverts and extroverts is that the latter use @here and @channel a lot more frequently
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.
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.
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.
> 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.
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.
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.
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.
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'm at a company now where we are trying to do this but the CIO/CEO keep weighing in on EVERY conversation where they disagree with the approaach. The whole reason we are having the open conversation is for ideation and good communication but when a high level person comes along and says "well thats not the way I would do it" everyone decides to go back to 1:1s, direct messaging, and calls so as not to document anything publicly in feat of being called out by the higher ups.
Quick note that if you're actively working around the CEO on a regular basis, you need to stop and find another job. Or possibly replace the CEO but that's a high stakes low probability of success endeavor.
What's happened here is precisely why communication should be public, it's revealed a real problem in the company you're at.
I've been on teams exactly like this, but the problem isn't public channels, it's "leadership" not knowing how to let go and trust their teams. Doing more work in private is the negative consequence of this bad practice, but I assure you this issue will eventually cause problems no matter how clever people are in avoiding public conversations.
And startups that are on the path to long term success will have leadership abandon this type of butting into every day communication very early in their growth. A good C-level must learn the build teams that can scale beyond their individual interventions. You literally cannot grow beyond a 30 person organization (and survive) if this much intervention is required.
You need a private channel with everyone except the C-level. We find this very, very effective at our 2500+ person org
Incredible. Every point of data shows the highest compensated members of a firm doing the least work / being the most harmful to productivity lmfao. Wonder what the takeaway here is
I don't think this would be such a problem if people were comfortable challenging the CIO/CEO. So maybe that's the cultural aspect that needs to change on the exec's behalf?
It’s still a waste of time to have to debate every single thing every day.
That CEO would also micromanage in an office anyway. Oh wait, now it's called "founder mode" and it's something good.
Sounds like they need to spend their time differently. Yuk.
Private team channels sound like a good compromise
Also someone with good standing in the company to politely point to the CTO that it's not his job to give his 2c at every conversation in slack (typical behaviour of people coming from the technical side)
I was going to say the same thing. Had this setup at my last job and the CEO would chime in with irrelevant, outdated, not feasible, or already considered ideas. We'd then have to spend time communicating and explaining the shit we had already been talking about for the last month or whatever. It was incredibly frustrating because it gave a public impression that our team was either incompetent or combative. It was gross.
I wonder if they would behave the same way in an everyone in the same office situation. Team leads should take this as an issue to the CEO.
The CIO is the problem here, not your setup.
A thousand times this.
I find it very dangerous when you have some technical people who moved upwards into non-technical roles still being involved in technical discussions.
Their words carry a lot of weight, yet they have no idea about the actual context of the work being done.
Sometimes this is useful and a fresh perspective from an experienced colleague can unblock things, but more often it stifles discussion and discourages the juniors from thinking freely.
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 seek back channels anyway
I think this is something that can really be mitigated by more senior people modeling good behavior.
For example, as a principal engineer on a new project or working on something I wasn't familiar with, I'd go out of my way to ask things along the lines of "Hey, this might be a dumb question, but I'm new to X so could you explain how I do ..." I think this goes a long way to building up a culture of psychological safety on a team.
1000% agree. I'd rather spin my wheels for an hour on Google than ask a silly question in public
I would like to work with you. Asking searchable things may be considered disrespectful to one's time
Given the rapidly declining quality of search results, and the subtle hallucinations of LLM on advanced topics, I think that attitude is outdated.
We’ve gone backwards in terms of the internet being reliable. Human experience is still useful.
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.
Hamfisting an ideology to human nature just doesen't seem to work no matter how nice the end result could be. People don't generally do uncomfortable things unless they are forced to, take for example literally anything else in life; entire fields of professions exist because we don't like cleaning thing X or Y
Yeah, I'd agree you want a healthy balance of 1 on 1 and group conversation. A quick aside is one thing, and if it is a question that should lead to documentation then documentation should be written for it instead of just assuming someone is going to search through a year+ of slack messages in some public channels.
Even in person, not every conversation is good to be had in front of the large group for a variety of reasons.
> 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 time means calls. They seem to dislike discussion threads in Slack and want meetings for things instead. I’ve also noticed things like the person who reviews a pull request being the one who has to merge it and essentially take responsibility for it, versus just giving approval and the author merging it and making sure everything is okay after CD.
I’m very much the opposite and prefer to have things in writing and like asynchronous communication. But when it is written messages, usually people either ask for a call or just do “Hey.” I actually made this a while ago hah: https://quick-answers.kronis.dev Either way, people also really seem to dislike writing README files, or all that many code comments, or making the occasional onboarding script or introducing tooling to do some things automatically. I don't get it.
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.
> 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.
If I could magic-wand my own company, I would 100% aim to hire folks who are extremely comfortable with written communication. Asynchronous, written communication is 1000% more productive than meetings imo, and makes the organization's knowledge indexable and permanent.
> 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.
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.
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.
> I’ve also noticed things like the person who reviews a pull request being the one who has to merge it and essentially take responsibility for it, ...
I worked on some teams that had that and it wasn't bad at all. In the end, what's on the main branch is everyone's shared responsibility (...was our thinking).
It encourages real PR reviews, where the reviewer is paying attention to the changes, spend time on the review until they understand what is happening and why, and when they feel comfortable, they merge it as if the PR were their own. It doesn't sound efficient, but in the end it means you always have a backup person to turn to in case there is an issue, and we mainly only had "exotic" bugs.
This only works with the right team and leadership. It was completely normal to say "yesterday morning I spent half the day reviewing that PR".
OTOH, I was also on a team where PR approval means someone scrolled through your changes in 1 minute and didn't find anything blatantly wrong, go ahead and merge and hope for the best. This team broke the main branch in a significant way 2-3 times a week.
Sounds great! Where do you work?
Change orgs then.
My experience (being fully remote for over a decade) is that it's extremely distracting to have all discussions public. It creates a lot of noise and it's very hard for people to not get drawn into conversations that doesn't directly affect them. It's definitely good to have finished conclusions available for everyone, but the "sausage making" is more distracting than useful.
Of course it depends on the size of the team we're talking about.
It depends on your self-discipline as well, as in, leave Slack or whatever alone for X hours a day, leave channels that aren't important, and if the volume is higher than you can manage in a reasonable time, Slack has AI powered summarization tools nowadays which are pretty decent. Ultimately though, your attention span and information management is your own responsibility, nobody else will filter it for you.
It helps to have lots of channels that specialise. I was effectively remote for 15 years (I was in London other in US). ` If you are concentrating then you don't notice the chats, unless they are made urgent. When your focus has finished look at the channels that are nearest your speciality or sub team.
How to find comfort for and include characters that don't like the spotlight? At least not during early phase/brainstorming.
I've worked with many great people that hate to handle things without their usual group first, and will stall until a reasonable approach can be presented. Which means creating shadow communication process - the more you push for "discouraging 1:1" the more they will hide.
What your organisation did with such "incompatible" people, relate them until the team left likes how they work, or were there better ideas?
Core values are core values, and for better and worse, everything is not for everyone.
If all-communications-are-public is the company culture, then the company culture is also not to accommodate that alternative communication style.
Because any out of channel communications require multiple people to participate, not just the person who prefers it.
In my experience, most of the time this can be solved by resetting expectations. Once people learn that asking basic questions won’t open them up to mockery, things move a lot smoother for everyone.
After all, a culture on 1:1 communication has a lot of downsides. The same question gets asked repeatedly, replies don’t become searchable, the same people (usually the most experienced) end up being constantly tapped for answers
That's key, it has to be considered safe to ask questions. Anyone mocking or showing contempt to another on a channel would be immediately reprimanded in private by managers at my company.
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 the problem can be as simple as having the new team member do pair programming sessions with everyone on the team, so that they can get to know everyone better, which will make them more comfortable to speak up. maybe their previous job had a bad culture that influenced their behavior.
those pair programming sessions can also help you identify if there are particular people that cause problems by being intimidating in some way to others. sometimes pair programming can even fix those problems, by allowing the two to get to know each other better and learn to respect each other. that doesn't always work though, and care must be taken that the person who is "afraid" to work with the "bully" is not forced to an interaction they are not comfortable with. if the discomfort is that high a more cautious approach is needed. especially if the person afraid is a long term team member.
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 comment) will work for some, but will also create an artificial leash for others. I think it's too strict and to generic to try to just implement it by force. Yes, whole team should be available to see details, be able to participate, but why enforce that on such a low level as forbidding 1:1 talks...
From my recent experience, aside of excluding many personalities, it kills a lot of inertia that spontaneous prototyping and brain storming needs.
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.
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.
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?
There was nothing that drastic in my original comment. I'm speaking of differences that are present in all of us, not extremes.
See those 16 personalities or character colors tests I referred to. (although I'm not saying these are good, just illustrate well what level of differences I'm speaking of)
those differences should not prevent you from speaking up in a group. not wanting to speak up when you have something to say is something drastic that needs to be addressed.
No one is inherently "incompatible". It's mostly the environment influencing their behavior. There needs to be a culture where everyone feels comfortable speaking up and working outside silos, and that is always driven by management and senior eng leaders. For example do junior engineers get constructive criticism on a bad idea or design or are they yelled at and penalized? If the latter, of course everyone will think twice about being open.
And even then you can only do so much. If someone really doesn't want to participate then, well, it's on you to decide how to deal with that.
I’d want this as much as I used to enjoy open floor plan at the office… Discouraging 1:1 and private communication in my experience would actually have 100% opposite effect of what you are describing. This is equivalent to discouraging pair-programming which while may not be everyone’s cup of tea many find extremely productive
The point is search needs to work, including for people not involved the conversations. Private and 1:1 chats break that.
Use mute and let people @ you to pull you in when you're really needed. You don't have to leave notifications wide-open on every channel.
I’m with you, then again Best Practices mean best for your work environment, not all. I’m currently making sure to cultivate an environment where my staff are comfortable sharing information openly. Not all of my people are comfortable announcing things to the group and want to bounce things off me or other supervisors. Sometimes you have to meet people where they are at. Like establishing the vision and just keep making sure you’re moving towards it.
you bring up a good point. what matters is the forum where decisions are made. you can talk about ideas in private. but the ideas need to be brought up in the group before any decisions are influenced. especially if the private conversation is with a team leader. if a team leader hears an idea in a private conversation they should ask that person to repeat the idea in public. but also they should discourage team members to specifically approach them to bring ideas. that is what is meant by discouraging private conversations. of course you can talk in private, but if the idea is not repeated in public then it is as if it was never talked about
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.
While Slack - if you pay for it - permanently stores all communications and makes it archivable, it's also ephemeral and anything said more than a day ago is effectively gone. They do have an AI summary tool to catch up though, if you pay for it, which is alright.
To me the difference is in the affordances and mental model.
Basecamp - groups all communication, assets, participants, tasks in a project space. I open the project which establishes context for everything and everyone. This predefined context makes short efficient communication very powerful.
It’s incredibly simple and sophisticated at the same time - allowing grouping activity by people projects tasks etc.
The ephemeral nature of chat-centered systems makes me incredibly nervous about missing things or being unable to find them.
Massively agree with this. It can be difficult to create a culture where everyone talks in the open but it can save so many little and big mistakes!
This contributes to stress and notification fatigue, especially when bombarded with alerts from every channel. Some will turn off notifications entirely or disengage to maintain focus on their workload.
I'm struggling with this at my current job: nobody communicates about anything in asynchronous channels, doesn't want any form of daily synchronous meeting (e.g., standups), and won't agree to ad hoc meetings outside of our 1 hour once per week meeting. So lots of decisions and work get done in vacuums, which cause errors in various systems that would have been easily caught and addressed if someone just said "hey, I'm changing this column name from X to Y". So, just to say that the counterfactual here isn't "no stress because no notifications"-- it can be more stress from failed coordination.
There are in betweens here, with the major one being threads in slack. Everyone gets notified about a single message at the start of the thread, but does not get notified for any subsequent discussion. Any interested party can read more and participate as needed. For someone like me (a leader on paper but not really in practice), I'd read all the message and look for dependency or similar problems, but for others they may not need to.
And that's fine. You're not expected to stay online and respond at all times, that's the antithesis of asynchronous communication. Just reserve a block of time per day to catch up - like you would with emails - and go through things then. Only leave notifications on if they're addressed to you specifically.
Teams badly fucks this up by not providing normal-ass chats that aren't private ephemeral-ish groups. Their "teams" only have these weird announcement-oriented chats with terrible UX and visibility for ordinary chat activity, so you end up having to do everything in meeting-tied chats (created by the meeting, not the other way around) or ad-hoc group chats.
You can fake it with lots of manual "pinning" but that relies on everyone agreeing which chats are primary and should be pinned so they don't start splitting messages over other chat rooms, then you still end up with things like chat for one basic topic being split across multiple meeting-chats that all have the same membership or (worse) just slightly different membership.
It's as if they designed the tool to make effective remote work hard—but this also (like most things that make remote work worse) makes using it in an in-office context worse. It's just flat-out bad.
100% agree.
The people making the decision to switch to Teams don't "get" slack.
They think the features are the same, so what's the problem?
Ironically, Microsoft Teams is terrible for teams.
It's a Frankenstein cross between instant messanger and SharePoint.
100% this. The fact that teams does not have an easy voice channel is a disgrace.
Every team needs a one-nine (CB channel for chat/truckers)
what happens on that channel?
oh you mean this: https://youtube.com/watch?v=UAAwTlCp3OE :-)
Oh no. I meant this - https://www.youtube.com/watch?v=87r0CPQbFds
lot lizards
I can appreciate the thinking here, but it not ideal. Different details are relevant to different people. And async is inefficient for many situations. Yes publish findings/results, but overcommunicating has a cost.
Better to create different channels (sync, async, 1:1, broadcast), provide guidance and trust workers.
It's not necessary about trust, or relevancy. I believe motivation is contagious, and making communications hearable/visible for all most of the time can be beneficial because of this.
... and soon with this type of setting you will arrive at siloing the information. Having all communication public in the channels comes with its cost but everything is as transparent as it can be. Important distinction is that you get to choose if the detail is relevant for your work or not. And not your manager or whoever.
In addition slack search becomes a great onboarding tool.
I'm sure there's features here or in progress where you'll be able to ask for an AI summary of all the recent discussion and decisions made on different topics.
How do you deal with unavoidable information overload and necessity to read bazillion channels with tons of irrelevant crap in it?
Since that's teh inevitable state of communication via slack with this sort of policy.
Slack / IM often, don't demand a response instantly though, async & remote go hand in hand.
Put important stuff in email not slack/IM
Have a company wiki
Prefer video calls for alignment
Write to each other often, spend time crafting written narratives, 1-pagers, amazon 6-pagers etc. to share ideas, make people read them, use google docs or ms word online and get comments inline in the document using those tools, follow up on video calls to confirm alignment.
Gitlab has a handbook for this stuff, they are a 100% remote business and very open about their practices: https://handbook.gitlab.com/
consider personal readme's if your team is a bit larger (example): https://gitlab.com/swiskow/swiskow
Nothing team-related should be in email. It's a horrendous place to hide data - worse than even than slack private channels.
Only because we've ruined our email with automated systems that are way too trigger-happy on notifications. I think I've received atleast a thousand-fold amount of mail from JIRA that someone has clicked on something, compared to actually useful, actionable requests.
a wiki is much better than google docs IMHO as the later quickly becomes an unmanageable dumpster fire. I like mediawiki a lot since most people are familiar with it from wikipedia and linking to yet-to-be-created pages encourages participation.
Agreed on the broad points. Personally I found simpler wiki systems to be worth it because you'll spend less time making stuff work and less time debugging because it's less complex. MediaWiki, at least from my experience with -pedia, the OpenStreetMap wiki, and others, is that it's complex and slows down to a crawl for hours~days if you bust the cache by making a change to a central template. DokuWiki runs smooth without needing to concern oneself with caches at all—but, of course, is less versatile if you have a 10'000-people organisation and need advanced features for managing all the information (we don't; it works great for us). I'm sure there are also other great options besides DokuWiki, especially if they use a markup language everyone already knows like Markdown instead of some custom syntax only used on your wiki. Another consideration: GitLab, Gitea, and friends iirc all didn't have page locking when I looked at those options ~2 years ago, so you overwrite each other's changes without noticing. Anyway, just some thoughts on implementation details. Wikis are definitely the way to go as compared to a set of documents on a drive!
> Put important stuff in email not slack/IM
I personally think important stuff should be in public slack/teams/whatever channels. I pretty much never use email for any communication; the amount of spam I get, even on my work email leads me to ignore basically all email notifications I get. If I really need someone to see some information, it goes in slack. Email is only used for external communication, and even then if both orgs use slack we just create an external channel instead. I get crap for this on HN every time it comes up but I just can't stand email as a communication medium
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 about whatever. A replacement for break room chatter, not Yet Another Meeting. It didn't always work very well but when it did, it was great.
Some of the best conversations I had were with an autistic SRE who spent his first month telling everyone how autistic he was in case we needed to know. He did better virtually than he would have in person - lack of eye contact due to camera angles, maybe? So yeah, this has value even for you neuro-atypical, "I don't need chatter, just code" types.
> This is nice but for many people the lack of genuine social interaction is a killer.
Emphasis mine.
This difference of what people consider genuine or not, some people even including the medium itself in their definition of "genuine", sounds like another possible cultural difference that must be kept in mind when communicating with others.
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 can
I've got friends who work great over chat. Beyond keeping up the conversation just like someone would irl, the choice or lack of a smiley, the lengths of messages, sentence capitalisation and punctuation, timing of messages and read markers or typing notifications... everything combined works the same as nonverbal communication: how they are feeling, are they busy or can I interrupt, are they at their desk or on the move... It's not that different to sitting across from them
Other people, though, don't work this way. A few aren't as familiar with computers so the cues are hidden under a layer of technical struggles; others simply don't seem to communicate well by text. As colleagues, you're somewhat forced to make it work and so the success rate is much higher than with friends in my experience (probably by saying things more explicitly and less nonverbally), but it can still be a damper and make conversations transactional and sterile
Especially if you had a disagreement or misunderstanding with someone you're not very familiar with, the more-universal nonverbal IRL communication is easier to pick up on than their digital cues. Calling is a decent middle ground but requires synchronicity (often worth it, of course)
The internet doesn't need to make things sterile, but for many people, it does seem to, so I can understand what the person means even if it isn't my only experience
I'm not sure where you read that but it certainly wasn't in the comment you responded to.
> 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.
"Inherently"
It's simply the premise on which the entire post is based.
All work (in-office or remote) is inherently transactional. If I am in an office, I have to pretend to have genuine social interactions with people. Social bonds made between colleagues have will happen organically. No in-office mandatory fun.
I never pretend that co-workers are my friends. I just understand they are co-workers and treat them as such. so then if I was forced to have mandatory socialization and fun I would quite despise it. if I wanted to interact with them, I would reach out and schedule one-on-ones as would happen IRL
I think that you can have genuine social interactions remotely, but that it takes a certain kind of person. Most people, even most younger ones IMO, just aren’t accustomed to interacting with people online via chat. But people who are eg prolific Reddit/twitter/etc users, or heavy users of discord/IRC/chat-heavy MMOs do really well IME (and yeah, a lot of these people are neurodivergent). You also probably either need to be really passionate about your work or have some kind of common interest to chat about to build a genuine connection, and not to be so shy that you self-censor yourself (/have a culture that doesn’t force people to self-censor).
Video calls are nice but I personally think they’re functionally the same as meeting in person. The biggest difference between remote vs in-person work is how you interact with people outside of formally scheduled meetings (eg showing people how to do something or casually conversing with them). Regular “hang out” meetings can’t fill this role, you really need something like chat IMO.
At prior jobs I’d say usually only 5-10% of people I came across directly at work were “good at chat”. If you could figure out how to filter for these people when hiring you could run a remote company very well, and have a strong culture and sense of community.
Remote work feels a lot like Reddit. I don't actually know any of these people I work with, I just have very shallow interactions with them. I started coming in to the office after years of remote work and its unreal how much more social and friendly it is. People who I would hardly have more than the most transactional of chats with on Teams are now sharing their personal lives freely.
I'm Gen Z so remote work has been most of my work history. I'm just genuinely shocked at how much more effective and fun it is to work with people in person.
Please no. This sounds awful tbh.
You're not getting genuine social interactions from people who are paid to spend time with you. If you want genuine social interaction, get a dog.
I think you mean get a cat.
I miss donut. Is it still around?
Feeks like a relic of the early pandemic times (although there are countless other tools like it now).
Donuts are okay, I've used it at 2 different companies now, but I inevitably find myself disabling it after 2-3 months on the job, usually when I start getting repeats. Maybe it would be okay if you could silently veto who you got paired with. No offense to some of my coworkers but I groan when paired with someone who isn't very conversational where I know I'm going to have to shoulder the burden of finding something to talk about.
ALL work is transactional. I solve your problems, you pay me money.
I have family and friends for "social interaction" and "meaning". I do not seek that from a job, nor do I want a job that claims to provide it.
Any recruiter that tells me "our company is like a family" gets a reply that says "so i can cry on your shoulder in case of a bad breakup, and you'll help me move furniture?" and then gets blocked.
This is such a simplistic take. There is a huge gulf between "We are a family" saccharine corporate BS and "I am a cog in the machine. I am forced to make conversation. Hello Coworker How Do You Do" robo-employee mnemonic.
Personally I prefer to work with people who have a sense of humor, self-awareness about the importance (or lack of) of our work, have some interesting things to talk about it, can be surprising, etc. They don't have to be my best friend ever but I don't want to be bored.
The "we're like family" phrase can mean many different things in the work environment, so don't read too deeply into it.
That being said, it's often a sign of poor management; managers will use "we're like family" instead of addressing problems that they need to address. It can create a very stressful situation if you're a high performer, because the expectations and handholding quickly get unreasonable.
(The song "Surface Pressure" from Encanto explains the situation exactly.)
For example, I once worked with a manager who used the "we're like family" excuse when incoming tickets were incomprehensible and missing critical information. He was just copping out of his job, which was to set processes and make sure new employees knew the processes. Instead, his expectation was that I would handhold the organization through the ticketing system.
100%
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.
You sound like a joy to have as a coworker…
Again… read between the lines. Think a little bit into what i said. Think about it a little critically
There are important ad hoc interactions that you have in an office that you don’t when you’re remote.
I personally prefer remote, but recognize that it’s easier to collaborate in real time in person.
> I [...] recognize that it’s easier to collaborate in real time in person.
Not everyone is you and not everyone agrees with that evidence-free claim
It’s both well known and self evident that communication is richer in person for the vast majority of people.
Not really something worth arguing about.
Water is also wet, but I don’t have a specific source to link for that.
there is a middle ground. if i walk past you and you make eye contact, i say hi. if you are focused on your screen ignoring me, then i remain silent
That doesn’t account for folks who fail to make eye contact (of which there are many in tech)
it does, because i won't be greeting them, which is exactly what the poster above is asking for
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.
Love it, love the spite, but you will actually legitimately lose people who don't want to join a cult. If you wouldn't drive me to the airport for free, then we're not family, sorry. Save that term for, like... people who aren't paid to spend time with you.
there is nobody in my family on whose shoulder i can cry except my wife. the friends that i have where i can do that i all met through work. and yes, coworkers have helped me move too.
"we are a family" is still a warning sign though.
it could mean that the team is a tight knit group that a newcomer will have difficulty to break into, especially an introvert.
or it could mean certain expectations towards each other that i would not understand or be comfortable with because i have not experienced any family like that
so instead of rejecting the idea i would ask some questions to find out what they mean by that.
You're being downvoted because you aren't being a team player. Now please sign this PIP from your "family".
What becomes apparent very quickly outside the imposed rigidity of a physical office is that different individuals and different roles all have different optimal communication patterns. And people can get really fussy if they aren't getting the structure/tools/freedoms/whatever that they feel they need.
And so the answer to your question is ultimately much more idiosyncratic than you're hoping it to be. Whatever answers you find here, take them as inspiration for things to try out rather than specific things to do.
With that said, effective communication patterns tend to naturally snowball, so if you can start getting people feeling connected and collaborative, you'll find that they'll naturally keep that up and build on it.
But you are going to need to throw some spaghetti at the wall to see what your team needs in order to get that process started.
> if you can start getting people feeling connected and collaborative, you'll find that they'll naturally keep that up and build on it.
A great insight
Try to reduce the number of required sync meetings in favor of async alternatives. For the required sync meetings, make sure there is a rock solid agenda and EVERYONE knows what is expected from them going in. Make sure the meetings cover meaningful material and helpful to all attendees. Encourage everyone to speak up and contribute. If you find certain individuals not contributing or not prepared, proactively have a conversation with them outside the meeting to reset expectations.
For async communication, it can still be helpful to set specific windows of time for things to get discussed. Example, Mondays 9am-Noon ET we review/discuss sprint goals. I like to record short videos with Loom to kick off discussions like this. Make sure to center these types of communication around specific tools, e.g. JIRA, Confluence, Google Docs, etc. Make sure the discussions convert to traceable decisions in your tooling.
>For the required sync meetings, make sure there is a rock solid ...
What about a rock band instead?
Responsibly. Which means as short as possible, visible, to the point, and with clear indication of urgency.
And as the currently top comment says: make your messages public by posting them in the right Slack channels. I had a former colleague literally sabotaging me -- he thought he was getting fired because I was hired, and quickly hated my guts apparently -- by not responding to my Slack DMs which I used to bring a bit more details that I felt could be too much for the channels (logs, error messages from CLI tools etc). I could not progress on important tasks for a few weeks because of him.
After he pulled this stunt twice, I simply started posting in our team's channel where executives are also present. He never dared to delay a response ever again for as long as I was there during the contract.
It's sad that it sometimes comes to this but work is work and I am paid to deliver, not to develop endless empathy towards childish insecurities that result in a literal sabotage of my work.
Use Google docs. Ideally, everything or as much as possible should be public and accessible to anyone on the team. Especially planning and scheduling documents. Each meeting should have an agenda attached to the meeting on the Calendar. Each meeting should be transcribed and then summarized using Gemini.
Minimize the unsearchable communication tools, like Slack and Discord, though these tools are fantastic for casual conversations. Everything possible should be done to minimize notifications from Slack/Discord. In fact, minimize interruptions as much as possible to maximize the asynchronous benefits of working remotely.
On the development side, everything should be code reviewed before merging to main, as this helps spread knowledge and increase the signal:noise in written communications.
On the business side, all customer meetings (many of which should use GMeet), should be transcribed and summarized so the developers and other folks can be as close to the customer as possible.
Meet in person as a whole company AT LEAST once per year, perhaps 2-3 times. This can get expensive. As the team learns each other, the frequency can reduce. During periods of employee growth, increase the frequency.
Read "Remote" and other books by the Basecamp team.
we also use Google Suite. Google Doc's [] task button is very helpful. We use a single to-do list for the team, which helps keep everyone on the same page
Right. Also use the @user comments to notify people as needed.
> No plans to be in person
Figure out how to have some kind of face-to-face relationship. This could be an annual all-hands trip, or otherwise take a week to fly out and spend time with the person you work with.
You learn A LOT about each other when you interact face-to-face. I once worked with two developers in India, and assumed that the shy one was just so-so, and the talkative one was brilliant.
After some deep day-long conversations, and a few day trips, I realized my assumptions were completely wrong: The shy one was shy, and the talkative one spoke before thinking.
---
More recently, I started work with a hybrid team. I live 60 miles from the office, but it's brutal commute. I go in once a week.
I've also met someone who was so different in real life, not their funny and exuberant selves at all, that I had trouble seeing them the same way when we later met back online. This wasn't work-related but a formerly multi-year friend I met in a video game and talked to daily about anything and everything. It was a strange experience for teenage me, but so this can go both ways (nearly all of my "first IRL meetup" experiences were good, though). If someone is great in online communication, I wouldn't say that there is a reason to meet up unless both parties want to. But you're probably right that, for a company, you need to decide to invite everyone or not to have this type of meeting. You can't exclude some of them so the point is probably moot
For the meetups my company does, one thing I like a lot is that we mix it up. Different countries, different settings, different events. Beyond that not everyone enjoys the same environment, the change itself also makes it interesting and creates talking points. People share more tips or explore something together because nobody is already familiar with the place and/or activity
Since I haven't seen this yet in the comments, a startup I worked at in a previous company set up Discord channels for small teams, and it by far replicated the closest to "folks are sitting next to each other in the same room" experience that I've seen before.
I see lots of advice here about documenting everything, discouraging 1-1 conversations, etc., and while I agree with that up to a point, this advice can also drastically slow you down if you require a level of formality for everything. The thing that was nice about having Discord channels is that if I needed to get a quick explanation about something, I could ask quickly without needing to schedule a meeting, etc., and everyone else in the channel can listen in (if desired). Discord also has good "deafen" features, so if you're heads down and don't want to be bothered it lets people know.
Again, I think this only works well with about ~8-10 people max per channel, but that's about the optimal max size for project teams anyway in my opinion. I highly suggest you try it if you haven't - when I first tried it I thought "How is this any different from Slack Hurdles?", but the small usability improvements in Discord made it feel to me like it approximated the in-person work experience much better than Slack (note we didn't use Discord as a complete replacement for Slack, just for small "working group" teams).
We do three things:
First, we use Missive to integrate email and chat. This way everything's in one place, properly threaded, and we can easily discuss emails internally in context. Much much better than GMail + Slack.
Second, I run video chat office hours twice a week (Tuesday/Thursday). Anybody can drop in to discuss anything — or not, if there's no need. This lowers the activation energy for "in person" discussions that otherwise might not get scheduled and promotes async work the rest of the time.
Third, regular company offsites! Even a few days a year is good.
> I run video chat office hours twice a week
I used to do that with a large remote team. It was extremely helpful with onboarding, and keeping a dedicated space for technical discussions.
I've always liked to make bug reports (called issues this century it seems) the center of gravity for task-oriented organization communication. Unfortunately there isn't an obvious best in class solution available but github is usually not too bad. Or the issue system we dare not name (rhymes with era). Communication about non-task-focused subjects in Slack. No DMs unless for palace intrigue. Don't much care about meetings except for socialization. Nothing gets done in meetings but it's nice to shoot the shit once in a while.
Edit after reading other comments: no team private slack channels. Super annoying.
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.
First off learn to relax. breathe. Just because people aren’t constantly communicating doesn’t mean nothing is happening.
Learn to embrace long pauses in video calls. Learn to accept that a response to a message sometimes takes several minutes or even an hour to come through.
You said everything is going well. Okay, so what’s the problem then? The amount of communication currently happening clearly must be sufficient, otherwise things would not be going well. Right?
Just chill.
Video calls. If you aren't having at least one video call a day something is probably wrong. Configure it such that starting a video call takes no more than 4 clicks.
Have a company-wide General/Coffee chat where people talk about arbitrary things. It's better if this chat has history which expires in 24 hours.
Write lots of short documents -- especially for designs. Review them much like you would review code. This can be as simple as Markdown documents in your repository using your normal code review tool. Ensure all documents are listed in a single easy-to-find index of some sort.
> If you aren't having at least one video call a day something is probably wrong.
Depends on how you work? A video call every day would be too much for me, but two a week seems alright. I'm also not a fan of daily meetings in person either, though.
Agree with the occasional relaxed "coffee chat", and having a repository full of good documentation, but...
>If you aren't having at least one video call a day something is probably wrong.
That seems excessive to me, especially if everyone is also staying connected via chat, emails, etc. Weekly meetings are about my limit, considering I also have work to do, meetings with external stakeholders, ad-hoc meetings, etc.
At least one video call a day is more about socialization than work; chat and email doesn't really strengthen psychological feelings of connection to the team. Regularly putting a face to the nickname is important.
I consider small meetings (say <10 people) within the team, ad-hoc or otherwise, to count against the once a day minimum. It doesn't need to be a purely social call to be effective.
Different people want different levels of socialization attached to their job duties. If the meetings are a requirement, having them daily is too much for my taste and is more likely to strengthen my psychological feelings of being annoyed.
In any case, not having a daily meeting does not mean something is wrong, as the parent poster stated.
> It's better if this chat has history which expires in 24 hours.
This sounds fun to have a b.s./watercooler chat channel. It'd be cool if Slack had that feature but I wonder if that's a non-starter for corporate reasons.
Workspace Owners and Org Owners can adjust retention settings for public channels. Private Channels and DMs can also be set by members if allowed by admins.
Note that not everyone likes being filmed. I somehow find it quite different to meet irl compared to being on camera, perhaps because then I can observe what they're looking at. Video calling is like being on stage. (I don't mind being on stage much, just like how video is not a big deal either, but the feeling is similar)
I've had a lot of productive days where I wasn't forced to broadcast my face for an hour. Can you tell me what I was doing wrong?
> It's better if this chat has history which expires in 24 hours.
Probably wise to run that by counsel.
it is insane that we can have face to face and even video meetings that are not logged, but we can't have text based chats like that? what if we meet on IRC? should that be illegal without a bot to log the conversation?
Sadly, I'm sure that the only reason that face to face meetings are not logged is technical capability more than anything else. The law just hasn't metaphorically noticed yet that those can all be recorded to. It's still on the pricy side at the moment. (Don't forget not every business is a tech business that still reasonably expects 20%+ profit margins.)
I often bang on the fact that laws made in the 20th century are often written against an implicit background of what is physically possible that people underestimate, like, the number of laws that people nominally break every day but are impossible to enforce because we don't all have an assigned police presence assigned to us. We should not casually assume that once we acquire the capability to enforce these things that we should. Another example of this is that while I understand the drive to document what a company is doing, we need a certain amount of ability to speak to each other off the record, even in a corporate environment. Yes, it is used to do bad things, but we are humans, we need that slack, and it is used to do good things too.
“Slack” under the law is quite an interesting concept. “Inherent logistic pseudo-discretion” might make me think less about a friendly guy smoking a pipe, but it has some disadvantages, too.
I’m interested by the fact that you and I could travel to Nebraska and whisper to each other in a cornfield in ways that violate the law left and right. Why is this not a huge problem? Because inherent in the logistics of getting there is a presumption that most law enforcement will use their discretion not to care.
Is cornfield-whispering becoming more powerful as other comms get weaker? Is it becoming less powerful as fewer of us choose to go to those lengths? Interesting stuff to consider in the golden age of surveillance.
The friendly guy smoking a pipe was merely ahead of his time. If we are flinging ourselves into an AI-driven total surveillance state we're all going to miss slack more than ever. Hopefully if anyone survives the AI-driven total surveillance state will eventually realize that with the degree of control it has it doesn't have to crack down on literally everything just because it can.
in the culture series iain banks paints an optimistic picture of an AI driven idealistic utopian post scarcity society where nothing is secret, from the AIs at least.
some of the ideas seem to be that in post scarcity many crimes become meaningless, and that the AIs keep your privacy.
well, it depends on the country. in germany this kind of surveillance is illegal unless ordered by a judge, and there is a high bar to get that order. even at work recording of conversations is generally illegal to protect employees privacy. however i think logging of text chats and storing emails is legal. and i believe some people want to make it mandatory.
it is a constant back and forth between both sides.
earlier i have made the argument why written communication should be treated just like the spoken one:
https://news.ycombinator.com/item?id=41913176
https://news.ycombinator.com/item?id=41912666
> It's better if this chat has history which expires in 24 hours.
Your legal and HR departments will be much less enthusiastic about this idea if your org is big enough to have either.
My vague understanding of the related laws is that as long as the company has a consistent retention policy and is under neither a court order to increase retention nor retaining records for specific incidents as part of policy, that a short retention period is fine.
I expect legal would actually be happy about shorter retention periods since it makes their job easier. HR of course wants infinite retention periods because it gives them a bigger stick, but universally longer retention is not the only way to address those desires.
Set it to retain (for legal purposes) but make invisible (even to CxOs). You can still pull the data with a proper request.
I've accidentally made it work extremely well in the past with Discourse[0] (not Discord). It was meant to record decision making processes, but it ended up replacing almost all of our async communications. Messaging was used only for emergencies. I've since left the company and never tried it again due to different cultures in my following companies.
[0] https://www.discourse.org/index
In addition to all of the management, communication, and team building strategies mentioned here, I've got a shameless plug for a product I've been building with a fully remote team of ~30 people over the past four years: https://katmaitech.com/
In person collaboration is best, but for a fully remote company and geographically distributed team I think we've built the next best thing.
Many of us are on camera all day, others pop on just for scheduled meetings. But with the mix of working styles we've managed to maintain a pretty healthy culture, where we can have some of the spontaneous interactions that are so important.
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.
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.
This is what my last, 6 person, startup used, and it was really helpful. It lowered the barrier to having a quick discussion, since you could see if someone was at their "desk" or busy in a meeting.
Also you can see if other teammates are having a discussion or co-working in a common area, which made for some ad-hoc co-working sessions.
I'm surprised at all the positive mentions of gather town. It just looked like a childish gimmick to me? I was tempted to log in and make some jokes about the pool being closed but I didn't want to out myself like that at work.
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.
Gather is great. I think it lowers the barrier to chats just enough to make it more organic. In particular I find it's really great if you're having a 2-3 person conversation and realize someone else would be really valuable to add. You can just glance at their desk and see if they're available, "wave" to them, etc.
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.)
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.
> Oh god, please kill it with fire.
> This is horrible.
> This would be insanely disruptive to me and I think most of my team.
> There are much better ways to handle this.
Hi! You could probably turn this from a low-effort rant into a productive comment by removing the first 2 lines of your comment and expanding the last one into something informative.
I have worked with several companies and collaborating across vastly different time zones...and the thing that seems to work best is some central document repo/wiki. Sure, group chats help, 1:1 chats help, email helps...but for institutional knowledge, or even info that needs to be passed across time zones, i find it helps to "dump" info in a central place that everyone knows to look at like a doc repo/wiki...and a chat becomes too ephemeral, plus as new messages get added very critical info gets pushed down...and if a chat platform allows to "pin" some critical info, then you just pivoted to need a doc repo/wiki of some sort.
I will also add that if the info to be conveyed is less than institutional knowledge, and it more about "what's status of a project?", that too, can best be posted in some sort of succicnt dashboard...which can live somewhere in an appropriate place in your doc repo/wiki. Again, i will state again that ephemeral platforms like chat have their place, but there's nothing more powerful to ensure EVERYONE everywhere in your org knows what's up, what's happeneing, and/or how to get help to keep moving forward on all efforts.
Huge bias here as I work for Figma, but multiplayer collaborative editors like Figma do wonders.
We run nearly everything out of a figma or figjam file. Retros, planning, etc. There's something really nice about being able to see everyones cursors at once, and feeling like you're collaboratively creating something. Presos and slide decks often feel very one-direction from a data flow perspective, which becomes problematic for remote-only roles.
how do you think Figma slides will play into this? (Big Figma/Jam fan here BTW, thanks for your work!)
Against what is mentioned in other comments I suggest that all the information and discussion should happen in your documentation platform. Confluence, notion, even Jira.
While slack seems like popular suggestion, its not made to keep structured information and what happens is that you have some discussion in slack, some discussion in a meeting that was not recorded and then, in a best case scenario, some conclusion in Confluence. This is a bummer because a lot of information was lost, specially the logic behind a decision. It would be far better if the discussion happened in writing within the comments section of the document. Now all the context is in a single place and searchable. Plus its possible to add to it somewhere in the future, so the document base doesn't necessarily grow with time.
The most important thing to me about remote communication is making time for "coffee catchup" to chat about non-work things.
We literally sit down with a fresh coffee for 5mins just as we might when crossing paths in the office. Find common topics among colleagues to shoot the breeze - football, video games, cars, etc.
Soon you'll have cross-team relationships with people who might never work directly together.
If you find yourself constantly trying to explain stuff visually, invest on a graphics tablet. Even a "cheap" <100 EUR goes a long way.
As for the "whiteboard", just opening Excalidraw when you need it is very low friction in my experience. Google Jamboard and Miro were okay-ish, I guess, but for me the simplicity and responsiveness of Excalidraw is still better.
I've integrated draw.io into our Confluence. We can now create inline diagrams right in the page being edited. Resulted in higher quality documentation, with a lot more diagrams for even mundane things. I generally work in pictures, so it's great for me.
But I do agree, excalidraw is great. I recon its an importan skill to be able to confidently and quickly whip up a diagram while in a call. I worked with an engineer who preferred MS Paint, but he was really good at it, and it resulted in him explaining tricky concepts really elegantly.
Slack / IM often
Use video chat for meetings (encourage camera on but don't require it - management should lead by example)
Be kind. Reach out using other forms of communication (like snail mail) if you want to encourage each other with thank you notes, etc.
Use some kind of shared wiki for long term 'shared ownership' documentation. Don't be afraid to lead by example. Don't be obtuse. Give visual examples of processes, technical components, etc.
Lean into visual examples everywhere you can (screenshots, mock-ups, diagrams, etc).
In video chat, screen share and encourage use of annotations when discussing things. (Zoom has this feature and it's awesome)
Use an agile cadence. Encourage people to share questions / concerns at story grooming sessions (which should be regular). Also encourage feedback at retrospectives (which should also happen regularly). Managers should lead by example in blameless retrospectives and lean into positive feedback.
If you're a team of all dudes (or any one thing), you have a blindspot with perspective. You should rectify that.
I work from the USA with people only in Singapore and India.
I wrote "Writing style for Slack" a couple years ago if you're interested:
https://www.kcoleman.me/writing/slack/2023/03/11/writing-sty...
Actually do something when people don't reply to their peers.
Even at companies that aren't "remote", there are people who will simply ignore emails and messages. You're forced to go nag their manager or escalate to yours to get them to respond.
> You're forced to go nag their manager or escalate to yours to get them to respond.
That usually happens in big companies. It is so annoying.
Effective communication in a remote startup requires clear tools and processes. Use platforms like Slack or Microsoft Teams for real-time messaging, and schedule regular video calls via Zoom or Google Meet to stay aligned. For task management, tools like Trello, Asana, or Notion can help keep everyone on track.
If you're looking for a fun way to unwind after work, check out 1xBet slot https://www.bangsaonline.com/berita/130476/setiap-orang-memi... for some great online gaming options!
One thing I've found useful is to have deliberate google meet calls when having planning discussions or firming up decisions.
I set up the recording and transcription and then up front we define the problem and what we want the outcome to be. Afterwards I give the transcription to ChatGPT and get it to summarise the content, decisions, etc and add that to our documentation with a link to the recording.
This helps you stay on the same page and also gives context to people who werent present about what has been discussed and decided.
Gemini is actually good for audio transcriptions, I tried other AI tools that were much worse.
I didn’t find another good use of Gemini, but the audio transcription combined with the summaries were great. Best I’ve seen.
Distributed startup founder here. We love Figma, keep in touch with Gather.town, and have been very happy with Flat.app for keeping us from Asana/Slack hell.
+1 for Gather.town we've been using it for years
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.
Be honest about people not showing up and say it's not ok. Hours need to mean something. If there is a block of 4-5 hours a day where everyone (that has a dependency on each other) is available, this is key.
Anything less and you'll have people just enjoying a day at the park (without the laptop).
Communicate in startups by keeping messages clear, concise, and action-oriented, using tools like Slack or Notion for collaboration. Foster transparency, regular check-ins, and a feedback culture to ensure alignment and adaptability.
Like an MMORPG guild. which in 2024 means Discord.
(No “professional” solution is even close to gamer tech for remote communication)
I find Discord clunky, speaking as both a gamer (perhaps I'm getting too old for this) and employee who used it with a customer. What does it do that nothing else does, or where is the friction lower in your experience?
It's funny how true this is - how long has Discord had voice channels now?
Maybe Zulip for a slightly more searchable option?
A little bit on the softer side, but It's good to encourage a feeling that you can just say something publicly even if it might make you sound slightly naive, because it's WAY more common that everyone else actually has the same misconception or bad assumption. People tend to do that once, someone makes a rude comment about them not already knowing, then they pretend to know things from then on. I think that has to come from the top by example. People will emulate sounding like the highest up person they're interacting with on a project or in a meeting.
Make all repos public within the company and use issues a lot on the repos directly - so they remain searchable along with the code.
Same for Slack - keeping stuff public as much as possible.
Set aside time for reviewing PRs separately and together, and same for project plans (RFCs, timelines, etc.).
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.
Don't assume people know how to communicate. Provide education material, cultural backgrounds, descriptions of things to avoid. Incentives that are aligned with good communication.
For example:
- Chat discourages thought. - Chat burries decisions. - Brainstorming and ideation vs reasoning. - Brainstorming, ideation and reasoning vs preferences and biases (CEO weighs in) - Documentation vs works in progress. - Proposals vs time to consider them. - Bike shedding. - stupid forum formatting. etc etc etc
Current social media is shockingly poor training for good communication.
WhatsApp is very common for smaller simpler projects, and I'm pretty happy with it.
My main communication related complaint is when it just doesn't happen at all.
Plans change and nobody tells me so I work on cancelled features, only one person actually knows what's happening and they're busy so you don't want to ask them about every detail, minutes are not taken at meetings.
I also would prefer calenders be managed better. Google shared calendars are amazing, I'm sure there's something similar people like for bigger projects where some people use apple... But nobody seems to really see the need for anytime like that.
We have a weekly "all people's" meeting every Monday morning - high-level wins for the past week and fires for the coming week, touching on OKRs, high-level direction, then each department goes through what they're working on/wins/fires. A bit of back-and-forth and "how was your weekend" at the beginning. Runs about 45-60 minutes. It's invaluable in keeping everyone on the same page and in the loop at a medium level of detail. (Not too vague, not into the weeds.)
If the items in this meeting were put into a shared document, not only would you stay on the same page, but you would have a searchable history, which becomes valuable as time moves forward. What really triggers my red flag here, though, is that "standing meetings" are one of the worst offenders as far as useless meetings go. Instead of forcing everyone to sync at a specific time, if you put these updates in documents or emails, you allow for more asynchronous consumption, and you don't affect the flow of individuals, especially if you have multiple time zones.
Tickets. Email. Signal (emergencies and sensitive info only).
Async all the things.
Keep devs out of meetings.
Don't track work hours.
Never do Slack/Teams unless a client pays a lot to suck you into that or if they pay a very large number to have your devs in it as well.
Regular group discussions (not standup) are important. My team meets 30-60 minutes four days a week to discuss technical details and long term strategy.
It plays two important roles
1. establish rapport between team members
2. gives known space for issues. Leads to Better balance of focus time and group convo
This is the most important meeting of the day. Create doc to people can add things to the agenda. Managers job is to keep the meeting relevant, efficient.
Outside of that. Devs encouraged to pair together separately for troubleshooting.
1:1s are critical early on. DO NOT CANCEL THEM. And keep them relevant
> My team meets 30-60 minutes four days a week to discuss technical details and long term strategy.
Long term strategy needs to be decided on four times a week? Each instance taking ~10% of the working day's time? I expect I'm misunderstanding you but I'm not sure in what way
Slack. Weekly meetings (encourage but not require camera on). Annual in-person retreats.
Don't be afraid to small talk and goof off just a little (in a way that's respectful to your colleagues). Allowing people to be more themselves fosters better working relationships IMO, of course with the expectation that anything public facing is done with professionalism.
If you're asking a question (whether 1:1 or in a group setting), frontload as much context as possible. Always give:
- some minimal description for the problem you're trying to solve
- what you've tried already, and why it hasn't worked
----
Bad:
> "Hey! Does anyone know how to use X"?
...time passes...
> "Sure, I can help with that. What are you trying to do?"
...time passes...
> "I'm trying to do Y."
...time passes...
> "Okay, sure. You can set it up like this."
...time passes...
> "Oh, I already tried something like that actually, and it didn't work."
...etc., etc., etc.
----
Good:
> "Hey! I'm trying to use X to do Y as a part of feature Z. I already tried A and B, and they didn't work for <reasons>. Could someone help me out?"
> "Oh, yeah, that's a known problem with A and B. We can get around that by setting up X this way. Since you're working on feature Z, you might also want to consider..."
1. gather.town 2. Zulip (nuances of design much better than other chat systems for remote work specifically) 3. the 'latent energy' is going to be lower when people aren't eating lunch together and rubbing shoulders. you have to bring the energy to an empty room all the time when working remote. this also has to be exemplified by founders. doesn't mean loudness but instilling a sense of urgency etc.
+1 for Zulip.
Still some warts, truthfully, but the core of it is just better for finding information and structuring things.
Integrations are also easier.
Definitely one of my more controversial additions to my company, but the pure volume and quality of conversations would he impossible otherwise. You would be required to wade through a lot of irrelevant dialogues otherwise.
We have been using Zulip as well now for a few years. Especially enforcing topics is a big win.
On the softer side, I found remote work to be painfully dry the past few years so created a small Slack extension to add color / life / levity to internal communication. Collect team quotes & images, make memes. It's added a lot of joy to teams, especially eng teams.
https://www.usecubby.com
At Zed, we use our native collaboration to make sure we get a lot of synchronous time together. We also use it to do design review as we're coding a feature, letting us skip code review all together!
Dailies (we have 3 in a week) for synchronization helps a lot. It’s also help’s with new stuff onboarding.
This is a great article on the topic: https://hbr.org/2022/03/what-great-hybrid-cultures-do-differ...
Check out gumroad public youtube channel, they publish all their internal meetings and call with board members. I think its powerful to have public communication however they proudly talked about remote work and now going in person.
https://cdn.zapier.com/storage/learn_ebooks/e4fbeb81f76c0c13...
https://www.hashicorp.com/resources/remote-culture-at-hashic...
https://www.hashicorp.com/resources/the-remote-developer-s-p...
Stripe's Increment had an entire issue devoted to remote work: https://increment.com/remote/
Try using video meetings through virtual frosted glass via MeetingGlass (https://meetingglass.com/).
This will give you the feeling of being at the same desk, with the opportunity for quick, spontaneous conversations and collaboration.
Here you can find articles about virtual frosted glass: https://meetingglass.substack.com/
Slack, notion, and a meeting every Monday to talk about what we're doing and priorities.
A few things help me:
Get used to the idea that someone isn’t necessarily there when you message. Try to predict when you’ll need to talk to someone and send the message with the info you need.
Document. Everything. Confluence needs to become your best friend. You and your colleagues rely on this information to keep up on things they might miss.
When you’re planning work, especially with lots of uncertainty, optimise to be inefficient. It’s better to start with 20-person calls at the start of a big project and cut them down later than to have 3-person calls and realise you missed critical people 2 weeks before your target date.
On the flip side, once you know what you’re doing, keep your status checks lean. Invite only the leads you need and write down the outcomes to share with the wider team.
Be willing to change your communication habits as you grow. A weekly all-hands is fine for a 10-person startup. It’s a monumental waste of time when you have 200 people across 5 departments.
Dumb idea: play some game together.
Tools like Slack for instant messaging, Zoom for video calls, and platforms like Trello for task management.
Discourse (not Discord chat, but the threaded forum software) is a much better choice than chat like Slack. All meetings and discussions/decisions should have a thread for them, even just a placeholder, and posts to document conclusions or next steps or rationale or whatever.
Have a company wiki.
Have anyone who can’t touch type learn to do so, on the clock, as priority 1, before anything else.
If you can’t type a lot and quickly, you will resort to speaking instead, which isn’t convenient to consume and isn’t indexable. Strongly discourage calls and synchronous communications in general.
We use Slack in general. But whatsapp too comes in the picture.
Not sure if it's been mentioned here, but The Async-First Playbook by Sumeet Moghe (Thoughtworks) is a great book that summarises a lot of what people are saying in this thread and adds more.
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.
Poorly.
Asynchronous communication. Make use of public slack channels and text based communication.
Hire only good communicators and non-psychopaths.
I worked for multiple companies remotely and the thing that worked the best for me was:
- Everyone must be connected to Discord in an audio room. - Encourage pair programming. - Record every meeting make them available to everyone. - Log every decision in a central place, easy to browse and discover. - Meet regularly (IRL) with you colleagues.
By far the most important point is always being on Discord. You can quicky jump in someone's room and feel very connected to your teammates. Obviously, like in a real office, don't disturb someone if it can be managed asynchronously.