Sorry, we can't join your Slack
reifyworks.com
reifyworks.com
I see people at my office (and different companies!) saying they quit Slack/Whatever because they were getting bombarded by notifications... They had the option to notify on all messages. ¬¬
Even then, come on, I cannot believe experience hasn’t taught most of you how to handle quick interruptions. I usually just quick look at the notification to see if it’s really urgent. Otherwise it may be 7-10 minutes until I actually check the application, in case I’m doing some heavy thinking/coding session.
There are true interruptions like constant notifications, people physically talking to you about other things, and stuff, that while you cannot really tune them all out, you should be able to handle better with 2-3 years of experience. I read a lot of people on these forums with many more years not being able to cope with that.
I will die still unable to believe it was the norm, and not the exception :(
It's just a communication tool. Either it works for you personally, or it does not. I don't think it deserves a weekly HN first page discussion though.
At my current job I was asked to join a client's slack group (added without my consent) and it was a nightmare. The problems have nothing to do with notifications or interruptions, but it gives them the implicit understanding that I am a custom developer for their needs. Since they can reach me at any time, they assume that I am going to fix their bugs, add their features, etc. It circumvents what I think is the proper procedure for work. I suspect that's more the heart of why the author is saying they aren't going to join their client's slack group.
If you aren't their personal dev, then don't be one. The only thing my presence in a client's slack means is that I (and/or the other people from my company in their slack) am reasonable first point of contact. I'm perfectly happy telling them that their problem is not one I can solve (or choose to prioritize), and that they should touch base with <appropriate person>.
If I am ok to carry on this tangent we are already on, I cannot wrap my head around a scenario where it would be appropriate for a member of a SaaS company, dev/PM/CTO/QA or what have you to be in a slack channel for one of their clients. It's completely unprofessional and should be avoided.
What feels demanding to me is coworkers who will simply send a message containing my name, sometimes followed by a period. Opening slack to see just "John." (not my actual name) is somehow both more and less personal than "Hi". I believe it's mostly a language barrier thing, as it's only ever ESL speakers who do it, but it still feels like nails on a chalkboard for me.
I've been trying to think of a good way of asking it. Maybe something like "Just so you know, I won't be offended if you ask the question with your initial greeting. It would actually be helpful because then I can start thinking about the answer right away. :)" Does that work?
If they say "Hi" and wait for you to respond, now you're engaged and it's harder to ignore after they pose the question.
To carry your analogy further, it's more like calling someone and hanging up before they answer in order to prompt them to call back.
I am saying "Hi" (without anything else) - to check if person is available for discussion (exactly like okusername described it).
Here it is: "please don't just type "hi"". It's that simple. I've never had anyone perceive that as rude or negative in any way, and they usually adapt pretty quickly. If they don't learn, you just have to step up your ignoring game ;)
I feel like I've seen something similar as a general rule. If your company has any sort of internal etiquette guide for its internal communication tools, this should go there verbatim. If not, then it can still work to post it in certain places; for example, a slack channel where people ask your team questions.
If you're getting asked questions but your teammates aren't, then you are special! So just tell them directly. Even better, respond to the DM saying that for the benefit of everyone, such questions should be asked and answered in a public channel, so that others have a fighting chance of finding it with a search tool. This eliminates the "hi" problem entirely.
However, Bob pretends to be afraid of me. People walk up to me all the time when I'm working and ask questions and it's perfectly fine. But when Bob has a question, he _whispers_ to get my attention. Or he'll stand just in the periphery of my vision and literally wave until I respond. I've told him, nicely, more than once, that he can just talk to me whenever he wants. His response is always along the lines of, "well I didn't want to break your concentration" or, "I didn't want to bother you if were busy." Bob knows I don't ignore people whether I'm busy or not. I don't want to believe he does it just to annoy me but I'm failing to come up with a more logical explanation.
Improving this style of interaction may be a matter of showing/proving that you really don't mind a more blunt approach, and in fact prefer it.
You've answered your own question. The product is distracting by default.
The savvy user can cut down on the distractions by configuring notifications, teaching themselves how to scan messages, etc., but if there's one thing we know from 70 years of writing software it's that most users accept whatever defaults you give them. Sometimes that's because they don't know they can reconfigure the software; sometimes it's because they do know they can reconfigure it, but can't figure out how; sometimes it's because they know how to reconfigure it, but are too busy with other things to do so. But the underlying reason doesn't really matter, what matters is the general effect: the default experience the software provides is the experience that most users are going to have with it. And with Slack, the default experience is distracting.
> Even then, come on, I cannot believe experience hasn’t taught most of you how to handle quick interruptions.
How many threads have been posted on HN complaining about things that take programmers out of their state of "flow"? How many programmers have you met who are happy to hear their phone ring when they're working?
> There are true interruptions like constant notifications, people physically talking to you about other things, and stuff, that while you cannot really tune them all out, you should be able to handle better with 2-3 years of experience.
2-3 years studded with bouts of lost productivity is a lot of lost productivity. A product that tells me my life is "only" going to suck for 2-3 years while I learn how to use it is not a product I am going to be thrilled to use.
Those are what the true interruptions are about. A notification? I'm sorry, but after less than a month one learns how not to let a simple sound or notification distract you. Constant phone ringing is a true interruption; one ringing loop? Not so much.
> 2-3 years studded with bouts of lost productivity is a lot of lost productivity. A product that tells me my life is "only" going to suck for 2-3 years while I learn how to use it is not a product I am going to be thrilled to use.
Handling interruptions is about not letting them make you lose much productivity, but after all, this is for true interruptions. They will affect you, but there are ways to lessen the effect. If people allow other people to constantly interrupt them without setting clear boundaries/priorities, it's your (or your Manager) problem. I usually set things in the clear from the beginning, and after two or three times, it'll never happen again. But again, these are true interruptions: Some are necessary, and those which are not can be handled better.
The problem isn't the notifications here. Sure, I can tune my notifications to my preference, but when you're a resident in a client's Slack the expectation is that they can directly message you, anytime, for any reason, and for any size request. Like the article says, Slack does not encourage deep and meaningful messaging – it's more like a text. I have found that opening a channel like this almost always brings with it a firehouse of small changes requested in bursts, whereas a single e-mail encourages bundling of issues and requests into minimal amounts of messages. The worst thing about Slack is the constant "10:00am: hey HBOSCH, can you do X?", "10:15am: oh, and can you also do Y?", "10:47am: and while you're at it, maybe you could handle Z? haha sorry for being crazy!", "10:49am: <silly gif>". It's so annoying.
I also tune my notifications effectively by using Do Not Disturb mode on my iPhone from 12:00AM to 11:59PM, along with the "Bedtime" feature in my alarms. This keeps my phone quiet all day, only allowing phone calls from people on my Favorites list to come through, and the Bedtime function in Alarms keeps my whole device totally silent from 10pm to 6am. But that's not helpful if a client is trying to reach me at 8am EST when they need an emergency update before a morning meeting.
This is kind of true. I work with several partners of our ecom platform using Slack. Most of them are not that responsive, and that's fine - Slack is a chat app but it's still asynchronous! As long as people answer reasonable queries in a reasonable time (so e.g. within the working day) then it's fine. I never expect instant answers.
Manage expectations I guess?
Why do you think that? The client's I'm in slack with certainly don't expect that.
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.
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.
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.
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.
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.
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.
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.
--Now here is an example of the boss being an idiot and interrupting 30% of the staff. The accountants don't care, neither do the secretaries, the Help-desk, the Customer-support, or the SysAdmins. But because the idiot starts the conversation in the wrong fucking channel every damn reply and conversation that is sparked because of this interrupts me.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.
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.
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.
“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).
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.
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'
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.
I worked in a support role for a big company. We had one notorious customer who was prone to just racking equipment, not setting it up, and calling in priority 1 support cases to basically have us configure it for them with little to no data / would not do what we said. (this was their SOP, and they're also a huge company...)
We used Microsoft's messaging service at the time and I had no idea that IT had configured it to allow people outside our company to message us.
So as you might expect one day I'm working another customer's "real" network down priority 1 case and I get a frantic message from someone I didn't recognize asking a vague question as if we were in the middle of a conversation. I assume this is some sales guy I never met frantically messaging me (some sales guys knew me and handed my name out as I was friendly and I'd help them out if I had time). But then I can't find this guy in outlook and suddenly I realize.
So I mute my mic and announce to my cube mates "Guys... X company is instant messaging me ..." The response was hilarious, managers came running, some folks announced they were shutting off their laptops ... it was immediately clear that this was an untenable situation.
Fortunately the solution was right in front of me. In another conversation I had a sales VP in on a chat for the customer who had a "real" priority 1 case. I told him that I was receiving instant messages telling me I needed to stop helping his customer and go help X company. Granted I wasn't actually going to drop him and I phrased the FYI in a way that made that clear, but also let him know he had some competition for my attention / our focus on his customer's issue.
Suddenly we had a Sales VP as an ally breathing down ITs neck to shut off outside access to the support team's instant messaging.
At one point management had the idea that we should do "chat support" on the website.
The website (a god awful mess) was run by the marketing department (that's why all our handy documents were hidden from the world) and they took the lead and suddenly announced support was just gonna be available to "chat" 24x7... and support via twitter would come soon too... nobody in support knew anything about it.
Thankfully even the CEO recognized the amount of manpower it would take and how bad an idea that was for what often were complex issues.... and really most social media and chat contacts were from folks who bought second hand equipment and had no support contract.
I've known a few people in my life who could talk anybody, including themselves, into any stupid idea you could imagine. And then talk themselves out of it again in six weeks. The whiplash is tremendous. I've started applying advice for talking to addicts to my conversations with them (supportive, but don't invest in it). It's so disruptive. And personally, I find it exhausting.
Most of them have been in sales, at least once.
Promising things that the company can't possibly deliver for a price that will bankrupt you. Classic marketing dept.
Working in a place like that is exhausting, but very little ever seems to get done.
I'm definitely more productive the days when I keep Slack closed.
I love that mode of communication, it feels less like drive-by opinion-slinging and more like conversation.
Chatting with the customers and making them feel good is sometimes the actual product. Some people buy candy and not salads!
Here's a perspective: Since most businesses fail, you're usually making entertainment for rich people.
I want that phrase on a t-shirt
You made me chuckle, since you're definitely right about app-of-the-day startups. Strive to build something that matters!
This is no nicely put. Explains a lot of things startups arena is filled with just in a single sentence.
Slack solves actual problems, open office plans exactly one: managers can reduce operational costs and with them raise -their quarter/yearly boni by cramming more people in less space, just like a herd of chicken moved from free range to a huge mega stable with 1 DIN A4 space per chicken. By the time the epidemics race through the chickens (=workers flee) the manager responsible is long gone and cannot be held accountable any more...
I came back to find an employee of one of my customers sitting at a desk in our office. Turfed him out. Had to "fire the customer". Lost about 30,000 euros of work time and unpaid invoices.
In my view joining someone's Slack Channel would be no different than that little piece of "management kidnap". Everyone in the office had completely turned their attention on that single customer's problems.
They learn that you will say no, every time. So they ask someone else, and someone else, until they get the answer that most resembles what they were after, then they lock into that as a commitment instead of a hypothetical conversation.
As a child you figured out which parent was more likely to say yes to treats, and under what circumstances (mood, which sibling asks, how they ask).
The thing is the customer gets rewarded for results, no matter how they get them. So if they stoop to juvenile tricks and get a promotion for it, they're just gonna keep doing that forever.
We have a couple of shared channels with companies for whom we are customers and it also does not feel like that. The other company assigns one or two resources in each case to helping some of our staff with issues when they come up, and we pay them for that support. Only a small number of our team would be a member of those channels.
Video calling might be even more efficient during the call itself but personally I would spend so much time thinking about the call, preparing or worrying before the call itself that it would be a bigger drain on my productivity overall.
Not to mention that my personal productivity is not even the most important thing. In this case these Slack conversations fixed a client relationship and moved our work with them forward in a way that was far more valuable than any SLOC I could have produced in that time.
I like the fundamental ideas he puts out:
• We felt busier, but were getting less real work done
• We knew the clients better personally, but we knew the product less
• We had more superficial conversations, but fewer substantive ones
• We were able to react more quickly, but our responses were less measured and effective
That said, Slack is a pretty cool tool, but there's lots of cool tools that I don't use that much.
If you're using it internally, though, it probably makes sense to use with high-value customers, too. Slack's shared channels go a long way toward enabling teams to stay in their own space, on their own terms, while working together.
On its own, Slack isn't as well suited to working with customers -- notifications and confused ownership get complicated, and stuff starts to slip through the cracks.
We've helped teams scale up Slack-based support and customer management with an add-on called Frame for Slack (disclaimer: I work at frame.ai).
With @frame sitting in the channel, it's way easier to manage these channels just like a support system. Tailored escalation schedules to fetch only the people who need to respond in a given channel at a specific time, state management to remind people a conversation has not been resolved, and analytics to provide transparency into the level of effort by each person in each channel, responsiveness, full text search and reporting on the substance of historical messages, etc.
This statement makes sense in the smaller context of the point the author is trying to make, but is IMO pretty bad advice taken generally, and it smacks of survivorship bias. It's a good way to overengineer, overplan, and run out of money without delivering much, from my experience.
> We knew the clients better personally, but we knew the product less
> We had more superficial conversations, but fewer substantive ones
> We were able to react more quickly, but our responses were less measured and effective
These are very similar to the reasons our company moved from Slack to Google Chat a couple years ago. It was quite liberating.
Edit: In addition to Slack, we also started using Twist (https://twist.com/). We use Google Chat for quick communication, but anything requiring more than a few seconds of thought goes into Twist. So far this has worked really well for us.
As long as the output is basically acceptable, clients are going to prefer to employ contractors with whom they have strong personal rapport. Making communication difficult and intentionally avoiding the "distraction" of building that relationship is a quick way to die.
I'm in about 15 different Slack, with 15 different credentials. Authentication is a miserable problem, yet Slack chooses to make it worse.
I had taken this as a huge plus in my circumstances -- having them separated in their own space per organization allowed me to decide what set of rules I use for replying very quickly vs. when I get a Round Tuit, but that's a very small problem to fix if I had to manage credentials for 15 channels!
Well now that is just incredibly broken - for organizations without a strong culture of documentation, chat/email histories are vital. To just loose conversations sounds painful.
That may be a setting in the organization or something that your Slack admins are doing? I'm able to look up DM history with former employees in our Slack, their account is just tagged as having been deactived.
Stuffing those in a folder a la Discord would be a boon, but the only option that comes close is using a separate organization, which would cost more.
Once they took VC funding, by definition they are building for a quick exit.
It no longer matters what they want, it matters what the VC wants.
Our lives are easier and our communication with our clients is way more productive ever since we abolished slack.
Would you do work for free? Nah. This isn’t a slack thing.
This isn't a Slack thing per se, but it is a "direct line of low cost comms to the team" thing, and Slack encourages that. There's an implicit cost to things like face-to-face meetings. You can literally bill for them, so they don't happen very often (relatively speaking). By using a chat app you can bombard a team with requests for free, and there's an expectation that they're not going to push back because the 'real time' nature of it means they won't have time to carefully consider a negative response. It's much easier just to say yes, so teams do. A lot of clients abuse that.
Managing clients is hard, and it's a real problem.
The implication also being that they act as the filter that's often missing on such "low cost" communications.
Maybe it's just the way the companies I've worked at have used slack, but it's never been expected to be any more "real time" than email.
If that's the case, then why not just use email? I always thought that the only value that an IM system brings is that it's real-time.
Compared to that emails (and Basecamps and such) feel anxious: tens and tens of different information cramped in a long form text and the expectation us to handle all of them at once and as soon as possible, after all it’s email.
And then again I know of people that have it completely other way around and I understand that. I also think that there’s no solution for that in software form, but in behaviour: we need to embrace the asyncronisity.
Where Slack helps me the most is asking my group questions which seem too small for an email, like "hey what is maximum RPM of the motor we are using?" where anyone could respond and also other people can benefit from the answer.
That's interesting, because I view this exactly the other way around -- an IM is like a phone call, in that if someone is sending one, it's because they have an urgent need and are expecting an immediate response. Email is for the lower-priority things.
Slack might just be worse by degree.
I hate all of the above often having to "support" Tech Support.
I have often wanted to tell a customer, "We will not make progress on this till we stop updating you on progress every 5 minutes."
This stuff is even worse when you have an army of internal "Customer Success" types at a big company.
That said the 25 year rule is absurd. Who really thinks Slack is going to exist in 25 years? Netscape was just founded 25 years ago.
I tried Twist but couldn't get any buy in from the team. Seems like it would solve the issues I have with Slack: it has real-time chatting, but also long-term async storage. It's also easy to move a conversation from the real-time chat to the long-term storage thing.
No noise. Just 2-3 people having a very focused discussion.
On one hand, I've had each of the issues he lists in his bullet points when dealing with Slack (though we only ever join customer's Slack channels), though I've adapted my approach and it's been minimal-to-non-issue, lately -- and I've got no customers asking for this at this very moment. The thing is -- I do not and have not had these problems on Teams.
I believe these sorts of problems aren't general problems that messaging applications introduce, but are problems Slack doesn't handle well. At first, my thinking was "everyone can have it, so it's like the old days of AIM, except people use this for business and a lot of businesses use it", so I went to "it's a public form of AIM that corporations are asking employees to use". None of that is particularly accurate, and it ignored the fact that every OCS - Teams installation that I've used had been federated with people I worked without outside of my organization. Slack didn't really "mainstream" this sort of thing with the people I worked with, so why do people on Slack behave differently?
The only reason I can guess is "Status". Microsoft always pushed this as a huge selling point to their product and I remember thinking "that's dumb" for the first several iterations, but right around the Lync time-frame, I realized that it created a behavior change in me. We used OCS for everything, including telephony, so when someone had a meeting blocked out in their calendar, or was using their phone, their status said "In a call" or "In a meeting" and was bright red. When you shared your screen, your status went do not disturbt[1]. Screensaver pops up and your status goes yellow "Away". You can also set these statuses, manually (which was rarely abused at the 3 shops I was at).
Another important factor was that chats were not persistent[2]. This changed with Teams, and the jury is still out as to how this impacts things, but I think it will make the specific bullet points he mentions worse. In general, when I would send someone a message on Teams, I'd not expect an immediate reply -- even if their status was green -- and if I didn't get a reply, I'd follow up with another method of communication. The idea was to avoid a phone call for something easy. Yes, this eliminates a lot of the "personal hands-on sort of interactivity" that a phone call grants, but it also eliminates 10 minutes of talking about spouses/families when you and I are in the middle of 3 other things and aren't terribly interested in keeping up with cultural norms.
Because status gave me enough information to answer the questions (1) "Are they likely to respond?" and (2) "Am I likely to interrupt them?". I did a lot of development for this platform and I had a ~15,000 person installation to get stats from -- it's interesting to see who had "status change alerts" setup for whom, when they'd be turned on/off, how often people would set their own statuses vs. using the one automatically set. It worked about as I described; replies fell off when statuses were not green, follow-up phone calls frequently followed unanswered chats -- all of this data was relatively easy to grab out of the massive set of SQL databases that powered the whole thing on-prem.
Contrast that with Slack. Unfortunately, at my new employer, we use Slack and are migrating to Teams, online, so I can't get stats like that any longer and my only visibility is myself and my immediate coworkers. There are, effectively, three/(four?) -- mostly worthless -- statuses, some of which behave in a manner that contradicts the features they provide:
(1) Zzzz - it's before or after work; useful when I need to reach out to folks in Seattle and I forget how to subtract by 3. Otherwise, as useful as a clock or my own two eyes looking at the desks nearby. And why warn me not to send this message? You're going to keep it there until they wake up and look, so how about just warn me that you're not going to notify them because they've snoozed alarms, but that the message will be waiting for them when they return?
(2) Offline - grey circle - they're not there or left, or maybe they went to screen-saver or their client as acting up. The thing is, I rely on status so minimally that I can't remember if there are two to cover Offline and Away. Both mean "don't bother" even though they shouldn't -- they're saving my history (if I'm paying, but even if I'm not ... for at least a few hours!)
(3) Online - green, solid, circle - they might answer me.
In addition to that, you can set an icon with a secret (/s) message. I say "secret" because nobody ever sees or reads it. I set mine last week to a "BIG RED STOP SIGN" with a message indicating that I was focused solely on a single project and in the middle of a crunch. I've been done with that for a few days; I received more messages about other projects I had to table last week than any other time working here and this message was so noticeable that I didn't even remember to turn it off until I looked at it just now for the purpose of this post.
So people message more. And they still follow up with phone calls and e-mail, just like they did before, but the messages are reaching their audience less frequently. When people at my last employer sent messages on Teams (Lync at the time), it was 85-90% targeted at "Available" and "In a meeting[3]". I'd bet it's the same way now, only "Available" covers a whole lot of time when nobody is available, causing more messages, less success and more frustration with the product
[0] To be accurate: I lived out of Office Communications Server (OCS), OCS R2, Lync, Skype for Business (and all of the CUs in between) -- I used to develop for these platforms so I was an early adopter.
[1] So intelligent -- never have someone send you a sarcastic or embarrassing comment while you're sharing your screen.
[2] Not, strictly, true and not true at all with Teams. If administrators enabled the capability, chats were stored in your e-mail box where they might as well have been deleted. Group Chat behaved exactly the opposite -- you had to install a massive client and all chat logs were kept forever with no way to delete them IIRC. Very few actually used this product. Teams behaves more like Slack but with all of the capabilities of Skype for Business.
[3] This was puzzling; we assume it was because the vast majority of meetings were conference calls after full adoption of OCS R2, so "In a meeting" meant "I have a meeting on my calendar that got cancelled" or "I have a very rare, in person meeting with only people in the office", otherwise it said "In a call". So really, it became "Extra Available" since you had time blocked out that freed up.
I've been an add-on developer for Microsoft's competing product since the TAP (beta) program for OCS and part of a few organizations who used it as their only telephony/messaging product but people used that product differently.
As part of a project between the two TAP programs, I wrote a dashboard site that provided stats about the operation of the on-prem installation, mostly centered around telephony, but included a lot of information about who was "tagging users for status change alerts" (without details, just rolled-up), IM-only conversations (this was tricky) and stats about interruption with regard to user's status. My personal experience was that we communicated more frequently via IM and had fewer "missed connections" on Teams, resulting in fewer escalations to less convenient forms of communication (and less of a feeling of being ignored). It is my belief that this happened because Teams provided rich information about the status of the user (and also didn't keep IMs around so you didn't expect them to follow-up later if they didn't reply in a few minutes).
Unfortunately, I have no such insight into Slack's back-end, but anecdotally, I am interrupted far more through Slack than I was in Teams and my messages go unanswered far more often to the point that in Teams where I positively relied on status before sending a message, I don't even look at it in Slack because it doesn't help me to decide whether or not I'll be better off picking up the phone or e-mailing.
the Slack status feature you mentioned is -- sadly -- most often used by Slack users to add a cute emoji or whatnot. this is unfortunate.
Slack administrators can set suggested or "default" statuses. it's at https://<yourslack>.slack.com/customize/statuses
and so, a company can set statuses that staff can be required to pick from, perhaps some common ones like:
- In the office - Working from home - In a meeting - PTO
and the company can then make it known to staff that their status icon should accurately reflect their current work ... status, and not whatever cute emoji they want to use.
DND/Do Not Disturb should not affect use of Slack status. Force the notification through if your message is urgent.
this is not rocket science.
if Slack usage is affecting how a company works because staff can't tell if someone will respond or not -- change the way the staff use Slack to better suit the business.
/shrug
The major point that I didn't make clear enough about statuses "not working" is that even if there were more statuses, they are manual. We observed that people manually changed their status, most often, to "Available" from another non-available status, under Skype for Business. Outside of that, people simply didn't manually manipulate their status. And when they did, they'd often leave it that way for a ridiculously long time because they'd simply "forget".
Inadequate status choices are not as bad as completely unreliable statuses. Teams shined in providing enough status about a user, automatically, for a non-developer, non-technical user to reliably answer the question "Will I get an answer to my IM/call when I send it?" and "Is my IM/call highly likely to be an interruption?".
If you used it for telephony, or had the Skype for Business mobile client installed, you switched to "In a call" when you were on the phone, "In a conference" when you joined a Skype for Business conference call, "Do not disturb - Sharing" when you started screen sharing (and it kept inbound messages from showing up on-screen for your audience). Honestly, it seems like one of those under-the-fold bullet point features, but it is its most important.
In the scenario you talk about, above, two things have to happen (after configuration is altered to allow changing statuses). The user has to regularly change their status to signal their availability (not physical presence or time of day, but "I am busy doing something that should keep me from responding"). And the rest of the users have to rely on that status. The only way that happens is if the status is accurate far more often than it is wrong. That won't happen unless everyone is rigorous with making status changes... and that's not a memo I want to send.
Lync/Skype for Business (and I assume Teams) gives you both options. Let it run automatically and it'll switch your status when you receive/make a call, join a conference or have a meeting time blocked out in your calendar for you and put it back when you're done, or set it to what you want. And you could extend this capability[0] and automate it in different ways.
[0] The old on-prem version was insanely customizable; you could completely re-implement the client, they provided every hook required to re-implement dial-in conferencing (an "Enterprise" feature) in Standard edition (and actively assisted in a project I worked to do just that).
Not to mention, chatting with people usually means they treat any request you have as low priority. Whereas going to them elevates that priority substantially.