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.
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 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).
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.
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)
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.
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.
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).
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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)
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.
> 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.
> 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.
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.
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.”
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.
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.
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.
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)
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...
> 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.
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
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 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.
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.
> 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.
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.
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.
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.
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.
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.
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!
(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)
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.
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!
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'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)
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.
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!
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.
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.
> 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!
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.
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.
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.
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.
> 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.
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”.
> 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.)
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.
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.
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.
> 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.
> 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.
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.
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)
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.
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.
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.
204 comments
[ 0.28 ms ] story [ 292 ms ] threadI'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.
There's a place for async chat. But it isn't good at replacing actual processes, documents, conversations, and organizing principles.
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).
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.
(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)
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).
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.
- 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)
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.
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.
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.
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?
Anyone reading the "to" line can see where the reader was introduced.
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.
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.
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/
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.
Why? Having multiple different communication buses seems like a problem as well. Possibly a worse one IMO
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.
> 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.
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)
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.
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.
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.
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?
edit: this is evidence (for me) of why UX is B.S. completely detached from HCI.
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.
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.”
Presence indicators are a dark pattern.
what's in a name?
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)
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...
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.
This is how Zulip works. It's extremely effective.
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
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.
Usually, in our workspace, it's the person leading the discussion that at some points decide to redirect the talk somewhere else
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.
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.
Practically there is little difference between an issue tracker that supports comments and Discourse, and most teams already have the former.
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.
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.
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.
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.
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.
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)
https://wordpress.com/p2/
It seems most similar to FB Workplace from what I’m reading.
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.
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
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)
Is that sentimental to you?
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
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.
https://twist.com/slack-alternative
Supported by Doist which also supports Todoist which I am using
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-...
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!
Please suggest more solutions.
We can always use more choices.
I am just mentioning what works for me (for now).
Have the conversation and put the relevant stuff into the ticket / bug / wiki. If there are FAQ, time to write an FAQ!
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.
... and first explain that they should use huddle, that works everywhere, instead of call, which is chrome-only. Great UX /s.
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.
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.
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.
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.
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.
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.
Clearly the problem here is the policy.
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.)
I'd prefer to fill out a reCaptcha.
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.
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.
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.
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)
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.
Don't blame the medium.
Instead, change your response so that they stop expecting your time.
I found his observations about needing to separate specialist time from support-style time to be very intriguing.