Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Can Slack-mania be cured with systemized discipline? (brandur.org)
142 points by ciprian_craciun on Feb 17, 2022 | hide | past | favorite | 199 comments



This doesn't really sound like a problem with Slack, but rather a personal or cultural problem with a lack of setting or respecting boundaries.

Slack has options to communicate:

- that you're away

- that you're on a call or in a meeting etc.

- to pause notifications for an hour or whatever

- to star the most relevant channels

- to mute less-relevant channels

- to leave irrelevant channels

- to sideline conversations into threads

All of that is just Slack itself, in addition to things like putting meetings and vacations and other appointments on the shared team calendar. Some people where I work book meetings with themselves to guarantee focused distraction-free time. That's completely valid.

Part of being a professional is setting boundaries, communicating them, setting the expectations that the rest of your team will do the same, and of course, respecting those boundaries.

That includes not calling or pestering people that are on vacation. Which also requires that you don't "check in" while you're on vacation, because if you do, then other people will feel like they're expected to as well.

Set and communicate your boundaries, and in a team that respects each other, it shouldn't be a problem.


"You just need discipline" is a common phrase, which usually masks the root problem. Why does something need continuous effort? Is it the best place to put our energies? Are there any other ways of solving the problem?

See "Willpower: Rediscovering the Greatest Human Strength" (https://www.amazon.com/Willpower-Rediscovering-Greatest-Huma...) on willpower as a resource that can be drained, often pointlessly. Having a constant temptation is one of the core cases (e.g. candies on your sight).

Instead of helping us, a flawed tool forces us to work against the current. For the Sauron's ring, this constant test of the hobbit's strength of will was unavoidable. For Slack... it is much easier to throw it into a volcano.


All the options you mention are designed in order to reduce the main problem: that it requires synchronous communication. That is, after you "come back" from a meeting or being away, you can't just work in peace and when you want just send a reply: no, you are expected by design to engage in a conversation.

I'm not interested in engaging in a conversation at all unless there is something really extremely important that requires my undivided attention for a specific period of time. But when companies use Slack, they integrate it as a part of the culture. You are expected to be ready to answer. Sure, you can pause notifications - but you know people are waiting. Are you a good team member if people are asking questions and you are not answering?

For contrast, I found out that many people I worked with are too lazy to write an email and will prefer to solve the problem themselves rather than write to me if I don't answer soon enough. Which shows another interesting aspect of Slack-type culture.


I don't understand the attitude where it's lazy not to write an email but it's an unreasonable chore to respond to a question on Slack? In mind Slack is preferable to email for many things because the issues are resolved in public and I can later look back on what questions have been asked etc.


For the simple reason that in my opinion it's never "answering a simple question" but more often than not having a chat, with multiple messages and the expectation of responding quickly. The worst offenders are the ones who don't even ask a question but instead write "Hello?... Dude?... Are you there?..." Just state what you want and this will allow me to answer your question in a more efficient way.


I just choose to no to respond until they come to state what they want. Some are offended but otherwise I'm stuck forever.

Teams has it solved much better with a visible "message read" indicator that can be somewhat managed on the reader side, i.e. if you only see the notification it does not count as viewing.


However, Slack doesn't allow you to a) stay alertable to a subset of the company (e.g. people you are working heads down with on a project) while b) ignoring everyone else in the company. Even if you stick those people in a common channel and mute the rest of the channels you are in, people can still jeopardize your focus with a single at-mention or DM. Just anyone can hijack your sidebar.

Slack doesn't respect something as simple and fundamental as the focus of a small team within a larger org. But if they did that, they wouldn't sell as many subscriptions, because it would be less addictive, I guess?


This isn’t a slack thing, it’s a humans thing. Whether it’s a telephone, a marked urgent email, am @mention, or whatever. If someone wants to get your attention, that’s not a technology problem.


You forgot the most important option of all: closing the window.

Unless your occupation precludes constant communication (like emergency services or such), then the expectation should be that you are generally contactable, not constantly interruptible.

And if you can't close Slack without fear of repercussions then the problem lies with your company, not Slack.


I'm tired of constant chatting.

Slack encourages quick, stream-of-consciousness, short responses. Plus, it's hard to find past discussion, and it's hard to jump in after being gone for a few days (or, even a few hours).

Threads are absolutely the answer. But, the defaults matter - Slack isn't encouraging threaded, long-form messages. Instead, it makes all messages feel urgent - and it makes the cost of sending a message way too cheap.

I'm on a mission to bring back forums, where threading is the default. Inspired by YC's Bookface software, I'm working on a project to make forums as slick as Slack or Notion [1]. I think that long-form discussions and slow notifications are the key to bringing sanity back to discussions. And, I think the key is one amazing email summary per day - and few (if any) other notifications.

If you're interested in this problem - please reach out!

[1] https://booklet.group


My friend works at a company that -- on orders from legal -- has set a 5-day "disappearing messages" policy for all of the corp Slack. Unfortunately nearly all technical discussions happen on Slack. He tells me that it's not unusual for messages to start disappearing before the issue being worked on has even been resolved, and everyone has to re-ask the same questions and re-post the answers at that point, and sometimes things slip through the cracks. Then there's no way for people joining the company to get answers to already-asked-and-answered questions, and they end up spamming everyone on various channels with frequently-asked questions that often go ignored because people are tired of re-posting the same answers over and over again.


This seems like a very simple problem to solve - the issue owner should move important discussions to somewhere that isn't Slack. Writing a summary (or just cut and paste from the Slack messages) into a Jira or Github issue comment isn't much effort, and reading a summary of a problem is a lot easier for new people.

This actually highlights a problem of Slack. Reading an old Slack conversation is massively inefficient, especially if people have chimed in with irrevelevant stuff. Taking what you learn from a Slack conversation and using it to update proper docs or an issue is far better for anyone who isn't part of that conversation at the time.


The problem here isn’t Slack. Clearly the participants prefer discussing things like this in Slack over doing it in issues or Jira or whatever (which I understand, it’s a much nicer medium for discussion, IMHO), otherwise they would already be doing that. Your suggestion is essentially “just subvert the IT/legal policies by discussing it elsewhere, in a less efficient way”.

Clearly the problem here is the policy.


> move important discussions to somewhere that isn't Slack

At first I read this as having the discussion on a different medium in the first place, which seems a bit extreme. But from the rest of your comment I think mean just copy the discussion rather than move it, by copying and pasting (or manually re-summarising) elsewhere. I definitely agree with that. As you say at the end, that's a good idea even if Slack messages aren't auto-destroyed. (But there are definitely cases where it seems like you'll never need some scrap of information again and then it turns out you do.)


> Then there's no way for people joining the company to get answers to already-asked-and-answered questions, and they end up spamming everyone on various channels with frequently-asked questions that often go ignored because people are tired of re-posting the same answers over and over again.

In my office, Slack messages that live forever don't stop people from asking questions that have already been answered. The search tool is an afterthought.


I think the search tool could have been broken on purpose. It was somewhat-working in the previous, less "smart", version.


I'm struggle to understand a situation where that would ever be justifiable.

If they have a good reason for deleting messages, that's bad. If their legal team is overzealous and that power is unchecked, that's also bad.


A situation where the corporation is engaged in embarrassing or illegal shit and they're using Slack so they can do all the above-board, non-embarassing stuff via email that would show up in discovery.

5 day retention is so wildly impractical, it's a tacit admission the corp is up to something. Gives legal time to drag anything out in court until it's all gone. By the time the other party learns they have the 5-day retention, it's too late.


>By the time the other party learns they have the 5-day retention, it's too late.

Anyone hoping to use this trick to pull off the perfect caper will be dismayed to discover that not only is the other party allowed to talk to your employees, human testimony is admissible.

The idea of trying to make the past go away after five days, by deleting the digital records, reminds me of https://xkcd.com/1494/.

I'd also like to point out that this thread - where we're discussing the pros and cons of a technique for getting rid of inconvenient records, is itself the kind of awkward talk that, if found in a Slack channel during discovery, would turn in to something else entirely in the hands of some other company's lawyers. That sheds an interesting light on these retention policies.


If it wasn't for HN, I don't think that XKCD would have been anything more to me than a joke about programmers enjoying coming up with "cool hacks". But in the comments here I far too often find people trying to come up with legal loopholes that assume the system is perfectly rigid.


I was at a similar company. It's a bad sign when companies prioritize hiding errors over enabling success.


Has legal decreed you can't have a wiki as well?


I would guess that since wiki is less of an impulsive stream-of-consciousness type of a medium and more of a "sit down and write things in an organized manner after thinking things through" type, people are much less likely to put something that could create a problem for legal there (as opposed to Slack).

Not sure how factually true this is, but that rationale makes perfect sense in my head for why legal would make that rule for Slack/messaging while being totally cool with persistent wikis.


The sign up flow is really not great. Pick one and stick with it, but having to do “Phone Number” click “Insert verification code” click “Email” click, “Enter verification code” click. Either defer email verification, or get rid of phones altogether. It’s a forum, I’m not expecting replies in texts hopefully.


I closed the tab as soon as it asked for a phone number. Slack doesn't need it, neither does this thing.


I went to try out this service and the sign up process feels pretty invasive: a phone number, a code, my email, a code, and then "pick a username" - with no indication of what sort of visibility it's going to have or how far and wide on the service it's going to go.

I'd prefer to fill out a reCaptcha.


Good feedback - thanks!


I have tried Zulip but I think Twist has better UX & UI.

https://twist.com/slack-alternative

Supported by Doist which also supports Todoist which I am using


I've used Twist. It's a good piece of software, but I think it's too work-focused.

Consumerization of Enterprise is real - people don't want work to feel like work. Even Slack is more of a social tool than a work tool [1]. So, I think that the key to building a great work-focused tool is to start on non-work use cases - such as social groups.

Looking at Twist - I don't think it emphasizes usability, users in multiple workspaces, quality notifications, easy onboarding, and group discoverability. Take a look at the nav - it's built for hundreds of people, but groups will start with far fewer than that, and churn before they grow. Plus, it's entirely a logged-in experience - how many beloved forums are logged-in-only?

Twist is a good tool for certain uses - but I'm going for something more generalizeable.

[1] https://www.newyorker.com/culture/cultural-comment/slack-is-...


> So, I think that the key to building a great work-focused tool is to start on non-work use cases - such as social groups.

I've been thinking about this as I build a slack-meets-twitter like chat platform for public discourse (https://sqwok.im) and have had a few ppl ask if they could use it for a work communication tool.

It isn't my primary vision but it is something I've been thinking about and def open to hearing if other people would be interested in that.

I'll have to check out twist, had never heard of it!


No problem!

Please suggest more solutions.

We can always use more choices.

I am just mentioning what works for me (for now).


I never bother reading slack backlogs. I use slack to get quick answers to questions and then for any kind of design decisions, they go in to a diagram or wiki page which will be discussed in the next meeting.


Quite, slack is the equivalent of an office conversation, you can join in or ignore it. If someone wants you specifically they can @ you, and you can briefly glance at the context over the last few lines. Usually at that point you'll jump into a huddle / call, maybe you'll have to go back over it, but it only takes a few seconds to get the gist of what's being talked about, far easier than getting the gist of an office meeting that you've just been pulled into.

I don't see much point in having more than a few kilobytes of text in the scrollback. If it's persistent, put it in jira.


> jump into a huddle / call

... and first explain that they should use huddle, that works everywhere, instead of call, which is chrome-only. Great UX /s.


Slack is like twitter, if you are scrolling back through the feed bad things are happening.

Have the conversation and put the relevant stuff into the ticket / bug / wiki. If there are FAQ, time to write an FAQ!


If there is no discovery of things I wrote I don't care to write. Why should I write in slack if I have to write it again elsewhere?


Zulip solves the problem you mention extremely well.


I hadn't seen this - I'll check it out. Thanks!

Self-hosted software has its benefits. But, it's inaccessible to a lot of groups. So, I'm intentionally building more of a managed product. Controlling the deployment end-to-end will allow setting up new features more easily such as inbound email parsing.


Agreed, I guess that's why Zulip has a managed version as well.


The name is not great. The photo on first page is bad. And I couldn't find a demo at all. I was curious because forums where my go-place for online discussions growing up.


All valid feedback - and things I'll address. Thanks!


I’m interested in your idea, bringing what we’ve mastered in chat to the forum, but I don’t want to give my phone number or spin up a forum just to see. Is there an example forum?


I've been posting updates here, where you can see a demo: https://bookletupdates.substack.com

I'm working on "public" groups, so that I can link directly to a meta group about the project from the homepage. It should be live early next week!

--

I'm using phone number as primary login for these reasons:

1. I want passwordless login

2. Passwordless login with email is confusing because most people have multiple emails. But, most people have only one phone number.

3. I want to support per-group email preferences easily (i.e., multi-email)

4. iOS auto-fill makes it trivial to sign in

5. Phone number verification hopefully provides enough spam control that I can avoid deploying tools like Recaptcha - which I think are more invasive to privacy. (I'm aiming to be 100% Google-free and Facebook-free)


Let me share with you, this one quick, easy trick on how to lose 90% of sign ups.


Unfortunately, the data reflects this. I'll reevaluate phone-based login!


YMMV, but I'm absolutely not giving my phone number to a service of dubious providence because my employer told me to. I'd suggest federated login ASAP.


I personally find giving out my phone number as being several orders of magnitude more invasive to my privacy than filling out a simple captcha.


Thanks for the feedback!


It sounds like what should be brought back is NNTP or mailing list.


I think of Booklet as a better mailing list


That requires a web browser to use? No thanks.


I plan to build email bindings, too. But, I plan to start on web.


Landing page isn't particularly appetizing with "SATAN'S COFFEE" in big block letters.

Is that sentimental to you?


Yes, the homepage is a placeholder. Planning to update it in the next couple of weeks.

Satan's Coffee is a great little spot in Barcelona. The inspiration was that Booklet should feel like a fika [1] where once a day you sit down and participate in some thoughtful conversations.

I spent a couple of years as a digital nomad, and have fond memories of some cafes such as Satan's Coffee!

[1] https://en.wikipedia.org/wiki/Coffee_culture#Sweden


No wifi, no decaf, no bullshit.


> For the next five years I operated in “Slack culture”, the communication paradigm that I suspect is in use by many companies these days. Email inboxes were more or less reserved for broadcasts from exec and HR along with JIRA spam. Everything else happens on Slack.

This is the real problem, IMO.

Slack shouldn't be replacing e-mail or meetings or phone calls. It's great for impromptu discussions with a lot of back-and-forth, but once it becomes a serious conversation with multiple parties you need to escalate to a call or meeting or e-mail. Casual, asynchronous chat is great for low-importance conversations that aren't time sensitive. It's terrible for coordinating and making important decisions in a timely manner, though. Don't be afraid to schedule a synchronous communication session in whatever flavor you prefer.

Once you start making Slack the center of communication, you stop making deliberate decisions about who is included in e-mails/meetings. Now everyone in the channel has to skim everything to make sure they're not missing out on anything important. Busybodies love it because they can be a fly on the wall for everything. Heads-down workers hate it because they have to choose between focusing on their work or checking into Slack all of the time. It optimizes for the wrong kind of engagement.

Trying to enforce a lot of rules around threading is a band-aid, IMO. The real solution should be to create a culture where people aren't trying to force every interaction into Slack or avoid meetings at all costs. Excessive meetings are a problem, but going out of your way to avoid all meetings will waste more time than it frees up.


> Don't be afraid to schedule a synchronous communication session in whatever flavor you prefer.

That is its own separate problem. Constant distraction in Slack, followed closely by Zoom call hell because you didn't respond fast enough in Slack and wouldn't it just be faster if we all got on a call?

If we're going to leverage the power of remote work, part of that is re-learning how to do effective asynchronous communication and not succumbing to interruptions just because it's so easy to inflict them.


This behavior is caused by the presence indicator. People subsconsiously are afraid that closing Slack will signal to their boss (and team) that they're not working. However, the result is that they spend their days slacking - not working.

Presence indicators are a dark pattern.


With Twist, https://twist.com/, everything is a thread and no presence indicators


I think the name indicates its intentions quite clearly. Make employees slack.


> they spend their days slacking

what's in a name?


> Slack shouldn't be replacing e-mail or meetings or phone calls.

Absolutely wrong. We use Slack messaging and huddles to replace these things and are a more efficient workplace because of it. Really this is the point of Slack.

I have no desire to go back to the throat clearing and careful writing that comes with composing emails or wasting time in unfocused real-time meetings and phone calls that could have just been handled through a few async messages on slack. If a co-worker sent me an email (which no one ever really does) I would ignore it until they message me on Slack about it.

On top of that, Slack apps really decrease cognitive load by putting useful information into conversations or providing good prompts to start discussions from webhook notifications.


> Casual, asynchronous chat is great ...

I'm in the lead-weight-dragging tail (working in a bank using Teams, but dealt with this at the last job in Slack as well). The major hassle seems to be getting people to understand this is asynchronous communication (perpetrators are both developers and executives) and this problem seems to stand before the rest of the more sophisticated complaints evinced here can be even addressed.

A: Hello B.

[... typing/waiting animation]

B: Hi.

A: Good afternoon.

B: All clear for transmission, A. What's going on?

[... now B is derailed, waiting several minutes for A to compose his thoughts and type and edit them]

For all the pseudo UX voodoo we go through, can we not do something to give a hint that this is not a fucking phone conversation or something that requires a Q code? Or am I exiled to some benighted colony? Why is this not the first-order problem to be dealt with?


We have an unofficial policy in my company that all pertinent information should be in the first message specifically to avoid the scenario you mention. Highly recommended.


The business I work for has the same, it is branded "Naked pings suck".


That's grand and I'm envious. I guess what I'm suggesting is that if UX were grounded in HCI in any way, this would be the _primary_ problem to be addressed and is the issue which thereby outs UX as an over-priced modern-day hardware store color palette for the blind (primarily preoccupied only with forestalling law-suites).

I guess my question, really, is what affordance could be surfaced to suggest this communication medium is asynchronous and discourage this imposing behavior? Or, while the more socialized effete users know this is a problem and are properly socialized and are more concerned with problems on the frontier, I'm suggesting that there are major problems in the hinterland that have simply been ignored.


> what affordance could be surfaced to suggest this communication medium is asynchronous and discourage this imposing behavior?

I was employed through the transformation of pre->post changes, It took about 6 months of consistent reminders on all communication mediums, it even become memeish at one point.

>I'm suggesting that there are major problems in the hinterland that have simply been ignored.

I strongly agree with this, the lack of 'deep work' that instant communication mediums have created has destroyed so much innovation, possibility and profit through its creation.

Ginsberg was a genius, but things have changed.

“I saw the best minds of my generation destroyed by madness, starving hysterical naked, dragging themselves through the waking hours looking for slack notifications, burning for the modern digital connection to the dopamine laced cloud.”


Can you shed light on how this consciousness was raised? I'm the sort who demurs to be his own cause.

edit: this is evidence (for me) of why UX is B.S. completely detached from HCI.


Curious to hear more about your UX vs HCI thesis


I put my status as nohello.net , and if people don't follow, I politely say that nohello.net is the better way to do things in the future, and everyone can answer you questions faster if you do it that way.


I one day dream of having someone place my outgoing calls Is this xyz? Please hold for Blitzar. I might have to extend this to all messages.


Yes, I see this problem as well. People need to be told that they don't need to ask if you can ask... just ask.


I have enough respect for the study and discipline of HCI to think there is an interface solution here which doesn't resort to the (threat of the) cat o' nine tails.


> but once it becomes a serious conversation with multiple parties you need to escalate to a call or meeting or e-mail.

Why? Having multiple different communication buses seems like a problem as well. Possibly a worse one IMO


If you need a specific list of people engaged in a conversation, you can either:

1) Schedule something in a time slot that works for everyone. Everyone arrives prepared to focus on the conversation and reach a conclusion before returning to work.

2) Ping them in Slack or @channel and try to pry them away from whatever they're working on. Get a mix of half-attention and hurried responses and force your devs to choose whether to continue focusing on their work and risk missing out, or to drop everything and alt-tab over to Slack and try to catch up on the backlog as quick as possible.

Using synchronous comms or e-mail for everything is a mistake, but trying to force everything into asynchronous commons or Slack is just as bad. Know when to use the right tool for each job.

You can get away with a lot of Slack sins in small teams or companies, but try to scale Slack-only communication up to company scale and it's a nightmare. I worked at a company where I would accumulate upwards of 200 (not a typo) Slack notifications every single day because it became a battle ground of people competing for attention and trying to give drive-by input as they rushed on to the next Slack thread. Moving to e-mails forces people to put some minimal thought and prep into organizing their thoughts, which makes all the difference.

> Having multiple different communication buses seems like a problem as well. Possibly a worse one IMO

You have different types of communication. Why would you want to try to force them all into the lowest common denominator medium?

Trying to force everything into Slack is a disaster. Slack is great for real-time, interactive communication. Information has a very short half-life in Slack, though. Once something requires a longer half-life than Slack supports or a more careful handling, you move it to a better medium.


It depends, though.

Meetings are expensive, and often a waste of a number of people's time. And sometimes figuring out _who_ should be there is a problem (and cause also burn time).

Having broader discussions in a Slack thread has the benefits of:

a) it fosters transparency -- others are able to see the discussion, and chime in or move on

