Ask HN: How do you ensure everyone on the team is heard on Slack?

92 points by _rzt9 4 years ago | 106 comments

The premise of this is that I feel people are pinched for time and need space to work – yet when they come back from their coding mode the answers team members provide seldom respect the depth, severity, or nature of the queries which are posted while people are focusing on dev work and, in some cases, simply delay the discussion of it until the next weekly/in-depth check in.

I've been thinking about this a lot lately, and while daily meetings are nice, once you start to go beyond the bounds of "yesterday I was working on ... and today I'm working toward ... could you provide a bit more help and/or context on <such and such> ..." the discussion balloons beyond a reasonable check-in limit with regard to time.

The properties of communication in remote work seem very hard to crack and I'd like to know if this problem is something your team has succeeded at – and, If so, how?

Edit: To be sure, I'm not talking about alerts/system critical stuff. Additionally, I work in a small company, so maybe there are safeguards for this kind of predicament in larger orgs.

Thanks

bluehatbrit 4 years ago |

In previous teams I've worked hard to make sure slack isn't the place for decisions to be made that are any greater than where to go for lunch. Same with bigger questions as well.

Slack is great for small insignificant chatter but developers need long uninterrupted periods of quiet to work. That doesn't go well with an IM system that people expect to get big questions answered or key decisions made with.

If the team needs to discuss a key decision everyone should be given time to digest the information at hand and respond. That might be in a synchronous meeting or over an asynchronous email but either way people need to have time to think and contribute. Slack prioritises whoever is first to reply and no one wants to read a 50+ message thread to figure out if they have relevant input.

If someone external to my team wants to ask a question thats of any significance I'll try to jump in and set their expectations. If it requires input from multiple people on my team then it's best done over something slower like email / collaborative docs, or as a last resort a meeting. If it's internal to the team I'll try and push it out to a mechanism that allows people to set time aside to consider the topic and respond.

Most questions in and around the team are small and less opinion based. How does X work? How do I do Y? When did Z change? Anything like that is usually fine to be answered by anyone when they get a moment and doesn't require much input from the whole team, Slack is totally fine. To help out I like using the slack action thing for when someone joins a teams channel to let them know that it could take a bit to get an answer because the team may be focused on something else.

As you say, emergencies are different. Those are raised via alerting of some sort and interrupt people in a different method.

don-code 4 years ago | |

> Slack prioritises whoever is first to reply and no one wants to read a 50+ message thread to figure out if they have relevant input.

My personal belief is that Slack provides a perverse incentive to reply quickly, rather than thoughtfully. There's a time and place for quick communications, but the majority of discussions I have over Slack feel that they'd be better served by thoughtful requests with equally (if not more) thoughtful responses.

E-mail was great at this: the extra overhead (if it could be called that, but I digress) of writing an e-mail encouraged information density in that e-mail - I want to convey my point in the least number of round trips possible, and likewise, have my question answered in the least number of round trips possible. Slack does away with this; round trips so easy as to be common, and in fact we have sites like nohello.com showing that the trend towards round-trips isn't helpful.

irrational 4 years ago | | |

It might incentivize it, but you don’t have to give in to the incentive. I turn off slack when I am heads down working. When I am using slack, I try to leave a few minutes in between my responses so the other person can add more if they wish as they are given more time to think. It also helps to train people to not expect an immediate response from me like they might get from text messaging.

MuffinFlavored 4 years ago | |

> Slack prioritises whoever is first to reply and no one wants to read a 50+ message thread to figure out if they have relevant input.

But they want to read a long e-mail thread?

bluehatbrit 4 years ago | | |

Not nessesarily, but it tends to be slower moving and each element in the thread tends to be larger and better thought through. I find this means they tend to end up shorter as a result when you skip all the email signatures. There's also less sense of urgency to reply as well meaning you can set aside some time rather than feeling like you're missing out on the slack thread which may still be moving.

Other tools can work as well like shared documents if the content/context is several pages or something.

shafyy 4 years ago | | |

I think Basecamp nails the compromise between email and Slack (I’m sure there are other tools similar to Basecamp that also do a good job)

jesterson 4 years ago | |

This is excellent writeup I could have made, but @bluehatbrit made it much better.

