Great points in article, I was just expecting more than critique of slack. I think slack might be used as efficient group mind by disciplined team. For example, using one channel to strictly stay on topic and keep focused, and another channel for meta-discussion and/or voting for next thing to focus on. Perhaps a third channel for archiving reached decisions, where discussions are not allowed.
If there are such battle-tested practices of efficiently using slack, perhaps they should be distilled to build a better communication tool around them. There's so much potential in collaboration tools that's untapped because everyone takes IRC or Word as baseline and improve on that.
Unfortunately I cannot offer guidance as I have yet to experience efficient teamwork with collaboration tools. In last company we used Slack as generic chat client with static channel groups. The current company uses Skype for Business which is the worst chat service in existence.
I have such project in side-projects backlog, I might get to it in few months. It would combine note entry with online collaboration, plus some automation for formal logic / decision making and task scheduling. It would be conceptually similar to 'group mind' as described in this article, except I can only do a prototype and not coorporate-ready tool.
This was an enjoyable read. Are there any sites where credentialed experts could participate in software that is designed to help simulate a group mind? Kind of curious what would happen if you put a bunch of scientists in a server, guided them into group mind structures, and hit play.
Discord has greater roles & permission control than Slack, I wonder if it can improve on the outcome in the article.
I dislike discord for serious work on a pragmatic level. Every team member is automatically a member of every channel, which is unnecessary and doesn't reflect the needs of even a small company like mine, where there are channels for things like marketing and operations that I, a programmer, don't care about or need to be involved in. Furthermore, and this issue grows as your team does, Discord doesn't have threading. Conversations between 2 or 3 people dominate channels, and if two groups try to have a conversation in the same channel at the same time, it descends into chaos. Sure, you could just tell people to limit conversations to one at a time or make greater use of DMs, but why, in 2018, restrict ourselves to treating text chat like we used to treat radios? The whole advantage of slack is that it's somewhat asynchronous, I can jump into a thread I ignored a few hours ago and concerned parties will see my new message without flooding more recent conversation in the same channel.
To your point, I don't see how fine grained permissions would help with the issue OP points out. Sure, it lets you represent a hierarchy of sorts, but only in terms of what features of the app users are and aren't allowed to use, it doesn't change the nature of the communication.
This is completely my opinion, but if I would make Slack 2.0 or Discord 2.0 for that matter, I would add the option for no hidden or locked channels. all is free for everyone. Maybe even no dms. I would make thread autocreate a new temporary channel that can be archived after some days inactivity. Channels in my mind are hubs. If a conversation starts, all is good. if a second one starts, it's time for a temporary split. Finally, better notifications. I know the Slack team has done a very good job with them, but they need moooore work. That's one thing I don't know exactly how it could be improved. I just know that it can and should be improved.
Pricing however doesn't work for larger groups. It cost 6,25€ per user per month (~ $6.25), so having a group of 1000 users will cost your company 6250 € per month.
If there are such battle-tested practices of efficiently using slack, perhaps they should be distilled to build a better communication tool around them. There's so much potential in collaboration tools that's untapped because everyone takes IRC or Word as baseline and improve on that.