Hacker News Reader

Comment by paxys | Hacker News Reader

Here's what this conversation always boils down to:

Slack is a tool, just like one of probably dozens you use in your day-to-day work. It doesn't set or enforce any guidelines for how it should be used. If left unchecked it has a tendency to amplify the worst parts of your company's culture. If you make an effort to moderate it, it can be a huge asset to productivity.

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 criticism I most often hear is "Slack expects me to be online all the time". No, YOUR COMPANY expects you to be online all the time. Slack can be closed with one click.

View on HN

This ignores the fact that defaults matter, and defaults shape the usage of the tool. I want to reply in threats, but often don't, because it requires me to let go of my keyboard and fumble around with the mouse to do it. That's why I vastly prefer Zulip (which additionally isn't slow as molasses).

I want to reply in threats

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

Nice fingers you typed that comment with, it'd be a shame if anything were to... happen to them.

Another plus one for Zulip, huge improvement over Slack for me.

Threads are an extremely important asset in large channels to maintain organization. Less important in ad-hoc quick conversations in small DM groups for sure. I've never experienced any issues with people not using threads and the UX around it has always seemed fairly smooth to me.

My issue is that I'll reply out of thread because it's much, much faster in Slack, and then I'll be kicking myself because that means I won't get notified of further replies (and neither will anyone else).

I'm always not sure when a conversation will need a thread. Sometimes I start a thread and then it's over with just one message that provides the answer. Other times I don't start one right away, but now if I start one then the first 4 messages of context will be missing at the top. I would use threads ofif there were a way to create them retroactively.

The reason I don't like threads is that I can't expand a thread without seeing it in the sidebar. That's so effing annoying.

Yeah, they really botched the implementation of such an essential feature.

A 128oz tub of pork rinds with an easy-open cap is just a tool to alleviate hunger when you're looking for a salty snack. Placed next to an incredibly disciplined person like an Olympic athlete, the tub will probably last six months and not damage their health. But placed next to an ordinary person it will definitely encourage overeating.

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.

Bad analogy though because persistent channel-based chat is a good way to handle ephemeral and interactive collaboration, especially in a Covid world where few lightweight options exist. Do we have to open a Zoom, send an email or start a doc for every single thing?

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

I've had jobs where every little thing required a bunch of back and forth. Integration, and spinning up a new product. Slack (or IRC if you aren't hooked on giant emojis) work well for this.

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 was going to post the same thing. Use tools in a healthy way and they should be useful not harmful.

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.

At my employer we have Slack channels for engineering teams but anyone in the company can (and does) come in to ask what amount to low-level support questions. I've dealt with it on my team by rotating the job of responding so that whoever is on-call for the week deals with it. It means there's a lot of interruptions, unfortunately, for whoever is on call, but at least the rest of the team is explicitly given permission to ignore it.

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.

We deal with the same. Here's an easy solution – set up a #support- channel for the team. If anyone asks a question in the regular channel, redirect them. Have a fixed rotation and SLA for the support channel.

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.

Alternatively, set up a #eng- or #dev- channel so you don't have to redirect anyone to #support-

The channel name is not the problem. The problem is that people will go to whatever channel they want and ignore any "official" support system. It's the same as the guy in sales who comes to your desk to bug you about something he promised a customer. He knows he's supposed to go through channels, but he's going to do what he wants, regardless of mechanism.

That can be solved with the right company culture and a good manager. If someone was disturbing my work in that manner I would mention it to my boss, who would probably tell me to not spend time answering them next time and direct them to the proper support channel. If it happened repeatedly, then my boss would escalate it with the salesperson’s boss.

They will keep doing it if they keep getting positive results. Eventually it's up to you and your team to set boundaries.

For sure, but then management gets unhappy because sales people are unhappy.

When you force the company to use your custom internal platform instead of an industry standard, it's only fair that you become responsible for providing the instant answers they would otherwise get from Google and Stackoverflow.

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.

> If you make an effort to moderate it, it can be a huge asset to productivity.

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.

> 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?

I once worked at a (open) office where sales people were constantly berating engineers, asking for a feature or pestering for a status update on a feature/bug in progress. It got so bad they installed a wall around that area.

Because management should be rigorously defending devs from being needlessly interrupted with whatever some sales guy thinks is important in the moment? Management can filter out the garbage, condense down the really important bits and deliver them during a time it won't knock dev out of the zone?

Worked fine where I worked. You know you can turn notifications off? You know you can tell a sales guy he's being annoying?

We were banned by management from turning off notifications.

I see lots of tools and they all have good and bad points.

- 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.

I think this is very wise. Slack as the scapegoat isn't quite correct, the actual root cause is how they used it.

>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.

Tools use and shape us to the same degree that we use tools. We're not enlightened rational choice actors who correctly discard bad tools and only use good ones, most of the time we just pick defaults, because choice is costly and attention is in short supply.

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.

Slack expects you to look at slack during your work hours - and robs you from the focus needed for deep work.

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.

Slack doesn't expect you to do anything. Your coworkers do.

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

I don’t mind the pedantry; the issue I’m pointing out is that people will not wait for you to chime in but will make their decisions and move on. Because slack as a chat encourages that attitude.

The guys at 37signals/Basecamp said it well here: https://m.signalvnoise.com/the-presence-prison/

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

Good article. I love reading Jason's thoughts on work culture. They must really have one of the best working environments in the world.

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

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

Often baked into SaaS pricing models as well. At “call us” pricing tier $Company includes 24/7 support with guaranteed response time SLA

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

Yeah, that's my point though. You can't expect your employees to be permanently on call, watch them burn out, then blame Slack.

I hope the other commenter's idea of "right on-call practices" involve hiring enough employees to give a humane on-call schedule, and compensating appropriately for the on-call time. That's my idea of the right on-call practices, and would go very well with "add 2 zeroes" in the pricing of that SLA.

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

I had a manager tell me we can't hire people to be low productivity people just because we need people in the rotation. Idk if I agree with that, though I guess I get the point.

Who suggested hiring low productivity people?

If there's not enough work to go around but you need people on the rotation your productivity will be low

In that case, just contract with skilled infrastructure consultants (whether as individuals or through multi-person consultancies) to share on-call duties with your infrastructure employee workforce on an as-paged basis rather than hiring them full-time.

Reply on news.ycombinator.com