This does assume only one of the kinds of work that I mentioned though.
If our database server goes down and the site is offline and we're losing money, that is when Slack shows its value. We have a full log of what's going on, we can rapidly communicate statuses to stakeholders, we can debug things in realtime even if a distributed team.
I'd love to not have those sorts of times, but there's always going to be times like that for almost any business, any type of work. They can be minimised, but sometimes you just need fast communication.
In that way, I see Slack as a better long-run conference call. I can dip in and out as needed, it's got rich information, it's easy to look back through history. For things email is good for – let's stick with email.
“This requires to be able to work on a couple of problems at the same time.”
...which is a really bad idea, because context-switching carries a heavy productivity penalty. Many studies show this clearly: even though people may feel more productive when multi-tasking, they actually are much less productive, and the solutions they come up with to complex problems are more likely to be wrong because they haven’t spent as much time in the same context (i.e. asked for help, couldn’t get any on time, was forced to switch to another task/problem).
Is anyone using dsr55rhel? I need to reboot it.
"Last week I lost 3 days of my work because someone rebooted dsr55rhel and I didn't see the reply in time. To avoid this next time, I suggest we: ..."
There are probably cases where it's necessary for multiple people to be communicating/collaborating on some issue simultaneously and synchronously. Most won't be.
I think cases like "what if something comes up and you need multiple people" is a smell that something can be improved, rather than a common unavoidable problem.
Is anyone using dsr55rhel? I need to reboot it. 0:00 Is anyone using dsr72rhel? I need to reboot it. 0:05 Is anyone using dsr21rhel? I need to reboot it. 0:09 Is anyone using dsr97rhel? I need to reboot it. 0:11 ..ad infinitum
1 Month Later, some over the top, ITIL compliant business-flow is setup to quash that nonsense. And now everyone is suffering the consequences with hyper bloated business process procedures.
...basically the disease, the cure, and the cure for the cure are all equal when killing productivity.
It really comes down to people and discipline. You're either working with smart, competent, well adjusted adults, or you're not.
If your organization is small, brilliant, tight ...then any/all decent tools can be utilized to maximum effectiveness, because again it's people.
But the larger the organization, it mitigates any and all tools, even the best of tools, and it also mitigates the possibility of having a small collection of really smart, talented people. Smart people in this environment typically will feel suffocated in a few years, unless they are protected from the endless nonsense that large organizations naturally create. This is how brilliant managers operate, and the competitiveness is interesting to see. Savy manager, makes his way up the food chain by being a problem solver. How does he solve it? Pooling talent, shielding them, in exchange he has high expectations from them, they come through, all are heroes, but the manager gets majority of credit. He/she then gets moved to a higher level, or a group that tackles harder problems. He streamlines the group, gets rid of the dead weight, steals better talent from other teams, protects his team pushing the boundaries as granted to him/her due to previous successes, then uses the potential to solve problems that no one else can/wants-to solve. Wash Rinse Repeat.
If someone regulary utilizes a broadcast to ask everyone "who is using this server, anyone on it, can I reboot it?"
Something is terribly screwed up at that organization. And having Slack as the broadcast tool is just an enabler.
Allow your team to response in a matter of hours/days, not minutes. Let them think about and rethink a problem or question.
This requires to be able to work on a couple of problems at the same time. Divide the work accordingly. Or use the time waiting for a response to learn something.
There's a quote going like this: The urgent is not important and the important is not always urgent.