Slack is very distracting. I surprise some people saying I am pushing every meaningful convo out of slack and hopefully one day to completely scrap it and throw away.

Emails are way better since it pushes people to think the problem first, and you'll be surprised how many problems have found solution before "Send" button is pressed.

It's easier to just send something like "Hiyo Mark, hihi! Wazzup?". This is where it gets dangerous to performance and focus.

bluehatbrit 4 years ago | | |

I think Slack has a place in communication but it has a really poor balance. It's so easy to create and send a message to a channel and tag a few people. As a result it moves quickly and makes it hard to digest and reply slowly. It's also extremely hard to find things again later, even with the improvements to search.

Back in the days of IRC a lot of people thought lack of history was a "missing feature" but now we have it with Slack I think it was probably the best feature of IRC. When the platform has no memory you're often pushed away from it for anything that's deeper. No one can come along later and find your messages so you know you can't put anything that requires wide visibility or input there.

I'm not going to shill for IRC and say everyone should go back to it or anything, it's not really practical. But that said, I do think Slack has a huge flaw in it's design of making it so easy to send messages and pretend everyone's going to see it.

nlnn 4 years ago | |

Any tips on making sure that Slack isn't the place for important decisions?

We're facing this problem at the moment, with Slack being heavily used for almost everything.

Main difficulty is changing culture around its use - there are plenty alternatives that we push people towards, but they tend to get ignored in favour of Slack since asking is easier there.

bluehatbrit 4 years ago | | |

I think it really depends on your team and your position within the team. For me it was just a case of pointing out that people feel under pressure to respond and it's making it harder to focus. It was a genuine problem within the team that lots of people were feeling so it wasn't really news to anyone. Then it was just a case of being the one to start noticing topics that are larger and pushing them out of slack. "This feels like it might need some team wide input, Phil, can you do a summary in an email and send it around?" or something along those lines.

I suppose it's important to say don't be militant about it and allow discussions to happen a bit to really see if they're shallow or deep topics. Shallow topics are fine for slack because you probably only need a couple people's input. Deep topics where you specifically want the whole team are the ones you want to pull into something slower moving.

Trying to change habbit is tricky so it's a case of slow errosion of the old habbit with the new one. Eventually the team started to make those kind of calls themselves, and newer team members picked it up quickly as well.

pseudalopex 3 years ago | | |

Limit message retention.

taeric 4 years ago | |

I don't fully disagree, but I do disagree that I want all decisions done in a long format. Especially when I'm specifically trying to get my team to be way more agile and willing to make decisions while they are working.

Throwing up a quick discussion point on a slack room while you are acting on the idea is perfectly fine. Just as it could be perfectly fine to toss the code if the idea doesn't pan out.

fendy3002 4 years ago | | |

My current supervisor do it right, a big decision is stared in slack. It usually attracts 3-6 people in that discussion. A huddle or teams meeting is arranged if needed.

Then another slack discussion is posted with a v1 proposal in it, and link to previous discussion. This time, more people can give dissenting opinion. If nothing conflicting, a short sharing session will be held presenting this, and see whether there's dissenting opinion again.

bluehatbrit 4 years ago | | |

That's fair enough! I don't think it's about completely eliminating all decisions from happening in slack. It's just the one's OP was talking about where they would benefit from the whole team having the opportunity to consider the topic and give their input. Smaller decisions which only require the input of a few members of the team and shallow conversation I think are fine to be had in slack, that's where slack works really well.

I think a bit of it boils down to each team being different as well, if you need a team to be more agile then using slack more might be the right thing. In OP's case they sound like they need their team to slow down and consider some things more deeply and slowly. In that case pushing those topics out of slack may make sense.

flakiness 4 years ago |

A subset of tech community in Japan has established a strange form of "broadcast" yourself in Slack, which is called "minute-updates" channels, that is, each team member creates a channel owned by oneself, posts short updates (or tweets, if you like to think in that way) there, and lets others chime-in freely. So it's a channel for monologues out loud.

This clearly doesn't scale for large orgs, but any communication method doesn't anyway. One clear advantage of this is the low entry barrier: You don't have to worry about interrupting and shutting down the ongoing conversion unintentionally, or spamming others.