b) it's asynchronous -- others can chime in when they're able to, vs. having to drop what they're doing and join a meeting

c) it's self-documenting -- others that may not have been able to attend the meeting, or may just want to know the context/takeaways can just review the discussion

Of course, it has the downside of blocking a decision, where a meeting can help arrive at a decision more quickly. But -- at least, in our experience -- most decisions aren't urgent, and the turnaround time a Slack thread yields is typically sufficient. When it's not, we'll jump on a call.

Email, to me, is the worst of both worlds. You mention below that it forces more thought, and I agree with that as an upside. But typically (again, in our experience), people are pretty put together pretty well-thought-out discussions together, so it's not really an issue for us. We _never_ use email, and I'm perfectly happy with that.


How does email not have the exact same issues? I agree that a meeting might be better though.


> How does email not have the exact same issues?

Chat and e-mail have entirely different dynamics. Most people use chat as rapid-fire communication. Most people write e-mail with at least some thought and structure before hitting send. Think sentences versus paragraphs.

You also pick the audience from the start when you fill out the "To" field. With Slack, it can be hard to narrow the audience of a conversation unless you go to private messages (which will be lost to search) or go to threads and only ping the people who need to see it (which is what this article is proposing as their solution)


Because email is a snapshot in time. Slack on the other hand can get overwhelmed by noise and most people, myself included, don't go back very far when opening a channel. Emails, on the other, I make sure to read each thread.


