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 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.
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.
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
Also it was expected that only urgent stuff will be handled that way.
It serves a similar purpose of being both a social gathering spot, and also a place where you can quickly ask an impromptu question.
I find it super useful for building a social environment in a fully remote environment.
such communication becomes the friction itself.
>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.
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.
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. :)
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.
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.
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'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'm keeping a list of what I find at https://www.ebiester.com/annotated-links/documentation/2020/... but I'm not seeing what I really want just yet.
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.
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.
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.
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.
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.
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.
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.
I now recall that C2 wiki has convention of comments. They're immortal. It sucks.
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 hope someone someday cracks this problem.
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.
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.
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.
I just gave up eventually.
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.
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.
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.
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.
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.
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.
I turn my video off during video conference calls, but others may not feel they have the autonomy to do so.
https://www.bbc.com/worklife/article/20200421-why-zoom-video...
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
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."
A very good article on the topic was written by a well-known (and extremely effective) trainer, Erica Sadun, here: https://ericasadun.com/2020/03/11/so-youre-going-to-teach-re...
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.
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.
Say, "this is how I want the grid to be arranged", and maintain that arrangement over many meetings, with absent people blank and not repacked?
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.
For a service that's probably being marketed a lot at schools, that sounds like a perfect feature for the classroom and you could use it, as well :)
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.
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.
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.
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.
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.
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).
I like it very much, it is like email, but faster, less formal (and no, it doesn't replace email, both have different uses for me).
It is similar to instant messaging, but you can ask a question to more than one person at once.
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.
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:
https://www.stavros.io/posts/seven-tips-great-remote-culture...
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.
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.
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.
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".
I don't miss it.
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.
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).
Who would tolerate an employee standing in the middle of the open office screaming at the top of their lungs for attention? :)
Of course, we all make mistakes from time to time. Guess the real problem is a lack of learning from them.
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 :-)
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.
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.
(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.
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
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. :-)
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.
If it's some idiot in a distal group trying to
justify their existence by being vocal
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.
Only the medium has changed, not the message.
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.
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 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.
But for business sensitive discussions where we expect a lot of efficient brain time and valuable discussions, hell no, send me an email.
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.
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.
Doist, the remote-only company behind Todoist, created Twist [1] to address this issue.
(fyi, not affiliated with them in any way, just really happy with their product, they deserve a shout-out!)
Forums are great for structured conversations, but poor for unstructured—and Slack is the opposite.
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.
> 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.
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.
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.
Or would you say there's a class of communication and coordination use cases that are best addressed by in-person (currently)?
Interesting, isn’t it.
it’s much worse because emails can be filtered, while it’s still impossible to mute bots in Slack.
- 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).
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.