Although this barrier lowering seems to be helping a lot in the highly peer-aware environments like Japan. I'm not sure how effective this is in a different context. So take this as a grain of salt.

jakecopp 3 years ago | |

This sounds like a fascinating social medium/"platform". Could you share more about the community or an article about it?

I tried sending you an email but it bounced!

zombietrumpet 4 years ago | |

This is interesting, actually. I like it. Thanks for sharing!

0xbadcafebee 4 years ago |

Email is the best method of communication for anything complex. It's asynchronous, long-form, has a historical record, allows threading, you can seamlessly include anyone in the world in the conversation, have shared mailboxes and mailing lists, attach files.

But people are afraid of e-mail. Will anyone ever read my e-mail? When will I get a response? What if I mess up my message? It is unknown, immutable, does not provide instant gratification. I want everything NOW. So Slack was created to poorly reinvent e-mail, but with instant gratification and emoji buttons.

I really love open source mailing lists. Every once in a while I'll go skim over some I'm subscribed to and see what's been going on. If I ask a question I usually get an answer within a day or two. The archives provide searchable record/context for everything. I can even review patches and comments on patches, and see the history of all the e-mails before/after it, whereas GitHub PRs are little islands unto themselves. Best of all, it's all stored offline, and I can use any client I want.

It's sad that technological progress means 'things got more advanced', and not 'things got better'.

safetythirds 4 years ago |

At my place of work, our internal chat rooms (not Slack, but a similar product) are automatically wiped of messages older than two weeks, to actively discourage anyone from using it as a knowledge store.

Instead, we have a company-wide BookStack instance that's the primary store of documentation, split into different sections for project information (per project) and rough notes (per employee). Everyone is expected to contribute to the former, and may also add to the latter if they wish to share something that may be useful to others.

Usually, helping someone else out with the information they need involves pointing them to the right page where it's already documented, or writing something up for them. Perhaps also talking them through it one-on-one if it's complex.

This works for us because we're required to provide reports to our customers every few weeks, in regards to what we've been working on in the each contract - in addition to any actual deliverables. Keeping everything well documented internally makes it much easier to document for our customers.

This is a small company of around 40 employees. Not sure how well this will scale as we grow, but it's been working well so far.

gibrown 4 years ago |

In my experience (11 years fully remote/distributed growing from 90 to 2000 employees) my first impression is it sounds like you’re doing too much synchronous. Async is so efficient.

My team’s current systems: - Most deep discussions happen on blog posts including project status. We use (and built) https://wordpress.com/p2/. We don’t use email. - Start of week everyone prompted to post what they did last week and what they plan to do this week. Also have a kinda fun ice breaker question that is easy (e.g avoid asking about favorites) and sometimes generates discussion. Last week was “Pick an olympic sport to represent your life.” - Daily Slack prompt to give folks a place to report on yesterday/today. The most important thing is how people feel though. “Pick a red/yellow/green emoji for your status” and “What feels risky or a blocker?”. Create space for feelings. - weekly team meeting is then about discussions and never about status. How do we solve X? How do we feel about Y? - debugging and such does occur in Slack but longer discussions are on blog posts/comments and so can be long. - I do 1-1s weekly for new folks and bi-weekly for longer term folks. Encourage sync 1-1s between the team also.

A lot of the prompts can be automated. I dont consider them mandatory, if you get them right then folks will be happy to do them because they feel the utility of them.

https://ma.tt/2020/04/five-levels-of-autonomy/ Is a good read too.

Iterating is very important though (which you are doing yay!), I’ve tried lots of different cadences/systems but the above is the core of what my team has used for 3-4 years now and I’m pretty happy with it. I still try to make sure we reconsider if we want to experiment with something new every few months. Partly why I wrote this long comment is I’m thinking if there is anything to tweak.

binarymax 4 years ago |

IMO slack is a poor medium for in depth questions and answers. It’s a chat application made for short text. A better tool would be something like an internal stackoverflow…which would have more durability and findability.

metadat 4 years ago | |

Agree 100%, slack is the wrong tool for the job in this case.

Your proposal is a cool idea, and there are even self-hostable FOSS clones available.

See: https://meta.stackexchange.com/questions/2267/are-there-any-...

dicknuckle 4 years ago | | |

I haven't read too far into those, but if one has an integration or feature to automatically send a message to the team's Slack channel with a link to every new Local SO post, it could really light the fire on that new system. Then all the replies would be easier to capture on the SO post, AND eyes would be on the new posts, AND it wouldn't be cluttering inboxes.

chrsig 4 years ago | |

Unfortunately, I've seen an internal stackoverflow fail right out the gate because of clout chasing. For example, people asking questions only to answer it themselves immediately.

josephcsible 4 years ago | | |

What's wrong with that? On the real StackOverflow, that's not only allowed but encouraged, and it doesn't seem to cause problems like that.

yesiamyourdad 4 years ago | | |

So remove clout. SO did it because they wanted network effects from a collection of people that needed incentive to contribute.

samstave 4 years ago | | |

S.A.Q.s

Self-answered-FAQs

We typically call that "Documentation!" :-)

junon 4 years ago | | |

Which is exactly what SO encourages one to do.

samora 4 years ago |

You need to establish some rules to make Slack work for most teams without overload.

1) People should avoid DMing each other when talking about work, use threads instead (see 3) to discuss topics in team channels (see 2).

2) Keep channels to a minimum. Every person shouldn't have more than 2/3 channels they need to pay attention to. A private team communication channel (eg #dream-team) and a private work channel (eg #dream-team-engineering) is enough for most teams. All team members are in the private team communication channel. A work channel is specific to a domain, such as engineering. Example you don't want engineering work banter to distract those working on other stuff.

3) Use threads religiously! This is super important as it helps declutter the Slack experience and keep conversations heavily organized.

Groxx 4 years ago | |

I really wish Slack would let users / channel-moderators move messages. Push them into the thread they belong on, copy-to-room for ones that need broader visibility, send question X to team Y's channel, etc.

Instead, what's done is done, and it can lead to rapid degradation in communal rooms that have a lot of newcomers.

KennyBlanken 4 years ago | |

Or just switch to Zulip where everything is threaded...

bennathanson 4 years ago |

What has worked for my (mostly) remote team is a mix of different tools for different communication needs:

- Daily standups on Zoom. Each person's standup should be short and to the point. Don't be afraid to tell people they're getting into the weeds. If more open-ended discussion needs to happen, interested parties should either 1) stick around after standup or 2) schedule a new meeting to discuss in greater depth 3) start a Slack thread to discuss.

- Weekly code syncs to go more in-depth as a team, make sure we're rowing in roughly the same direction, and knock out decisions in minutes that would take days on Slack. This is especially valuable when building new products or refactoring.

- Weekly office hours held by senior+ level engineers to give more junior engineers an opening to ask questions.

- Weekly architecture meetings to formally discuss sweeping technical changes that impact multiple teams in a meaningful way, e.g. migrating to a language

For me it has been less about "email bad" or "Slack good" and more about asking questions - "What is the right medium for this type of conversation and our culture as a team?" or "What is the right tool for the job?". It's also an answer that evolves as the team/company grows; you have to reassess every few months and make adjustments.

There's also a question of culture and setting expectations that might be at play here.

- For the people answering questions, are they passionate about teaching? Do they feel incentivized/recognized for being active in answering questions? Do they have the bandwidth to help others?

- Are those asking the questions asking good questions? Are they respecting the time and attention of those trying to help them?

kazinator 4 years ago | |

Why would you do standups on Zoom if you have Slack? Is it because you're running into the 15 person limit and need video (so cannot use huddles)?

bennathanson 4 years ago | | |

Great question! We do use huddles sometimes, especially when a Slack thread starts to get too deep. They're wonderful for pairing on problems. I'm sure we could migrate to huddles for standups if we really wanted to, there's just more momentum in Zoom meetings.

But I will say that Zoom integrates nicely with Google Calendar, offers video, and like you said has a higher limit.

We're also experimenting with doing standup three days a week so we can have less time spent in meetings each week.

heretogetout 4 years ago | | |

Slack huddles have poor ergonomics what with their use of global keyboard shortcuts. I avoid them whenever possible.

