Slack the company really needs to embrace distributed work practices if they want to actually build a tool for distributed work practices.
Slack has totally become a drag on productivity and a net negative. Channel and message overload is arguably not much better than the email system it is meant to replace.
My prediction is that Slack will be replaced quite quickly by the first tool that really nails remote messaging and coordination. Slack is not it.
I've never really "got" it when it comes to tools like Slack or Teams. To me they've always felt like a forum with a handful of mega topics that go on forever with worse (or no) pagination.
I also don't get why some devs of successful open source projects hang out in Slack. Do they feel like they need to or do they want to? The specific thing I don't get is that a lot of projects have both an issue tracker and a forum so they can filter low level questions into the forum, but then you can get direct access to the devs by visiting the Slack channel. I mean it's cool, but WTF?
I guess maybe my thinking is old-fashioned at this point, but I think people seeking out help should RTFM and be held to a certain standard when it comes to the effort they make. I self solve more than 50% of my problems while I'm trying to build a test case or write a good quality forum / SO question.
Maybe Slack, etc. are popular because the informal nature lets people skip the part of the process where they're expected to make an effort.
It serves the same purpose as irc channels, jabber, skype, discord - always-on, no friction communication.
It replaces the possibility of asking your friend who sits on the next chair a quick question.
It can be abused, of course, but I think it creates a healthy hierarchy of information:
If you need the answer today write an email.
If you need the answer in 10 minutes write on irc/jabber/skype/discord/slack.
If you need the answer now - go in person or use a voice call.
We actually had our manager tell us this in my first job and set expectations for how fast you should reply on each channel (of course you can answer faster, up to you). This allows to communication without worrying about destroying other's flow.
And of course you should check documentation and google before you ask, but that's tool-agnostic.
Also for remote teams it shows who is currently available, which is useful in its own way and solves some trust problems employers have with remote workers.
How do you get 2 hours of uninterrupted time if you’re expected to respond to slack within 10 minutes? This becomes a major problem if you’re part of a team that owns something that supports dozens of teams. Even if each other team only slacks you one question per day: you now are getting at least one question every hour or so. If you can’t control your calendar and create “office hours” to aggregate all those questions and answers, then you either need to be really great at multitasking and preserving mental state while dealing with unrelated problems, or you just can’t spend multiple hours of focused time on a problem during normal working hours.
Even if a slack response expectation is only within your team, requiring people to check for notifications more than every hour seems really disruptive, unless you have designated “slack meeting” times.
For me (on IRC) the rule was always that it's fine if people don't answer within 10 minutes, but you should be told.
Specifically, you're expected to answer in IM timeframe unless you set an afk message. This way people know that they should wait for an answer that might not come until hours later.
In an office this is self evident since if you walk to your colleague's desk you see if they aren't there, but requires a bit of explicit communication via IM.
I simply set my status to "AFK deep code" or simply "afk" and turn off notifications to get 2 hours without interruptions when I need it
The term seems impossibly dated, but the "watercooler" type moments or discussion also happen much more organically in an always-on communications system.
>And of course you should check documentation and google before you ask, but that's tool-agnostic.
the tool which significantly decreases the cost of asking naturally encourages the asking and discourages the documentation and google check by virtue of making the check a waste of time when the answer can be quickly obtained by the asking.
I definitely share with you the view that Slack is a poor substitute for proper documentation and company communication. To me it just feels like that any project that is managed via Slack transplants the dynamic of open-floor offices to your computer and mobile phone. Yes, it is easy to gather everyone and share quick updates, but only in a fast-food kind of way.
One big change that I got with my team to do successfully in a company was to change the attitude regarding communication and documentation on Slack.
It involved one single, simple rule: whenever you want to ask anything you need to do your work on Slack, phrase it a way that relates to the Wiki/Knowledge Base.
In our case it was Confluence. So, instead of getting questions on channels such as "How do I do X?", we would ask "Can someone point me to the Confluence page that explains how to do X?". Instead of asking someone to send a file or spreadsheet with data that I needed, I would ask them to revise and update the Confluence page, and so on. That would apply even for meetings that were held. If someone missed a meeting and wanted a re-cap, it was easy to point to the page with the minutes of the meeting, and so on.
In the beginning we did have to prod and nag some of the colleagues so they would drop old habits, but after a couple of weeks when the majority understood that Wikis are meant to be editable freely it was working really well. There were no longer huge threads on Slack and there was no more stress about missing anything that happened on Slack. It did help (a lot) that we had the support from upper management in implementing this, as they were the ones worried the most about losing communication scattered in a million threads and channels.
So, how did you solve the organization problem? That has always been the biggest problem with confluence and wikis in general.
People actively dislike confluence. (And it's something that's stuck in my craw - how do we build documentation that's easy to organize? That's my quarantine project. :)
Confluence as a Knowledge System is like Democracy for Political systems: the worst ever, except for everything else that was tried. As much as I'd like to replace it, it did everything we needed and was better than any alternatives that we considered for both tech/non-tech teams.
The solution we had was to give one Space for each team/department in the company: one space for Customer Support, one for Engineering, Data Scientists, Business Analysts and Operations/Management. Each team lead was responsible in ensuring that other teams from the company could find the information needed, but aside from that we let each team organize itself.
The only hard rule was the one I stated above, everything else came somewhat organically. Managers and Business Analysts, for instance, still preferred to work in Word/Excel, so their pages was mostly just placeholders for Office Docs and attachments. This was fine by me, as long as they could always respond quickly with the right file/link if someone else in the team asked for something.
> The solution we had was to give one Space for each team/department in the company
This is the single biggest tip I would give any company who uses Confluence. For some reason, most companies I work for that use Confluence insist on using minimal separation of Spaces. I.e. IT in general has a Space, and my team has a folder nested 6 folders deep in some path that I can never remember and have to bookmark.
It makes search effectively useless. If I search for "X api documentation" I get 10,000 results ranging from meeting minutes that some unrelated team put up that just happen to use those terms, to pages from other teams documenting how they use the API.
A Space should be treated the same as a Jira project. If I had my way, I would create a Space every time we created a Jira project.
And my biggest request for the Confluence team would be better markdown support (I should be able to indicate that I want to type Markdown without having to click through a giant list), and a way to set up a space to sync from Markdown files stored in Git. Some of us don't want to use the WYSIWYG editor, and I would love to be able to use an MR review process for documentation changes before they go live.
From Steve Yegge's famous Rant about Google not understanding platforms:
So one day Jeff Bezos issued a mandate. He's doing
that all the time, of course, and people scramble like
ants being pounded with a rubber mallet whenever it
happens. But on one occasion -- back around 2002 I
think, plus or minus a year -- he issued a mandate that
was so out there, so huge and eye-bulgingly ponderous,
that it made all of his other mandates look like
unsolicited peer bonuses.
His Big Mandate went something along these lines:
All teams will henceforth expose their data and
functionality through service interfaces.
Teams must communicate with each other through these
interfaces.
There will be no other form of interprocess
communication allowed: no direct linking, no direct
reads of another team's data store, no shared-memory
model, no back-doors whatsoever. The only communication
allowed is via service interface calls over the
network.
It doesn't matter what technology they use. HTTP,
Corba, Pubsub, custom protocols -- doesn't matter.
Bezos doesn't care.
All service interfaces, without exception, must be
designed from the ground up to be externalizable.
That is to say, the team must plan and design to be
able to expose the interface to developers in the
outside world. No exceptions.
Anyone who doesn't do this will be fired.
Thank you; have a nice day!
I think about that a lot when designing any system, machine- or human-centered, that needs to communicate with a disparate group of entities. Encapsulate the implementation details to those who are closest to the actual information and have enough power to take action, and make the contact interfaces very explicit. This alone will get you 85% of a functional system. The rest is just selecting actors in your system that know how to cooperate and understands these boundaries.
The biggest problem is that "everything else that was tried" wasn't from experts who truly understand information management, nor has our industry learned patterns from other industries that also have similar problems.
I'm trying to do that work now. It's not even that I don't think it can be done in confluence or wikis in general, but rather we don't have a great methodology in organizing it.
I am afraid I won't be able to help you much there. Every place I saw trying to come up with a grand top-down scheme to organize documentation failed.
Too much structure, and people will wait until they have all of the details needed to start contributing, or they will not contribute unless it's "their job". Too much flexibility and they don't know where to start.
I found that it was always better to let documentation and knowledge sharing follow the same principles as code: let it come bottom-up, see what patterns emerge and only worry about structure when the current practices hit a bottleneck. But then again I never worked on any project that I had hundreds of people directly depending on the documentation, so it might not work as a strategy for larger-scale organizations.
I've thought about this problem a lot and the conclusion I came to is that tools like Confluence are like the original Yahoo directory of links. Organizing seems like a good idea when there are a small number of items, but it quickly becomes unwieldy. What I've settled on, while not perfect, is shared Google docs where owners of the doc allow suggestions to help keep it up to date.
Also have similar experience with Confluence, as an alternative: we adopted a VuePress static site that we host internally (behind proxy), which basically just renders a bunch of markdown files. For easy discoverability of content we use Algolia's documentation search on top of it. For updating content we either use git locally for technical people, non-technical people can also directly update the content on remote git via gitlab interface. This has been working really well for us once setup, the main challenge we still have now is how to effectively communicate changes to the relevant people at the most appropriate time.
Your knowledge system keeping in sync with your version control is also a major plus, this is the primary reason why I don't like tools like Confluence, because it's easy for them to get out of sync with the actual system, and this can require too much coordination.
> it's easy for them to get out of sync with the actual system, and this can require too much coordination.
I don't follow. How much do you have of your non-techies updating your knowledge base and how do they get to know if what they are updating is "in sync" with the system if the changes are making are orthogonal with the functionality?
It seems your case is mostly about documentation of the technical product, specs, requirements. Yeah, this can go to your version control, and I would bet that you could find a Confluence plugin that would generate the documentation from version control and sync with the rest of your Confluence pages if you wanted.
But I really, really doubt your method can scale beyond the IT side of any middle-to-large organization. The moment you ask Business/Customer Support people to actually go look at anything like Gitlab/Github's interface is the moment you lose 90% percent of buy-in from both non-techies and management at any company that is not absolutely dominated by Software Engineers.
Requiring integration with version control is a convenience for engineers, but it is so far from the tooling from those that live on Excel sheets that you might as well ask them to never touch the documentation side.
Granted, we're still a fairly small organization (+- 10), but our business and customer support people are also using Gitlab to maintain our knowledge base: once you properly guide them on how to use it, they are definitely able to handle this. All the actual git operations happen under the hood of the web interface. So we do strongly believe this is scalable, at least for our use case. This has been working fine in fact for long-lived information across multiple departments (not only technical docs, but also e.g. sales/customer support guidelines). For short-lived information we use Google Docs (e.g. meeting summaries).
> All the actual git operations happen under the hood of the web interface.
The interface is not so much what I object to it. It is the fact that you mentioned "being in sync with the system", which I assume you mean "being in sync with the codebase/released code".
There are plenty of things that happen on any company that have no relation to the code, and you are telling me that you have people on the non-tech side which are expected to understand on what branch of the repo their contributation with documentation is supposed to go? Are their milestones and projects always dependent on the codebase? This is the part that makes no sense to me.
> So we do strongly believe this is scalable, at least for our use case.
I am not telling you that what you are doing is wrong, but scalable it is not. Beware the usage of the Royal We when you say "our use case": are you speaking on behalf on the whole company or just the tech team? This is key difference that you will learn as the organization grows.
> There are plenty of things that happen on any company that have no relation to the code
Some more details about our approach that addresses your concerns:
(1) for content changes unrelated to code, anyone (tech or non-tech) is able to open a new MR, and after approval it automatically gets merged into our reference branch and deployed
(2) for content changes related to new (unreleased) code, the input from non-tech people (e.g. customer support) is usually requested via an already existing merge request (via a mention), they can then add their input/content via gitlab's interface straight into the markdown files (and see a live preview), this way we ensure this sort of content goes live along with the code and requires no extra coordination
> I am not telling you that what you are doing is wrong, but scalable it is not.
I hope with my clarification above it makes more sense.
> when you say "our use case": are you speaking on behalf on the whole company or just the tech team?
On behalf of the whole company: we have a single product/platform that is continuously increasing in complexity, and it really helps to have a single process in order to maintain a knowledge base that covers as many aspects as possible (tech and non-tech). We believe this approach will also minimize replication of content across departments (facilitates cross-linking), and we're intending to also create an aggregated search (next to the individual search) across all categories of our knowledge base (product/engineering/support/sales/..), in order to more easily retrieve relevant content.
> Beware the usage of the Royal We when you say "our use case"
I am not implying this is set in stone, we (as a whole team) thought long about this flow, and for now it seems to work great, and I hope (responsible for maintaining this technically) that it scales up to some point far enough in the future. I'd say we were mostly inspired by Gitlab, they seem to adopt a similar approach, and that seems to be scaling quite okay over there :). We've noticed ourselves that the general "documentation mindset" has definitely grown among the team because of this specific process and the ease of adding content, updating content and retrieving content.
So essentially you are saying that the tech side still works as gatekeepers of the documentation - need to approve MR's, requesting input via mentions - which is fine until the organization is skewed to the tech side.
As for Gitlab, their work processes are interesting, but I assume that most of the non-technical work there goes to issue tracker and the wiki? I am failing to see where there a strong connection to the code repository is required there.
Afaik, Gitlab's wiki/knowledge base is also a separate repository and content is added/updated via regular MR flow. Our knowledge base is still part of the main codebase due to practical reasons (CI/CD related), but we'll eventually also migrate this to a separate repository as well, to avoid the unintentional gatekeeper aspect as you mention ;).
Futureperfect: can those convos be mediated via a wiki?
While using Confluence, I tried to keep track of activities. Like when another team updates an API I'm using. Manually. IIRC, I could watch pages. But I couldn't follow individuals, topics, teams, etc.
In the wiki page proper? Theoretically, yes, but it would involve a lot of discipline from everyone in your team.
One thing that worked for our team (i.e, our Confluence Space) was to keep all pages with a "comments" page at the end. Any comment that came up on that page was basically meant an "issue" to be resolved in the documentation: clarify a point, update another, link to a related page with more details, etc. Once the person that created the comment was satisfied, we treated the issued as resolved and deleted the comment without prejudice.
FWIW, I've been advocating everything (everything) gets a TTL. Like renewable leases. Culling is such a huge problem, burden. As others have commented (in the org-mode thread), upkeep becomes onerous. It may be cheaper just to rediscover stuff that's gone stale.
--
There are different types of convos, interactions, transactions with their own use cases that all need to be implemented specifically.
All of the purpose built focused tools I've seen, per that cliche, eventually add an email feature.
And I can't think of a hybrid solution. Maybe bug trackers.
> I've never really "got" it when it comes to tools like Slack or Teams.
I've used everything from IRC and ICQ through XMPP and HipChat to Slack, Discord, and Teams and let me share why I think Teams is so much more than all of its predecessors.
As someone who manages a large Active Directory domain and Office365 setup, Teams comes free. All I had to do was install the Teams client on users desktops and everything just worked instantly. Users logged in, installed it on their mobile devices, all secured by O365 2FA. I created an AD group for managers and all of them got the ability to send out Teams meeting requests via a local dial-in number for $4/month. When they schedule a meeting, the attendees can use Teams desktop app, mobile app, web app, or just dial-in via phone. Without this $4/month, users get everything except the dial-in phone number.
I created a few "Ask [Department]" channels in Teams and my users are using them in the appropriate way without over posting. Users message others in groups of 2-5 and create their own channels without asking IT. My users have conducted Teams webcasts for 40+ attendees, frequently video chat with groups of 8+, and have drastically reduced texting via their personal cellphone or using the old internal IM client. All of this without any training from IT.
So Teams is different because except for email, it has replaced text IM, SMS/MMS, forums, audio conferencing, video conferencing, and screen-sharing. It can also replace file-sharing and co-authoring but for business reasons I disabled that as much as I could. Also it automatically integrates with Outlook Calendar so users are alerted the same as before, just with a Join URL now. We were paying over $2k/mo for audio conferencing and now it's barely a few hundred dollars for a better, more stable product. Other than audio dial-in, Teams is effectively free for us because we have been on the O365 Enterprise plan for years now.
I last used Slack about 6 months ago and back then it had poor audio conferencing and no built-in video conferencing or screen-sharing. I was hoping after they bought Screenhero, at least screen-sharing would be native quickly but that was not my experience. Overall I like Slack, just that for enterprises already on O365, Teams is a no-cost no-brainer. Not even going to try setting up Slack.
Every few months I revisit the idea of Teams and ask around whether the notifications have been fixed. The answer is always no.
Until MS figures out notifications, I won’t be switching. It is hard to understate how annoying it is to not be able to trust accurate notifications and notification settings.
Apologies, not sure what you mean by notifications. Do you mean email notifications of unread Teams messages? I get a few of those and just ignore them. When I look at the Teams apps, it's very clear what I need to respond to.
Notifications on my laptop or phone about DMs or @‘s. There are certain people or channels that I want to get notifications from. Since I can’t trust the notifications I end up having to leave Teams open and check it constantly. This is distracting to me.
Most messages don’t have an expectation of a timely response. But of those that do, I need to be able to rely on notifications.
So I'm not the only one. At least once a week for 4 years I have tried fiddling with my notification settings in several different slack projects because they're not functioning how they're supposed to (not how I have set them up).
Could you provide examples regarding how they've failed?
Have you spoken with Slack directly about this? I've brought up several issues to their "Feedback" area and usually have very quick responses for a company that services as many people as Slack does.
Discord's notifications are on-point, so competition _there_.
Of course Discord has the image problem of being marketed to gamers (and that's fine, because it lets them focus their efforts), but as a tool it is pretty well crafted.
So maybe I've just never seen it used properly since most of what I've seen is more along the lines of a single "General" channel that's way too hard to follow. I can definitely see the value in your "Ask [Department]" explanation which is a great example.
I've only really evaluated Teams for one use case and there were limitations that made it impractical. I was hoping to set up Power Automate rules that would let me forward an email to a group and have it auto-create a Planner task, auto-create a Team Channel with a link to the task and a copy of the original email posted, and reply to the email with a link to the channel. Then all conversation about the task happens in the Team Channel and someone can own the task to make sure it doesn't get forgotten. When the task is closed, the channel gets archived. However, there's a limit of 200 channels per team, so it's not good for short lived channels. Planner also has some crazy low limitations, but I don't recall what they are.
I know that sounds a lot like an issue tracker, but the hope was to trend towards the other scenario you describe where email, IM, SMS, etc. are all replaced by a single tool. Just email + SMS are enough to de-thread a conversation and cause confusion / miscommunication.
My users have conducted Teams webcasts for 40+ attendees, frequently video chat with groups of 8+
How are you finding the Teams limitation of only 9 people on screen at once in a videoconference? That is the one major flaw that Teams lags the competition in, e.g. Zoom.
Personally, I can't see a reason to see these many people at one time.
Nine people on the screen is a nice ratio, and if the 10th person says something, they take the place of the person that hasn't said anything the longest on the grid.
There are other reasons I dislike Teams, but this isn't one of them.
they take the place of the person that hasn't said anything the longest on the grid
This is just a recipe for excluding people who don't speak up. In a larger meeting I particularly want to prompt juniors to speak up, for example. I also want juniors to see each other so they feel more a part of it.
If you are only interested in the last person to speak that's fine but you might as well just use a voice call for that.
Voice calls would reduce Zoom fatigue. I’d argue having everyone on screen at once is an edge case, and one that causes more stress than benefit to participants.
I turn my video off during video conference calls, but others may not feel they have the autonomy to do so.
Then it is on you, as the moderator, to step up and call on these silent participants. If not then get tooling that does but, FYI, none of the major video platforms have an option to avoid your recipe for exclusion.
Honest question, but why would I want to see more than 9 people in a video conference?
My vision of video conference is that one person is sharing their screen or something, why would I want to watch other peoples avatars or rooms in all kinds of video quality
If you are a trainer, then having immediate access to all the attendees is fairly important.
I'm in the process of "refactoring" my training approach to a videoconference approach (using Zoom).
I'm actually really surprised at how intimidating the process has been. I've been doing training and speaking in person for a long time, but not via Zoom.
It will work out, but the biggest issue that I'm encountering, is not having access to "immediate feedback."
Virtually all my teaching is online, in a dedicated tool. Of course I used slides and approach to teaching that i inherited from previous teachers of the course - which includes heavy use of polling using the builtin easy polling feature of our online class tool (collaborate ultra).
Once i taught a guest lecture in zoom. I ended up using directpoll.com to approach the polling features I'd normally use. Lots of yes/no questions, easily asked and answered (always same url, can watch answers coming in), some exercises.
Extremely positive response. Simple, oft-used interaction truly is a game changer - even if limited to yes/no.
Honest question, but why would I want to see more than 9 people in a video conference?
Because it more closely mimics the experience of being in a room. For example maybe I want to listen to, or be, the person speaking while gauging reactions from facial expressions. I have a 30" 4k monitor, I can easily have 20-30 faces on screen at once in software that supports it.
If you read the MS forums there are plenty of complaints about this, a typical use case is a teacher or lecturer who wants to see their entire class.
I am totally OK with the number of faces on screen at once being a user-configurable parameter in the client - but 9 is a hard limit baked into Teams.
Also, if you are a host/co-host, the order of the "Participants" list keeps shifting. I end up accidentally muting/unmuting people, because their position changed between my moving the cursor over their name, and clicking.
How is that a limitation? The person speaking should have focus and even then can you guarantee that everyone is going to use video? The side bar chat is a good feature for running conversations while another is presenting.
FWIW We are still dealing with the four persons on screen limitation and even then there is a good chance of no one having video. Management wisely decided against forcing the issue. Plus throw in that many times we end up with someone sharing their screen.
No one turns on the video at our corporation. Everyone only uses audio. We've actually hit the 250 user limit on some of these Teams conference calls (major outage, all departments needed help), and not one of them bothered with video.
For many projects, you still can - if you know where to look.
It's what makes FOSS "support" (i.e., having someone to talk to about a technical problem in a meaningful way, so that you get closer to resolving it) so much more effective than costly support contracts with big and faceless corporations that make you jump through all manners of hoops - only to end up with some expert level blame-shifting, and no real solution in the end.
> a handful of mega topics that go on forever with worse (or no) pagination.
Your conversations with the guy next to you, or the guy at the watercooler is unstructured.
When you communicate about a specific issue you might communicate in an email or issue management system, but that doesn't mean there is a need for unstructured communication too.
> people seeking out help should RTFM
> Maybe Slack, etc. are popular because the informal nature lets people skip the part of the process where they're expected to make an effort.
All informal/unstructured communication isn't just "people asking for help". It's navigating an organization and just communicating (who is it that manages thing X in our company? I can't use email today, is it just me? Who wants to go out for lunch?). It would be absolutely horrible to fit all this impromptu and unstructured chat into a forum or issue management system.
I think the success of Slack is that it's so easy to set up a team. It feels like Trello: you are up and running in a minute. As a freelancer I got a list of Slack teams and it is just very easy to switch.
But like you said: that's about it. It is slow, the text input box is horrible and most of the time you loose track of conversations.
What I lately notice is that teams start to use WhatsApp groups as Slack replacement. To me that shows that Slack is just a messenger.
Using WhatsApp groups for me is terrible since it means all my private and business stuff lands in the same app. Slack has neat features like tracking time zones and auto silencing. In WhatsApp im left with the option to completely mute. Terrible
" To me they've always felt like a forum with a handful of mega topics that go on forever with worse (or no) pagination."
After using Slack and Teams I have concluded that good, old forums would probably be a better solution. You can discuss a topic in focused way instead of big discussion threads that never end and have tons of things mixed with each other.
Problem is that you can't propose such a thing in a company because something old can't be good.
If a big reason for the popularity of media like Slack is that problems get solved quickly, then it may well be worth it.
One of the reasons I use StackOverflow, is that I can get a question -often a “showstopper”- answered fast.
I’m quite capable of solving every question I ask, given time.
It’s that “time” coefficient that I need to reduce.
If I can resolve an issue by quickly formulating a question to get a useful response in fifteen minutes (versus spending a couple of hours trying different approaches), then it’s worth it -even if it is delivered with a side dish of condescension.
That said, I’m not really a fan of Slack, or its ilk. I don’t like letting others have unfetterd access to my contiguous time.
A forum like SO is better suited to that, where I’m not bothering others. In fact, they compete with each other to quickly answer my question (and maybe take dig at me).
Mixing in users asking and answering questions keeps developers honest... ehh I mean kept. You also don't go blabbering about lunch on topical irc channels.
I agree that Slack fails as a structured discussion tool, but I find that having one giant notification repository with channels that anyone can subscribe to and filter is great. A server is down, someone is ordering food for lunch, a new customer signup with a premium plan, a competitor tweets something relevant, someone has a good joke, etc... Then unlike email it allows for a quick reaction and discussion on the topic. Also as a generalist I find that being able to have some notifications and sometimes participate without silos on marketing and sales topics (and reciprocally) pretty valuable, both for the company and my personal growth.
Slack is fundamentally just a persistent chat room, so yeah, there's really nothing groundbreaking about it. A decade ago Microsoft Office Communicator or IBM Sametime had similar, if more clunky, solutions that did the same things.
Sorry to see there has been no mention of Zulip so far. I fooled around with Slack a little, and then Zulip. And in my opinion zulip hit that sweet spot between email and chat. I really like the way conversations can be segregated into actual conversations. The trick to using it, I've found, is to set team expectations that posts might not be replied to until later in the day. There is something subtle about slack that sets your expectation for immediate gratification, and that drives the exhausting 'always on' culture.
I imagine you are all relishing that sweet irony/hypocrisy of a tool that facilitates distributed work, not permitting its team to work in a distributed fashion. Culture fail!
Fifteen years ago or more, I was able to work pretty effectively with a team using email and IRC. I know IRC is out of fashion now, but my point is that a lot of the challenge is team culture and expectations, and software doesn't really fix that problem.
I read the GP's comment and wanted to reply, but then I saw your comment. Completely agreed, Zulip is exactly what I've been looking for, and email+XMPP (one on one) was the best communication mode I've ever used, though I have a feeling that Zulip will be very close to that.
We've been using Zulip for a year in my company and we love it, the ability to just follow the topics you want and ignore the ones you don't is great for focus, and the stream view is perfect for catching up on everything. I wrote up some thoughts here:
I think one of the strengths of email is that it forces you to be less-synchronous and take the time to craft a somewhat long, point-by-point reply, rather than just fire off a quick message. That's something I'd like to see Zulip encourage more.
Moreover email is federated, distributed & seamless.
In my previous startup, A Slack account was the second thing I created for a new employee after an email account. Everything from real-time communication, screen-sharing, log/product/system health alerts, analytics to daily tasks summary were handled with the help of slack bots; we ourselves built a bot for the platform.
But the productivity benefits of real-time communications are dubious at best. Apart from alerts(read emergency), email communication is better than real-time chat IMO, as the lack of peer pressure to reply fast enables more thoughtful communication.
So to test this, In my current work(Startup Coaching) I communicate only via email with my clients, no phone calls, no chats. It's been over a year and it's been great for productivity for both myself & my clients; of course this has been possible because there's no emergency communication involved.
When I see people asking for discord channel in Internet forums/subreddit which has no use for a real-time communication, it worries me.
What’s entertaining to me on this topic is that I am no more “immediately available” on slack than I am by email - I close out both when I want to get work done.
And, based solely on various productivity blogposts which come up on HN and Reddit, I’m not alone. I can even say that the number of us “going offline to work” types is growing with time.
To me the big benefit of Slack over email is that Slack is only communication with actual humans. My email inbox is chock full of automated emails from various websites / services.
> To me the big benefit of Slack over email is that Slack is only communication with actual humans
Until folks in your org start adding in slack integration bots. I have multiple channels that are nothing but alert/notifications about systems. that separation may be useful, but it definitely requires some discipline - I've been on some teams where people wanted to throw in automated slack integration messaging in to the 'regular' channels "so we won't miss anything".
Yeah, we have a few of those at work. But I've muted those channels. Too noisy to be useful. The only one I keep on is downtime notifications, which really do need to be responded to ASAP.
Not sure, but I think this got me fired from a job. Slack was a main channel for our group of 30. Critical messages in real time on the (several) channels. So, must monitor channels in real time, all day. Whoops, no time left to get real things done. Why aren't you getting anything done?
I’m sorry, but this is poor company culture, not a Slack issue per se. A company with this sort of issue would struggle with any communication tool or medium; the root issue here is an utter lack of understanding about proper working conditions and the concentration needed to do this (and most any) sort of work.
I’ve been in a similar boat at a similarly poor company.
It is trivial to use Slack in a non-destructive way. Our company follows a simple rule. If you need somebody’s attention, you @mention them.
We do not have to monitor anything. It is expected that you will keep an eye on your team’s channel when your time and attention permit as of course there may be some hallway-style conversations going on, but you are never required to monitor any channel, much less several channels. That is what mentions and notifications are for.
It is absolutely mind-blowing that some companies screw this up so badly.
Well, yes, it was ultimately stupid for the group to use Slack in this way. And yet, Slack invites it. It's a bit like cocaine. There are certainly good uses, and still it's easy to slip into bad uses.
As for the @mention, in my current job, some stupid twat kept doing that in a broad group, and unfortunately our current tool (Teams) doesn't provide an easy way to shut them up. So, fuck that, I removed myself from the (otherwise useful) channel entirely. Fail.
Chat is great for useless nonsense. Anything else requires discipline, which rarely exists (the military excepting, perhaps).
I guess this is subjective, but I've never found Slack (or IRC, or Discord, Hipchat, etc) to somehow encourage @mention overuse/abuse.
I just don't see it. Perhaps more to the point, I can't really fathom a communication medium that somehow wouldn't allow an overzealous or inconsiderate person to become a distraction. Unless that system made communication super onerous in the first place.
Perhaps somebody could write a Slack plugin that limits a person to a certain number of @mentions per week, with the option to "purchase" more by contributing money to the company party fund or something :-)
At the extreme, everything is poor company culture, not <insert tool> issue per se. That is not a good argument.
Being tagged @mention several times a day, with the expectation that you respond right away (ie < 3-5minutes) is just as much a drag on productivity. And I have not seen any company explicitly (put in their written guidelines) states that you should not be expected to respond to a slack @mention right away.
Being contacted several times per day seems totally reasonable for, I think, the vast majority of jobs in existence.
Few jobs would allow one to be totally dark until you arbitrarily decide you would like to crawl out of your figurative cave and interact. If you truly have that kind of job (and certainly, they exist) then yeah, maybe a real-time-ish communications platform is simply not right for you or the team.
Now, I am a programmer. One who often struggles with attention issues and getting into the zone.
More than many, perhaps, I realize that even a "quick" 1min. interruption can have a far greater drain on one's productivity than would be immediately apparent - it might take 5, 10, or 30 minutes to get "back into the zone" after an interruption.
Having said that, though, it still seems reasonable in all engineering jobs I've had for others to ask me questions periodically throughout the day, especially as I have gone from junior to senior engineer. Typically if something is blocking them. I don't want somebody sitting around for 1 hour or 3 days because they are missing a piece of the puzzle, held by me, that is leaving them at a standstill.
At the extreme, everything is poor company culture, not
<insert tool> issue per se. That is not a good argument.
Sure as heck is. It's not realistic to expect a communications tool to somehow magically allow only "good" communication. Therefore, we have to resign ourselves to considering tools that:
(a) Make efficient, respectful, productive communication the default. Broadly speaking I would define this as making non-intrusive async communication (but making those conversations easily searchable/browsable so you can "catch up" if desired) the default.
(b) Does not somehow encourage bad behavior.
I have plenty of nitpicks with Slack but I believe it passes those criteria. Some would say that the existence of @mentions makes it fail (b) but I can not agree. Certainly at my current employer, we have a nice Slack culture and it required zero pain to get there. Makes it a decent tool in my book.
> Being contacted several times per day seems totally reasonable for, I think, the vast majority of jobs in existence.
Sure. I do not agree that developers belong to the same group with the vast majority of jobs with regards to interruption and synchronous communication though (async slack is fine, if the developer got to decide when to see and reply to the @mention).
Being blocked for 3 days is definitely bad (although we do not solve it with Slack), but I do not agree that someone being blocked for an hour is worth the interruption of another developer. I just took on an engineering manager role lately, which gave me more time observing others. And one thing I have noticed is that a couple of junior developers pinging each other every 30 mins to ask a question that they might or might not be able to solve with some more effort just ruin everyone's productivity.
It seems like we end up agreeing with each other on both your a) and b) point. So I will just make my point more explicit: too many team culture expects synchronous Slack usage. And I do not know how much Slack encourage that, but it is definitely more synchronous than email, which Slack is supposed to replace
So I will just make my point more explicit: too many
team culture expects synchronous Slack usage. And I
do not know how much Slack encourage that, but it is
definitely more synchronous than email, which Slack is
supposed to replace
Slack certainly makes gratuitous "drop what you're doing and think about my problem" messaging easier than email. But email makes it easier than sending it by snail mail or carrier pigeon.
To say that Slack encourages that kind of thoughtless communication... I can't agree. Those @mentions are not the default. You have to either consciously think, "yeah -- this is worth interrupting my coworker" or fail to consider your coworkers' feelings at all.
If developers are being lazy and using their peers as substitutes for Google, that needs fixing at the root level.
It's possible they honestly aren't considering their coworkers' feelings. It's worth discussing.
I have guided junior devs in the opposite direction before - they have sat there spinning their wheels for too long before getting help. Never had one that erred in the opposite direction!
I generally tell them that if they are spending much more than a half hour stuck, to please ask me for help. I've never worked with deadlines so lenient that I can have engineers losing large chunks of days, or entire days.
Now, if they were needing help more than a few times per week, I would know there is an issue there.
Maybe they just haven't worked with Framework XYZ before and need time to get their bearings. Maybe some pairing is in order, or they could take a class. Maybe they were a bad hire. Maybe they are inconsiderate. Maybe the thing they're doing is just too advanced for where they're at, experience-wise. Maybe they need me to suggest that they could batch up their questions and we can some time together going over them a each morning at a regular time. Whatever the reason, I would like to stay on top of it.
This conversation has made me think, though, that a Slack plugin that limits team members to a finite amount of @mentions per ___ days might be a fun experiment, though. :-)
> Being contacted several times per day seems totally reasonable for, I think, the vast majority of jobs in existence.
If it's your boss, or one of your critical colleagues, maybe. If it's some idiot in a distal group trying to justify their existence by being vocal, hell no.
And if the chat tool doesn't have a "mute the idiot" feature, that makes the whole thing useless.
If it's your boss, or one of your critical colleagues,
maybe.
I'm surprised a few people pushed back on my assertion that it's okay/normal to have coworkers synchronously contact you several times per day. Are there a lot of engineers who are able and permitted to work for entire days on end, totally "dark" without some realtime pings from coworkers?
If it's some idiot in a distal group trying to
justify their existence by being vocal
I'd certainly agree here. An old manager of mine referred to these sorts of outside-the-group disruptions as "drive-by shootings."
I have always liked that phrase. Those disruptions are definitely a great way to unexpectedly murderer productivity.
You need cross-group pollination, but random productivity-murdering drive-bys are not the way to do it.
What’s weird to me about this is no one would have their knowledge workers also be on call for external customer support full time, but for some reason that’s the norm with internal customer support.
I've had non-remote jobs that were similar. A lineup forming outside my cubicle. Days when I got absolutely nothing done except address constant interruptions from others who needed help Right Now.
I've never really loved email, but hell it just works. What I like about email is that people don't interrupt me or try to chitchat with me, they just state the bussines of things and I can decide wether I want to react directly, in which folder to move or with which label to tag it (automatically or not), etc.
If somebody forgets something in a mail I could just write back or call. And if I really want to chat, matrix/irc or a signal group should be good.
For other things (by no means related to code only) repositories are good, or issue trackers like trac.
I never really liked slack although I tried. It doesn't really feels like it focuses the mind of a group and helps you move forward.
I think the asynchronous nature of email makes it a superior communication medium. With slack and other messaging apps, we all end up writing short bursts of whatever is on the top of our head, without much thought or organization of the ideas. In contrast, with email, you can take some time to create a concise and well-organized message. I find email threads to generally be shorter than the comparable slack threads with each email adding more useful information.
>With slack and other messaging apps, we all end up writing short bursts of whatever is on the top of our head, without much thought or organization of the ideas. In contrast, with email, you can take some time to create a concise and well-organized message.
This hit close to home. When writing emails I sometimes find gaps in my own logic or alternate recommendations while writing the email, and am able to address those before sending.
With Lync, too often I end up "blurting" assumptions or guesswork that doesn't always necessarily end up being true. While blurting out ideas can be useful, depending who you're talking to, it can also make you look like an idiot.
With email people also don't leave you hanging with "hey...". Please don't send "hey" to me. Go straight to asking your question or favor.
I typically check my email once a day, first thing. Occasionally I will also check them if I'm bored around 4. If I have to write an email, I normally suppose that takes half an hour. I don't if emails use less words than slack threads, but I think I spend more time producing them. So "shorter" seems like the wrong measurement.
> Channel and message overload is arguably not much better than the email system it is meant to replace.
I still don't understand why this is surprising. Why do people continuously think that moving to another way of receiving messages will somehow help with the overload? At best it's only a short term solution, before all message faucets that are responsible for the overload eventually get migrated over.
Personally, despite their declared mission, I see Slack as replacing phone calls rather than emails. It suffers the same problems than phone : people writing fast without thinking twice about what they say to have a chance to put their idea in the discussion, lost forever knowledge because searching slack is a mess, short and meaningless interventions in the discussion, etc. It is indeed to me better than phone, because you don't have to reply within 5 secs when someone tries to reach you, so it's less interruptive.
But for business sensitive discussions where we expect a lot of efficient brain time and valuable discussions, hell no, send me an email.
Because of COVID19 my workplace has rushed right into Microsoft Teams. There's so much efficiency lost creating large-scale meetings and phone conferences. Coming from the land of IRC I've created a few teams with massive rosters, but nobody seems to really understand the paradigm. They see all these messages come in and they leave the team/discussion/channel.
I keep saying "mute the discussion" and @mentions will signal you if needed, but it is lost on folks who haven't done this kind of things.
They're used to discussion spaces being set up per-incident, instead of just lingering/loitering in a room.
I find per-incident discussion spaces far more productive. I.e. if you want to talk to me and some other people about something, create a space (channel in Slack jargon). That way everything about that conversation has it's own isolated history. I can control my notification settings for that conversation sanely. If I need to find a message from that conversation, I can limit my search to that channel.
My manager heavily pushes us to use Threads for that purpose in Slack, but Slack's handling of Threads is just miserable. It's one my biggest peeves about Slack. If I get mentioned in a Thread, Slack will ping me for every new message (and I've been pinged on threads that went on for several hundred messages). If I need to find a message in a Thread, scrolling back is useless, I have to use search and just pray I have the right keywords.
I think I'm just burned out on Slack; they need to find a method of communicating and invest into it instead of their current "you communicate however you want and we'll halfway support it" method.
Twist was a true game changer for our remote team, been using it for over a year now after 3 years of slack. Before, with slack, we also experienced the typical frustrations of it being very distracting, and the synchronous communication could often lead to unneeded tensions within the team. Since adopting Twist, our workplace is now much calmer and more productive! They also dogfood their own product, and their team has been remote from the start AFAIK.
(fyi, not affiliated with them in any way, just really happy with their product, they deserve a shout-out!)
The real issue is that no tool really will be able to work well for teams over 10-15 ish users. Its the same issue DropBox, Drive and Box has. They are really “just” glorified network drives.
Email by its de-central nature still is the best fundamental design pattern we have for a truly scaleable communication platform and i wonder if we will ever see a perfect mix of asynchronous and realtime messaging.
we're trying to create the perfect mix of asynchronous and realtime message. would love to show it to you and get your feedback: https://usepingpong.com
> Slack the company really needs to embrace distributed work practices if they want to actually build a tool for distributed work practices.
> Slack has totally become a drag on productivity and a net negative. Channel and message overload is arguably not much better than the email system it is meant to replace.
> My prediction is that Slack will be replaced quite quickly by the first tool that really nails remote messaging and coordination. Slack is not it.
"Slack the company really needs to embrace distributed work practices if they want to actually build a tool for distributed work practices."
The question is, do they? In the companies I have been working in, slack has been a communication tool like email or sms. Doesnt really have stance on whether the work should be remote or not.
FB workplace is an option. It has workplace groups and workchats, this helps differentiate half baked ideas being collaborated vs fully baked ideas to be published as posts. Allows for a lot of conversation and collaboration on workchat a topic while also keeping the signal to noise ratio in the workplace group high.
I used slack in my previous company, didn't like FB workplace at first, but I see and appreciate many differences now.
>by the first tool that really nails remote messaging and coordination.
What would that look like?
I mean, I hear what you are saying about channel and message overload, but I'm trying to imagine how this gets fixed. Seems like what I've seen is that when a channel gets too much chatter, it subdivides into more granular channels to the point that main channel chat slows. But then you have more channels to read and respond across... and the message overload often feels like a function of either too many people in the discussion and/or a signal to noise issue.
Outside the software development bubble, Microsoft Teams is starting to dominate in the way that Exchange did in the 00s. It's a huge advantage that it's free with Office 365. Basically, if your company is already a Microsoft shop, there's no reason to go out and get another enterprise collaboration tool. Teams has default integrations with the whole Microsoft stack, including Azure DevOps and MS Project.
Most of the companies I work with still use Slack for development teams, but even then the devs are usually running both Slack and Teams because the business stakeholders they need to communicate don't use Slack. Slack is already being replaced in a lot of orgs as a result.
I detest the constant distraction of Slack and I'm thankful that I no longer work in a place which uses it. A lack of discipline on sending out notifications, and you can be spammed all day long with workflow-breaking distractions. Even direct messaging can interfere drastically with your productivity. The requirement to down tools and immediately reply to random requests can really make you lose focus.
If there are organizations where distributed work / remote work is working very well, then I presume those groups have solved the "message overload" and "coordination" issues.
Or would you say there's a class of communication and coordination use cases that are best addressed by in-person (currently)?
Maybe they've some data based on which they are against remote work, and maybe that data will not be shared to public as they might have come up to conclusion that more remote work in their customers is better for an app like slack
I feel much the same way (work at a large company). I feel like Slack is a battle royale of one person's time versus another.
- What incentive is there for anyone to ever spend a second searching for anything when they can just DM or @ me?
- The @ in a large busy channel can derail me big-time. It churns up a lot of low priority and very unrelated questions/queries. It's like someone asking me to their desk to answer a question, and then announcing to everyone on the floor that I am there to answer their questions.
- Are you providing the answers or are you the one asking them? If it's a two way street, or you are the one asking, you probably love Slack. If it's a one way street where you only provide answers/help, you feel differently
- Seems to cater to Ask Alexa, Ask Siri type mentality. Things that were once covered by process or documentation, now devolve into "ask person or channel X".
- There is often a massive imbalance between what is urgent to me, and what is urgent to the person asking me. This was always an issue to some degree, but the immediate response requirement sometimes puts me in a place where I feel like I am encouraging bad behavior by answering quickly.
- Things that are "quick questions" often require a rather lengthy answer.
- Context is often often missing. This often happens with the people that hate e-mail, love slack, and end up asking a question to me about something that exists in e-mail. I end up asking for more context and then get forwarded the e-mail where I can figure out what the person was actually answering.
- Context again, I have to change focus to see what someone is DM'ing me about. In e-mail I can quick glance to see if actually urgent or not.
- No great OOO. With e-mail, if I am away for a bit I can put an OOO with a bunch of common questions/answers. With Slack options are limited, other than letting people know I am not available and to contact someone else. Maybe bots could help, I dunno.
- People can't complete full thoughts before hitting Enter. Hi (Enter). Have a quick question (Enter). Joe contacted me(Enter) Can we set him up with X today (Enter).
- People seem to be very dense about people in different time zones compared to e-mail. Normally not an issue since I use DND on my phone, but occasionally I've accidentally logged back in off hours on mobile somehow.
- Threads vs. No Threads Warriors. "No threads" people complain about not seeing replies in threads or it slowing them down. "Threads" people complain because it becomes impossible to link to it later. I think is where you create a temporary channel to deal with it, but that's too much work for most people.
- I had someone accuse me about being set to Away for "4 days" and asking my boss where I was. I went offline on a Friday for a couple hours to meet a deadline, and then was away for meetings for a couple hours on Tuesday (Monday was a holiday for him). If he had just asked his question on Friday, it would have been answered Monday at the latest, but probably Friday. Instead I get a "wtf" because I wasn't on the precise two times he happened to look.
In general it seems like the tool is significantly worse now that it's used by the whole company. At one point it seemed to just be a replacement for e-mail dist lists, which I can understand. As usage grew it became more of a synchronous tool (demand wise).
This bugged me about Atlassian when I worked there as well. On one hand, one of the key marketing messages was about working from home, and additionally, they had an evangelist talking about the "future of work" being remote. On the other hand, only a couple teams out of probably 50 allowed remote work. Signs are showing the pandemic is changing attitudes, hopefully permanently.
I guess the saying "the future is here, just not evenly distributed" can apply to companies as well as society as whole.
Don't underestimate how much inertia will be established after a year plus of perma-WFH. That's a lot to try to come back from. After a whole year, most people who are renting will have had their leases expire, and may have moved farther out where they can get more value for their money.
Yes, but you rarely can put it in the open this way. It's one thing to say "I think remote teams are hard to make work efficiently, let's not risk that" and another is "I crave control so I won't allow remote teams even if it were easy to make it work". And you could get away with the former easily as top management is happy with "don't mess with a thing that works" approach. But now when we'll have an example of remote teams working, the former argument is dead. Now if your real argument is the latter, you won't be able to lay it bare for everybody to see, so insisting on banning remote work would be way harder.
Corporate middle management is starting to learn how to control workers in a distributed environment. It's catching on in corporate America, but people probably won't like the results.
If your team or company's culture sucks, then Slack will amplify it. On the other hand, if you work in an environment where people respect each other's time, communicate clearly and don't try to pass the buck, then Slack will amplify this too.
Our experience has been very different from many of the people here.
We were forced to switch from being in-house to remote only due to the Covid-19 outbreak. We were using Slack before the whole company started working from home. If it weren't for Slack, our transition would have been much more difficult.
The features have been great, including the ability to start a call that anyone in the channel can participate in. The UX has been great. The uptime has been solid too.
The biggest problem with Slack for me is how slow it is. I have been using chat apps for a couple of decades now, starting from mIRC to IM chat applications. And slack is by far the slowest chat product that I have ever used. Takes a few seconds to startup, takes GBs of ram just so that I can send chat messages and the interface just isn't snappy. Earlier I would keep chat apps open in my system tray all the time since they were so lightweight and barely consumed any resources, but every now and then I need to shut slack down if I'm running out of memory.
Exactly. Just 30 minutes ago I observed delays between me typing text and the text appearing in Slack's text input box. With my bare eyes on an idle system with 32GB RAM and a quad-core i7-6700! It isn't even rare. That's just absurd.
Back around 2012 I would have Empathy (XMPP) always on and I would use GNOME's wonderful "reply in notification" UI to talk to people. It felt snappy and its resource use wasn't noticeable on a laptop with 4GB RAM and a dual-core CPU. Modern chat apps are crap.
Desktop Slack apps are based on Electron and just so you’ll get a sense of the bloat of it - all Electron apps have bundled in drivers for Xbox 360 controllers.
I'd recommend Ripcord [1] as a blazingly fast native app that can talk on Slack and Discord while taking a max of ~50-100MB of memory at any given time, even with lots of connections/channels open.
I tried ripcord and enjoy the idea of it, but I can't replace my slack workflow because ripcord does not have slacks keyboard integrations.
What ends up happening is I try to leave ripcord open and then every time there is more than just basic use of slack, I have to open up the original electron client to post pictures or polls or similar.
Yeah, I agree that's an issue. It's funny though because even if I'm running Slack in my browser, if someone posts a picture, it shows a thumbnail and you have to click on it and open it in a new window. It's such a horrible workflow. Ripcord makes that even slightly worse because if I click on an image in Ripcord, it launches my browser and I have to log in to Slack, navigate to the channel with the image, click on the image to open a new window... etc.
Given that Slack doesn't work remotely, I also have to ask, do they actually use their product? Because I can't imagine someone who can change the product putting up with the ridiculous workflows that Slack forces on you.
Agreed. Speed is only half the problem with Slack. The other half is lack of integration with the system it's running on. Ripcord doesn't do any better than Slack at this, and in many cases does worse.
Does that reduce the ram footprint and the slowness of the thing, or does it just mean the task manager/system resource monitor files it under "Firefox" instead of "Slack"?
(I write and dislike web apps since I tend to lose them. Having dedicated windows which don't host all the links I click on to documents is much more conducive to my organisation style. Actually, I would go so far as to say that I wish web browsers would still let you turn tabs off.)
For me, its not about the resource consumption of my computer, its about my personal resource consumption. Keeping it away from my taskbar (on an entirely different workspace, in fact) helps keep it from being an excessive interrupter.
Also they go out of their way to make it slower, add more buttons that make you take more clicks, and just use up useful real estate with buttons that nobody ever uses.
The entire UX for slack is just getting more cumbersome to the point where they added a lightning bolt so they dont have to think about all the crap they are shoveling in their program, and now the useful stuff is not available except beyond this lightning bolt.
When native apps start running into this problem, they allow you to customize defaults, but slack just wants to be the worst of both worlds imo.
How does it compare to signal? Whenever I load signal on desktop it can take 30-60 seconds because it loads hundreds of messages from the phone into the desktop app. It used to be terrible on my older computer, it would take 5 minutes to open signal there.
Someone said that Slack was the "open office" of communication software. I think this is a good analogy - but at my work it feels more like working from a huge, lively dinner table. Sure - you can put on some noise cancelling headphones and ignore the conversation, but it will still be distracting, and worse, people will judge you for being antisocial.
Every once in a while, if you are lonely or your current task is sporadic and slow, it makes sense to bring your computer to the dinner table and casually work while being part of the party. However, if this is your environment 40 hours a week, its highly taxing to productivity. My only answer is to mute all Slack notifications or turn off Slack all together. This works in the short term, but in the long term I bet it will be detrimental as I wont be seen as a "helpful" person that answers questions. Ironically, I think it's exactly those types of qualities that will help you to get promoted. Our Slack rewards the developer that just "hangs out" and answers questions all day instead of getting meaningful work done.
That being said, I think the problem isn't necessarily Slack, but large, poorly organized organization. Personally, I am part of a dozen "catch all" Slack channels that put me into direct contact with over 100 people. That might make sense for some jobs, but it's absurd for a software developer. My actual day to day work involves mainly working with a few developers and a manager or two. My Slack should reflect that - it should literally just be a chat between these 5 people.
The rest of the organization should not be able to Slack me that easily, and instead only be able to contact me through a triage process. If there is really a question from someone that I am best qualified to answer, then I am willing to answer it, but they should have to first determine that from other, more external facing people. So I think the ultimate problem with Slack is that it makes it too easy for too many loosely related people to contact each other. It's like giving every passenger in the airplane a way to send a message to the pilot.
Do you still have notifications turned on for messages? Turn those off, mute most channels, and get control of your communications. Same for email. You don’t need to be distracted every few minutes. Take a break once and hour or two and check for high priority messages. Once a day you can catch up on secondary priority messages. delete or ignore the rest. Your job title is not slack reader or email reader.
> Take a break once and hour or two and check for high priority messages.
But that requires parsing a torrent of mainly chatter messages. Slack is really poorly suited to time-shifted message review; scroll, scroll, scroll...
If your entire issue with Slack is people being able to message you out of the blue and doing it always, it sounds like something you should speak with your manager about for solutions.
But often the technology is to blame at the root. Smartphones, for example, are a management problem because you need to ask employees to put them away and get to work. But they’re now needed for things like punching in, receiving important messages, updating information, filling out checklists, etc. So you can’t just ban them anymore.
It’s not that the employees want to be stuck on their phones, they’re just that good at captivating attention.
Similarly, some sort of online conversation is useful to employees and employers, but the technology can reward unproductive behavior and make productive behavior hard.
I don't know how to respond to what you're saying because I disagree with your premise. Smartphones aren't a problem in this instance, social or personal issues, and there are several of them.
1. There's the internal discipline that the employee apparently doesn't have when they keep going to their phone.
2. There's the assumption from management that a person needs to be 100% focused on work and that lapses in focus are a loss of productivity (when in fact, stepping away and walking can be a perfect way to get an idea and move forward).
3. "punching in" and "filling out checklists" especially are management problems if they're required to use the phone for that, since by the premise of the argument phones are bad and should never be used and then they require them.
4. There's the blaming of the tool rather than the user.
5. With the vast multitude of notification management settings that Slack, in particular, provides, including just closing the app, or muting every single thing except @person's, a disciplined person can absolutely limit their Slack usage as necessary; or, speak with a manager about going dark to 'get some work done'.
When working as CTO of an eBay company I had to fight to remove all phones from developers, it didn't make any sense they had a phone, but policy was back then, everyone needs to have a phone (sure this changed).
I fought that fight at Esri. first office (we were a remote r&d center) we simply put all of the phones in a box and put the box into the locked server room.
when the second office was being built out, and Esri's CTO visited along with some IT staff, we noted that we wanted as wireless of an office as possible. IT asked, "but how will we connect all of the phones?" my answer was, "no phones." they looked at the CTO, who said, "you heard him, no phones" and the precedent was set in stone.
> IT asked, "but how will we connect all of the phones?" my answer was, "no phones."
We've come so far in time, that I didn't connect that as a desk-phone reference & instead was still wondering how wireless wasn't related to "phone".
Also, about a decade ago my job had a "no phones" rule, which was that our mobile phones would be shoved into a lockbox when entering the R&D area.
The "no desk-phone" policy is almost universal recently, mostly because nobody can "step away" to talk something confidential and instead end up polluting the entire open office area with ringtones & otherwise irrelevant gossip fodder.
> our mobile phones would be shoved into a lockbox when entering the R&D area
our main focus was location on mobile devices, so having a lockbox, while nice for noise, would have defeated our whole purpose. I like the idea though!
I guess you weren't doing anything relating to sensitive government work. In those situations you do want a desk phone. In those cases you're not taking your smartphone into the work area...
^ This. You get people who will scoff IRC for its simplicity, but ultimately the up-time is near 100%. I've communicated on it effectively all the way for to a 5kB/s internet connection and it was still quite responsive.
A similar story using Jazz RTC - it used to go down every week or two weeks or so. It was so bad that we had quick dial to their call center. The joke was, we used to switch over to a Raspberry Pi hosted locally in the office running a Git Server - and there was zero downtime on that.
Just a small bit of polite anecdata, but I've fled IRC partly due to some pretty extreme quality-of-service problems - and these were on the major servers and communities that were really the only raison d'etre for using it in the first place - things like Freenode and stuff.
Basically we had a lot of cases of silent failure where messages would completely fail to go through, and this led to some pretty nasty social awkwardness, because there was no indication the service wasn't being 100% reliable. I only ever discovered it after several years, when I had a bouncer logged in from a rather different network address, and it was pretty terrifying how much was getting dropped (sometimes up to 10% of messages - although usually it was "periodic" failures where a whole conversation would essentially be dead for one side. I observed this over several months, and it was just mindblowing.
It was the silent failure that was the most insidious thing - there was absolutely no indication things weren't working perfectly, and it was only after we discovered this that we had the horrible realization that all of those communication problems we had in the past were not because individual "people" were bad communicators (or were ignoring you, being rude, etc), but because they genuinely weren't receiving entire paragraphs of text. At random, with no indication anything was dropped.
There are a lot of other extreme frustrations we had with IRC, but this "hidden QoS problem" was the last straw. A lot of the work we were trying to coordinate on it (gamedev stuff) involves more than just text, and just trying to share images across the thing constantly felt like being a second-class citizen (manually uploading something to an FTP when even AIM/MSN could transfer stuff no problem with a copy-paste). The fact that I was forced to use it for over a decade ... I've lost thousands of manhours of my life fighting with it when almost any modern tech stack would have avoiding those particular wastes of time, and that's just something I can't forgive. As irrational as it may be to do so - I can't help but hate it. :(
I run an IRC network (this one: ircs://irc.darkscience.net/darkscience) and there are shortcomings with the protocol for sure.
I've been a staunch advocate for IRC for a while, but the truth of it is that there's nothing built-in for reliability. It assumes reliability from TCP.
If the TCP connection is interrupted, you will be disconnected.
If a route on the internet changes, you will start losing incoming and outgoing traffic; and you will be kicked from the server with a ping timeout. Losing messages shouldn't be possible without a route change on the internet that drops state, but I suppose if there is a leaky bucket style buffer cache somewhere in the pipeline it could happen?
In a similar vein; mattermost, when I ran it, would deliver messages out of order or not at all- I believe this was caused by nginx and a limited amount of buffer caches.
I suspect that the reason slack forces you to use their client is because they're working around protocol limitations like this with retry logic, because I've had messages not delivered with programs like wee_slack or my python bot (which thinks it delivered the message).
Anyway, if you want a more reliable connection for IRC there is RobustIRC which alters the protocol to be more reliable. Also ircv3 extensions largely attempt to solve issues inherent with relying solely on tcp.
Sounds like your client wasn't configured to send periodic PINGs. Usually you set your client to send a PING every 30-60s, and disconnect if there is no server PONG for two to four times the ping interval. That way you have an upper bound on what messages from you may not have reached the server. (IRC is over TCP, so if a server sends a PONG for a PING, then every message you sent before that PING has reached the server.)
This is unlikely to be the case. Almost all servers out there require fairly frequent ping/pongs and if your client doesn't work right it'll just be entirely unusable (like "disconnect every 5 minutes")
What they typically require is a message of some sort sent regularly from the client, and if they haven't received anything in a while, they'll send a PING to elicit a response from the client (if it's still alive). Most servers don't even check that the PONG matches the PING they sent, they're just happy to get something back before the timeout, although there are servers that send a cookie in a PING at connect time that they require to be reflected back correctly as a countermeasure for certain kinds of proxy abuse.
For example, EPIC is one of the oldest clients and it doesn't send its own PING messages unless scripted to do so, and it works fine.
Dropping messages is something that should notify you - in the raw protocol this is entirely possible, so it's just something that needs to be added to the client.
The problem of adding files is something that it would be nice to solve, I think in general the IRC servers themselves wouldn't want to potentially sacrifice the ability to handle text whilst being overloaded with attachments. It feels like something that could be solved with a third party server and a client that supports it, with a short-ish TTL to keep the server freed up. Receiving side it would simply be a case of opening a link or deciding if the content can be displayed inline.
I quite like not being available when I'm offline. I don't want to logon to have a quadrillion messages to read back through - most out of date and don't concern me. We have email for this kind of thing.
Things are starting to sound to me like if there was an authenticated HTTP “endpoint” that juuust echo $line >> www-root/channel/latest.log, then that could replace ~80% of all intents and purposes of Slack and IRC and Wiki with million-fold resource savings...
We'd just made the transition from local hosted HipChat over to Slack about a month before a _big_ outage occurred. The team responsible for the internal tools got told by management to do some herculean efforts to get hipchat temporarily resurrected.
I logged in to my desktop machine, and had IRC up and running in under 5 minutes and had details out to the team ready to use it should an emergency strike. It's _really_ simple to spin up an IRC server for such purposes. Just about the time the Slack outage was over, the HipChat server was back and working again... :) (there's a lot of reasons why it took so long, and it wasn't really Atlassian's fault)
It genuinely is impressive. The protocol itself is so simple that building something like a bot to write the results of builds is a job that can easily be done in a day (assuming you're completely working from scratch, i.e. pushing bytes over sockets).
There are quite a few clients that even support encryption, so it's not even necessarily insecure either.
5 kilobit per second should be fine for IRC. A typical PRIVMSG command is what, 200 bytes or so, which gives space for three PRIVMSGs in a second. IRC doesn't compress, but it's also not particularly wasteful with bandwidth.
I meant 5 kilo bytes. Of course that speed is screamingly fast for IRC, but for most of the internet you're left with a completely unusable experience. Try loading Slack on a 5kB connection for example and post back your results in a week! :-)
Lets be real though, nobody actually enjoyed dialup speeds. Sure, we were lucky we had the internet at all but when cable and DSL came around it was a breath of fresh air.
I don't miss the speed, but I miss what the speed enforced. Pages were lighter and less wasteful with resources. These days you have pages that will not load without JS enabled, which is sometimes 10x or 100x the actual content it's displaying. That's not to mention images - people happily throw in a 1MB image, because why not? A 10MB gif to replaces a 1MB video, because why not?
Of course there are still people in remote areas, poorer Countries, low-signal zones, etc, who actually do have to deal with this daily. I remember reading a while back how Youtube and Facebook were completely unusable for some users because of this - not because of the actual content they are delivering.
My old laptop with win 7 cant run youtube 144p (anymore). It just freezes up. If I download the videos in lubuntu, vlc plays the 720p but 480p is all I need. There is clearly nothing wrong with the hardware.
When downloading files, there was a lot of waiting involved, but if you were dealing with email without attachments, usenet, IRC, and some of the older chat platforms like ICQ, AIM, MSN messenger, yahoo messenger, etc. the lack of speed wasn't really noticable.
These days, most websites and online platforms like Slack won't work at dial-up speeds.
Usenet could take quite a while to download your messages. All text websites and IRC were reasonable by the time of 33.6kbaud modems, but even by 1995 most websites had some graphics to download which were always painful. It only got slower from there as more was added each year.
This episode of computer chronicles may remind you of the joy and horror of that time period. Note that most of these people are actually on corporate networks not dialing in... and its still horrendously slow.
We use GSuite for all of our office tools and the Google Slack competitor is our official policy for if Slack goes down. We all already have accounts setup without paying for anything else so it’s a simple transition during an incident.
When I interviewed there ~3 years ago, yes, I asked, and I think they use Skype when there's an outage. And IRC server hosted on another cloud would work just as well, too.
It sounds very ironic that the company whose whole business is built on facilitating remote workplace communication would be willing to lose talent in order not to let people work remote.
> Their model is around workplace communication in general, it doesn't have to be remote
It doesn't, but I think the added value of Slack is much more prominent in remote scenario than when everybody is in (roughly) the same room. If it's not good enough to enable that - makes one think what it's good for?
> And maybe they're just pushers, not takers.
Then reasonable question to ask is - why not? What do they know that the takers don't?
If a team isn't set up for remote work, a single employee moving to a new location and timezone (while the rest are in SF) is absolutely going to affect everyone's productivity.
Unless the role was remote to begin with, such requests would get denied at most companies, so I don't see what the big point of contention is here.
If they move anywhere outside the Western Hemisphere. I have no problem doing meetings with coworkers in New York and even São Paulo, although Europe and Asia are indeed brutal. My team is very lucky in that our remote collaborators are in Latin America rather than India. At this point I simply decline any meetings with India unless someone very high level personally asks me to be there. Getting away with it so far.
Back in 2007 I moved to a team where everybody was located in the same building in USA and I was alone a continent away. The team was definitely not set for remote work, it was the first time they tried it.
When I changed the team in late 2010 I was the best rated in that team and I was replaced by 3 people in Germany (my role expanded), already knowing remote can work. During the 4 years in that team I went to the US office 2 times for a few days each time.
I'm in the midwest. It would be a long list if I tried to name all the companies who (pre-covid) were not hiring remote. I haven't forgotten their names and hope others won't either. They all had the resources and know how, but the folks in control of these companies are all about power. My personal opinion is those companies should not end up in powerful positions in the market after this just because they were forced to do what they should've done in the first place.
I don't understand the need to insist on the righteousness of your particular opinion with regard to remote work. To conclude that an organization that doesn't meet your expectations about remote work as you is "all about power" seems to me to be a huge leap.
I would disagree. I think it's definitely a power move when what you decide to do is (a) more expensive (b) unnecessary (c) less efficient. By ignoring an entire planet worth of qualified (probably highly qualified) people when you don't have to you're doing no favors to your shareholders.
Where do you get so much self righteousness to conclude that your assessment is appropriate for all companies, all positions, everywhere?
And why does there have to even be a single "formula" for work in any case? I find that attitude extremely narrow minded.
At the same time I fully support your freedom to seek out the opportunities that work for you. I just don't understand the attitude that other people must be on power trips if they don't think they way you do in this regard.
I think it's strange you are saying this idea of remote work is a "single formula". If anything, refusing to do things differently is more like a "single formula" in my mind.
Maybe you think differently about this, but I can't fathom a real-world scenario where tapping into all qualified candidates in the entire world vs tapping into all qualified candidates within a 20-30 mile radius from my HQ could be even close in comparison.
Obviously we won't decide who is "right" here in a forum. But I will be interested to follow what happens to the companies who weren't prepared for this and companies who already were.
I anticipate some major reshuffling will be happening in the coming years. The companies who built their entire culture around on-site teams vs companies who built infrastructure and culture around acceptance of work from home. Companies with large balance sheets will be able to hide it for some time, but their unpreparedness will begin to show within 1-3 years I think.
This is all given the premise that things don't 100% go back to "normal".
> Obviously we won't decide who is "right" here in a forum.
Is there any debate to be had about that anyway? From what you've written here, you are right and everyone who thinks otherwise clearly hasn't thought things through well enough.
What exactly is true? That remote working is always better in all conceivable scenarios and that anyone saying anything else is stupid and wasteful and probably smells too?
> That remote working is always better in all conceivable scenarios and that anyone saying anything else is stupid and wasteful
This. Exactly this.
>and probably smells too?
But not this.
It is probably the opposite. When I work remotely, I rarely shower. Showering is stupid and wasteful. Millions of people lack potable water and here we are wasting it for showering
I find your mode of thinking frightening. You are insisting that you have discovered a universal truth about working relationships and that anyone who disagrees with your religion is "on a power trip".
Does your thought on this matter change based on the size of the company? The complexities of different times zones, languages, tax jurisdictions, labor law? How about the nature of the work? What if you have to interact with material goods such as in manufacturing? What about if you have to be onsite with customers?
You seem to think I'm arguing against remote work in general. I'm not. I'm stating what should be obvious -- one size doesn't fit all.
He or she must be saying something right, if all of these tech megacorps are starting to embrace remote work, potentially sparking a sea change that will sweep Silicon Valley.
This is just sloppy logical thinking. Even assuming your statement that "all...megacorps are staring to embrace", it is not reasonable to then conclude that any alternate opinion about remote work at all is wrong thinking.
By what logic can you assume the special case of some types of positions in Silicon Valley "megacorps" is generally applicable to all other jobs?
So what? I'm not arguing against remote work. I'm arguing against the religion of "universal remote work". One size doesn't fit all. That should be completely uncontroversial.
I actually agree. I don’t think every single white collar position should be remote. However, the poster you’ve been replying to didn’t say that, either. He or she simply said that these companies that are doing an about-face and moving towards permanent remote were always in a position to try more remote- they had the resources and capabilities to experiment, and is bitter that they didn’t do so until forced by the pandemic. They weren’t saying that remote must be done in all circumstances, that’s a strawman you read into their posts.
Controlling managers lose power, that is not needed for the functioning of the business, when you are not in their physical presence. To call it power tripping seems like a logical conclusion.
You could be right on the economics and still wrong on the motivation. Are the economics so clear cut in every context that an uncharitable explanation is necessary?
Reframe it this way: decision making managers and executives need to be in the office to do their work, thus they want their peons to be working away right near them as well. The decision makers are doing a different kind of work than the workers, that is the issue.
You've divided the working world up into "decisions makers" and "peons" and you want me to view your thoughts on this as reasonable?
And is there some law of physics that I'm not aware of that neatly divides all jobs into two buckets, "decision makers" and "workers"? Leaning on that sort of manufactured dichotomy is low resolution thinking.
Same in London. Majority ofcompanies didn't go past 1 day per week and only if "exceptional circumstances" (e.g. a strike/major incident on the railways - meaning you already spent 2-3 trying to get in) and while the managers/directors were working 2-3 days per week from the office (mostly to take a 3h lunch break with their mates and return at 3pm pissed-drunk).
I never chased those contracts because life > work, and London commute is a royal pain in the ass.
> should not end in powerful position
I believe they will JUST because of that reason. They will be forced to adapt, drastically increase the WFH, and staff will unleash their productivity and companies will benefit from that. It may take a while since staff may be a bit undisciplined/disorganized in the beginning but eventually they will be super productive. And bad managers will try to take the glory and set up daily zoom calls just to ascertain dominance to their packs.
This just shows that a lot of company can get work done remotely if they have to. The jury's still out on remote work beyond that. How effective are people on individual projects? Collaborative projects? Long-term planning? How's satisfaction with work?
Why do I still get an instant headache when I read Twitter. It's like a bad meeting with a few blowhards that suck out all the air, except magnified by 100x.
Strange how just because it's on Twitter, people treat it as if it has more value than any other online comment thread. No one is going through YouTube or Breitbart comments and pretending they have value beyond anonymous ranting.
I think because Twitter's energy is different. People intend their forum accounts to be relatively anonymous, but expect twitter to be a place where you show your name and face. Twitter is more personal.
Yeah, and while some people talk big with no credentials/experience to back up the talk, there are a lot of people I don't know personally that I follow whose opinions I trust more than some anonymous forum commentator.
That being said, I deleted Twitter in January and am much happier for it.
I don't know why people think Slack is a remote working tool. The reason slack is popular, is it was better than hipchat, which was better than gchat/hangouts/lync, which was better than IRC. It solves a specific problem, but when you try to shoehorn it in as your solution to remote-everything, of course it fails.
Their marketing team is just playing the hand they've been dealt. That doesn't make it a "remote working tool;" it's the same tool as before--it's OK for remote work, but it works fine when you're colocated, too.
So if something is marketed as a means to reach a certain goal, it suddenly is the way to reach that goal?
In other words, if I start wearing Nike shoes, will I become an athlete? If I start drinking Heineken, will I become an amazing socialite and travel the world from party to party? If I use Axe body-spray, will gorgeous women fall over themselves to be with me?
This seems weirdly combative and aggressive. The original question was "I don't know why people think Slack is a remote working tool" so I'd say a legitimate answer would be "Well they say so themselves in their marketing copy, maybe that's why people think they are?"
I read brown9-2's comment as saying that Slack is a good remote tool because it is marketed that way. I am not critical of people thinking it is a good tool, but the premise that what is said in marketing messages is true per definition.
Now, when you say that you read their comment that way... did you truly read it that way? Do you actually believe that brown9-2's position is that everything that is said in marketing messages is true?
Slack positioning itself as a remote working tool makes it fair to discuss if it really is a remote working tool or a remote working company, which is exactly what the person I am replying to commented about.
You are right, I read the emotion of your message wrong. I thought you meant that Slack IS a good tool for remote work because they say it is. You were reacting to the question of why people think it is.
Sorry for the hostile reaction either way, neither interpretation deserved that.
Asana with its inbox workflow (most people don’t pay attention to this feature) will help all remote companies. It basically is a non noisy inbox for tasks , when paired with a culture of not providing immediate feedback works nicely. Didn’t believe it at first but after using it for onboarding all remote like how it enables async work. We also use slack and think the two pair really well. Allows for deep work even as a manager. Disclaimer I am a recent Asana hire that onboarded remotely.
My work has more than 100 slack channels (I once asked if there was a place to see a list of all slack channels and was met with laughter. Apparently that isn’t something slack provides?) Whenever I need a question answered by a particular team I’ll post it to what seems like might be the most relevant channel. 99/100 they will direct me to a new channel I’ve never heard from. So I’ll join that channel and post my question. At this point I have about 80 channels spread across 5... whatever groups of channels are called in slack. Frankly it is overwhelming. It would be a full time job just trying to keep up with all the channels (I’d estimate there are 3000-10000 new messages everyday across all channels). I haven’t figured out anyway to know if something has been posted that would interest me under the deluge. On occasion I’ll be searching for something and discover that on a channel a very important announcement or policy change was made recently that I missed under the deluge. Anyway, I’ve given up. I’ve turned off notifications and don’t even open it up unless I have a question that needs answered. Then I start the arduous task of trying to figure out the right channel.
I work for a Fortune 100 company with thousands of IT people. I literally have no idea who I would talk to about this. Maybe there is a slack channel for that ;-)
I would start with your immediate boss and maybe his skip-level. For the skip-level come with a precise explanation of what Slack is doing well, what your experience with Slack seems to show for negative and some potential remedies :)
Well, one problem is that I don’t work for the IT department at my company. I’m not sure if my boss (or his boss or his boss’s boss) even knows what slack is.
It's more like calling a company who builds a remote work product and touts the advantages of remote work in their blog and marketing, but frowns upon it internally, as hypocrites...
Not to mention that this is a bad choice of example, as the verbatim suggestion to "eat your own dog food" is an old-time best practice in the software world.
Agreed. One powerful feature of Slack is search. The best thing about it is that it works! You can look for troubleshooting discussions (e.g. code build issue) and usually there’s a solution already. In that sense it’s also a permanent information page like Confluence, albeit less structured, but a perfect fit for info like tedious bug finding thread where people just don’t feel like writing up a well organized wiki for it.
You can search for data years back, but you don’t have to. E.g. code troubleshooting tips are only relevant for a couple months, since the code keeps changing. The other nice thing is that you can share the findings via link of a thread or single comment with your team, and they don’t have to leave Slack to be able to see them, which is definitely a smooth experience - if they are already on Slack at that moment. In terms of search experience, it probably depends on use case, but I dont think Slack’s search is apparently worse than its alternatives like Outlook, Confluence, Jira etc. - if at all.
Agreed they're all "more necessary than ever". What interests me is that, at the very same time, so many people (and I'd include myself) bitch and moan about how pisspoor they are at a whole load of stuff.
So the more interesting think/conversation is: How do we reimagine these tools to make them much, much better fit for purpose?
Jira -> Offers structure for bug findings, requests, ideas.
Confluence -> Permanent place for information.
Slack is greatly helped by integrations with tools like this. Otherwise you would only have chaotic discussions and then try to find messages in Slack to remember things.
I think you’re missing the forest through the trees. I like Jira for simple request processes and tracking projects. Confluence is nice because you can making a living document that is constantly updated. I see huge benefits using them vs not using them. It saves organizations a huge amount of time for knowledge management. Slack, Jira, Confluence are much better than using email and Sharepoint.
IMO they should get no credit for doing what they refused to do when they could but didn't have to. Now that they have to, and are doing it, what credit do they deserve?
Positive reinforcement when someone does the right thing is a great way to keep them doing the right thing. For many people, if someone isn't treated any differently when they change their behavior for the better, what value is there in changing behavior to something harder and less self-serving?
It seems there's a lot of frustration here about the use of Slack effectively, so I'm going to re-post something I posted a bit over 2 months ago in a different conversation about slack.
Each company has different practices when it comes to Slack; and, as someone who has used Slack so much that it's mentioned about him at those companies (not always in a positive light?), I have a few thoughts and rules about the best Slack usage that I think help, in general.
1) At any not-small company, you're going to want to almost immediately change your Sidebar from "Everything" to "Unread and starred conversations".
2) Star all channels that you personally need to keep track of (or want to keep track of for a certain amount of time) and all people that you want to talk to or are currently in an important conversation with.
3) Unstar channels and people where #2 is no longer the case.
4) Create private channels for any conversation / project or issue that will ever require more than the people that are currently in a 'multi-person private message'. Archive them when the issue is over.
5) Use @here sparingly and @channel way more sparingly. If you're at a company that doesn't use @here / @channel sparingly, mute them for the channels that use them in excess. My current company has a meeting room shortage, so every single time a meeting room is freed up unexpectedly, there's an @here in one of our channels. That channel has @here notifications disabled.
6) If you can, in your broader "all the devs hang out here and can chat about work stuff" or "talk with ops here" channels, consider adding group aliases, so you can say, in those channels @ops, or @team-ops to notify just that group when things are important.
7) Use @here sparingly, yourself. Use it only for extreme situations.
8) Give chatty bots their own channel. Having the pull request bot for your dev team in the same channel as active development is going on, or in the same channel as other teams are supposed to come in to talk to you about a project your team is working on is just not the best.
9) Current, unproven experiment: at my current job, my team is experimenting with a heavy use of threads. Previously, we had multiple projects occurring concurrently and historical knowledge on features is spread across the team with a lot of new members, so we can't use the tricks of private channels per project to as much effect. Threads have a lot of weaknesses when it comes to readability and following; but, they do reduce the chances that someone's important message will get lost in a swarm of other messages on more pressing issues.
edit: Whoops, thought of more.
10) Use snippets for any bit of code even slightly long. I'm thinking like 7 lines or more. There's syntax highlighting, and they're collapsible, saving precious screen real-estate
11) Use Posts for large format messages you want to post to a channel or multiple channels. They have formatting, headers, and so on. They're also collapsible, again to save on screen real-estate.
12) Personal preference: try to not send multiple, short messages, unless that's your company's culture. It breaks up the conversation and makes it a bit hard to follow where a thread is, if you're using threads. For example, which message do you put the response on? The part where the situation got confusing? A random message in the middle? The last one? The first one?
edit 2, 3: more adding (I'll just add more after this and not say I'm adding more, if it happens again), and some removing some unnecessary information
13) Mute channels that you want to remain in, but don't want to be bothered by (maybe unmute @here and @mentions on this channel). This could include your company's random chatting channel, or the operations channel, or even your personal team's channel if you're currently heads down in a major project, but you might need to be pinged for something serious.
Slack has totally become a drag on productivity and a net negative. Channel and message overload is arguably not much better than the email system it is meant to replace.
My prediction is that Slack will be replaced quite quickly by the first tool that really nails remote messaging and coordination. Slack is not it.