This is the difference between a good idea and the implementation.

People just act differently in "official" topic channels.

It's like when you buy that super secure door lock and the lowest bid handyman bends it while installing because it's such a pain to align correctly and now it's just as vulnerable as any other lock.

yep, also doscoverability is not an issue with Slack. You can find most things with a search, people typically don't go scrolling through a channel to find something.

People start by searching within a channel, especially when terms are vague or frequently used.

What a Poe's Law of a comment.

Slack's search is … okay … but there are any number of times when I have issues finding a thread I was looking at prior.

For all the AI hype that is the current time, search still can't a.) rank the alert bot that is just spamming the alerts channel as "not relevant" when "sorting by relevance" or b.) … find the thread when I use a synonym of an exact word in the thread.

Or the other day I was struggling to find an external channel. I figured it should be easy. But again, I chose a synonym of the name, so miss there, but I though still — by management edict, all of our external channels start with #external-, I'll just pull up all external channels and linear search by eyeball … but management had named this one #ext-…

Yes - not only is Slack search underpowered, but also records management folks are likely to configure pruning of Slack content older than a couple years or so. This is IME less likely to be a problem with wiki pages.

> search still can't a.) rank the alert bot that is just spamming the alerts channel as "not relevant"

I find "Exclude automations" toggle to be good enough. But we might have very different workspaces, as I usually don't see the point of "sorting by relevance" at all: for my purposes, relevance is almost always better approximated by date than whatever Slack's ML team comes up with.

> from a manager’s perspective this format is something we’ve tried to avoid

I'd rather avoid the manager's perspective.

The blog post is from a manager’s perspective. It’s a manager explaining what they had their employees do.

As a CEO 'manager' myself, I try to let people just be. Getting too granular about person vs. topic and redirecting people to the right room sucks the fun out of everything. Let people mess up and post in the wrong place, who cares?

OP's post was about a great experience 'tremendous value' they had and now you're pooping on it with 'manager' opinions. Read what you wrote from the employee perspective, you're sounding like the self-appointed fun police.

FWIW it's not something I had "my" employees do. The practice started organically and continues to exists because everyone created their own channel and kept going with it.

One thing I suggested was that they should be muted by default so that they aren't a distraction and don't set the expectation that they should be read.

I thought it would be interesting to write about because it was an emergent practice that seems to be sticky and useful within our team.

yeah, total buzzkill.

I get the need to call a peg a peg, but it's also good to allow a little fun as well or you end up with these dementors sucking the life out of a company.

For a slack group, I think it's relatively harmless if the focus is around casual shoot the shit convos.

That's the remote equivalent of banning informal conversations in the hall and saying "save it for the daily team meeting".

It feels good as a manager to formalize things, but the best collaboration and ideas happen organically at less formal times and places - and those times are worth at least as much, if not more to the company than anything formal.

You might as well say "no thinking about work in the shower."

Ouch, my wife has encountered almost exactly that in a recent brush with a biotech company that seems to have been infected by FAANG expats. She was advised that any kind of sidebar conversation is a faux pas.

I struggled to guess at the real motive. Is it some project manager's blatant control freakery? An org-level, cynical management attempt to commoditize their knowledge workers? Or some kind of emergent failure where culture morphs through openness -> radical transparency -> enforced conformism a la 1984?

Probably cargo culting from companies with 50k+ employees (where minor friction for one is way outweighed by more availability for all).

The worst manager I ever had literally told the team off for discussing things in a 1:1 setting, it was wild.

I've found the best way to kill a conversation is to point out the appropriate place the conversation should have started.

More productive, on both counts, is to move the conversation to that channel.

That is, don't put the burden on the initiating party, but also don't continue the dark-channel discussion.

This is a great comment. Thanks.

In my case - indeed the name is a historical baggage, I'm not arguing for or against it.

Indeed we had regularly situations that we had to pull in experts from other rooms, to discuss specific topics (like TCP), so we should have forwarded the conversation at the start.

But I don't think this should be categorical. There is value in non-experts responding faster (the channel had good reach) by your non-expert colleagues than waiting longer for the experts on the other continent to wake up.

Maybe there should be an option to... move conversation threads across channels?

I think there is place for both - unstructured conversations, and structured ones. What I don't like about managerial approach, is that many managers want to shape, constrain, control communication. This is not how I work. I value personal connections, I value personal expertise and curiosity. I dislike non-human touch.

"You should ask in the channel XYZ" is a dry and discouraging answer.

"Hey, Mat worked on it a while ago, let's summon him here, but he's in east coast so he's not at work yet, give him 2h" is a way better one.

I know that concentrating knowledge / ownership at a person is not always good, but perhaps a better way to manage this is to... hire someone else who is competent or make other people more vocal.

And yes, I don't like managers trying to shape communication patterns.

> I know that concentrating knowledge / ownership at a person is not always good, but perhaps a better way to manage this is to... hire someone else who is competent or make other people more vocal.

> And yes, I don't like managers trying to shape communication patterns.

I'm a manager who shaped communication patterns (e.g. default conversations to a public channel) because we're solving different problems. By moving conversations to a public channel away from an individual, we're improving redundancy and reducing single points of failure. Our primary responsibility, which understandably garners discontent, is to prioritize the system over the needs of individuals, within reason.

There are many issues resulting from defaulting conversations in private channels or DMs that you've probably seen first-hand.

"WE ARE THE BORG. YOU WILL BE ASSIMILATED. YOUR UNIQUENESS WILL BE ADDED TO OUR COLLECTIVE. RESISTANCE IS FUTILE."

It does feel a bit like that fighting institutional pressure to "optimise efficiency" and "reduce individual dependence".