Right, because people definitely read each thread in emails and definitely don't read each message in a thread. It's incredibly easy to link to a specific point in time in Slack, where you can contextually read the discussion from there. Quoting email replies is not the same.

> most people

Based on what number of people in what context?

To put it another way, I don't go back very far when opening an email. Slack, on the other hand, I make sure to read each message.


The real problem is Slack's engagement tactics. Reducing time on Slack benefits everyone, except Slack itself.


In the main article Slack communication is assumed to be synchronous. I find life to be a little happier when it's assumed to be asynchronous. That means turning off some channel notifications.

When I really want effective synchronous communication I tend to escalate from Slack to audio or video a screen share -- it seems like there's an extra layer of collaboration that you can have with a bit higher bandwidth.

For meetings I like to have audio plus a screen share of a shared document -- usually not a Slack document, because it's valuable to have more than one person be able to make edits.


Slack would become the best chat app for every company out there with just one simple feature (or the lack of it):

- remove the "user is online" green dot.

Really, it's not needed. Once it's removed then everything becomes async by default (and so everything slows down a little bit =>everyone is happier)


E-mail is inherently async. Async to the core. Why not just send your async requests as an e-mail so the other person can handle it as they process their inbox?

Slack excels at real-time, interactive communication. It's chat, designed for back-and-forth. Your messages will get scrolled into the backlog if there's a lot of chat while you're away.

