[lynchdt]

I work mostly with Engineering teams, and consider slack inbound a pathology. Slack is great for collab in places, but it’s not a strong way to manage inbound, IMO.

The teams I’m responsible for make it easy for their stakeholder to raise issues, asks in a more deliberate, calmer way e.g. via GitHub issues or manager email. In exchange, we commit to mutually agreed response times on certain categories of business critical issues.

Generally, I don’t think it takes an ADHD diagnosis for slack inbound to completely kill your productivity, it’s a general problem. I don’t have ADHD but have strong empathy for how this must be a complete nightmare for you.

Perhaps have a manager put some structure on your inbound on your behalf?

[MarathonSeeker]

It starts with a culture where I'm not sweating the fact that I haven't checked my Slack notifications in a while.

Slack is used like a kitchen sink in the two places I've used it - there is no easy way to determine what is urgent vs what can wait. One literally has to comb through all the red dots to filter them. If you believe channels solve this because you can create dedicated channels for the important stuff, very soon someone starts abusing the responsiveness on this channel to their selfish ends, first seeking an exception, and very soon making it a habit.

To top this, the Slack UX is literally designed to maximize the time one spends with it. I often find myself on Slack intending to either - 1. Check one of the important channels or 2. Recollect something someone shared that I now need to use

And before I know it, I'm responding to something that I didn't need to at this time. I often also forget why I came here in the first place.

Yes, email and ticketing are also pervaded by spam, but Slack is essentially a corporate sponsored, culturally accepted medium for noise and distraction with no easy way to apply controls.

You typically need strong leadership to define the constraints through culture, because the tool by itself isn't designed for this.

[sublinear]

I completely agree.

I am so fed up with this problem that I'm not going to mince words.

Nobody wants to be told they're disorganized and sloppy, but people outside engineering (especially sales and client people) are the absolute worst. They're the ones with the ADHD.

Engineers rarely have trouble with deep focus on work unless they're constantly being nagged by idiots who don't understand what they're costing the company.

There's a strong business case against the abuse of chat for "quick questions" or whatever other bullshit people are too dumb to figure out on their own if they just spent a few seconds more in thought before bothering anyone else.

[Tagbert]

I'm curious about what you mean by "inbound". It sounds like messages from someone "outside" but not sure if that is probably a limited definition.

[devonbleak]

Inbound = something that requires a response/action. Could be an automated alert that creates a ticket, could be a slack message from someone asking for something.

If you're not great with it every message can feel like an inbound and you're compelled to go cycle through all the channels and read everything whether it's immediately relevant or not.

[davzie]

I think the meaning of inbound here refers to work that is defined or asked of you or a team via Slack instead of via more thought-out and defined work.

[lynchdt]

I mean sources of incoming work, could be a quick question, an ask for something, automated alarm or a bug.

Slack makes it super hard to stay on top of this and systematically triage the low from the high value.

[Tagbert]

Thank you

[tetha]

Indeed, very much this. We spent some efforts structuring this at work and now we have 2-3 rules in place. First off, all requests for work and services are always issues either directly in the ticket system, or via mail to a central mail address. Nothing from chat will reliably trigger any work done.

However, we have defined a role "first contact". This role rotates on a weekly basis, and whoever is first contact has the job of monitoring some well-known channels for requests. They then act as a first level support pretty much, helping people to figure out how to best request what they need. They also handle mails that aren't automatically handled in the central mailbox.

The latter in turn enables the team to just ignore pretty much all chat notifications outside of the team. First contact person will ensure they are heard, and first contact person will also address high severity tickets directly to people after creation. And as much as that sounds like a slower process, it has improved our resolution times because people aren't distracted as much.