Your uniqueness is not tolerated, assimilate to the collective, follow the processes given to you, don't think individually.

Except when solving these problems, they require creativity, be creative. BUT ONLY HERE

I like this post. It has the right balance between uncomfortable reality and some humour!

All middle managers (in my experience) talk a big game about reducing/preventing key person dependencies, but on 100% of my teams, there were always multiple key person dependencies. The real issue: If you are not the key person for anything, you are the easiest to layoff (fire).

Thanks, the humour helps keep the melancholy at bay.

Agreed, you never want to be the one holding no secrets when the music stops.

A slightly different viewpoint is that sharing in public or larger private channels allows for knowledge sharing and collaboration. Sometimes the key person is wrong because they aren't the only one working on something. I know that ego might get in people's way sometimes but other people in the team and in the organization also have valid perspectives. As a manager, its important to try and get to a best solution and that means collaboration, not a specific person's approach all the time.

The redundancy also helps the key person be able to disconnect when on vacation. If you are the sole knowledge base for some critical part of the company, might as well drag the work laptop with you every where you go.

OTOH I hugely appreciate my manager who makes a conscious effort to direct people to ask questions in public channels and not just ping “hey” in my DMs all day. And it saves them time too, because my response is going to be “you should ask in channel xyz”. (And yes, in that public channel I am likely to be the one who answers it, but not always, and it’s now visible for other people who also need to know - the exact problem you were so proud of solving!)

The best Slack culture I ever saw also had a strict “No DMs” policy. All discussions had to take place in public or semi-public channels. DMs were reserved for “hey you’re missing standup” or similarly trivial stuff.

> Maybe there should be an option to... move conversation threads across channels?

I believe Zulip can do this, but Zulip is not really favored in these parts

> I do the same thing when someone starts asking specific technical questions in #random or #general: Redirect to the project specific channel.

What if it is a specific technical question but does not clearly belong to a specific project?

Oof. From a manager’s perspective why don’t you focus on getting this information being in place for your team so that they are productive? You could feed that content into a platform the is searchable, categorized and part of onboarding. Utilize utilities that will automate collecting information, rather than discouraging learning.

Focus on eliminating tribal knowledge, implementing a learning culture.

> I would encourage everyone to just go to the appropriate topic channel and discuss it there.

These just become apologetics channels. Not productive.

A common mistake that some managers make is pushing the burdens of managing onto those you're managing. Any of us who have been managers can look back and see things that we tried to push down to those we've managed because it made it easier for us while later realizing that wasn't the best solution.

If there's a catch-all channel that employees are using to share knowledge that's not a bug, it's a feature. If, as a manager, you want a more structured means of conveying institutional knowledge generated within such channels then it's on you to put that together. Trying to push that burden down the chain often results in that institutional knowledge being shared verbally or via private emails/DMs in order to avoid the burden of documentation, which is a net negative.

Such information is a force multiplier for teams as well as a great asset for onboarding new hires. Both of those are direct benefits for the manager and the company, so take the advantage of that kind of spontaneous documentation rather than insisting on passing on the cognitive burden.

> If, as a manager, you want a more structured means of conveying institutional knowledge generated within such channels then it's on you to put that together

Isn’t the GP describing exactly that?

IMO, the greatest force multiplier in onboarding is automation... How many user interactive steps does a dev need to walk through to get up and running?

I've often gotten this down to a single directory and a primary script you need to run 3-4 times... mostly because of required reboots, such as after WSL setup, also, a few options to set in Docker Desktop. I've done similar with mac/homebrew.

From there, you have docker-compose and shell scripts to run against the projects... these scripts and the compose file(s) are the entry points into a project, actually documenting where things are, and how they connect (to an extent).

Effectively, getting a working solution running sooner than later. This is just my own opinion, but automating a dev environment for onboarding, especially if you're a larger org, is a great tactical decision.

Heavily seconding the “setup script” method for anything that can be scripted in lieu of documentation and handholding. I’ve done this at multiple companies and it proved valuable. Even if it eventually breaks it’s easy to fix, and it’s usually pretty self-documenting, so anyone who’s even a little curious what’s going on, they have access to all the “secrets” of how it’s being done (and can also improve it).

This is why so few people have loyalty to a job. Managements role appears to be simply killing all individuality and fun in the workplace.

"First Warning, this is an unauthorized topic in an incorrect location. You are permitted to discuss this topic but only in the predesignated area."

"Did you complete your TPS reports this morning?"

"Yeah... I'm going to need you to come in on Saturday. We have a go live in 3 weeks for our mini waterfall agile release and you currently have 2 bug tickets assigned."

This murders the last spark of connectivity for remote workers who are already left out of the daily in person banter and bonding that in office work provides.

Comments like these really make me appreciate that we are simply numbers in a spreadsheet and no longer real people to companies and leadership.

> doing anything that starts gravitating the knowledge toward a person instead of a topic creates problems for discoverability, searchability

Channels aren’t searchable. Messages are.

> risks creating the impression (for new employees) that certain specific people are at the center of projects they just happen to know a lot about.

Sorry to break it to you, but that’s not just an impression. It’s a fact.

This is a terrible suggestion, please ignore it.

If people have found an effective way to communicate information, leave them the hell alone. I have too often seen people like Auronis decide to come in and manage something to be proper, and then destroy the communication.

The appropriate thing to do is to find a way to augment, without interfering, the channel to shore up any weaknesses.

Formal channels are often too formal - people don't want to look dumb, or get chastised for asking something incorrectly. Formal channels are intimidating, not welcoming.

The point is knowledge sharing, not "appropriate" knowledge sharing.

I love how the OP was like, "hey, we created this informal channel and communicated valuable info to the whole company", and then Auronis is like, "yeah, don't do that!"