The green dot (or the "busy" setting) is great for understanding whether the other person is going to receive your message as a notification at their computer or a push message on their phone. That's highly relevant.


I don't understand the love of email. It's little pieces of conversations that get sent around in an ad hoc way.

Email doesn't have an easy way to add someone to a thread, or to manage a forked conversation. It's closed and non-discoverable by default.


> Email doesn't have an easy way to add someone to a thread

You add them to the cc list.

> or to manage a forked conversation.

Your email client is at fault there, any decent email manages forked conversations.

> It's closed and non-discoverable by default.

Thats why you have mailing lists which are indexed and searchable. You may see 'closed and non discoverable' as a downside, I do not. Anything that should be discoverable should be on a wiki.


>You add them to the cc list.

I have very minimal experience using email, but doesn't this just add them to a new message as opposed to adding them to old messages?


Yes, in this case you explicitly introduce the reader with context, which is important when you have specific information that may be considered sensitive, or history that is not relevant.

Anyone reading the "to" line can see where the reader was introduced.


I find workplaces that default to closed conversations, and require explicit reading in of new participants, to be poor places to work. It feels like people use connections, being involved in key discussions, and their ability to connect people, as social currency. This is good for them, bad for the rest of the organisation.


I find it great, it saves me from information overload. For 'project' things, these often start on a mailing list and I can go back/search a mailing list if its that important.

I'll be honest to say, most things that is said in any communication medium is a complete waste of time. Having i searchable rather than forcing it on people globally is the only scalable option.


You do know that you can set yourself as away and nobody will be able to see your online status?


But then your boss/manager can’t spy on you!

I think most of us are lucky enough to work in companies or roles where that’s an acceptable option, but many others are not. It’s gotta be a cultural company change or one driven by the product team at Slack.


Or just leave yourself 'online' all the time.


I've never noticed that dot before. Just because I have slack open doesn't mean I'm available, and that's what I'd expect from anyone.


I’m just glad it doesn’t have read receipts


I have all notifications off all the time. I check slack when I have a moment, like if I'm waiting for CI or a long compile. Actual highlights will turn the tray icon red, so I will notice soon, but replying even to highlights immediately is madness.


Is there a way to have this async communication presented in a better way? I am on Discord, Telegram, and Slack sometimes with thousands of members. Yet, I mostly don't read posts anymore because it's just a full marketplace talking and finding that needle in a haystack of good information is impossible. So unless I am in sync I can't read.


Yeah, I think the author could do well with just muting slack for a few hours a day, and hand out his phone # for emergencies.


One of the things I miss working at Facebook is the internal FB (called Workplace). It basically replaced email for the whole company, and worked really well for long form posts where maybe you would write some proposal up or make an announcement and get a bunch of comments. I now work at a slack centric company, and it just doesn't compare - there is no 'newsfeed', so unless you remember to check all the channels, you end up missing stuff. You can send out a group email, but people are reluctant to reply-all, so this doesn't get good discussion either.


I've seen internal Facebook-alikes a couple places and they've been gross LinkedIn-tone places taken over by HR and managers doing rah-rah-let's-go-we're-so-great stuff and a few workers trying to kiss ass. What about Facebook's kept it from being that? Broader culture, or was there some enforcement of it?

