[larrik]

I feel I disagree with most of the comments here, and agree with the article, even if its a little shallow and short.

For starters, he's talking about communications within a team, not the whole company. Should all work conversation happen in a single #general channel on slack (or whatever the equivalent is wherever)? Absolutely not.

For a long time my boss was a big proponent of this, and I was against it. However, I'm personally tired of having the same conversation over and over as we realize we need to add more people to it. Or half the team decides on an approach in private, and then someone in the other half sees in the PR immediately that they didn't consider some huge thing and now it's back to the drawing board.

So now, everything should happen in the team's open channel.

[theptip]

I don’t think the OP at any point advocated for using one channel. That’s a horrible approach IMO.

Public vs DM just means (to me at least) “put all comms in the relevant channel, never in a DM”.

I’d go so far as to advocate temporary channels for individual projects but not everyone buys into that. At least have team and working-group/functional channels.

Basically it’s analogous to email (point-to-point) vs. archived mailing lists (which anyone can subscribe or view after the fact). Mailing lists and public slack still have threads/channels.

[SPascareli13]

I have come to the very same realization as you in the "temp channel for a project" thing.

Before this, the devs would make a private channel without product and management people, to discuss technical things openly or just to complain. But product/management was unhappy to be left out of this communication channel.

Eventually we, devs, decided on our own to end the private channel and "banalize" the main team channel, by that I mean that we were going to try to make the main channel less "official" looking and more casual, like sending memes, talking outside of threads and so on. With the intention of making people mor comfortable in using it.

This had mixed to low effectiveness, some people were more comfortable speaking entirely on the main channel, some other people pretty much just started only using private conversations and never used the main channel.

So my solution was to create a temporary project channel, open, but only with devs explicitly invited (but communicated at the main channel that the channel existed). This channel is implied to be a dev channel, but whoever wants to join in can, or they can also just peek in without joining, being a public channel.

So far this has been working well, as long as you are in a reasonably long running project. I have archived more then one of these channels as the projects ended, and I'm thinking of maybe not even achieving the current one and just rename it after the project, let's see.

So, keep of trying to make this fly with your team, it did worked somewhat with mine.

[xboxnolifes]

> For starters, he's talking about communications within a team, not the whole company. Should all work conversation happen in a single #general channel on slack (or whatever the equivalent is wherever)? Absolutely not.

If we can agree that not all conversations in a company happen inside of one big channel, we've already agreed to subdivide the company's conversations into smaller subgroups (teams). Why then do we dismiss the idea of subdividing a team's conversation into smaller subgroups? Why is a team the smallest unit?

Is there not also times where you share information to your entire team, but then realize you need to add in other people from not in your team? How is this different from the example where half the team had a discussion? Why is the entire concept of subdividing conversation lower discarded in an attempt to fix an issue that doesn't even end up fixed?