←back to thread

Principles of Slack Maximalism

(aelerinya.substack.com)
51 points surprisetalk | 3 comments | | HN request time: 0.007s | source
Show context
throwaway150 ◴[] No.46110290[source]
This is one of those posts where I cannot work out if this is earnest or satire. I kept waiting for a punchline but I don't know if it ever came. Makes me suspect the whole thing was the punchline.
replies(3): >>46180713 #>>46180753 #>>46180858 #
1. antonvs ◴[] No.46180753[source]
It seems serious. I can only imagine it’s referring to a pretty small company. I suppose it can be tempting to do everything with one tool.

I’ve seen some slack maximalism before, like using Slack as a primary operations platform - sending alerts and so forth to it, and nowhere else. But then that company hired a real engineering manager.

replies(1): >>46180968 #
2. simianwords ◴[] No.46180968[source]
im not sure what you mean - bigger companies also use the slack maximalist approach.
replies(1): >>46181635 #
3. antonvs ◴[] No.46181635[source]
I’m not just talking about heavy use of slack, I’m talking about maximalism as described in the article. Larger organizations will typically have several different systems to perform many of the functions described in the article, and it generally wouldn’t make sense to replicate that functionality, but worse, in slack. It would quickly become unmanageable, because slack simply isn’t designed for that. Heck, slack is barely designed for its own core functionality - e.g. its thread support is incredibly limited.