(plus, and this is just a me-problem, I find them impossibly confusing because they ape Facebook's UI, which I find so hard to understand that my one attempt to use it for about a month c. 2010 was nothing but frustration and wondering how the hell normal people manage to use it)


The biggest thing about Facebook's Workplace instance is that it's actually used by everyone, so while there will be the HR and manager posts, there are also all of the incident discussions, feature discussions, investigations, etc in there as well. With teams having the power to create their own (potentially private) groups to manage their own communication too, it meant that a lot of the content was useful.


Good question, and I don't know the answer, because I've never seen the alternatives. In WP anyone can create a group, and make it private, so you can just make a private group for a bunch of engineers to work on some project with no pressure to be 'performative' for the rest of the company. Basically its a replacement for email distribution lists, but with many advantages over plain email.


I work there currently and I agree - I can imagine frustration for a while after leaving and not having a good place to make a bunch of posts.

Posts and work groups are actually a generally good way for scalable work communication - and leaving a public and searchable record. This doesn't replace Google docs and wikis, but serve as another layer to organize them. (I promise this doesn't lead to needless bureaucracy, that still happens but not because of Workplace).


Does it show completely different posts each time you reload the page, like it does on Facebook.com?


Yeah you miss a lot with newsfeeds lol.

If people need you to see something, they can message you directly. I just look at some priority channels semi regularly. No channels create notifications for me, thread replies do not either only DMs and direct @mentions do.


Workplace Chat is like Slack and depending on the team, that can be where a lot of the discussion happens. For a couple of my teams I feel like it’s been the worst of both worlds. I still have emails, gotta check my WP posts, but also have discussion happening in chat all day long.


We had Yammer at my last job and it was a pretty good forum for stuff like this.


How did that work well when nothing was ever in order?


At my company we have a “thoughtful communication” guide[1] that addresses Slack and other communication tools. The simple rule for Slack is it’s for ephemeral or urgent communication only. All “conversation” material essentially routes through email and it works great. Takes some getting used to but our Slack instance is very, very relaxed. Most employees silence all Slack notifications and are encouraged to do so to (try our best to) preserve focus.

[1] https://www.ashbyhq.com/blog/company/thoughtful-communicatio...


> The simple rule for Slack is it’s for ephemeral or urgent communication only. [...] Most employees silence all Slack notifications and are encouraged to do so [...]

How do urgent combine with silencing notifications?

Honest question, it seems I am missing something from the context here.


Fair question and good point. Our Slack isn’t absolutely quiet - we do have a channel for coordinating on customer issues (meets our urgent and ephemeral criteria) and it might be that some matters are raised by other processes outside of Slack but Slack itself is a good fit for in-the-moment collaboration. But in short we aren’t absolutists, it’s a mix of a few specific channels for certain contexts, channel-specific muting, and updating one’s Slack status - all under the guidance that Slack immediate responsiveness is not generally expected but more the exception. It sounds like a lot as I write that, but as a broader cultural norm within the company it does (so far!) support itself.

That said, I’ll pass your question on to the team as feedback, we should make the answer more clear.


The default setup for Slack (I think) dings you on any traffic in any channel. This is insane. Dinging on a direct message or a mention in a channel is a lot more reasonable and basically mimics the behavior of IRC.


If it's anything like one of the places I've worked at, it doesn't combine. You're simply expected to be switched on throughout the work day.


Microsoft has a solution to that problem: Teams. It is so painful to use and to do anything in it that it encourages people to actually use the bug tracker or other venues to discuss any serious topic.


I honestly don't think it's that bad. I've used both Slack and teams simultaneously for a few years, and I honestly don't see a lot of differences.


Search is horrendous across the board, list of conversations is where messages go to die, the "teams" part which is a weird hybrid forum has an awful UI and no way to not collapse messages by default (and little to no options). What works well is A/V meetings planned in the outlook calendar. There is no third-party reliable API that we can use to have anything else than the web (or electron) client), which happen to be fairly buggy and very heavy, while at the same time leaking unwanted information to other people. Calls are intentionally crippled on firefox to make sure you use chrome, their web browser, or their app.

But I guess it allows management to spy on employees while being integrated with the microsoft ecosystem, so it gets a free pass.


Have you ever tried discovering a team you were not already part of? Or tried having any reasonable conversation outside a chat room?

I figured I could get used to teams, but it’s just so useless compared to Slack it isn’t even funny.


Teams is garbage. I'll end up with conversations or images that don't load until I click back and try again. If I search a chat for something, clicking the result will often not scroll the correct message into view. It doesn't allow you to be on a call on multiple devices at once so I can use the desktop I'm remoted into for viewing a screen share while using the app on my phone for audio. It tries to retain the formatting of what you're pasting in, often resulting in a mess and sometimes getting stuck with certain font formatting.


> It doesn't allow you to be on a call on multiple devices at once so I can use the desktop I'm remoted into for viewing a screen share while using the app on my phone for audio.

This was actually fixed a ~month ago. And they broke the ability to answer group call in the mobile app with that update.


To me, it is incredible that Slack is used WITHOUT threads. There is no way that information and discussions can be effective without a threaded conversation - it would just be pure cause otherwise.

Also, I find feature-specific channels to be such a pleasure. It's easy to have everyone focused on the same topic in a given channel, without any confusion or missing information between different channels or private messages.

Moreover, I have also considered Slack to be asynchronous - meetings are necessary for sync work, but I find Slack to be working perfectly if no one expects that you reply within minutes, but within a few days (if you are not actively working on a project - in that case a lot of times is just easier to schedule very fast meetings during no-focus times)


> To me, it is incredible that Slack is used WITHOUT threads.

The first time information you need is sent in a thread that started a week ago and that you're not already on, you'll get why folks don't like Slack threads. They're an anti-feature, IMO.

If Slack offered a way to show all messages whether or not they're in a thread, as they come in, I'd be down. I wouldn't like 'em but at least I could work around their fundamental flaws.


And it's such a simple option to add, too - as far as I can tell, each message in a thread is just a message in the channel, just with a "threadId" attached to it. The client's the one that hides it and makes a mess of the experience.

But what it really needs is elevating threads to something like a temporary "sub-channel". Show them on the side-bar just like channels so you don't lose messsages CONSTANTLY if you're in more than 1 active thread at a time.


I understand and agree on this, BUT I feel like we are not at the point where Slack could decide autonomously which threads deserve their own channel.

Usually, in our workspace, it's the person leading the discussion that at some points decide to redirect the talk somewhere else


I just dream of the day when Slack has "all threads with unread messages" show up in the side bar - somewhere. Let it be an option you can turn on/off, if need be. But right now I feel like I have to obsessively scroll down the threads list and look for things that are new.

Maybe it's a company size thing, as mentioned elsewhere in this discussion. At my size company (<10 people), every thread I'm watching - I pretty much need to see all of the new messages.


Isn't this what the slack search bar is for? I was sceptical of using it at first but I often find what I'm looking for by typing in one or two key words and restricting the search to certain channels that likely have the information.


