[HN Gopher] Ask HN: How do you communicate in a remote startup?
___________________________________________________________________
Ask HN: How do you communicate in a remote startup?
We are a remote company. Everything is going well. No plans to be
in person, but I'd say we can do a better job at communicating. Any
tips or articles to read?
Author : aml183
Score : 189 points
Date : 2024-11-15 19:17 UTC (4 days ago)
| toomuchtodo wrote:
| 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...
| kingkongjaffa wrote:
| 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
| shortrounddev2 wrote:
| > 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
| gorfian_robot wrote:
| 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.
| ta1243 wrote:
| Nothing team-related should be in email. It's a horrendous
| place to hide data - worse than even than slack private
| channels.
| travisb wrote:
| 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.
| ziddoap wrote:
| 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.
| travisb wrote:
| 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.
| ziddoap wrote:
| 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.
| singleshot_ wrote:
| > It's better if this chat has history which expires in 24
| hours.
|
| Probably wise to run that by counsel.
| em-bee wrote:
| 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?
| jerf wrote:
| 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.
| singleshot_ wrote:
| "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.
| jerf wrote:
| 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.
| em-bee wrote:
| 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.
| em-bee wrote:
| 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
| alexchantavy wrote:
| > 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.
| esses wrote:
| 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.
| toast0 wrote:
| > 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.
| bigfatkitten wrote:
| > 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.
| travisb wrote:
| 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.
| ta1243 wrote:
| Set it to retain (for legal purposes) but make invisible
| (even to CxOs). You can still pull the data with a proper
| request.
| bengale wrote:
| 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.
| dijit wrote:
| 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.
| jjcm wrote:
| 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.
| kingkongjaffa wrote:
| how do you think Figma slides will play into this? (Big
| Figma/Jam fan here BTW, thanks for your work!)
| deadbabe wrote:
| 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.
| screye wrote:
| 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.
| betamike wrote:
| 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.
| Atotalnoob wrote:
| 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?
| mh- wrote:
| _> 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.
| mh- wrote:
| 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.)_
| zeendo wrote:
| 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.
| extr wrote:
| 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.
| morkalork wrote:
| 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.
| cole_ wrote:
| 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.
| screye wrote:
| 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.
| vundercind wrote:
| 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.
| zeendo wrote:
| 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.
| swatcoder wrote:
| 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.
| AbstractH24 wrote:
| > 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
| great_wubwub wrote:
| 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.
| zb1plus wrote:
| 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.
| hackernewds wrote:
| 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
| dmitrygr wrote:
| _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.
| extr wrote:
| 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.
| semitones wrote:
| 100%
| gwbas1c wrote:
| 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.
| dartos wrote:
| 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.
| dmitrygr wrote:
| > 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".
| dartos wrote:
| 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.
| dmitrygr wrote:
| > 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
| dartos wrote:
| 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.
| em-bee wrote:
| 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
| AbstractH24 wrote:
| That doesn't account for folks who fail to make eye
| contact (of which there are many in tech)
| em-bee wrote:
| it does, because i won't be greeting them, which is
| exactly what the poster above is asking for
| mvdtnz wrote:
| 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.
| em-bee wrote:
| 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.
| extr wrote:
| 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.
| quectophoton wrote:
| > 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.
| 2024user wrote:
| Please no. This sounds awful tbh.
| AbstractH24 wrote:
| 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).
| vundercind wrote:
| 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.
| mvdtnz wrote:
| I'm not sure where you read that but it certainly wasn't in
| the comment you responded to.
| vundercind wrote:
| > 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.
| weitendorf wrote:
| 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.
| Gigachad wrote:
| 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.
| karpovv-boris wrote:
| Dailies (we have 3 in a week) for synchronization helps a lot.
| It's also help's with new stuff onboarding.
| littlestymaar wrote:
| Like an MMORPG guild. which in 2024 means Discord.
|
| (No "professional" solution is even close to gamer tech for
| remote communication)
| GardenLetter27 wrote:
| It's funny how true this is - how long has Discord had voice
| channels now?
|
| Maybe Zulip for a slightly more searchable option?
| itake wrote:
| 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...
| mushufasa wrote:
| 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.
| dijit wrote:
| +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.
| jlundberg wrote:
| We have been using Zulip as well now for a few years.
| Especially enforcing topics is a big win.
| paxys wrote:
| 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.
| viewhub wrote:
| 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!
| szszrk wrote:
| 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?
| brudgers wrote:
| 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.
| paxys wrote:
| 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.
| underwater wrote:
| 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
| swader999 wrote:
| 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.
| em-bee wrote:
| 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.
| szszrk wrote:
| 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.
| em-bee wrote:
| 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.
| szszrk wrote:
| 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.
| em-bee wrote:
| 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?
| szszrk wrote:
| 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)
| em-bee wrote:
| 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.
| notTooFarGone wrote:
| 100% this. The fact that teams does not have an easy voice
| channel is a disgrace.
| vdvsvwvwvwvwv wrote:
| Every team needs a one-nine (CB channel for chat/truckers)
| em-bee wrote:
| what happens on that channel?
| zikduruqe wrote:
| 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
| em-bee wrote:
| oh you mean this: https://youtube.com/watch?v=UAAwTlCp3OE
| :-)
| edm0nd wrote:
| lot lizards
| oc_elder wrote:
| 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.
| broken-kebab wrote:
| 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.
| menaerus wrote:
| ... 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.
| bdangubic wrote:
| 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
| em-bee wrote:
| 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
| spaceisballer wrote:
| 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.
| vundercind wrote:
| 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.
| vdvsvwvwvwvwv wrote:
| In addition slack search becomes a great onboarding tool.
| swader999 wrote:
| 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.
| KronisLV wrote:
| > 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.
| sillyfluke wrote:
| 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.
| KronisLV wrote:
| > 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.
| pavel_lishin wrote:
| > _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.
| Cthulhu_ wrote:
| 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.
| aen1 wrote:
| Sounds great! Where do you work?
| serial_dev wrote:
| _> 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.
| KameltoeLLM wrote:
| Change orgs then.
| adamhp wrote:
| 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.
| Gigachad wrote:
| 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.
| andrei_says_ wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| Jimmc414 wrote:
| 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.
| reureu wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| lvspiff wrote:
| 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.
| dgfitz wrote:
| Sounds like they need to spend their time differently. Yuk.
| bongodongobob wrote:
| 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.
| swader999 wrote:
| 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.
| raverbashing wrote:
| 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)
| switch007 wrote:
| You need a private channel with everyone except the C-level.
| We find this very, very effective at our 2500+ person org
| lpapez wrote:
| 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.
| dboreham wrote:
| 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.
| darkwater wrote:
| That CEO would also micromanage in an office anyway. Oh wait,
| now it's called "founder mode" and it's something good.
| saxelsen wrote:
| 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?
| Gigachad wrote:
| It's still a waste of time to have to debate every single
| thing every day.
| marliechiller wrote:
| 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
| vel0city wrote:
| 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.
| mvdtnz wrote:
| 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.
| aen1 wrote:
| 1000% agree. I'd rather spin my wheels for an hour on Google
| than ask a silly question in public
| negus wrote:
| I would like to work with you. Asking searchable things may
| be considered disrespectful to one's time
| griomnib wrote:
| 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.
| hn_throwaway_99 wrote:
| 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.
| vundercind wrote:
| 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.
| bsuvc wrote:
| 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.
| lutorm wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| pasc1878 wrote:
| 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.
| rsingel wrote:
| 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.
| piotrkaminski wrote:
| 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.
| gwbas1c wrote:
| > 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.
| bjclark wrote:
| 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.
| sethpurcell wrote:
| +1 for Gather.town we've been using it for years
| danesparza wrote:
| 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.
| scott_w wrote:
| 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.
| viewhub wrote:
| 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.
| lazystar wrote:
| >For the required sync meetings, make sure there is a rock
| solid ...
|
| What about a rock band instead?
| theendisney wrote:
| Dumb idea: play some game together.
| gwbas1c wrote:
| > 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.
| quectophoton wrote:
| 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.
| beAbU wrote:
| 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.
| comprev wrote:
| 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.
| oc_elder wrote:
| 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
| vpai wrote:
| 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
| mannyv wrote:
| Slack, notion, and a meeting every Monday to talk about what
| we're doing and priorities.
| sn9 wrote:
| Stripe's _Increment_ had an entire issue devoted to remote work:
| https://increment.com/remote/
| kentich wrote:
| 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/
| eternityforest wrote:
| 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.
| jspdown wrote:
| 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.
| kkfx wrote:
| 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.
| HackYourGrowth wrote:
| 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.
| starlite-5008 wrote:
| Tools like Slack for instant messaging, Zoom for video calls, and
| platforms like Trello for task management.
| Arindam_56 wrote:
| We use Slack in general. But whatsapp too comes in the picture.
| coding123 wrote:
| 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).
| sneak wrote:
| 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.
| pdimitar wrote:
| 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.
| haolez wrote:
| 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
| why-el wrote:
| 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.
| organsnyder wrote:
| > 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.
| MisterKent wrote:
| Agree with the above, except:
|
| Sharing solutions in slack works until stuff becomes impossible
| to find.
|
| Using confluence or some type of team documentation feature can
| help with that stuff. Better yet, keep it very low effort to
| add docs there, so people can copy paste important (long lived)
| messages there.
| rglullis wrote:
| 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.
| mettamage wrote:
| > 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! ;-)
| patrickhogan1 wrote:
| 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.
| diggan wrote:
| > 1. Gitlab somehow statistically tracks public / DMs.
| Haven't implemented at my startup but if anyone knows a
| simple way to do - please let me know.
|
| If you use Slack, I think the admin panel already contains
| the number of messages in channels VS DMs. Long time I last
| saw it myself, but I think it was missing a breakdown on how
| many members of the Slack received the channel/"public"
| messages (as not everyone is part of every channel, 2 member
| channels vs 200 member channels for example), maybe it looks
| different now.
|
| > 5. Slack Is Great But (SIGB) - teach people that they don't
| need to read everything. Many people get overwhelmed
|
| I think this happens when Slack is the "source of truth",
| because the ephemeral feeling it gives since it's a chat
| ultimately. If you instead use a wiki/whatever to actually
| collect things that are important, there is less stress about
| possibly missing out on important things. Make summaries by
| week/month and it'll be even easier for people to catch up
| easily, which means even less stress :)
| patrickhogan1 wrote:
| Thank you! I'll check out the Slack admin panel! I removed
| that item from my main message because I was concerned some
| people might misinterpret "tracking" as something invasive
| (e.g., reading messages). What you're describing is exactly
| what I'm looking for--just the stats--to support public
| disclosure and knowledge sharing.
| Buttons840 wrote:
| 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".
| aen1 wrote:
| Meeting in person >1 hour away is difficult for people in
| many life circumstances. And if there are constant meetings,
| it either strains families or makes the person who can't make
| it feel left out
| ravishi wrote:
| Yeah. Once or twice a year should be fine, I would say.
| lanstein wrote:
| s/Slack/Zulip
| crystal_revenge wrote:
| 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 baring the fact that the latter makes me start
| to dread meetups rather than enjoy them.
| aen1 wrote:
| 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
| pasc1878 wrote:
| 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.
| neilv wrote:
| Are you sure that's introversion, rather than shyness or
| insecurity? The answer might help with the solution.
| eddd-ddde wrote:
| Agreed, you are collaborating with a team, if you are not
| comfortable sharing thoughts how are you gonna be
| comfortable sharing _code_.
| bezier-curve wrote:
| There's also such a thing as oversharing context with
| people that are already burdened with a lot of context
| related to their own tasks. Splitting off into private
| conversations helps keep irrelevant members from context
| switching.
| saxelsen wrote:
| 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.
| AlotOfReading wrote:
| 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.
| dangerlibrary wrote:
| 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)
| nickstinemates wrote:
| 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.
| oDot wrote:
| I'd say avoid slack as much as possible. Use evergreen
| communication:
|
| https://www.emergencyremote.com/emergencyremote#h.vvx9who9kf...
| caseyohara wrote:
| Slack and evergreen are not mutually exclusive.
|
| Asynchronous communication is largely a cultural concern, not
| a technical one, and completely compatible with Slack. Just
| give people permission to treat Slack as an async tool and
| remind them they don't need to be present there every minute
| of the day.
|
| Where I work, we encourage people to close Slack when they
| need to focus or simply don't feel like being present.
| There's no expectation that a message gets an immediate
| response, even if the person is online.
| oDot wrote:
| While this is generally true, is how I recommend to treat
| Slack, and how I treat it myself, the reality is that its
| nature is neither here nor there.
|
| It's true that if you treat it just right, you're going to
| get an async tool. However, you want tools that are
| naturally like that. There are many foods I can fairly
| easily cut with a spoon, yet my experience is much better
| using a knife.
|
| The mere fact you have to encourage to close Slack means it
| is used for something it shouldn't. Use evergreen
| communication for most communication, then use Slack only
| when you need it, which will be much much less.
|
| Slack is also terrible at history preservation, see my
| reply to a sibling comment.
| sanderjd wrote:
| How is this incompatible with (or even, different from) using
| slack? It is asynchronous and preserves history...
| oDot wrote:
| History preservation is not just about continued existence,
| but also about discoverability. Other forms of
| communication (issues, project planners, and email lists)
| are much better for the latter.
| sanderjd wrote:
| 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.
| m0rphling wrote:
| 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...
| sanderjd wrote:
| I think " _everything_ in public " is actually bad advice. Not
| everyone is comfortable saying everything valuable that they
| have to say, to a large audience. It is very intimidating to
| ask questions in a channel with a lot of members. "Too bad, get
| over it" is not the optimal answer.
|
| What I do believe is good is to encourage things to be public
| _by default_ , and to encourage people to be stingy about what
| they make private.
|
| I think a good balance is:
|
| 1. Private DMs with your manager, for sure. This is no
| different than why managers should have a set schedule of
| closed-door 1:1s with their reports. Sometimes there is awkward
| stuff to discuss with managers, and there needs to be a venue
| for that.
|
| 2. Private group for small "leaf node" teams. This is IMO the
| best place to share "I'm sick today" or "I'll be on vacation on
| these dates". In my experience, people prefer to share this
| kind of stuff with a smaller group, and I think that is
| reasonable. This also gives newer or otherwise more insecure
| team members a less intimidating place to ask questions they're
| worried are dumb.
|
| 3. Pretty much everything else public.
|
| YMMV of course, but personally, I've seen problems from both
| too-private and too-public cultures.
| sarchertech wrote:
| 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.
| emmelaich wrote:
| 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)
| jandrewrogers wrote:
| The biggest problem with Slack, by far, is that it is
| effectively ephemeral. An enormous amount of valuable content
| in Slack quickly becomes undiscoverable for all practical
| purposes. This creates significant challenges if history
| matters and this only gets worse as the number of people on it
| grows. In every organization I've participated in where Slack
| is the central "everything box", they had to invent parallel
| processes and systems so that things don't get lost in Slack.
|
| Slack should be treated like the super-IRC that it is, it is
| poorly designed to be the nominal system of record that people
| try to use it as.
| crystal_revenge wrote:
| 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).
| dyauspitr wrote:
| 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.
| shortrounddev2 wrote:
| Asynchronous communication. Make use of public slack channels and
| text based communication.
| GardenLetter27 wrote:
| 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.).
| avel wrote:
| This is a great article on the topic:
| https://hbr.org/2022/03/what-great-hybrid-cultures-do-differ...
| nitwit005 wrote:
| 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.
| cryptozeus wrote:
| 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.
| danjl wrote:
| 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.
| sandbx wrote:
| 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
| danjl wrote:
| Right. Also use the @user comments to notify people as
| needed.
| hn_throwaway_99 wrote:
| 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).
| jonah wrote:
| 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.)
| danjl wrote:
| 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.
| dboreham wrote:
| Hire only good communicators and non-psychopaths.
| dboreham wrote:
| 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.
| 1propionyl wrote:
| Poorly.
| kylehotchkiss wrote:
| 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.
| creer wrote:
| 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.
| saxelsen wrote:
| 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.
| SoftwareDev122 wrote:
| 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.
| llamaimperative wrote:
| 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.
| mxuribe wrote:
| 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.
| howiemc2000 wrote:
| 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.
| ketzo wrote:
| 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..."
___________________________________________________________________
(page generated 2024-11-19 23:01 UTC)