that's the thing that's so inorganic about this whole thing : it's not a judgement free zone, it's a zone that tricks people into presuming that.
If some underling somewhere says something that exposes their ignorance or naivety to either a policy problem or a technical problem you'd better realize that it's going to trigger a 'review mechanism' somewhere down the road within the organization; to think otherwise would be pure fantasy.
Similarly : if you go drinking with the boss, you do still have to remember that the drunk puking slob who you're carrying to their hotel room is going to wake up and be your boss tomorrow.
very few humans actually disconnect this stuff from their internalized judgements of people.
The first type don't ask questions. They know they're imposters and don't want to be called out.
The second type do ask questions. They also know they're imposters but they're trying to learn so they're not.
Judge people on their actions else you'll only spot the second group, and often with a bit of support those ones can go on to do great things, especially if they're experienced at one thing but they're not learning a new thing. When they get enough knowledge to connect the two things they can be absolutely brilliant.
I tell new hires that they shouldn't be scared of asking questions, and that if they're not asking questions they're probably not pushing themselves enough. But also caution to make sure that they check available resources first, and then ask the right audience.
You got to be really careful.
If there's a lot of jobs and a lot of market opportunity and a lot of demand for talent, then workplaces can be like this.
I'm afraid that with AI, one of these types of things are simply gone.
People who are likely to judge people for dumb questions are rarely involved in those groups in the first place, for exactly all the obvious reasons.
The more realistic outcome isn’t that your boss ends up a drunk puking slob (and for what it’s worth most of these groups don’t include leadership anyway, so not sure why anyone's boss would be involved) but that an intern floats a terrible idea ("I'm thinking of taking these 10 shots of 151"), nobody responds, they take silence as approval, and they end up causing a mess and then being judged for the mess they caused.
A quick gut check from them with a healthy group might get a few eye rolls and a "here's why that's a bad idea", but not any lasting judgement unless they completely ignored the advice.
The only case I can think of where that might happen is if they already did something which has policy or legal implications ("hey i accidentally dumped the whole user base including PII to my phone"), in which case - good? There should be a review mechanism, including consequences if they ignored a bunch of roadblocks.
Yeah, the incentive structure for something like this is totally misaligned for this to work effectively in many cases outside of a very small, tight-knit team. (In which case... why the formality in the first place?)
For the "juniors": Why waste time digging through documentation, searching, or thinking--I can just post and get an answer with less effort.
For the "seniors": I'm already busy. Why waste time answering these same questions over and over when there's no personal benefit to doing so?
Sure, there are some juniors that will try and use it as a last resort and some seniors that will try their best to be helpful because they're just helpful people... but I usually see the juniors drowned out by those described above and the experts turn into those described above.
I think we _could_ come up with something that better aligned incentives though. Spitballing--
Juniors can ask a question. Once a senior answers, the junior then takes responsibility for making sure that question doesn't need to be answered there again--improving the documentation based on that answer. Whether that's creating new documentation, adding links or improving keywords to help with search, etc. That change then gets posted for a quick edit/approval by the senior mainly to ensure accuracy.
Now we're looking at something more like:
For the "juniors": If I ask a question, I will get an answer but it will create additional work on my end. If I ask something already answered in the documentation that I could have easily found, I basically have to publicly out myself as not having looked when I can't propose an improvement to the documentation. And that, fairly, is going to involve some judgement.
For the "seniors": Once I answer a question, someone is going to take responsibility for getting this from my head into documentation so I never need to answer this again.
This has an added benefit of shifting some of the documentation time off of the higher paid, generally more productive employees onto the lower paid, less productive employees and requiring them to build out some understanding in order to put it into words. It may also help produce some better documentation because stuff that a senior writes is more often going to assume knowledge that stuff a junior writing may think to explain because _they_ didn't know it. It also means that searching in the Slack/other channel, any question you find should end up with a link to the documentation where it's been answered which should help you discover more adjacent documentation all of which should be the most up-to-date and canonical answer we have.
> Once a senior answers, the junior then takes responsibility for making sure that question doesn't need to be answered there again.
That might make sense for simple questions. But for anything more complex, especially when the issue stems from something you have control over, having senior folks take ownership might make more sense. If they can tie the fix to visible impact, there’s a strong incentive for them to actually solve the root problem. Otherwise, there’s always the risk that experienced team members simply ignore the question 100% of the time (which also solves the problem of "i've already answered this question").
One way seniors might approach these types of groups is by treating them as a source of ideas. Repeated questions like “how do I use X?” might indicate that X needs a redesign or better onboarding. An experienced corporate climber could treat those questions as justification for "X 2.0 which is way easier to onboard to" and get backing to work on it.
Anyone who’s spent time at a large tech company has likely seen this dynamic play out, because it’s a common pathway to promotion. Definitely taken to problematic extremes, no doubt, but a slightly-healthier version of that playbook still beats the alternative of relying on the arcane knowledge of a select few as gatekeepers of information.
I am surprised that I had to scroll this far to find this observation. If I see a person's posts in multiple channels, I don't switch ON and OFF my mental image of them based on channel like a SQL where clause where channel <> personal. Based on the same premise, the person posting also probably knows this fact and isn't going to be totally free and relaxed asking whatever comes to their mind due to fear of judgement - the same eyeballs are going to be looking at the posts, irrespective of the type of channel.
As someone posted elsewhere, it is all going to be cultural and if that is right, it pretty much doesn't matter how you structure channels.
So while the Q&A format is good to have available, I’d discourage creating separate channels around a person. I would encourage everyone to just go to the appropriate topic channel and discuss it there.
I do the same thing when someone starts asking specific technical questions in #random or #general: Redirect to the project specific channel. That’s the place where all of the relevant people will be relevant and watching and it’s the first place they’ll search in the future.
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.
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-…
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.
I'd rather avoid the manager's perspective.
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.
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.
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.
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."
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?
That is, don't put the burden on the initiating party, but also don't continue the dark-channel discussion.
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.
> 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.
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
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).
Agreed, you never want to be the one holding no secrets when the music stops.
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.
I believe Zulip can do this, but Zulip is not really favored in these parts
What if it is a specific technical question but does not clearly belong to a specific project?
Focus on eliminating tribal knowledge, implementing a learning culture.
These just become apologetics channels. Not productive.
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.
Isn’t the GP describing exactly that?
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.
"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.
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.
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!"
Hi, that's me! There were definitely a lot of fun conversations.
I liked that a culture of internal blogs became a thing too. It was good to see people brain dumping their experiments and findings. I think people learnt a lot from following all the internal blogs.
> internal blogs
In my personal experience the problem is the total lack of writing culture at non-premiere companies.
Put differently: unless you’re working on a great team at a great organization roughly 90% of people cannot be expected to write/read well as a component of technical collaboration. Any thoughts on that? I may just be too cynical
Reading comprehension is declining. Emphasis on individual "impact" and deadline pressure, common at both premiere companies and "non-premiere" companies mindlessly copying the former, both consume time that could have been spent thinking, writing, and engaging with optional things others wrote. People who avoid documents because they might get outdated create systems with no documentation at all. And now, LLMs promise a world where documents don't need to exist a priori -- a model will look at your code and generate a plausible description of possible intent and system architecture on demand, if someone implausibly happens to ask for documentation. If nobody happens to ask, that's even more time saved - a win-win!
Leadership can either support or inhibit the culture of writing and reading. However, modern managers are not immune from the rising pressure. Their response is to shift from thinking and deliberate information processing to rapid-fire pattern matching. Some of them don't see documents as "real output" to begin with, and operate solely in meetings without any written record or documentation whatsoever. Of coures their staff will pick up on the pattern. I have a vivid memory of engaging with a full team working on a substantial project in the absence of their senior leader, getting the tactical picture and then asking the team about the project's goal. You could have heard a pin drop. None of the people working on the project could speak about anything but their immediate assigned tasks.
I've many friends that worked most of their carreers in small to medium companies where this wasn't a thing and stuff mostly worked. We can't expect to replicate the high end tech experience everywhere, I doubt it is a good investment of resources.
This is, of course, without explicit management directives to update documentation as a task/chore. Much like in many (most?) orgs, churning through technical debt is rarely a priority.
That said, no place is perfect and it takes only a handful of people to improve a culture, but without at least management support and/or fostering such a culture, it doesn't tend to happen.
These were usually quite short notes. Like I did this and that. Or here are instructions I've run. Pretty much a "lab notebook".
Again, this was often useful to people. Folks new what I was working on at that time. Over time more people adapted this style of public note taking (within company), but I have the impression I was more consistent than others.
I did it for many reasons. I genuinely forget things. It was always nice to see comments (like James complaining that I shouldn't do `dpkg -i x.deb`, and instead finally install the package repo in apt-sources!). So again - searchability (a form of documentation), reach (getting feedback), and work log (for planning).
The format was also nice - short, without specific audience in mind. Zero drama, zero effort. Plentiful and low quality. Because it was "blog" and not "pages", this meant it was obvious when the note was written and nobody expected old blogs to be up to date. The lower the friction in note taking - the better.
Finally, I was working with an SRE team, which was tightly knit and communicated very often over daily checkins (which I wasn't invited to) and other informal channels. And I worked from home a bit. This meant I had to find an asynchronous way to communicate with the team. My personal blogs worked nicely. I highly recommend this style to anyone working remotely.
Although I must admit the personal "lab notebook" wiki thing is not scaleable. It's impossible to "follow" more than a handful of people.
I kept statistics. Here it is, my internal blogs on the wiki per quarter:
2013-Q4 | 0 |
2014-Q1 | 0 |
2014-Q2 | 2 | ##
2014-Q3 | 3 | ###
2014-Q4 | 2 | ##
2015-Q1 | 14 | ##############
2015-Q2 | 15 | ###############
2015-Q3 | 57 | ###################################################
2015-Q4 | 60 | ######################################################
2016-Q1 | 70 | ######################################################################
2016-Q2 | 71 | #######################################################################
2016-Q3 | 17 | #################
2016-Q4 | 23 | #######################
2017-Q1 | 13 | #############
2017-Q2 | 22 | ######################
2017-Q3 | 16 | ################
2017-Q4 | 25 | #########################
2018-Q1 | 12 | ############
2018-Q2 | 9 | #########
2018-Q3 | 23 | #######################
2018-Q4 | 14 | ##############
2019-Q1 | 14 | ##############
2019-Q2 | 20 | ####################
2019-Q3 | 18 | ##################
2019-Q4 | 36 | ######################################
2020-Q1 | 19 | ###################
2020-Q2 | 13 | #############
2020-Q3 | 4 | ####
2020-Q4 | 3 | ###
2021-Q1 | 4 | ####
2021-Q2 | 8 | ########
2021-Q3 | 3 | ###
2021-Q4 | 21 | #####################
2022-Q1 | 4 | ####
2022-Q2 | 12 | ############
2022-Q3 | 4 | ####
2022-Q4 | 28 | ############################
2023-Q1 | 14 | ##############
2023-Q2 | 16 | ################
2023-Q3 | 10 | ##########
2023-Q4 | 6 | ######
2024-Q1 | 12 | ############
2024-Q2 | 22 | ######################
2024-Q3 | 0 |
2024-Q4 | 2 | ##
2025-Q1 | 20 | ####################
2025-Q2 | 3 | ###
An amazingly large number of questions are generally applicable, but it is really hard to maintain a culture that actively encourages that.
Then I realized you meant colleague.
;)
I quickly realised that these conversations had value outside the two of us - pretty much everyone else onboarded had similar questions. Some subjects were about pure onboarding friction, some were about workflows most folks didn't know existed, some were about theoretical concepts.
So I moved the questions to a public (within company) channel, and called it "Marek's Bitching" - because this is what it was. Pretty much me complaining and moaning and asking annoying questions. I invited more London folks (Zygis), and before I knew half of the company joined it.
It had tremendous value. It captured all the things that didn't have real place in the other places in the company, from technical novelties, through discussions that were escaping structure - we suspected intel firmware bugs, but that was outside of any specific team at the time.
Then the channel was renamed to something more palatable - "Marek's technical corner" and it had a clear place in the technical company culture for more than a decade.
So yes, it's important to have a place to ramble, and it's important to have "your own channel" where folks have less friction and stigma to ask stupid questions and complain. Personal channels might be overkill, but a per-team or per-location "rambling/bitching" channel is a good idea.