Can Slack-mania be cured with systemized discipline?
brandur.org
brandur.org
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.
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.
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.
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.
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?
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.
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 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!
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 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?
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.
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)
[1] https://www.ashbyhq.com/blog/company/thoughtful-communicatio...
How do urgent combine with silencing notifications?
Honest question, it seems I am missing something from the context here.
That said, I’ll pass your question on to the team as feedback, we should make the answer more clear.
But I guess it allows management to spy on employees while being integrated with the microsoft ecosystem, so it gets a free pass.
I figured I could get used to teams, but it’s just so useless compared to Slack it isn’t even funny.
This was actually fixed a ~month ago. And they broke the ability to answer group call in the mobile app with that update.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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).
Slack. Almost nothing to do with work.
Discord. Almost nothing to do with communication.
I found his observations about needing to separate specialist time from support-style time to be very intriguing.
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
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...
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.
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.
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/
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.
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)
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.
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)
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
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?
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.
* 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
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.
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.
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.
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.
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.
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.
There's a place for async chat. But it isn't good at replacing actual processes, documents, conversations, and organizing principles.