dahart 4 years ago |

> The properties of communication in remote work seem very hard to crack

Many good replies here about what Slack is good for and what it’s not good for, but I wanted to take a moment to reflect on this part of the premise. The properties of in-person communication have always been hard to crack, and having everyone remote makes it that much harder. This is not an easy problem, regardless of the tools. But if people aren’t getting what they need out of Slack, it’s up to the team and the leads especially and the whole org to identify, discuss, and solve communication problems. This might be educating ICs about what to do when they don’t get responses, it might be about providing a system to escalate questions as needed, it might be about picking and choosing different communication tools.

In addition to some of the Slack problems others have listed, in the last two years, I’ve experienced a lot of: 1- new hires being very afraid to speak up in larger groups, they prefer to DM someone who’s friendly and receptive to interruptions, and especially prefer to steer away from asking questions in channels that their boss/manager is in. 2- Slack is pretty terrible for retention and searchability of info after a couple of weeks, it’s just kind of a void when it comes to keeping or tracking important information.

It’s great that you’re thinking about it a lot, because most people have reflexive opinions without a lot of careful thought. Communication is a hard problem, and it’s worth internalizing this and realizing that there aren’t easy answers to this nor single tools that will magically solve it.

theptip 4 years ago |

One important practice to keep daily standup snappy is to decouple the high level context (“I am blocked on X” => “you should talk to codeowners Alice and Bob”) from the actual solve for the problem, even if there is a quick answer.

It’s natural to answer “I am blocked” with a dive into the solution, but really you should just use the standup forum to figure out who you need to talk to, and circle back to discuss immediately after the meeting.

If you already know who you need to deep dive with, you should proactively sync with them before standup; that meeting is really just there to provide a cap on the amount of time anyone can spend blocked.

If everyone self-organizes to resolve blockers before the next standup then congrats, you have graduated and perhaps you don’t need that meeting daily any more.

It’s worth noting that in the “yesterday, today, blockers” format, the first two aren’t really needed if you just radiate context passively. The main value of the meeting is syncing on current/future blockers/impediments.

Finally I’d say a document-centric workflow can help here, because if you are all collaborating on design in a doc, then it’s easy to follow along async and see the latest state of the discussion, rather than having to read and understand every comment in Slack to keep up with the situation.

Vanit 4 years ago | |

This. At my current company any blockers that need more than a minute discussion inline get moved to an optional "parking lot" session at the end of standup. The point of this isn't to deepdive but just give a people a bit more support by ensuring there's a plan in place to either solve or further discuss the issue. I've found this really useful, but you need some discipline to not deepdive the parking lot - although sometimes if your team is desperately in need of more alignment, just do it. People not process, and all that :)

onion2k 4 years ago |

the answers team members provide seldom respect the depth, severity, or nature of the queries which are posted

This is a hiring problem. In short, the people you work with lack the ability to understand why it's important to respect their colleagues and to write better answers. Teach them to communicate better.

Also, the importance of good communication needs to come from the top. Seniors need to spend the time and effort writing good answers, and making sure replies from others are appropriate, adding a "Could you expand on this?" where they aren't.

If that fails, tell people to schedule more meetings. Face to face and video calls solve the lack of depth incredibly easily. You can't give a shallow answer if someone is literally asking you for a deeper one.

And if people push back on that, the answer is to replace them. People who aren't good communicators ruin team dynamics quickly. Hire for comms.

In a business, building good software is 50% about writing simple, understandable code and 50% communicating with other people so they can write simple, understandable code too.

oneplane 4 years ago |

Slack is for real-time stuff, not for plans and decisions. Make that distinction clear to everyone and complex questions can simply be put into complex meetings instead.

The real replacement that slack is, is for crappy emails and crappy phone calls and crappy meetings about nothing. Not a replacement for communication as a whole.

mrkurt 4 years ago |

We push Fly.io discussions to an internal forum (Discourse for Teams). Slack is an especially bad place to work async. And we want people to work async as much as possible.

Forum posts will frequently include a link to a Slack discussion, but I don't think anyone really clicks to read the chat.

This is not exactly what you asked, but peoples' managers are on the hook for helping them be heard. One-on-ones frequently trigger forum posts. Good one-on-ones are useful for this kind of thing.

karaterobot 4 years ago |

In my view the question asker can help themselves by asking better questions, if they aren't already. Sometimes people ask vague questions, and it's hard to respond to them, even if you want to. This is something we're working on in my team: ask specifically for what you want, tell the other person that it's important, and also, crucially, tell them when you need the response by.

But, assuming they are already asking good questions and just not getting good responses, they should instead be asking for a synchronous meeting with the other developer. They should be pairing, or screen sharing, or at the very least looking at each other when they talk. An ad hoc 15-minute meeting is a slight pain in the ass, but better than a Slack conversation spanning 2 days, followed by a 25 minute retrospective discussion on what went wrong.

Try to make it part of your team culture that, when somebody is blocked, anybody who can help them needs to put down what they're doing and unblock them as fast as possible. This was a firm rule on the most successful team I ever worked on, and I have carried it forward ever since then. It's better for everybody if they can expect to get help and are expected to give it.

alistairSH 4 years ago |

In my experience, Slack doesn’t differ a whole lot from email. A lot of crud, some useful nuggets, and overall not great for making hard decisions.

Within the team, we use daily stand-ups. Start out with the normal “I did X, working on Y” stuff, try to get that done in 10 minutes (for a team of 6 + manager + occasional BA or tech fellow dropping in). The rest of the 30 min block is open to whatever the team needs - stuff that if left to Slack would end up being a multi-day game of telephone.

Outside the team, Slack is ok for starting conversations, but generally anything important or hard needs a live meeting, even if it’s only for a few minutes. We have a few channels that are exceptions, where the team that “owns” the channel is better than average at making well reasoned responses. But, that’s the exception and those teams are always a pleasure to work with. And this is in a reasonably well functioning mid-sized company. I hate to think what it’s like at a large company.

bravetraveler 4 years ago |

We do really well communicating in Slack/text. Threads and a small team are really it, for us

A thread isn't that much different from an email chain, reading any of those that have gone off the rails is deplorable. Instead, encourage more concise proposals and rebuttals

Anything too in the finer details can be taken care of elsewhere, then the findings reported back

I wish my team met less often in a structured way. I don't really benefit from giving status updates or hearing theirs.

I'm not some lone wrecking ball, I just have responsibilities for services I designed before joining this team. We also don't really have much overlap. Maybe paired off on something

I feel that our more involved conference call time would be better spent on specific implementation problems or similar - with a smaller audience

spyspy 4 years ago |

Just spitballing...

I wonder if anyone has tried using a private subreddit for team collaboration? I feel like it has the opportunity to be a great asset. It's free, persistent, searchable (ish), supports threads, images/links/markdown, and even nice mobile app support.

SnowHill9902 4 years ago | |

Too easy to get distracted.

oneplane 4 years ago | | |

Also just a slower version of Slack so it doesn't really solve much.

presentation 4 years ago |

Our team has discussions on Slack but strictly in threads (NOT in DMs), and we try to tag anyone who ought to be aware ASAP. If it gets too complicated to hash out in a chat then we'll get on a call. Either way, it's a requirement that once the dust has settled, someone summarizes the discussion into a document in a shared Notion page for these discussions, links it as a reply to the thread (also posted to the channel), with clear action items that have arisen from it. Works alright for us.

hinkley 4 years ago |

I’m starting to think the deep dive is itself a problem, for reasons of Kernighan’s Law. Stepping away and thinking about other things has helped me find solutions when simply thinking harder about it has not.

Probably because as part of spinning back up I have to summarize for myself where I think I was, and the summary frequently contains the hint I missed. It’s not quite rubber ducking without the duck, and with more time to help others.

twblalock 4 years ago |

If you are discussing something about Slack that is deep in any way, ask people to schedule a meeting instead. Slack is not the right tool for that job.

e9 4 years ago |

To solve this problem for smaller teams I like to use private StackOverflow for teams: https://stackoverflow.co/teams/ The added benefit is that history of issues encountered is preserved for future employees.

SkyMarshal 3 years ago |

Why are people still using Slack when other chat systems have solved this problem? Whether it’s Zulip’s topic streams, or the ability to tag a part of a thread as “Important”, “Need Decision”, etc. There are solutions to this problem. Does Slack not have something like this yet?

dylanhassinger 4 years ago |

I am a fan of having twice or thrice-weekly in-person checkins, led by a tech lead

In my team we do these on Monday/Thursday. If something conflicts, we just bump that checkin forward a day to Tuesday or Friday.

tptacek 4 years ago |

We use a Discourse message board (Discourse for Teams) in addition to Slack. Slack is real-time and somewhat ephemeral. Important stuff is message board posts. It works quite well.

websitescenes 4 years ago |

I suggest you check slack in regular intervals so that you can contribute to the conversations. I do this and often revive dead threads that seemingly had an answer.

motohagiography 4 years ago |

I like slack, but as a medium, it's very easy to talk past each other. email is similar, where I was just on another thread where some more senior people were cc'd on a drill-down between parties and email threads can quickly become a power struggle if the seniormost person doesn't intervene and tell them to take it offline. All conflict is caused by power vacuums, which are in turn caused by gaps in leadership, imo.

Coming out of hacker IRC culture, I can keep up with anyone, but that puts some very thoughtful people, and therefore the team, at a disadvantage to what makes "good chat." I've seen it become a source of drama precisely because a normal team has a lead who sets the tone, but the equalizing nature of chat has the effect where it can both elevate dumb stuff and diminish important stuff, there's a mean reversion where the medium itself becomes the message. When it's good, it's very efficient, but when it's obligatory, it creates simmering rot in teams. It's amazing to have ideas stand on their own - but when it doesn't present the full person with them, the best ideas are no longer neutral - but rather assigned to our preconceptions about a person behind them, without providing them the tools to set tone in a way of relating.

We have to assume good intentions, but in an org, that's mostly performative, and the necessary altruism to sustain that doesn't scale. The reality of ostensibly flat organizations is that they are constant power struggles to extract value from each other (manage others), based on the ficton that the result is somehow organic leadership that produces authentic buy in and consensus. It's not. The necessary condition for value in a low-information medium like text or chat is shared purpose and aligned incentives. You need trust above all, as without it, text amplifies mistrust. The question of what facilitates that trust is the big hard problem. Anonymity and distance provides some trust in informal networks, as the consequences are limited. Text chats I'm on with friends that are absolutely private have trust that originates in friendship. Trust in on a team or in an organization is the fundamental problem to solve. Who can you trust, and for what? A single hub-spoke leader everyone trusts is the baseline, and the ideal is a complete mesh pattern of trust. Without something on that spectrum, your team is default dead. Low trust chat is lame and harmful. The best companies and teams have a relatively high degree of mutual trust as the result of aligned incentives.

When it goes to shit is when we're forced to pretend to trust each other, and then you get institutional bureaucracy politics, which async and text just amplify. I'm in a place where it seems to do it right, but I've been in places where they don't. Slack's message stats in the admin panel are a pretty good proxy metric for organizational trust, where if you see lower engagement, I'd bet just from that you have a trust deficit on your teams that is going to be a ceiling on the value they create.

If you gave me a company's outlook and slack admin panels, I would be able to tell you in a few minutes where your culture bottlenecks were. What people trust can be easily codified as well, but that's a tangent. Where I have seen Slack succeed is where the team has a basis for trust, and where I have seen it fail and become radioactive is where that trust was undermined because of a power vacuum and people defecting to where they think will prevail. Those are hard conversations becuase a lot of managers and employees personalize and moralize their position as being the effect of their identity, where they have internalized the status without a lot of examination of the practised skills it takes to do it well. Slack and email are neutral, but they are also extremely sensitive to deviations from alignment, where interpersonal conflict happens within the vast imaginations of the participants, and not in the real moment of dealing with another person.

tmaly 4 years ago |

I don't know about Slack, but I have a weekly teams meeting where I go around and give everyone a chance to say something.

brailsafe 4 years ago |

> daily meetings are nice

Daily meetings suck. Do them less frequently and allow for more time to talk about things.

politician 4 years ago |

Try Slack Huddles when the number of replies to a thread threatens to exceed 12.

readme 4 years ago |

