paxys
2 days ago
Make conversations public by default. If you use Slack, make team channels, project channels, announcement channels etc. all public. Discourage 1:1 and private communication unless really necessary, especially for engineering topics. This single change will have an immense impact on overall company culture.
KronisLV
2 days ago
> Discourage 1:1 and private communication unless really necessary, especially for engineering topics.
Working at an established org right now, where the team is still remote first. I tried suggesting this, but got pushback and the team actually settled on the opposite. For example, they want any optional changes (e.g. suggestions) in pull requests not to be left as comments but discussed in private which 90% of the time means calls. They seem to dislike discussion threads in Slack and want meetings for things instead. I’ve also noticed things like the person who reviews a pull request being the one who has to merge it and essentially take responsibility for it, versus just giving approval and the author merging it and making sure everything is okay after CD.
I’m very much the opposite and prefer to have things in writing and like asynchronous communication. But when it is written messages, usually people either ask for a call or just do “Hey.” I actually made this a while ago hah: https://quick-answers.kronis.dev Either way, people also really seem to dislike writing README files, or all that many code comments, or making the occasional onboarding script or introducing tooling to do some things automatically. I don't get it.
sillyfluke
2 days ago
The amount of strictness or enforcement behind the word "discourage" in "discourage 1:1 communication" in the parent post is open to interpretation.
What you have is people using a tool for different objectives, and when their chosen behavior hinders your objectives things seem out of whack.
I'm against shoving an eye of sauron communication hose down people's throats. I simply give my constructive feedback after the fact. E.g. when someone dm's me I say, "so-so is waiting for this to be done for their thing, so mention this part in the channel." or "the other team would need to know this for a refactor, so add this info to the wiki." If someone feels the need for dm'ing for some psychological safety so be it. But the cost of that safety is additional communication overhead for filling in gaps that the person should be ok with. And the people that value the psychological safety they gain usually don't object or have no grounds to object to a duplication of communication to fill those gaps when someone points out those gaps exists.
KronisLV
2 days ago
> The amount of strictness or enforcement behind the word "discourage" in "discourage 1:1 communication" in the parent post is open to interpretation.
Realistically, if the team decides that synchronous communication and not keeping too much of a historic record works best for them then I guess that's it, it's up to them to deal with that long term, since I'm just a colleague and it'd be counterproductive to try and change everyone's mind. If I did something like that, I'd probably just come across as a bit of a jerk.
You can show people the benefits of a particular approach but whether they accept that those are benefits (e.g. looking at a pull request of mine from 2-5 years ago that shows context for why a certain change was done a particular way, has images of benchmarks, descriptions of other factors to consider etc.) is up to them. Same for synchronous communication: to them, being able to call someone and have a conversation might be easier and more productive than the alternatives, they might just be unbothered by context switching or interruptions... somehow.
Though one could probably argue that some practices (like version control and CI/CD, for example) are objectively good to have, regardless of personal preference, for the sake of the development landscape not looking like The Wild West. How far that might extend, however, I have no idea.
szszrk
2 days ago
How to find comfort for and include characters that don't like the spotlight? At least not during early phase/brainstorming.
I've worked with many great people that hate to handle things without their usual group first, and will stall until a reasonable approach can be presented. Which means creating shadow communication process - the more you push for "discouraging 1:1" the more they will hide.
What your organisation did with such "incompatible" people, relate them until the team left likes how they work, or were there better ideas?
brudgers
2 days ago
Core values are core values, and for better and worse, everything is not for everyone.
If all-communications-are-public is the company culture, then the company culture is also not to accommodate that alternative communication style.
Because any out of channel communications require multiple people to participate, not just the person who prefers it.
underwater
2 days ago
In my experience, most of the time this can be solved by resetting expectations. Once people learn that asking basic questions won’t open them up to mockery, things move a lot smoother for everyone.
After all, a culture on 1:1 communication has a lot of downsides. The same question gets asked repeatedly, replies don’t become searchable, the same people (usually the most experienced) end up being constantly tapped for answers
em-bee
2 days ago
if i know a colleague is uncomfortable to speak in a group i can collect their ideas in person, and share it with the group, but ideally the protocol should be public. so create a public chat group with only the two people joining.
if the issue is that the person is afraid to speak up because of being ridiculed for their ideas, you have a culture problem that needs to be adressed.
if the shy person is new, addressing the problem can be as simple as having the new team member do pair programming sessions with everyone on the team, so that they can get to know everyone better, which will make them more comfortable to speak up. maybe their previous job had a bad culture that influenced their behavior.
those pair programming sessions can also help you identify if there are particular people that cause problems by being intimidating in some way to others. sometimes pair programming can even fix those problems, by allowing the two to get to know each other better and learn to respect each other. that doesn't always work though, and care must be taken that the person who is "afraid" to work with the "bully" is not forced to an interaction they are not comfortable with. if the discomfort is that high a more cautious approach is needed. especially if the person afraid is a long term team member.
szszrk
2 days ago
I appreciate your insight (and all other commenters).
> if the shy person is new
> if the issue is that the person is afraid to speak up
But that's my whole point: it's not always "fear". I'm talking about character. Personal preference. Or "people/character colors" or "16 personalities" or some other names it had.
Enforcing a strict way to communicate and bashing exceptions (which is my way of phrasing the original comment) will work for some, but will also create an artificial leash for others. I think it's too strict and to generic to try to just implement it by force. Yes, whole team should be available to see details, be able to participate, but why enforce that on such a low level as forbidding 1:1 talks...
From my recent experience, aside of excluding many personalities, it kills a lot of inertia that spontaneous prototyping and brain storming needs.
em-bee
2 days ago
not being willing to speak up is not a personal preference. being an introvert is not a preference.
it can be a deep seating discomfort, that comes from negative experiences to speak up in the past. sometimes it is so deep that they are not even aware of it themselves.
i was that person. i had no friends in school until i entered university. every negative reaction was a setback. fortunately my experience was mixed and i did have positive reactions too. i learned public speaking as a scout leader for example. otherwise i'd be a hermit now.
people like us need more positive experiences. especially when joining a new team. to allow us to slowly change our preference.
and even introverts need to accept that they need to cooperate with others, and that requires sharing their ideas. or they should find a different line of work.
szszrk
2 days ago
I'm afraid we speak of different things completely. I'm referring to personality differences and how to allow each personality to be part of the team. You speak of dealing with bad past experiences or maybe even trauma.
My point was that you should not and can not change other people's personality. You should make sure understand reasons of why others might not embrace same methods. And some advice in this thread ignores that. It's actually a source of frustration for many, not being understood on such basic level, while nothing is wrong with you.
em-bee
2 days ago
i know what you mean. my argument is that a personality difference that is so strong that it prevents you from participating in a group discussion must be caused by trauma.
group discussions are a requirement in our industry. if not wanting to talk to people is a mere choice then you should be looking for a job where you don't have to talk to people.
in my understanding, having difficulty or even just discomfort to talk in a group implies trauma. and they deserve any help we can offer. but if there is no trauma and they simply can't be bothered to make an effort to accommodate the group, then why should i make an effort to accommodate them?
szszrk
a day ago
There was nothing that drastic in my original comment. I'm speaking of differences that are present in all of us, not extremes.
See those 16 personalities or character colors tests I referred to. (although I'm not saying these are good, just illustrate well what level of differences I'm speaking of)
em-bee
a day ago
those differences should not prevent you from speaking up in a group. not wanting to speak up when you have something to say is something drastic that needs to be addressed.
paxys
2 days ago
No one is inherently "incompatible". It's mostly the environment influencing their behavior. There needs to be a culture where everyone feels comfortable speaking up and working outside silos, and that is always driven by management and senior eng leaders. For example do junior engineers get constructive criticism on a bad idea or design or are they yelled at and penalized? If the latter, of course everyone will think twice about being open.
And even then you can only do so much. If someone really doesn't want to participate then, well, it's on you to decide how to deal with that.
bdangubic
2 days ago
I’d want this as much as I used to enjoy open floor plan at the office… Discouraging 1:1 and private communication in my experience would actually have 100% opposite effect of what you are describing. This is equivalent to discouraging pair-programming which while may not be everyone’s cup of tea many find extremely productive
em-bee
2 days ago
you bring up a good point. what matters is the forum where decisions are made. you can talk about ideas in private. but the ideas need to be brought up in the group before any decisions are influenced. especially if the private conversation is with a team leader. if a team leader hears an idea in a private conversation they should ask that person to repeat the idea in public. but also they should discourage team members to specifically approach them to bring ideas. that is what is meant by discouraging private conversations. of course you can talk in private, but if the idea is not repeated in public then it is as if it was never talked about
viewhub
2 days ago
Massively agree with this. It can be difficult to create a culture where everyone talks in the open but it can save so many little and big mistakes!
andrei_says_
a day ago
Basecamp is incredible for this.
Encourages grouping people by projects, with all communication on a project being public.
All activity on a project listed in one place.
Catching up with work takes minimal effort, including when someone goes on vacation or leaves the team. All it takes is skimming through the project.
Slack is built around chat with high has its limitations when applied to the context of a longer term project.
notTooFarGone
2 days ago
100% this. The fact that teams does not have an easy voice channel is a disgrace.
vdvsvwvwvwvwv
2 days ago
Every team needs a one-nine (CB channel for chat/truckers)
em-bee
2 days ago
what happens on that channel?
oc_elder
2 days ago
I can appreciate the thinking here, but it not ideal. Different details are relevant to different people. And async is inefficient for many situations. Yes publish findings/results, but overcommunicating has a cost.
Better to create different channels (sync, async, 1:1, broadcast), provide guidance and trust workers.
broken-kebab
2 days ago
It's not necessary about trust, or relevancy. I believe motivation is contagious, and making communications hearable/visible for all most of the time can be beneficial because of this.
menaerus
2 days ago
... and soon with this type of setting you will arrive at siloing the information. Having all communication public in the channels comes with its cost but everything is as transparent as it can be. Important distinction is that you get to choose if the detail is relevant for your work or not. And not your manager or whoever.
vdvsvwvwvwvwv
2 days ago
In addition slack search becomes a great onboarding tool.