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?
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.
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.
Better to create different channels (sync, async, 1:1, broadcast), provide guidance and trust workers.
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
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.
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.
> 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.
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.
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.
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.
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.
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?
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.
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)
There are in betweens here, with the major one being threads in slack. Everyone gets notified about a single message at the start of the thread, but does not get notified for any subsequent discussion. Any interested party can read more and participate as needed. For someone like me (a leader on paper but not really in practice), I'd read all the message and look for dependency or similar problems, but for others they may not need to.
Use mute and let people @ you to pull you in when you're really needed. You don't have to leave notifications wide-open on every channel.
You can fake it with lots of manual "pinning" but that relies on everyone agreeing which chats are primary and should be pinned so they don't start splitting messages over other chat rooms, then you still end up with things like chat for one basic topic being split across multiple meeting-chats that all have the same membership or (worse) just slightly different membership.
It's as if they designed the tool to make effective remote work hard—but this also (like most things that make remote work worse) makes using it in an in-office context worse. It's just flat-out bad.
The people making the decision to switch to Teams don't "get" slack.
They think the features are the same, so what's the problem?
Ironically, Microsoft Teams is terrible for teams.
It's a Frankenstein cross between instant messanger and SharePoint.
Even in person, not every conversation is good to be had in front of the large group for a variety of reasons.
♫ ♪ ♬
It was the dark of the moon
On the sixth of June
In a Kenworth, pullin' logs
Cabover Pete with a reefer on
And a Jimmy haulin' hogs
We was headin' for bear
On 'I-1-0
'Bout a mile out Shakey Town
I says, Pig Pen this here's the Rubber Duck
And I'm about to put the hammer down
♫ ♪ ♬Of course it depends on the size of the team we're talking about.
This sounds like a hellish existence to me, tbh.
I'm not saying that either my preference or these folks' preference is objectively correct, but I am saying that I don't think I could work in this sort of environment long-term.
- Public communication about pull requests encourages knowledge sharing, not just between reviewer and reviewed, but anyone reading. It stores this knowledge sharing long term, so that any future reader can read up on the context and back-and-forth done to get to the chosen solution.
- Meetings are transient. Unless someone takes minutes or a recording/transcription is made and shared, it means the communication in that meeting will be duplicated when it has to be shared elsewhere.
- While I do think the author and reviewer share responsibility for the code in question, merging should be done by the author so that they know when it was merged and can jump in if something goes wrong. That said, in an ideal world it shouldn't matter who hits the merge button, and in fact, something should be automatically merged if it's approved and the pipelines are green, but that's uncommon.
I'd take notes if you ever notice waste from e.g. private / unrecorded meetings, or if someone has to repeat things said in a meeting; take it to a manager and hint that there is a lot of waste.
But ultimately, don't make it a hill to die on. I dislike people going "hey can we do a call" as well - I'm usually busy / elsewhere / focused on something, and there not even being a hint on what it's about is aggravating. The person asking it clearly believes their time and attention is more important (as in "I need feedback on this now"). Sending people that link (after ignoring them for X amount of time after sending a "hey") is passive-aggressive, but educational. Ultimately though, it should be higher-ups that encourage a culture and the etiquette of asynchronous communication.
Also someone with good standing in the company to politely point to the CTO that it's not his job to give his 2c at every conversation in slack (typical behaviour of people coming from the technical side)
I worked on some teams that had that and it wasn't bad at all. In the end, what's on the main branch is everyone's shared responsibility (...was our thinking).
It encourages real PR reviews, where the reviewer is paying attention to the changes, spend time on the review until they understand what is happening and why, and when they feel comfortable, they merge it as if the PR were their own. It doesn't sound efficient, but in the end it means you always have a backup person to turn to in case there is an issue, and we mainly only had "exotic" bugs.
This only works with the right team and leadership. It was completely normal to say "yesterday morning I spent half the day reviewing that PR".
OTOH, I was also on a team where PR approval means someone scrolled through your changes in 1 minute and didn't find anything blatantly wrong, go ahead and merge and hope for the best. This team broke the main branch in a significant way 2-3 times a week.
For example, as a principal engineer on a new project or working on something I wasn't familiar with, I'd go out of my way to ask things along the lines of "Hey, this might be a dumb question, but I'm new to X so could you explain how I do ..." I think this goes a long way to building up a culture of psychological safety on a team.
We’ve gone backwards in terms of the internet being reliable. Human experience is still useful.
I find it very dangerous when you have some technical people who moved upwards into non-technical roles still being involved in technical discussions.
Their words carry a lot of weight, yet they have no idea about the actual context of the work being done.
Sometimes this is useful and a fresh perspective from an experienced colleague can unblock things, but more often it stifles discussion and discourages the juniors from thinking freely.
Meanwhile if you have a call to discuss it or do it in person, you can rapidly answer any questions and get the reviewer to fully understand what they are looking at.
I've been on teams exactly like this, but the problem isn't public channels, it's "leadership" not knowing how to let go and trust their teams. Doing more work in private is the negative consequence of this bad practice, but I assure you this issue will eventually cause problems no matter how clever people are in avoiding public conversations.
And startups that are on the path to long term success will have leadership abandon this type of butting into every day communication very early in their growth. A good C-level must learn the build teams that can scale beyond their individual interventions. You literally cannot grow beyond a 30 person organization (and survive) if this much intervention is required.
Basecamp - groups all communication, assets, participants, tasks in a project space. I open the project which establishes context for everything and everyone. This predefined context makes short efficient communication very powerful.
It’s incredibly simple and sophisticated at the same time - allowing grouping activity by people projects tasks etc.
The ephemeral nature of chat-centered systems makes me incredibly nervous about missing things or being unable to find them.