This is how email or ticketing systems to an extent work. Though we have a rule that certain ticket discussions should go into a ticket itself so decision changes are not lost and people have accountability (which is better cause I get asked sometimes why I wrote code a certain way by the very person who suggested the change).
The last three companies I've worked at had the same rule, except with no exceptions. All discussions get recorded into the system, precisely for the reason that you state -- so there's a historical record of what was discussed, what was decided, and why.
Any "external" communications, such as with email or IM, are expected to be copy/pasted into the system so its permanently recorded in a useful way.
In practice, these records are only read from beginning to end when someone new to the issue at hand needs to come up to speed. Otherwise, the value is in being able to search through the record to find specific things.
This drives me crazy. Even worse is when I get told out of the blue that something I did is wrong, by the supervisor who told me to do it that exact way some months ago.
This has happened almost everywhere I have worked, and none of those places kept change discussions to a specific ticket. I'm going to push for this approach more in the future, it sounds like the right solution.
As we scaled, we had to transition to a ticketing system, for the reasons you mentioned.
Slack definitely feels backwards in some ways especially if you use it as a channel for dealing with customer requests, especially if multiple people at customer site are part of the slack group.
It's been hard adapting to the... less structured environment I'm currently in, but this is the thing that really gets me.
A company is very unlikely to ever side with a subordinate over their manager.
If he had his status changed from fired with cause to without cause, it would have made a difference in his unemployment. I do not believe that they could deny Cobra. Why would they? He would have to pay the full cost with no subsidy from the employer.
I'm just choosing to believe I'm doing a poor job explaining the tradeoffs, and then time or someone else does a better job a few months later.
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.
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.
Turn off notifications. Just like email, or SMS, or the phone.
Don't blame the tool if you aren't using it right.
However, not everyone has that luxury. In my office, we are required to keep slack running. There are bullshit channels like #random, #memes, etc. that I have set to ignore. But then there are "Serious" channels where if the Boss speaks the expectation is complete participation.
#General <Boss> I want to make all the icons a corn-flower blue across all of our sites.
Incorrectly using the "tool" disrupts everybody who does use it correctly. If this was an email, it'd be safely ignored for 4+hrs. I'm not mad at Slack, I'm mad at corporate overlords who shouldn't even be allowed to touch a computer. But because Slack exists, I am forced to despise it.
I've got half a dozen other ways to send IM's to my co-workers. I never got interrupted in the past with bullshit like I do with Slack.
Just have every channel on mute (apart from your co-workers).
If your boss insisted you could have a computer but had to use an on screen keyboard, you wouldn't complain the computer was bad. Same with slack.
Slack does a really poor job of guiding its users to use the tool properly. There is no warning when someone decides to @here the #announcements channel with 200+ people to wish someone a happy birthday. That's poor design.
The new book "Indistractable" makes exactly this point. Incidentally it also talks about how the Slack company uses Slack, and this is exactly their point, too.
The book goes on to talk about "Psychological Safety." In this case, defined as the lack of '>any sort of penalty'
I have found slack to be wonderful when troubleshooting production downtime. Not just during it, but after, for the post mortem.
Other times I try to treat it like email. That means turning off the notifications and closing the client for long periods of time.
an example not necessarily tied to work directly: there was a slack channel at work that was dedicated to free food. if you brought in food, or someone or a vendor was giving out food, you told the channel what food / when / where + an optional picture. Problem was, some people would just chat - about their vacations, dogs, etc and I would have to ask them to take it to another channel or talk direct message, because they would bury actual food announcements and cause all sorts of notifications. instead of realizing their folly, they would fight back and say you can always mute the channel, which totally negates the reason for being in the channel.
You also see alert crepe. someone has an idea of sending service information to a channel, and before you know it you have 25 channels dominated by computer talk.
you’ve nailed it and nothing else needs to be said about Slack.
Yes, that's what they say. It's like closing an HTML tag.
I disagree that nothing more needs to be said about Slack, though. It's a highly influential application, for better or for worse, and the social issues around it aren't opened and closed quite so easily as a div tag.
When collaborating on a time sensitive issue with remote colleagues it's fantastic. When trying to get my head down and complete a tricky bit of work it's awful.
I think the most important thing is not using Slack or avoiding Slack, it's building a culture that allows people to opt-out of it, without any sort of penalty, perceived or otherwise. If people want to hang out in Slack they can, if they want to shut it off for the day and just drop in to give a standup update or something like that, that's fine too. Important things are done asynchronously in a forum that everyone can experience.