Search can help address this issue if you know that people were discussing something you're interested in. However, it's possible (and in my experience likely) for an important topic to come up in a thread and not make its way back to the channel. In that case you may not know that it's something you need to search for.


> If Slack offered a way to show all messages whether or not they're in a thread, as they come in, I'd be down.

This is how Zulip works. It's extremely effective.


Well, that's because threads are just first citizen in Zulip, even more than in Slack!

Basically, a thread is visible at a first glance from the UI, while that's not true in Slack. Also, you can kinda replicate Zulip structure by just using channels with naming conventions, so you have: - generic channels, e.g. for status update for many stakeholders - specific channels for each feature - threads in each channel where you discuss a single point


I second this. Zulip works extremely well at my workplace.


The threading is a mess, especially if you are using the web UI.


What are "no-focus times"?


Some companies these days have so many interruptions (often in the form of Zoom meetings) that you need to dedicate "focus time" to get any actual work done.


Thanks, I thought that this person might have been describing something other than that because they said "no-focus" as opposed to "focus", and also because they made mention of scheduling meetings during "no-focus times".

I was wondering whether maybe "no-focus time" might have been something even wackier, like time in which it's explicitly encouraged to interrupt everyone as much as possible, which I know sounds silly, but you never know these days...


My main gripe with so much of the communication moving to Slack is that a lot of highly technical discussion moves into synchronous chat, and that removes the expectation which email often carried that the author spends time organizing their thoughts into clear linear writing.

Of course emails don't always come out coherently either, but my personal experience has been that moving into the streamed sentences model overall reduces the amount of effort put into organizing thoughts before communicating.


I think this is on the money.

Often in my career I find myself on the other side of an opinion after noodling on it for a while. The process of typing out a long-winded email, realizing the hole in your argument, then saying Fuck It, deleting it and instead replying LGTM, is a powerful instrument.

Everyone wins when discourse is more thoughtful.


I think the answer here is pretty straightforward: run a Discourse board alongside your Slack, and nudge conversations out of the Slack and onto the board. The board works for long-form stuff, and for stuff you need to reference in the future; Slack works for interactivity when you want the interactivity.

We've been doing this for over a year at Fly.io and it's worked out great; I wish every other place I've worked that did a Slack or Slack-like thing did a dual chat/board strat, instead of pretending that chat/email is a serious alternative.


At a previous company we added an emoji that meant "this needs to be captured somewhere better than Slack", and those would be surfaced in a channel, and then links would be added in response as things were actually moved out.


> and nudge conversations out of the Slack and onto the board

Getting serious conversations out of Slack and into a more thoughtful medium seems to be the key to success.

Every time I've seen Slack used as the central repository of communication and information, it's a disaster. No, I don't want to sift through 30 pinned messages in each of the 5 channels vaguely related to a topic to find some piece of information I need. Treat Slack as casual, interactive chat, but get the information and decision-making into a better medium as soon as it becomes more important.


I think an issue tracker can also be repurposed for this sort of thing if a team doesn't want to run Yet Another Thing. This is what I do.

Practically there is little difference between an issue tracker that supports comments and Discourse, and most teams already have the former.


Question. What is the value of slack at that point? It seems, as someone with no experience with this setup, that it’s just notifications? Couldn’t your threaded system just poll more?


It's a good question and I don't have the answer, beyond that there is a lot of value to it; if we lost Slack, it'd be a big problem, even though the board works really well.

There is something to being able to just randomly vent or muse on Slack and have a conversation organically pick up --- or not pick up, it's the optionality that's maybe important? Whereas, every message board post feels like an appeal for feedback and discussion, and so requires just a bit more activation energy.


You don't have to talk sync with chat, you don't have to do one line back and forths on chat, you can take hours or days to reply if you so choose on chat like email, you can easily do rich paragraphs. Slack is not synchronous communication, video / voice calls are.

Slack wins over discourse forms, stack overflow and email because it adds too much friction to do essentially the same thing. Slack wins because it's the least friction interface that gives you form and email equivalents, plus it organizes a bit better naturally . If you want to beat slack and change the communication defaults, you need to make a UI that works with less friction than slack.

You can change your chat culture with changing your behaviors and encouraging changes like nohello.net and threading like this post is doing and setting boundaries with how you will communicate.

Also, different people work better with different communication mediums, the slack hate that you see on HN is not universal, there is a quiet majority that works well with slack, otherwise you wouldn't see it naturally adopted so much like the author encountered themselves. There will always be a set that hates whatever the default is. Now WFH is default in the industry, there is a subset that hates it greatly and wish we had offices again. Go back to offices with private rooms or open offices, there will be a set that doesn't like it too.


No, Slack-mania can't be cured with systemized discipline.

Slack is a pox. It's not just about endless notifications that kill your ability to focus, it's an environment that actively encourages organizational anti-patterns. If you have a question, first you ask your manager. If Slack makes it easy to reach out to someone directly, your manager will tell you to Slack them. If you don't have Slack, and you don't have people's phone numbers, instead you get directed to documentation / wiki / support ticketing.

Organizational choice architecture matters. Slack makes bad choices easy and good choices difficult. That's enough reason to ditch it.


All comms through manager sounds like a dystopian nightmare worse than slack if you ask me...


I don't mean all communication, I just mean in the case that you aren't aware of what to do because you're new.


That’s way saner :)


> No, Slack-mania can't be cured with systemized discipline.

This matches with my (n=1) experience. The only way to cure "yourself" is to get away from organizations that use Slack in the way that OP describes.


If you want to be ahead of other engineers and have a meaningful impact, then you’ll want to maximize the number of uninterrupted deep work sessions. The more you can fit in a week the more you’ll achieve (rfcs, implementations, reviews).

This is one of the biggest contributor for high performing profiles.

To manage this when using Slack you can:

- set your status as “deep work” and decide to pause notifications for x hours

- use “mark as unread”. when you want to peek something but not act on it yet

- use “remind me” on messages you want to deal later on through the week

- avoid DMs has much as possible, so not just one person can help you, but anyone from your team

- avoid Slack on the phone

Then deal with notifications in bulk.

Slack isn’t killing our productivity, HN and twitter are not killing it either.

Our addictions to notifications is, but we can manage this with discipline and training.


For me Slack did not replace email, it replaced Instant Messenger. It replaced standing up from my desk and walking into another office to ask a question that I ether needed the answer to now, or never.

EDIT: I hate how all these code projects have their own Slack though, it's super annoying and has been a horrible way to engage with the community and get answers to questions. (Discord too)


I'm more annoyed that more of them don't use Matrix.


I'd prefer Discord itself since it has better UX than matrix.


I prefer to avoid closed and non federated IM services if possible.


> A practice that was already in place was one of diligent threading – not only was threading encouraged, but by strong convention, every topic goes into one. We thread like our lives depend on it.

