Look, I feel ya, but it is important to stay professional even in the face of annoying coworkers.

Tools placed in the hands of imperfect people will be used imperfectly, and in a way that amplifies the properties of the tool more than the priorities of the person.

I get that some environments might be fine without group chat, but for others it's indispensable.

But for the rest of my work there are questions but you can batch them if you think ahead, and write a good email. Or, just put the questions in the ticket and use the right collaboration tool.

I find that all chat-derived information needs to be rewritten (ideally) or being cut&paste into a document because chat is either ultimately ephemeral, or lives in an entirely different system from the rest.

I really like slack and use it constantly during work. If you need to go head down and focus on tasks needing concentration, put a notification on your slack profile saying you are busy. Make blocks on your calendar for sanity and concentration time and a slack status to match.

The same thing could be applied to email, I never answer my email later than work hours, sometimes the company itself is the issue, if they expect all hours communication I would look elsewhere, time and sanity are vital natural resources.

As a company we could and should do better at the support system, but that's just one aspect of the problem with company expectations.

Interruption is a feature. If we let our platform teams get into the zone and code too much, they'd NIH our damn editors. It's important to have support burden as a brake on the development of custom crap, and a thumb on the scale in favor of deploying tools that a) developers might already know, b) the internet definitely knows, and c) are higher quality and more capable than even the brightest team with your budget could create.

We have support channels for our Redis and MySQL installations. It is crickets in there. But the people who write a custom NoSQL are rightfully getting slammed 24x7.

In fact everyone now prefers this over the pre-Slack way where you had to randomly email or IM people one by one to try and get some help.

Sounds good in theory, rarely works well in practice.

The only times I've seen Slack work well is when everyone involved starts with similar expectations about how it should be used and what's appropriate. In my experience, this is easiest to achieve when Slack channels are closely aligned with teams who are working together.

The model tends to break down when Slack is used for communication that is better served by e-mail, calls, or meetings. An easy rule of thumb is that if it crosses department boundaries and/or is something that needs to be formally communicated to an entire team, it's better to direct it to e-mail or a scheduled call.

> Speaking of the example in the article, there is absolutely no reason clients should have direct message channels with your company's employees and expect to get a response 24/7.

Strongly agree, but it's not just clients. Sales people, for example, love to use Slack because it's a backdoor channel to circumvent management and go straight to the engineers.

And that's bad because?

- email is good for mindful conversations. It is slow and doesn't need to interrupt. mailing lists feed into this.

- wikis are great for information that is designed. But it takes a lot of energy, and really requires dedicated maintenance. I've never worked anywhere where internal wikis were better than mediocre.

- bug systems have an off-label use - they are great for finding out about problems in company specific software/systems

- ticket systems are great for resolving small problems. But they seem to be closed systems that aren't searchable.

- slack. Now slack is good, not evil. I think where slack shines is up-to-the-minute communication where several people help work through a problem. but in moderation! Be polite, do not nag.

It is also exceptional at "trivial" knowledge that nonetheless holds back bright minds from progress - and is searchable.

What goes into slack is the less-formal-than-email stuff, the less-organized-than-wiki stuff, and less-critical-than-bug-report stuff.

>Speaking of the example in the article, there is absolutely no reason clients should have direct message channels with your company's employees and expect to get a response 24/7. This is true with email, Slack, SMS and every other form of communication.

the craziness is that without slack this client would have still done this. I've had clients with my personal cellphone # printed out and put in the server room 'for emergencies only' but I'd have managers call me in the middle of the night because their helpdesk hasnt responded to their problem yet.

I was effectively on-call 24/7 and couldnt go do anything.

Build a culture with bad tools and you get a messed up culture. Applies both to the structure of many companies and their communication tools.

Funnily enough the point about choosing Slack can actually be made for skilled professionals and their companies. They can choose where to work, curiously enough many actually up at precisely the firms their top schools are funneling them to.

Or, you do deep work, and lose on the decisions, chatter made in real time.

Slack turns the working environment to an equivalent of n open office where everyone chatters all of the time.

Good luck doing anything else.

People don't interrupt me on Slack, simply because Slack doesn't jump in front of my IDE. When I see a notification dot and have time, I'll look at it and reply

The problem isn't the tool, it's the mindset that often goes with it.

Uhh... except in Investment Banking. I suppose when your client is paying so much, they rightfully expect a 24/7 hotline.

Oh you want the 30min SLA? Add 2 zeroes

The company then institutes the right on-call practices, ensures support staff is trained, triage is correct, etc

But, yeah, a lot of places don't do that.