Ask HN: How do you ensure everyone on the team is heard on Slack?
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
111 comments
[ 4.4 ms ] story [ 171 ms ] threadYour proposal is a cool idea, and there are even self-hostable FOSS clones available.
See: https://meta.stackexchange.com/questions/2267/are-there-any-...
It turns out there’s an official integration that looks pretty comprehensive: https://stackoverflow.co/teams/integrations/slack/
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.
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.
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.
“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.
> “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?
Self-answered-FAQs
We typically call that "Documentation!" :-)
teammates still see it without @everyone, do they really need to be disturbed for this message?
^ Arrest this man or woman!
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.
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.
But they want to read a long e-mail thread?
Other tools can work as well like shared documents if the content/context is several pages or something.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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!"?
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"?
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.
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.
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.
It shouldn't replace tools like BookStack, but nuking it every 2 weeks feels like its losing genuine knowledge too
- 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?
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.
"stay on after the meeting and we'll talk about that"
or
"why don't you and x meet up later to discuss y"
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.
jk don't :)
In my team we do these on Monday/Thursday. If something conflicts, we just bump that checkin forward a day to Tuesday or Friday.
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.
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.
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.
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.
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.
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.
Instead, what's done is done, and it can lead to rapid degradation in communal rooms that have a lot of newcomers.
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'.
I disagree. Email is a terrible medium for collaborative editing/creation of a document (whether source code or human language).
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.
Similarly for asynchronous, historical record, threading, and inclusion.
You can add emoji to email as easily.
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.
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".
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.
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.