This is describing Zulip. And indeed, Zulip is excellent. The only downside is that the mandatory-thread paradigm makes it difficult to find the appropriate place to deliberately fuck around, which is also a valid mode of human socialization. But if you want to get work done, use Zulip, not Slack.


I wish Slack had a feature to "threadify" comments that have already been made. I wouldn't even mind if Slack channels could designate certain users as "thread czars" that had the ability to move other users comments into a thread.


Never mind the thread czars — I wouldn't mind the ability to do this with my own comments. Often I reply to something in the channel, realize after the fact that it should have been in a thread, and then become sad when people start replying to it not in a thread.


This is a brilliant idea. I work in a slack jungle most of the workday in a very large org across possible 100+ channels. Multiple instances on top of that.

Sometimes replies bucket up under the thread, sometimes they do not. Sometimes what should be threaded get fragmented into separate threads.

Love this idea.

Some of the old school IRC-channel ops functions could go a long way too (I think discord is more like that).


Our experiences don't match regarding threading, and I don't think the author's are necessarily representative. Slack's threading implementation is an afterthought, a bandaid solution. With it, conversations usually end up as a mix of some replies in a thread and some in the default clutterspace. In this regard even Teams has a better approach, it's really obvious if you're in a topic thread or not.


Agree completely; if you've only used slack check out Zulip for an example of how a good threading model works.


I love chat software like Slack and Discord. But I gotta say, those products really nailed their product names.

Slack. Almost nothing to do with work.

Discord. Almost nothing to do with communication.


Highly recommend World Without Email by Cal Newport on this exact topic: https://www.calnewport.com/books/a-world-without-email/


Was about to recommend this, too. Newport's description of the "hyperactive hive mind" is almost dead on what this author is calling "Slack-mania". And Newport shows this is much bigger in scope than just the introduction of Slack or MS Teams. New technologies have repeatedly created way too many points of communication now that it's so easy to, well, communicate with anyone.

I found his observations about needing to separate specialist time from support-style time to be very intriguing.


If you're in the US, be careful with what you write on a company channel/email. Both Slack and email can legally be read by management.

Know someone who works at a well known digital radio company. Prior to joining management they were in a coworkers channel where people vented about management, with the exception being them. Upon joining management they were asked why they didn't report on the gossip/venting earlier even though they never partook and it was explained that management was tracking all channels on the company's Slack. Those that were gossiping/venting all got let go


From a quick skim of search results (e.g. [1]) it sounds like it’s unlikely (although not impossible) that they’d be reading private Slack messages as it usually requires a request to Slack who will ask for appropriate employee or legal consent. Of course this could be much easier to achieve (or avoid needing) than it sounds, I have no experience of this.

It wouldn’t surprise me if it was more likely that they were either told about the chat by someone, or perhaps saw it over someone’s shoulder or whatever.

Still, it’s good advice to treat what you write on there as something that could one day be read by someone unintended for sure.

[1] https://www.vox.com/platform/amp/recode/2020/1/24/21079275/s...


Has anyone used P2 (by Wordpress) as a replacement for Slack?

https://wordpress.com/p2/

It seems most similar to FB Workplace from what I’m reading.


I work at Automattic (makers of P2) and even we don't use it as a replacement for Slack. What P2 replaces for us is all internal email.

In fact, we use Slack quite heavily ourselves, for any real-time/synchronous discussions. P2 is for non-realtime/async discussions, and more or less serves as the "paper of record" for the company.


I (and somehow the rest of our company) has been spared the constant slack problem but I still don’t know if this is the nature of our work (we work on hardware) or the culture this company has somehow cultivated. Or both.

First, we use Teams. And we have set up Teams to be messenger/chat oriented first, and group chat second. In fact, the group chat feature is heavily controlled and limited to posting domain/company-wide updates. I don’t know if this was intentional, but so it goes.

Result: people use Teams as a substitute for walking across campus to ask a quick question. Or to bounce off an idea. Or to quickly check status. Or to send gifs in meetings.

Second, as a hardware focused company, traceability is super important. You don’t want to be leaving technical decisions on ephemeral chat. You don’t want drawings, schematics, and instructions lost to people just chatting in Slack/Teams.

Result: email/Jira/wiki it is.

Third: as a hardware focused company, the personnel is divided into technicians and engineers. And the technicians do not actively look at their phones/computers. It can be hours sometimes before one of them responds. Last thing you want is a tech looking at their phone every 10 minutes while wielding a rivet gun.

Don’t expect a design engineer to be so quick on their response time either. They’re either deep into a CAD design, in a design meeting, or on the floor with a tech. Don’t Ask to Ask is not specifically taught but most everyone learns to Just Ask because who knows when you’re “Hey I have a question” is getting answered.

Result: most online communication is asynchronous anyways. Urgent matters will result in a call or someone running across campus.

I’m sure Slack plagues many a hardware company. But somehow we have cultivated a culture that discourages spending too much time in chat or storing important info there. If a question becomes too long or complicated, we ask each other to email. If a question is asked too frequently, it is logged in the wiki. If a question becomes rather convoluted, we call each other to quickly resolve the matter.

Messaging doesn’t need to be the enemy. It can be a powerful tool to keep in touch with others flung across the campus/globe.


Did they just re-invent Zulip? :P


I agree with the author that threading is quite critical to maintaining sanity.

In my experience, it's insufficient by itself. I would recommend coupling with some naming conventions around channels and discouraging group DMs for anything substantial.

I wrote up some of my thoughts on this in a post: https://rushabhdoshi.com/posts/2021-08-02-taming-slack/


I have two tabs of slack open, each taking up closr to 4GB ram. I miss IRC.


weechat-slack will meet your demands.


> It was rare to open Slack in the morning and not already be immediately underwater by 3 to 5 mentions representing conversations that needed to be waded into.

The "Remind me later" feature is a good way to avoid morning-overload syndrome. Just snooze the ones requiring a reply for 1 hour, 3 hours, tomorrow. Feels great.

Then turn off notifications, and go get stuff done.


To everyone frustrated at this, I would highly recommend checking out Twist. It is "threads-only", and async-by-default. Interface is pretty nice too.

The biggest issue with email is that by default it only goes to the people in the To/CC/BCC list, so information is silod. But so much else about it is _very good_, and I think that Twist gets to most of that.

The main issue with Twist preventing professional adoption for me is lack of custom emoji support. Especially in full-remote land, custom emojis help with building a fun internal corp. culture, and serve as a way to ad-hoc workflows as well. Twist, add custom emoji you cowards!

https://twist.com/slack-alternative

(EDIT: to those who roll their eyes at "fun corp culture", not talking about dancing parrots, just like stuff like our own corp logo or little stamps to say something is done and the like)


What if you had culture where Slack messages don’t warrant immediate replies?

I set aside time to do “deep work” where I quit Slack and Outlook. If there is something urgent someone could text me (it never happens). If it is an “emergency”, I would get a page through my paging app that has a special entitlement to allow it to bypass silent and DND.


Or you could use Zulip, where everything is organized into first-class topics for exactly the reasons described.


