TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

92 点作者 _rzt9将近 3 年前
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&#x2F;in-depth check in.<p>I&#x27;ve been thinking about this a lot lately, and while daily meetings are nice, once you start to go beyond the bounds of &quot;yesterday I was working on ... and today I&#x27;m working toward ... could you provide a bit more help and&#x2F;or context on &lt;such and such&gt; ...&quot; the discussion balloons beyond a reasonable check-in limit with regard to time.<p>The properties of communication in remote work seem very hard to crack and I&#x27;d like to know if this problem is something your team has succeeded at – and, If so, how?<p>Edit: To be sure, I&#x27;m not talking about alerts&#x2F;system critical stuff. Additionally, I work in a small company, so maybe there are safeguards for this kind of predicament in larger orgs.<p>Thanks

35 条评论

bluehatbrit将近 3 年前
In previous teams I&#x27;ve worked hard to make sure slack isn&#x27;t the place for decisions to be made that are any greater than where to go for lunch. Same with bigger questions as well.<p>Slack is great for small insignificant chatter but developers need long uninterrupted periods of quiet to work. That doesn&#x27;t go well with an IM system that people expect to get big questions answered or key decisions made with.<p>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.<p>If someone external to my team wants to ask a question thats of any significance I&#x27;ll try to jump in and set their expectations. If it requires input from multiple people on my team then it&#x27;s best done over something slower like email &#x2F; collaborative docs, or as a last resort a meeting. If it&#x27;s internal to the team I&#x27;ll try and push it out to a mechanism that allows people to set time aside to consider the topic and respond.<p>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&#x27;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.<p>As you say, emergencies are different. Those are raised via alerting of some sort and interrupt people in a different method.
评论 #31970439 未加载
评论 #31972221 未加载
评论 #31974326 未加载
评论 #31974295 未加载
评论 #31973480 未加载
flakiness将近 3 年前
A subset of tech community in Japan has established a strange form of &quot;broadcast&quot; yourself in Slack, which is called &quot;minute-updates&quot; 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&#x27;s a channel for monologues out loud.<p>This clearly doesn&#x27;t scale for large orgs, but any communication method doesn&#x27;t anyway. One clear advantage of this is the low entry barrier: You don&#x27;t have to worry about interrupting and shutting down the ongoing conversion unintentionally, or spamming others.<p>Although this barrier lowering seems to be helping a lot in the highly peer-aware environments like Japan. I&#x27;m not sure how effective this is in a different context. So take this as a grain of salt.
评论 #32011043 未加载
评论 #31972986 未加载
评论 #31973449 未加载
0xbadcafebee将近 3 年前
Email is the best method of communication for anything complex. It&#x27;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.<p>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>I want everything NOW.</i> So Slack was created to poorly reinvent e-mail, but with instant gratification and emoji buttons.<p>I really love open source mailing lists. Every once in a while I&#x27;ll go skim over some I&#x27;m subscribed to and see what&#x27;s been going on. If I ask a question I usually get an answer within a day or two. The archives provide searchable record&#x2F;context for everything. I can even review patches and comments on patches, and see the history of all the e-mails before&#x2F;after it, whereas GitHub PRs are little islands unto themselves. Best of all, it&#x27;s all stored offline, and I can use any client I want.<p>It&#x27;s sad that technological progress means &#x27;things got more advanced&#x27;, and not &#x27;things got better&#x27;.
评论 #31972115 未加载
评论 #31972377 未加载
评论 #31974014 未加载
评论 #31973522 未加载
评论 #31973361 未加载
评论 #31974481 未加载
评论 #31973704 未加载
safetythirds将近 3 年前
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.<p>Instead, we have a company-wide BookStack instance that&#x27;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.<p>Usually, helping someone else out with the information they need involves pointing them to the right page where it&#x27;s already documented, or writing something up for them. Perhaps also talking them through it one-on-one if it&#x27;s complex.<p>This works for us because we&#x27;re required to provide reports to our customers every few weeks, in regards to what we&#x27;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.<p>This is a small company of around 40 employees. Not sure how well this will scale as we grow, but it&#x27;s been working well so far.
评论 #31973208 未加载
评论 #31970494 未加载
评论 #31971155 未加载
gibrown将近 3 年前
In my experience (11 years fully remote&#x2F;distributed growing from 90 to 2000 employees) my first impression is it sounds like you’re doing too much synchronous. Async is so efficient.<p>My team’s current systems: - Most deep discussions happen on blog posts including project status. We use (and built) <a href="https:&#x2F;&#x2F;wordpress.com&#x2F;p2&#x2F;" rel="nofollow">https:&#x2F;&#x2F;wordpress.com&#x2F;p2&#x2F;</a>. 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&#x2F;today. The most important thing is how people feel though. “Pick a red&#x2F;yellow&#x2F;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&#x2F;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.<p>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.<p><a href="https:&#x2F;&#x2F;ma.tt&#x2F;2020&#x2F;04&#x2F;five-levels-of-autonomy&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ma.tt&#x2F;2020&#x2F;04&#x2F;five-levels-of-autonomy&#x2F;</a> Is a good read too.<p>Iterating is very important though (which you are doing yay!), I’ve tried lots of different cadences&#x2F;systems but the above is the core of what my team has used for 3-4 years now and I’m pretty happy with it. I still try to make sure we reconsider if we want to experiment with something new every few months. Partly why I wrote this long comment is I’m thinking if there is anything to tweak.
binarymax将近 3 年前
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.
评论 #31970132 未加载
评论 #31970372 未加载
评论 #31970142 未加载
samora将近 3 年前
You need to establish some rules to make Slack work for most teams without overload.<p>1) People should avoid DMing each other when talking about work, use threads instead (see 3) to discuss topics in team channels (see 2).<p>2) Keep channels to a minimum. Every person shouldn&#x27;t have more than 2&#x2F;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&#x27;t want engineering work banter to distract those working on other stuff.<p>3) Use threads religiously! This is super important as it helps declutter the Slack experience and keep conversations heavily organized.
评论 #31971592 未加载
评论 #31971121 未加载
bennathanson将近 3 年前
What has worked for my (mostly) remote team is a mix of different tools for different communication needs:<p>- Daily standups on Zoom. Each person&#x27;s standup should be short and to the point. Don&#x27;t be afraid to tell people they&#x27;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.<p>- Weekly code syncs to go more in-depth as a team, make sure we&#x27;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.<p>- Weekly office hours held by senior+ level engineers to give more junior engineers an opening to ask questions.<p>- Weekly architecture meetings to formally discuss sweeping technical changes that impact multiple teams in a meaningful way, e.g. migrating to a language<p>For me it has been less about &quot;email bad&quot; or &quot;Slack good&quot; and more about asking questions - &quot;What is the right medium for this type of conversation and our culture as a team?&quot; or &quot;What is the right tool for the job?&quot;. It&#x27;s also an answer that evolves as the team&#x2F;company grows; you have to reassess every few months and make adjustments.<p>There&#x27;s also a question of culture and setting expectations that might be at play here.<p>- For the people answering questions, are they passionate about teaching? Do they feel incentivized&#x2F;recognized for being active in answering questions? Do they have the bandwidth to help others?<p>- Are those asking the questions asking <i>good</i> questions? Are they respecting the time and attention of those trying to help them?
评论 #31970351 未加载
dahart将近 3 年前
&gt; The properties of communication in remote work seem very hard to crack<p>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.<p>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&#x2F;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.<p>It’s great that you’re thinking about it a lot, because most people have reflexive opinions without a lot of careful thought. Communication is a hard problem, and it’s worth internalizing this and realizing that there aren’t easy answers to this nor single tools that will magically solve it.
theptip将近 3 年前
One important practice to keep daily standup snappy is to decouple the high level context (“I am blocked on X” =&gt; “you should talk to codeowners Alice and Bob”) from the actual solve for the problem, even if there is a quick answer.<p>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.<p>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.<p>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.<p>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&#x2F;future blockers&#x2F;impediments.<p>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.
评论 #31975532 未加载
onion2k将近 3 年前
<i>the answers team members provide seldom respect the depth, severity, or nature of the queries which are posted</i><p>This is a hiring problem. In short, the people you work with lack the ability to understand why it&#x27;s important to respect their colleagues and to write better answers. Teach them to communicate better.<p>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 &quot;Could you expand on this?&quot; where they aren&#x27;t.<p>If that fails, tell people to schedule more meetings. Face to face and video calls solve the lack of depth incredibly easily. You can&#x27;t give a shallow answer if someone is literally asking you for a deeper one.<p>And if people push back on that, the answer is to replace them. People who aren&#x27;t good communicators ruin team dynamics quickly. Hire for comms.<p>In a business, building good software is 50% about writing simple, understandable code and 50% communicating with other people so they can write simple, understandable code too.
oneplane将近 3 年前
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.<p>The real replacement that slack is, is for crappy emails and crappy phone calls and crappy meetings about nothing. Not a replacement for communication as a whole.
mrkurt将近 3 年前
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.<p>Forum posts will frequently include a link to a Slack discussion, but I don&#x27;t think anyone really clicks to read the chat.<p>This is not exactly what you asked, but peoples&#x27; managers are on the hook for helping them be heard. One-on-ones frequently trigger forum posts. Good one-on-ones are useful for this kind of thing.
karaterobot将近 3 年前
In my view the question asker can help themselves by asking better questions, if they aren&#x27;t already. Sometimes people ask vague questions, and it&#x27;s hard to respond to them, even if you want to. This is something we&#x27;re working on in my team: ask specifically for what you want, tell the other person that it&#x27;s important, and also, crucially, tell them when you need the response by.<p>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.<p>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&#x27;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&#x27;s better for everybody if they can expect to get help and are expected to give it.
alistairSH将近 3 年前
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.<p>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.<p>Outside the team, Slack is ok for starting conversations, but generally anything important or hard needs a live meeting, even if it’s only for a few minutes. We have a few channels that are exceptions, where the team that “owns” the channel is better than average at making well reasoned responses. But, that’s the exception and those teams are always a pleasure to work with. And this is in a reasonably well functioning mid-sized company. I hate to think what it’s like at a large company.
bravetraveler将近 3 年前
We do really well communicating in Slack&#x2F;text. Threads and a small team are really it, for us<p>A thread isn&#x27;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<p>Anything too in the finer details can be taken care of elsewhere, then the findings reported back<p>I wish my team met less often in a structured way. I don&#x27;t really benefit from giving status updates or hearing theirs.<p>I&#x27;m not some lone wrecking ball, I just have responsibilities for service<i>s</i> I designed before joining this team. We also don&#x27;t really have much overlap. Maybe paired off on something<p>I feel that our more involved conference call time would be better spent on specific implementation problems or similar - with a smaller audience
spyspy将近 3 年前
Just spitballing...<p>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&#x27;s free, persistent, searchable (ish), supports threads, images&#x2F;links&#x2F;markdown, and even nice mobile app support.
评论 #31970602 未加载
presentation将近 3 年前
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&#x27;ll get on a call. Either way, it&#x27;s a requirement that once the dust has settled, someone summarizes the discussion into a document in a shared Notion page for these discussions, links it as a reply to the thread (also posted to the channel), with clear action items that have arisen from it. Works alright for us.
hinkley将近 3 年前
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.<p>Probably because as part of spinning back up I have to summarize for myself where I think I was, and the summary frequently contains the hint I missed. It’s not quite rubber ducking without the duck, and with more time to help others.
twblalock将近 3 年前
If you are discussing something about Slack that is deep in any way, ask people to schedule a meeting instead. Slack is not the right tool for that job.
e9将近 3 年前
To solve this problem for smaller teams I like to use private StackOverflow for teams: <a href="https:&#x2F;&#x2F;stackoverflow.co&#x2F;teams&#x2F;" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.co&#x2F;teams&#x2F;</a> The added benefit is that history of issues encountered is preserved for future employees.
SkyMarshal将近 3 年前
Why are people still using Slack when other chat systems have solved this problem? Whether it’s Zulip’s topic streams, or the ability to tag a part of a thread as “Important”, “Need Decision”, etc. There are solutions to this problem. Does Slack not have something like this yet?
dylanhassinger将近 3 年前
I am a fan of having twice or thrice-weekly in-person checkins, led by a tech lead<p>In my team we do these on Monday&#x2F;Thursday. If something conflicts, we just bump that checkin forward a day to Tuesday or Friday.
tptacek将近 3 年前
We use a Discourse message board (Discourse for Teams) in addition to Slack. Slack is real-time and somewhat ephemeral. Important stuff is message board posts. It works quite well.
websitescenes将近 3 年前
I suggest you check slack in regular intervals so that you can contribute to the conversations. I do this and often revive dead threads that seemingly had an answer.
motohagiography将近 3 年前
I like slack, but as a medium, it&#x27;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&#x27;d on a drill-down between parties and email threads can quickly become a power struggle if the seniormost person doesn&#x27;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.<p>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 &quot;good chat.&quot; I&#x27;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&#x27;s a mean reversion where the medium itself becomes the message. When it&#x27;s good, it&#x27;s very efficient, but when it&#x27;s obligatory, it creates simmering rot in teams. It&#x27;s amazing to have ideas stand on their own - but when it doesn&#x27;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.<p>We have to assume good intentions, but in an org, that&#x27;s mostly performative, and the necessary altruism to sustain that doesn&#x27;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&#x27;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&#x27;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.<p>When it goes to shit is when we&#x27;re forced to pretend to trust each other, and then you get institutional bureaucracy politics, which async and text just amplify. I&#x27;m in a place where it seems to do it right, but I&#x27;ve been in places where they don&#x27;t. Slack&#x27;s message stats in the admin panel are a pretty good proxy metric for organizational trust, where if you see lower engagement, I&#x27;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.<p>If you gave me a company&#x27;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&#x27;s a tangent. Where I have seen Slack succeed is where the team has a basis for trust, and where I have seen it fail and become radioactive is where that trust was undermined because of a power vacuum and people defecting to where they think will prevail. Those are hard conversations becuase a lot of managers and employees personalize and moralize their position as being the effect of their identity, where they have internalized the status without a lot of examination of the practised skills it takes to do it well. Slack and email are neutral, but they are also extremely sensitive to deviations from alignment, where interpersonal conflict happens within the vast imaginations of the participants, and not in the real moment of dealing with another person.
tmaly将近 3 年前
I don&#x27;t know about Slack, but I have a weekly teams meeting where I go around and give everyone a chance to say something.
brailsafe将近 3 年前
&gt; daily meetings are nice<p>Daily meetings suck. Do them less frequently and allow for more time to talk about things.
politician将近 3 年前
Try Slack Huddles when the number of replies to a thread threatens to exceed 12.
readme将近 3 年前
just suggest that the person who exceeds their reasonable amount of time meets offline with whoever they&#x27;re discussing with<p>&quot;stay on after the meeting and we&#x27;ll talk about that&quot;<p>or<p>&quot;why don&#x27;t you and x meet up later to discuss y&quot;
3pt14159将近 3 年前
I&#x27;ve found Notion (or Google Docs, etc) to be a clearer source-of-truth and place-of-collaboration than Slack, which I&#x27;ve found to be better to debug ongoing issues or as a place to point people to the right notion doc.<p>Making sure someone gets heard in Slack isn&#x27;t a top priority for me. It&#x27;s surfacing information and solutions as fast as possible when they come up. Solidifying them in Notion is something a subject matter expert can do outside of the time constraints of a real-time conversation then the rest of the team can surface those answers as needed and mark where they fall short with comments in or additions to the Notion doc.
pcmoney将近 3 年前
Slack is for synchronous shallow short form communication.<p>It is great for communicating around an event. Getting quick in-flow queries answered. Asking what people want to do for lunch.<p>It is not for substantial nuanced in depth communication. When used this way it quickly becomes a conveyor belt of distracting trash.<p>It is also not a knowledge repository or source of truth. Slack overflow is not a good practice.<p>Pro tip: have slack history clear after 60 days.<p>Better alternatives: - Shared Google Doc with comments for analyzing an issue - Meetings with a pre-read period and memo and clear purpose&#x2F;outcome for the meeting - Pair programming - Live code review<p>TL;DR Dont use slack.
yesiamyourdad将近 3 年前
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&#x27;s not counting the private channels, DMs, and so on.<p>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.<p>Reading through the comments, I see a number of antipatterns emerging from this thread. I&#x27;ll enumerate some:<p>* 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&#x27;s topography. I do contract work for a global org, and @channel is almost never appropriate. It&#x27;s kind of looking at alerts as an SRE: does EVERYONE need to know this?<p>* Search really is terrible: I know people say &quot;just search Slack&quot;. Reminds me of a former colleague who joked about &quot;Google Battleship&quot; (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<p>* 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.<p>* Private channels are unsearchable, as are private conversations. I&#x27;ve personally banned my private conversations. People DM me about comments I&#x27;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&#x27;t allow DMs except for social BS like lunch plans.<p>* 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 &quot;slack zero&quot; mutes these channels anyway.<p>* 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.<p>* Final point is info fragmentation and overload. You don&#x27;t know what channel to ask a question in, and you can&#x27;t keep up with it all. I have a personal keyword filter, but basically in Slack, I&#x27;ve created a personal info silo simply to be able to have a chance to focus on my work.
wunderlust将近 3 年前
@everyone<p>jk don&#x27;t :)
DIARRHEA_xd将近 3 年前
Well I personally prepend @everyone to all my messages.
评论 #31970667 未加载
评论 #31970469 未加载
评论 #31970253 未加载