just suggest that the person who exceeds their reasonable amount of time meets offline with whoever they're discussing with

"stay on after the meeting and we'll talk about that"

"why don't you and x meet up later to discuss y"

3pt14159 4 years ago |

I've found Notion (or Google Docs, etc) to be a clearer source-of-truth and place-of-collaboration than Slack, which I've found to be better to debug ongoing issues or as a place to point people to the right notion doc.

Making sure someone gets heard in Slack isn't a top priority for me. It's surfacing information and solutions as fast as possible when they come up. Solidifying them in Notion is something a subject matter expert can do outside of the time constraints of a real-time conversation then the rest of the team can surface those answers as needed and mark where they fall short with comments in or additions to the Notion doc.

pcmoney 4 years ago |

Slack is for synchronous shallow short form communication.

It is great for communicating around an event. Getting quick in-flow queries answered. Asking what people want to do for lunch.

It is not for substantial nuanced in depth communication. When used this way it quickly becomes a conveyor belt of distracting trash.

It is also not a knowledge repository or source of truth. Slack overflow is not a good practice.

Pro tip: have slack history clear after 60 days.

Better alternatives: - Shared Google Doc with comments for analyzing an issue - Meetings with a pre-read period and memo and clear purpose/outcome for the meeting - Pair programming - Live code review

TL;DR Dont use slack.

yesiamyourdad 4 years ago |

My personal opinion is that Slack is a terrible medium for long term info exchange, acronym notwithstanding. I work for a company where we have almost 2 public channels for every full time employee, and that's not counting the private channels, DMs, and so on.

I was on a ski lift last winter with a guy who ran a small company (~20 engineers) who banned Slack and I think he had a strong argument.

Reading through the comments, I see a number of antipatterns emerging from this thread. I'll enumerate some:

* Urgency etiquette: @channel, @here, or just plain message? How about @here with a few personal @ throw in, which is like the gratuitous CC: in email? This depends a lot on your org's topography. I do contract work for a global org, and @channel is almost never appropriate. It's kind of looking at alerts as an SRE: does EVERYONE need to know this?

* Search really is terrible: I know people say "just search Slack". Reminds me of a former colleague who joked about "Google Battleship" (referring to the guessing game of Battleship), where you hunt for the right combination of words. Some questions are just hard to answer via context-free text queries, and this leads to the next point

* Atrophy of other documentation like Wikis and READMEs. The big problem with Wikis is that they have to be gardened - they need dead pages removed, outdated info updated, etc. Slack also needs gardening. The 2 week ban is draconian, but I imagine that in this org, people start moving important information to permanent storage.

* Private channels are unsearchable, as are private conversations. I've personally banned my private conversations. People DM me about comments I've made on a PR, rather than responding in comments or a public channel. I always direct them back to a public comms channel. The idea of Slack is to make communications public and searchable, but people need to enforce that individually. I don't allow DMs except for social BS like lunch plans.

* On the flip side, information-free channels. Some of my channels at work are completely noise - basically all they are is alerts from PagerDuty, or automated build noise, or the #fyi channel for all employees. Anybody who cares about "slack zero" mutes these channels anyway.

* Somewhat related to the last point, the auto-responders. At its simplest, if you have an auto-responder keyed to a single word or phrase, that indicates a problem, not a need for an auto-responder.

* Final point is info fragmentation and overload. You don't know what channel to ask a question in, and you can't keep up with it all. I have a personal keyword filter, but basically in Slack, I've created a personal info silo simply to be able to have a chance to focus on my work.

wunderlust 4 years ago |

@everyone

jk don't :)

DIARRHEA_xd 4 years ago |

Well I personally prepend @everyone to all my messages.

davzie 4 years ago | |

The trouble with this is that you will be missing some potentially valuable input; I recommend @all instead

xisukar 4 years ago | |

>Well I personally prepend @everyone to all my messages.

^ Arrest this man or woman!

nittanymount 4 years ago | |

my thinking, better to think twice before using @everyone, if it really needed to notify everyone (with the sound/popup) for this specific message.

teammates still see it without @everyone, do they really need to be disturbed for this message?

dopidopHN 4 years ago | | |

I suspect it was ironic ? Unclear