I introduced a similar thing at my work place and it works (there's a few points where people forget or sometimes there's cross over) we added some state to it to so in the context of triaging bugs.

we reacted to the original message with:

ticks - to indicate the bug or issue was accepted and we had enough information to raise the problem/issue into our tracking system

cross - to indicate not a bug

jiraicon - to indicate a ticket had been raised (and linked into the thread) all the information so far would be in the ticket and further comms hence forth would be in the ticket system.

in the channels we did this in, messages would be pinned till they were given the tick/cross so people knew what needed triage and what didn't (treated triage as a team sport, whomever got to it first saved the rest from having to dive into it, unless they so wished)


I don't really understand this workflow, why does this need to happen in Slack at all, when you already use Jira? Wouldn't it be far easier to raise a ticket in Jira directly, have all the info there, and then mark is as a bug/no bug?


My team just launched a product on Tuesday designed to solve this exact problem.

Email has a better threading model than Slack, but email clients lack the realtime features needed for synchronous collaboration. So we're trying to fix. The idea is to let you do long-form, async and short-form, synchronous communications using the same tool, and to do it over email so you can still talk to anyone.

Our product is Shortwave (https://www.shortwave.com/) -- we had a Show HN on Tuesday. We have a video here that walks through our team collaboration features: https://www.youtube.com/watch?v=Ex_o2d1GXf4&t=5s


I'm new to Slack (just leaving a FAANG for a startup) and all the inbox management skills I've built up over the years seem to be useless now.

Is there a good way to create an async task list from Slack? Right now if I get a message on Slack that I want to handle later I can:

a) Ignore it, so I keep the unread "red dot"

b) Use the "remind me" feature to make it synchronous but later

c) Just ... handle it now (sigh)

What I want is a list of threads I am meaning to get back to, but without having to actually use a separate list-making app. Is there a Slack app or workflow for this?


Just don't look at slack that often?

I work at an all-remote company and I just... don't notice when someone messages me on Slack, and i check it on my own schedule. It all just works.

I mute all channels I join apart from a few directly related to me on a daily basis. I very deliberately completely silence Slack so it's impossible for it to make a noise. I'm on windows so I don't get the notification toasts or the jumping in the Mac dock, so someone messaging me isn't distracting.


Add it to "saved items".


One thing I have not seen mentioned here is the “slack status”. I find that it has a subtle stress inducing effect:

* if it’s green are people expecting me to reply right away? And if I don’t respond do they feel anxious? * do employees feel pressure to keep it green to show they are working?

I told my team that I will keep my status to AWAY always, and they can feel free to do the same. Just because slack provides a surveillance method doesn’t mean you have to use it. This also reduces expectations of immediate replies and keeps it more async


I am fully remote at my current job, and I actually rely on the Slack status to indicate whether I am "in the office" or not, because obviously my physical presence is not a useful indicator of my availability.

But you are right, it also sets an expectation that messages can only be asynchronous up to a point. Maybe this is one downside to remote work: there is no way to distinguish between "performatively demonstrating that I am actually working" and "currently available for active discussion".

I have noticed that some people actually schedule "heads down" time on their calendar and set their Slack status accordingly. I could try that and see if people respect it.


The problem is that they have too few. The one I miss the most is "free for chat", but it'd be also nice to copy Teams with separate Busy and Do not disturb.


I always felt like the ultimate flow with Slack was to make focused channels for a given topic; threads are too generic and hard to track and I generally get the impression that they're meant to be ephemeral, whereas a focused channel will of course ensure all participants know the intent of the channel, and the content is not lost. Essentially, a channel should be treated as an e-mail thread. Once the topic has finished, you can close the channel and archive it for future reference.


no. Slack sucks and I don't think companies realize just how much time and energy it wastes. I am lucky if I can get one day of focused programming in anymore. Most days I am exhausted from constant interrupts and when I finally do get time at the end of the day I am completely spent.

Everyone needs a personal guide through AWS/K8s/Infra Tool when about 50% of the time we have internal documentation answering the questions that are linked to at the top of the channel. Another 40% of questions could be figured out with light googling and 5 minutes of reading. The last 10% are legit questions around issues we have in our environment or require a deep knowledge of how the systems work together.

But hey. If companies want to pay me to babysit lazy developers I'll do it for a good price. I'm fairly close to leaving the company at this point but this seems to happen at every company I have been at once you get to a few hundred developers and my motivation has been completely sapped.

Slack is for leeches.


People will always prefer asking, as that comes with a built-in lookup table and related links and probably up-to-date information. It's just easier than to spend time sifting through documentation that may or may not have the information they seek.

Don't blame the medium.

Instead, change your response so that they stop expecting your time.


interesting article because Stripe had quite a couple of "culture & hiring" issues the past months. This is just another example that the company is toxic and they rather focus on existing process/tools than people.

Working in shops that used slack (usually it means it's used heavily) has taught me to avoid any shop that uses that tool because knowledge isn't captured properly. There was a critical thread here accusing the same of Discord (for good reason). But Slack doesn't get the same fire from the HN crowd and it makes me wonder.

I guess you can create the same mess with Teams, but in the end it's the company culture that decides where to have discussions and at what point that value generated by those should be captured via which means. I certainly will not scroll up more than 2 pages in a chat so if info is lost better write an email.


Really…? You won’t work at a place because they use a certain chat application?


Maybe instead of Slack we should use more collaborative editing tools (like Google Docs or Miro).

I haven’t really tried that, but it might be interesting if for example during troubleshooting session everybody was putting the facts to same document.

At least the end result could be easier to consume than a very long chat log.


Are any Mozzers reading HN?

I worked with the Moz team on a project as a consultant, and their slack thread discipline was very strong, much like what OP described in his post.

It was equal parts confusing and refreshing at the same time.


Slack encourages a fast but irregular communication habit. For example, if you could document something that you discussed with someone for half an hour, maybe many people would benefit from it.


We're a very small company which makes this all easier, but we've ended up with a similar Slack convention of everything being in threads and it makes Slack a lot more managable.


This works well until your team hits a certain size and suddenly you've got dozens of threads going on per day, and you're trying to somehow manage following threads, channels, and DMs.

I'm sick of Slack for this reason, and I think I'm going to start participating only as much as is required not to lose my job.


Right. I'm here for norms and organizing principles, but their answer just moves the firehose around, he still has 5 notifications, it's just... now they're buried in lengthy threads instead of lengthy channels.

There's a place for async chat. But it isn't good at replacing actual processes, documents, conversations, and organizing principles.


Precisely why I’ve come to like Twist app, from the maker’s of Todoist. It needs some refinement and better thread management, but it’s asynchronous from the start.


I work at a company that has taken Slack-mania to the absolute extreme, and it's one of the reasons why I daydream about leaving on a weekly basis.


Work at a pretty big place and we very frequently use threads it works well and people picked up on it fairly fast.


Slack was supposed to cure email. Instead it created a new "mania"?


The solution to Slack is Twist.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: