Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you ensure everyone on the team is heard on Slack?
92 points by _rzt9 on July 3, 2022 | hide | past | favorite | 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




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.


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


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.


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


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.


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)


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.


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.


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.


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.


Limit message retention.


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.


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.


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.


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.


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!


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


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


Email is extremely bad for a whole lot of things though. Anything where the questioner doesn't know what they don't know. There can be a tendency to spend like a half hour composing an initial email in cases where the whole exchange would be resolved in under 5 minutes in real time, with better knowledge transfer. And the questioner can't really do it better, they don't know they're in the situation where the answer is going to info dump a whole lot of useful stuff that will completely change their perspective of what they were trying to do.


> best method of communication for anything complex

I disagree. Email is a terrible medium for collaborative editing/creation of a document (whether source code or human language).


> Email is the best method of communication for anything complex.

In my experience email is best when audience is less than 5 and have a tightly shared context. I've seen innocuous looking proposals getting out of hand just 'coz people jumped in to respond; multiple threads forming and so on. It gets nightmarish very fast.

I've found a combination of shared docs + meeting to arrive at consensus to work well. A small group of people propose a design/solution in a doc. Share it with wider stake holders get their first round of feedback, incorporate it in the doc and then have one or two in-person meeting(s) to get them all sign-off. Slack could be used to have short conversations but not ideal from what I've experienced.

This is with respect to a a for-profit organisation. Can't speak about open source as I don't have any experience collaborating there.


You're robbing yourself of understanding other people if you just paper over everyone's issues with email as being some sort of fear that prevents them from seeing the obvious superiority of email.

It's a red flag when you're attributing a negative quality to people as the reason why they use or even prefer something. The cure is simple: talk to people and ask them.


Have you ever been CCed into an email thread where 4 people already have been having conversations for days? It's a nightmare. "hello, please check 4 days worth of jibby jabba nonsense and let us include you in this topic with a vague question". And most often, the subject isn't even relevant anymore.


I know we all hate meetings, but this is a sign you need a meeting.


I don't miss email. One of the immediate benefits of Slack is someone can give a notice via Slack and the receiver can callback with an "acknowledged" or "noted".

The callback is very important IMO because things get lost in email all the time. And yet you don't want 5 people to reply "noted".


There is nothing inherently more long-from in email compared to Slack. Slack is not limiting the length of your text messages.

Similarly for asynchronous, historical record, threading, and inclusion.

You can add emoji to email as easily.


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.


Slack stands for Searchable Log of All Conversation and Knowledge - I'm not sure why people don't like to use it to look up information, especially disjointed information not formally recorded elsewhere?

It shouldn't replace tools like BookStack, but nuking it every 2 weeks feels like its losing genuine knowledge too


> automatically wiped of messages older than two weeks

How do you determine historical truth in a potential conflict scenario, where a manager says "why didn't anybody tell me we'd be running a test at the customer site?" and the engineer says "but I announced it two weeks ago and you even thumbs-upped the post!"?


The same way as 'I've told you that when we ate lunch last week, remember?'. The point is to make sure Slack is treated the same way as a conversation, not as a documentation and project history


Yeah, where I'm at most "important" stuff is at least in a doc somewhere separate from chat or email.


The commenter just said slack is not the source of truth in the org. If the post was important, the result should have been documented in the source of truth.


Sure, but the context is that the message wasn't something that the org permanently documents to refer back to, like... an API or a list of deliverables or something. It's just run-of-the-mill workplace interpersonal communications and announcements, like announcing that there's going to be an earthquake drill, or that you're going to be working from home the first week of August. Not documentation. Until a miscommunication occurs and you're suddenly digging for records to piece together how things went wrong.

What communications tool would people use for announcing an earthquake drill? And what does the messaging tool get used for?

Do you send an email to keep the paper trail (with the downsides of email, like that record only being searchable by the people it was sent to at the time)? Or does somebody update the company wiki with records like "2022-07-30: jbay808 absent today due to doctor's appointment"?


What would be used in the total absence of an IM tool?

How was this managed 10 years ago? Email?

How was this managed 50 years ago? Physical bulletin board?

What the GP is trying to drive at is that slack should be treated like a passing conversation, and nothing more. It cannot be relied upon as a persistent source of truth or a knowledge base.

We try to apply the same philosphy within my team.


By not having a culture where people need historical records to cover their ass.


1000% this. If you cant trust each other absolutely none of this matters.

If for some reason you need an auditable record of your chats thats fine but decisions should hopefully be documented elsewhere and linked into the thread/convo.


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

Or it's being wiped because your leadership team doesn't want anything shady uncovered in discovery or a warrant and "we do it to discourage anyone from using it as a knowledge store" is how it's being sold to everyone else.


But the shady shit can be put right into the other documentation systems OP mentioned. That’s not the reason.


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.


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.


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


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.


I’m in the process of identifying communication gaps in my org and possible tooling and process solutions. Stack Overflow for Teams is high on my list of tools to evaluate and it feels like a Slack integration would be important so your comment finally prompted me to look into it.

It turns out there’s an official integration that looks pretty comprehensive: https://stackoverflow.co/teams/integrations/slack/


Beautiful! I'll have to bring this up with my team. We just had a management expansion and I'm part of the process for changing the way we operate.


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.


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.


Yeah that sounds like a positive pattern to me: it means people are contributing to an internal persistent knowledge base. Sounds like it should be actively encouraged.


Perhaps it's a solution that does better at a large scale than at a smaller scale.

At a smaller company, it becomes much more evident that the contributions are being made more for self-promotion than for anyone's benefit. Either because you know the person making them and their personality, because the volume:quality is out of alignment, or because the person posting the question/answer wasn't actually having the problem and were just posting it for points.

Also the volume of organic questions is on the lower side, and could get easily drown out by what amounts to astroturfing. So in my experience, it never really gained adoption, and withered shortly after it's introduction.


Were their answers wrong, or were the questions completely unnecessary? How do you know it's "not for everyone's benefit"? I don't announce to the world when I consult the documentation. Are you measuring the reach of these answers or is it just a gut feeling?

I really fail to see how this is a negative thing. If anything, it's the people not doing it that caused the whole project to fail.


As I recall, largely unnecessary. I can't divine someone's intent, but I can surmise based on having worked with them for multiple years.

Measuring reach? certainly not. It was just setup as a confluence plugin by the corpit team and left as a free-for-all with no direction.

> I really fail to see how this is a negative thing

It discouraged engagement. You can argue until you're blue in the face if it should have or not.

If there's something to take away here, I imagine that it's not "internal stackoverflows are doomed to fail", and more "unstructured adoption of internal stackoverflows don't go as smoothly as one fantasizes"

Had we made some set of individuals as having been responsible for the adoption and moderation of it, it may have gone better.


Even if question seems unnecessary at the time, more often than not some junior dev will find it helpful once your company grows. It’s about preserving knowledge and no question is dumb at that point.


I don't question their premise, I believe that it happens. So remove clout, it's a feature to create network incentives for people who need an incentive.


That's right. Most people need incentive. That's how humans operate unfortunately and you have work around that to get anything done. That's why being good manager is hard. For example, if you make a competition to give some prize for most fixed bugs, they will get fixed. Yes some won't be fixed completely and you have to redo them but I guarantee you there will be more bugs fixed than if you don't have the incentive.


Yeah, sorry but I’m not buying. It all seems to me like projection, a lot of speculation and a bit of pent up anger for people getting reputation for doing documentation work.

“People doing a lot discourage people who don’t do anything” isn’t a very compelling narrative.

Really can’t see a problem here. I wonder what you’ll say when you find out those people are working for money.


shrug what you buy or don't is your problem. I don't really stand to gain anything by arguing my lived experience with you.

> “People doing a lot discourage people who don’t do anything” isn’t a very compelling narrative.

Who said the people being discouraged didn't do anything? It seems like you may be reading things that aren't there.

> Really can’t see a problem here.

ok? why are you posting then?

> I wonder what you’ll say when you find out those people are working for money.

pent up anger and projection of your own, perhaps?


I never met your co-workers so I have no axe to grind, nor am I accusing them of anything. But yeah neither of us has anything to gain here so let’s stop?


Again, what's the issue with that? How is organization suffering from it?


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


S.A.Q.s

Self-answered-FAQs

We typically call that "Documentation!" :-)


Which is exactly what SO encourages one to do.


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.


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.


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


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?


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)?


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.


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


Have you tried async standups via something like Geekbot? https://geekbot.com/


I haven't been in a position to proscribe process, I'm just a consumer. We have tried leaving messages in Slack but that process always ends in a matter of days from disinterest.


If it’s async, it’s not a standup, it’s something different, and far far better.


What do you call that? “A-sync-up”?


The lack of a detached floating window for huddles compared to Slack calls is a big regression in functionality for me.


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


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.


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 :)


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.


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.


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.


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.


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.


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


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.


Too easy to get distracted.


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


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.


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.


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.


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.


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?


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.


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.


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.


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.


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.


> daily meetings are nice

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


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


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"

or

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


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.


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.


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.


@everyone

jk don't :)


Well I personally prepend @everyone to all my messages.


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


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

^ Arrest this man or woman!


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?


I suspect it was ironic ? Unclear




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: