[HN Gopher] Ask HN: How do you ensure everyone on the team is he...
___________________________________________________________________
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
Author : adam_ellsworth
Score : 49 points
Date : 2022-07-01 06:17 UTC (2 days ago)
| twblalock wrote:
| 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.
| samora wrote:
| 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 wrote:
| 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 wrote:
| Or just switch to Zulip where everything is threaded...
| bennathanson wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Slack huddles have poor ergonomics what with their use of
| global keyboard shortcuts. I avoid them whenever possible.
| CharlesW wrote:
| Have you tried async standups via something like Geekbot?
| https://geekbot.com/
| krsrhe wrote:
| If it's async, it's not a standup, it's something
| different, and far far better.
| CharlesW wrote:
| What do you call that? "A-sync-up"?
| heretogetout wrote:
| 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.
| gibrown wrote:
| 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.
| spyspy wrote:
| 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 wrote:
| Too easy to get distracted.
| oneplane wrote:
| Also just a slower version of Slack so it doesn't really
| solve much.
| 0xbadcafebee wrote:
| 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'.
| binarymax wrote:
| 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.
| [deleted]
| metadat wrote:
| 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-...
| chrsig wrote:
| 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.
| samstave wrote:
| S.A.Q.s
|
| Self-answered-FAQs
|
| We typically call that "Documentation!" :-)
| josephcsible wrote:
| 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.
| simonw wrote:
| 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.
| chrsig wrote:
| 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.
| Nowado wrote:
| Again, what's the issue with that? How is organization
| suffering from it?
| ratww wrote:
| 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.
| chrsig wrote:
| 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.
| junon wrote:
| Which is exactly what SO encourages one to do.
| [deleted]
| DIARRHEA_xd wrote:
| Well I personally prepend @everyone to all my messages.
| davzie wrote:
| The trouble with this is that you will be missing some
| potentially valuable input; I recommend @all instead
| xisukar wrote:
| >Well I personally prepend @everyone to all my messages.
|
| ^ Arrest this man or woman!
| nittanymount wrote:
| 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 wrote:
| I suspect it was ironic ? Unclear
| tptacek wrote:
| 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.
| mrkurt wrote:
| 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.
| bluehatbrit wrote:
| 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 wrote:
| > 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.
| readme wrote:
| 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"
| karaterobot wrote:
| 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.
| 3pt14159 wrote:
| 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.
| theptip wrote:
| 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.
| dahart wrote:
| > 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.
| wunderlust wrote:
| @everyone
|
| jk don't :)
| pcmoney wrote:
| 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.
| oneplane wrote:
| 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.
| dylanhassinger wrote:
| 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.
| tmaly wrote:
| 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.
| [deleted]
| safetythirds wrote:
| 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.
| KennyBlanken wrote:
| > 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.
| jbay808 wrote:
| > 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!"?
| xboxnolifes wrote:
| 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.
| jbay808 wrote:
| 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"?
| beAbU wrote:
| 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.
| michaelt wrote:
| By not having a culture where people need historical records
| to cover their ass.
| ithinkso wrote:
| 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
___________________________________________________________________
(page generated 2022-07-03 23:00 UTC)