As I read this, I got the sinking feeling that I'd read it all before. But then I realised, it's just another case of someone thinking that their specific solution is best, solely on the basis that it worked for them, in their specific circumstances.
But here's the thing: every group is different, has different needs, and will respond differently to different styles of communication. Some people (especially people not using their first language) can find working in public stressful; some people get very stressed by the intensity of 1:1s. It takes all types, and as a manager, understanding how to get the best out of everyone is part of the job.
There is no single, correct way, and we know this because, if there was, then we wouldn't keep hearing about these interminable "solutions".
> Some people (especially people not using their first language) can find working in public stressful
Which is fine coming in, but the culture should be one that reassures these folks that public forums in the company are safe regardless of their proficiency with the main language.
Half of the people I work with speak English as a 2nd language (most are very proficient since they're mostly French-Canadian but there are plenty that make a bunch of grammar/spelling mistakes). That's never been the reason why folks try to use private channels to discuss work. The main reason I've seen is because people think it's more efficient to reach out directly to people. I've seen it a bunch with product managers and engineering managers that are new to the company and not used to a culture of trying to work out in the open.
On the opposite spectrum there's the experience I had at a Japanese company as a fluent but not native person. All communication happened in public, and I was made fun of whenever I had to ask clarifying questions. The entire team would see this and got the impression that I was hard to work with since asking questions can be seen as rude in Japanese, and the Japanese staff would understand things the first time around.
I wasn't disagreeing with you. I agree culture is the most important factor regardless. Maybe doing work in the open can exacerbate a toxic culture, but idk it was just one experience.
If people find a particular way of working stressful then it doesn’t matter what causes the stress. It was just an example. Some people are on the ASD spectrum, some are extroverts, some introverts. Some might have other difficulties, big problems at home.
But there is room in the world for more than one way of doing work. There are drawbacks to doing everything in public just as there are drawbacks to doing everything in private. If you care about getting the most out of the individuals in your team then finding the right balance is hard, and there is no one solution that will work in all cases.
I worked at a company that insisted on no direct messaging and no private team channels. It was stressful and counterproductive, in fact in the short time I was there (I left) I counted 3 different chat services people were using to discuss work topics that were outside the company. No one wants to perform their job on a stage all day everyday. Unless you're actually a performer, I suppose. It was also nearly impossible to keep up with everything and nothing indicated what I really needed to focus on.
Also worked at a company that encouraged people into public channels for inter-team communication and into team channels for anything useful to your team, but didn't have obnoxious rules around it. Also allowed private team channels. Worked perfectly, everyone felt comfortable talking to just their team in the private channels, and everyone searched Slack for old technical answers all the time because they were actually there, which is about as close to proof it worked as you can get.
Also there should be a buddy for all new hires and you should get a month or 3 of DMs with them because asking every dumb new-person question in public is tough for introverts.
I’m just going to add that it looks like this is some kind of Slack hasslebot dystopia. They want all conversations in public so they can data mine them?
From the home page,
> Teamplify | Hey @anna.austin, we haven't seen updates for PROJ-716 since Thursday, July 19. Could you please add a comment there summarizing your
progress as of today.
> There is no single correct way, and we know this because, if there was, then we wouldn't keep hearing about these interminable "solutions".
Yes, this is very true, and it varies not only by person but by situation. But most people have a default that they respond best to.
- Some prefer IM
- Some prefer email and will respond to a group discussion with an email (sigh)
- Some prefer direct phone calls and will completely ignore your IMs
- Some prefer group chat
- Some prefer more formal group chats (MS Teams calls these "channels")
- Some want you to walk right up to them and start talking
The truth is you probably need a mishmash:
- There's a time and place for group emails, most notably when you need to include an outsider, or if you want a better paper trail of the conversation
- If your team is accepting of it, some form of group chat really is super effective at greasing the wheels, but I find it's inappropriate for lengthy, detailed conversations. Then it truly does become noise.
- Direct IMs, direct emails, phone calls, and foot traffic are all extremely easy to abuse and should always be used judiciously. None of these should be the default unless you know this is someone's preference; it's just rude.
The other side of the coin is that if a team member chooses not to be adaptable they are limiting their own ability to contribute. If you want to be a finicky communicator don't be surprised if you get the dull work or get overlooked when promotions come around.
Yes, but so is which is best for which situation still the question?
Presuming that information asymmetry will hold over time is a bad assumption, regardless of cost of information security controls.
Why have these new collaborative innovative services succeeded where NNTP and > > indented, text-wrapped email forwards for new onboards have not?
Instead of Chat or IM, hopefully working on Issues with checkbox Tasks and Edges; and Pull Requests composed of Commits, Comments, and Code Reviews; with conditional Branch modification rules; will produce Products: deliverables of value to the customer, per the schema:Organization's Mission.
What style of communication is appropriate for a team in which phase of development, regardless of communications channel?
> Why have these new collaborative innovative services succeeded where NNTP and > > indented, text-wrapped email forwards for new onboards have not?
The new tools we have at our disposal are amazing. Of course they are better. But they are just tools. They don’t solve any problems relating to interpersonal communication any more than a hammer solves building a house.
> What style of communication is appropriate for a team in which phase of development, regardless of communications channel?
It’s the job of a manager to work that out. There is no formula. It’s not even possible to write one down. That’s the point.
Well, our societies value these communication businesses as among the most valuable corporations on Earth, so I think that there's probably some value in the tools that people suffer ads on to get for free.
> "Table 4 – Correlation of Development Phases, Coping Stages and Comfort Zone transitions and the Performance Model" in "From Comfort Zone to Performance Management" White (2008) tabularly correlates the Tuckman group development phases (Forming, Storming, Norming, Performing, Adjourning) with the Carnall coping cycle (Denial, Defense, Discarding, Adaptation, Internalization) and Comfort Zone Theory (First Performance Level, Transition Zone, Second Performance Level), and the White-Fairhurst TPR model (Transforming, Performing, Reforming). The ScholarlyArticle also suggests management styles for each stage (Commanding, Cooperative, Motivational, Directive, Collaborative); and suggests that team performance is described by chained power curves of re-progression through these stages.
>>every group is different, has different needs, and will respond differently to different styles of communication
YUP!!
Especially when some parts of the group are working with Controlled Unclassified Information (even more so for classified); it's a legal requirement that people access it only on a need-to-know basis. Even without that, companies that rely on trade secret protection (Apple, SpaceX come to mind) must also compartmentalize their information both to prevent leaks and to protect it's legal status as a secret (you must treat a secret as exactly that, or risk it being declared public domain)
I'm curious what sorts of groups/contexts working together wouldn't benefit from this. I'm having a hard time coming up with examples. If we're assuming that group activity means people that are all working on the same product, I can't see an argument for DM's and private conversations.
In one of my previous workplaces, my coworker and I used to exchange very… NSFW language while debugging certain bugs. It was all in good spirit and humour, everyone knew that’s how we communicate with each other, and it helped to alleviate the tensions for us. Obviously we would also give out statements in public channels to explain what we’ve done and so, but in a more public-friendly way.
It’s like having drinks at a bar solo, talking to people next to you (a bit more reserved, avoiding specific topics) vs. having drinks with a close friend. I don’t mind if someone listens to my private conversations with my friend, but the direct audience is different.
Ah gotcha. In this case it's not actually that you are hiding away and doing all your work via DM. You're just using it for smaller discussions and then circle back with the larger team to share info. That totally makes sense.
I was thinking that the OP for this comment thread was claiming that there are situations where public comments/knowledge sharing isn't needed for teams, which makes no sense to me.
I had a situation where some stuff isn't done in the public channel out of politeness.
For example: While working with text written by non-native speaker, had to explain often to some members of the team t hat the text was just awful and needed a complete rewrite. But I didn't want to type this in public so that the "culprit" wouldn't feel like I was out to get him or something.
At least in my culture, it is extremely rude to berate people in public, so I extended this to also considering rude to "blame" people in public when explaining why work is late.
Exactly. There is a goal to be achieved - building some feature, say - and we need to find the best way to achieve that goal with the people on hand.
If forcing all communication to be done in public makes the goal harder to achieve, then ffs do something else. Don't just force people to be inefficient because of some dogma.
The goal is not "make all communication public". The goal is to get the job done.
> The goal is not "make all communication public". The goal is to get the job done.
Just adding that "get the job done" shouldn't be confused with personal productivity. Many younger/inexperienced devs that are highly motivated go through a phase (some get stuck here) that optimizes their personal productivity above the team's productivity. You end up with pockets of people that share knowledge (or hoard knowledge) with others left behind. You also end up with different subsets of people making different decisions, younger devs clinging to each other for feedback/guidance (yikes), and way more thrash that needed.
Yep. I would find it incredibly distracting to have to wade through piles and piles of discussions about things that I trust other team members to handle, just to search for something that's actually relevant to something I should be involved in.
If you're stressed by typing in your team chat you don't trust your team and therefore there's a deeper issue already. I strongly believe you are wrong because all the examples you mention signal different team disfunctions. You need to understand everyone is different, yes, but your team should use public channels to communicate.
Yes, if you have a team, the team should discuss work progress, discoveries and problems in a shared space that is accessible by other team members. If conversations about the work itself happen in silos because someone is not comfortable, you're doing it wrong because you're fixing the symptom instead of the cause.
What if the “cause” is deeper than your influence can reach? What if addressing the “cause” is a multi-year endeavor?
Do you send the idiosyncratic team member home and forgo what they’d otherwise bring, or do you adapt your process to make the most of the team you have?
It’s great to have ideals to reference, but you miss a lot when you hold onto them as rules.
Indeed. It's just like when people say, "Well, if that's your problem, you need to fix your hiring process." It's amazing how many theories require perfect hiring.
I didn't mention hiring, but if you can't build trust in your teams as a manager you failed your first job. This is not like choosing kanban vs scrum, if your team members can't even speak comfortably you're not running a team, you're telling individuals what to do, which might be what you want to do, but then don't call it a team.
On the one hand you've said explicitly in another comment that there is only one way to do things. On the other hand, you're saying a manager needs to build trust. But in my experience, trust doesn't get built by treating everyone as identical, fungible developer-units who must do things exactly the way you tell them, and nothing else?
A team is a bunch of individuals, and working out how best to motivate everyone on your team is the manager's job. And not everyone is going to be optimally motivated by being told they have to do everything in public.
You really taking a strawman extreme example I've never met in 30 years as a counter-point to "discussion should be in public as much as possible"? The article even mention that /some/ communication can still be private, but the default rule is to be public.
Your counter-point is "there are a miniscule contigent of people who can't function at all in a team". Weak.
It's not my job to fix someone else's dysfunction. It's their job to speak in public about work.
Being uncomfortable isn't a veto.
All your criticism is just framing. It presupposes pathological work practices are actually just personal quirks. If you can't type a question in a slack with 20 members you are basically useless.
This is just word salad. Youre defining pathological work rules by the subjective mental state of fearful dysfunctionals. This is backwards and incoherent.
Good luck with all the alcoholic types you're going to be generating as a side effect of forcing people with anxiety issues into talking in a public space. You'll be seeing self-medication for gaba dysfunctions as people try to keep their job.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4303399/
This is why, when a colleague has a question about a pull request, or my feedback on THEIR pull request, I push us to have the discussion in the PR comments, instead of the pernicious "I just have a few questions, it will only take a few minutes" that always adds up to more time and attention than people claim. There ARE often situations where opening a synchronous communication channel is necessary, but even then, you need to capture your discussion and agreements publicly. Commit messages and PR discussions are "hyperdocumentation".
Some people get it. But overall in the cultures I've done it in, it mostly gets me branded as difficult.
I have mostly seen juniors/other people who lack self confidence are the ones who most want to push code reviews into “quick chats.” I’m happy to help when they are very new so I can explain a bunch of things, but it really frustrates me when people continue to do this long after joining.
I also think it shows a fundamental misunderstanding in what code review is - half the time I’m basically not invested at all in the outcome of the particular review, I am just giving my time and knowledge to help make sure that we produce good code. When people start these sync chats I have to context switch a lot and people often think I’m super opinionated on the outcome (so ask me lots of open ended questions I’m not prepared to answer), which is not what I intend to convey when I say you need to test something or document some particularly confusing part because it seems pretty likely to break.
If you explain your motivations well (& politely & thinking about their POV), I suspect you'll not get that branding.
"Hey, sure I can answer your questions, but I often find it helps to do that in public so we have a track record... etc. etc. And I'm not immediately available, so I'll get to it soon..."
It's tough to fight habit and culture. As the article points out, it's *all* about comms. That's a 101 statement. Having to explain the value of comms (and documentation) isn't something you should have to do. So if you are, chances are good they won't get it.
Yeah, and: if people resist, then let it be. It would've been better, but it's not important enough to sour relationships about, even if just a little bit.
> Some people get it. But overall in the cultures I've done it in, it mostly gets me branded as difficult.
Sorry to hear that. Getting the right balance of sync and async, and knowing when to use one or the other makes a big difference. In my current team we went through multiple iterations to come to a mix that works for us. If it's too much sync, the constant sync conversations drain you; if it's too much async, coming to a concensus becomes grindingly slow.
I have learned that its good to praise in public, criticise in private. It is possible to have criticism in PR's private inside a company which reduces its "publicness" but some people are still sensitive even with the reduced exposure.
I hate that idea. If I criticise an idea in public, and I'm wrong in my criticism, then five other people will immediately correct me. Or provide nuance and perspective I miss.
Also with private criticism, any decision tends to gravitate toward the opinion of the highest paid person. If the debate happens in public, everyone has more of an equal chance to be heard.
----
Edit: almost forgot! Private criticism also leads to an air of suspicion, in my experience. When everything public is upbeat and positive you start to wonder what terriblenesses people are hiding. It might be nothing, but that's the thing -- you just don't know.
Being able to publically discuss both the good and the bad is a prerequisite for a smooth operation, and the hallmark of a mature organisation.
> Also with private criticism, any decision tends to gravitate toward the opinion of the highest paid person. If the debate happens in public, everyone has more of an equal chance to be heard.
This. When I get criticized in private on an technical matter by someone more senior than me and disagree with them there isn't much I can do. Maybe I already have a good relationship with them and we can talk it out but if not I just have to suck it up. I can maybe escalate to higher up but that is also very risky and might more harm than good.
There isn't much I can do to defend myself.
In public there is a chance of other people offering their opinion. Senior people might get kept in check if their critic seems too unreasonable to the rest of the team.
I think a good rule is to criticize technical stuff in public and personal stuff in private.
> Also with private criticism, any decision tends to gravitate toward the opinion of the highest paid person. If the debate happens in public, everyone has more of an equal chance to be heard.
Interesting, that's the opposite of what I've experienced. Also a problem with group dicussions is that it's too easy for participants to drift into group think and conformism. I thought these are general principles, but maybe they are predicated on the group.
This is the biggest part of life that people just don't get and has always bothered me.
I can't stand people that are always-positive and nice all the time. I know they are lying and holding stuff back --- but what? I'd rather be friends with someone honest than nice. At least I know what they are thinking, and thus actually know them. Some people would rather just go through life in a mask and insist everyone else wear one too -- something I generally refuse to do.
Some people are insecure and terrified to ever have a record of them being wrong or ignorant. That's understandable, especially in cultures that hire a lot of relatively unskilled people and h highlight that they're competing. I think it's essential that those who are considered senior or expert demonstrate their own vulnerability by asking questions that show they don't understand or know about something, and being grateful for the response.
If and when you have that trust, criticism also needs to be more structured and question oriented. E.g.
- I think the main problem we're trying to solve is X. Is that right?
- if we do this, we'll solve Y but we'll also have a new issue Z. Do we think we would rather have Z than Y?
Most actionable code review comments are criticism. People have to be able to avoid taking criticism of their code personally, and to write criticism in an inoffensive way.
The whole team should be able to look at and learn from code reviews, and the best way to do that is if it's in the open for the whole team or company to see. I'm not sure if truly "public" is possible for most companies, so I'm not talking about that.
I would say that you're right about other kinds of feedback, like criticism about (mis)conduct, attitude, etc. That should for sure be done in private.
I also have learned that people that worked long time with toxic people, or are the toxic ones that are more sensitive to this. One starts being afraid of openness.
It's hard - but a wonderful soft skill - to do this in semipublic envs and be gentle.
"enhancement: Extracting the lines below into a separate function. As far as I understood it's only calculating x, you can call 'x_calculation'. Fell free to use a better name than my suggestion".
shorter, for a team that you are already know for some time:
"enh: extract into a new function. It's calculating x, maybe it's 'x_calculation'. You can name it better than me."
During retros then, I usually recall everyone that I'm open to be criticized in good terms, and send me a message if I'm out of touch. Or even be open during the retro.
True. And I guess you need to be prepared to favor sync at first for newer problems and colleagues. Once you understand each other better, the ambiguity of content and tone in async lessens.
Actually, I suspect some people don't like to write and/or read; for some it might even be stressful. Not everyone is an author, and at a smaller scale not everyone is comfortable with written communication. It is true that is more difficult than interactive Q&R.
That goes for speaking too, though. A lot of people are bad at/uncomfortable with speaking/listening. This just highlights using one's strengths rather than forcing the usual one-size-fits-all.
I understand anxiety, but at a certain point, we, as an industry, need to put our collective foot down and say that an ability to communicate efficiently in written-form is a mandatory qualification for success.
I really despise working with people who behave like this. The main problem is this turns the disucssion into written and asychronous. On a phone call there is so much more nuance, so many more questions that can be asked and so much more information for both parties.
When it's just async written messages, I'm constantly only able to say 1/10th of what's on my mind only for it to be misunderstood by the other person hours later. Sure you can blame it on me for being poor at written communication but I'd argue the other person is always just as bad too. They just think it's the other person and not them.
I am on the opposite end of these questions and feel quite differently. Code review tools are great at letting you ask questions about specific parts of the code. And they leave a record so you can go back and show someone else the discussion/others can follow.
It’s also, not necessarily disrespectful, but a very inefficient use of my time to spend 20 minutes chatting with someone about why you need to add a test in XYZ and make sure you check A - when I can do that in just a few minutes exactly when I’m ready otherwise. Because I am reviewing 5+ peoples’ code and have my own things to do as well. The asyncness is necessary for me to manage my time. I can also read much faster than I can listen, and it takes me longer to explain something with words than to find a couple links and write out a few sentences about something.
I have the opposite feeling. It's so much more convenient and efficient for me to communicate in text, largely because I can gather my thoughts and present them in a structured fashion. Which then becomes a reference as needed.
I'm back in a team setting again - we've got face-to-face, Slack, Teams / email, and Gitlab as communcations channels (too many different ones for my liking), and I'm already noticing how everything important seems to have to be repeated 2-3 times; there's the informal one to one, there's stand-up and other meetings, and then usually someone isn't around due to holidays or working part-time and they have to be caught up first.
If these things were written down there might be less of them. Might. It might just be part and parcel of working in a more enterprisey setting again.
I once joined a team and in my first face to face meeting the person who was the technical leader was upset in a meeting that “people are still doing this process wrong”.
Being new-ish I felt like I could ask the obvious question.
“Where do we find this process?”
Leader: “Oh don’t worry, I’m not blaming you. I sent out the process in email before you joined.”
“I joined nine months ago.”
Leader: “Yup.”
In the end this person was actually pretty great to work with but man having a ton of wonky communication methods and etc just constantly causes problems.
Yeah, not sure why people like to take PR discussions private so much. One workaround is to just post summaries of the private conversations as comments after the fact.
"Discussed A, B, C with <@person> and we agreed on <plan of action>"
Honestly, that does sound difficult. I get what you're trying to achieve, but if I'm trying to land a change, having a synchronous conversation (ideally in person) will resolve any misunderstandings between us on the order of minutes. Having an asynchronous back-and-forth takes on the order of hours or even days. And what do you get for your time? A nice record you can look back on? What are you going to use that for? Most changes likely aren't ever referenced again. Even if you, by some small chance, look back on a specific change and find the record missing, you just go "oh well, I guess we won't know exactly why that was done" and move on your with your life.
Let's not forget that you can go in both directions. If you capture what you want to talk about publicly, you still have the option of having a private direct conversation about that. I agree that blindly following public-only-async-only all the time is not good. I just happen to think that the balance is unfairly and unhealthily tipped towards the direct interruption pattern.
I think a lot of the effort that people perceive has to go towards async discussions is actually just resistance effort, too. When multiple people embrace it it can be surprisingly easy.
And a lot of times people push the async method because the environment is already difficult -- for them. Sometimes certain team members get bogged down in focus work and want to get that done as much as others want to have a discussion. How to have good conversations in the ideal workplace is one thing; how to have them in more dysfunctional situations is another.
I'm happy that you haven't made the opposite experience.
> if I'm trying to land a change, having a synchronous conversation (ideally in person) will resolve any misunderstandings between us on the order of minutes.
That does not match with my experience.
Imagine I wrote a comment on Steve's PR in foo.py line 31 that said "I see what you are doing here. Do you think this would be more readable if you used the itertools from the standard library instead of implementing this yourself?".
Now Steve asks me if he can have a call with me about my comments. I join the call and he opens the PR. He reads my comment aloud, then he says "OK" and opens up the documentation for itertools and reads it silently. I'm still in the call.
This goes on for every comment.
I see what you mean and wish that that was how it worked - and I've made good experiences doing this after 90% of comments in the "written comments" stage are worked on by the author. But just skipping it sounds like insanity to me.
Why would someone join a call to read you the itertools documentation? Seems like a very contrived example. If it were possible to use itertools, wouldn't they just research that, update the PR, and say OK in a comment? The fact that itertools was used for the implementation is not something that even needs to be documented as part of the "public discourse"
It was based on my real-life experience working with a colleague from another team.
> If it were possible to use itertools, wouldn't they just research that, update the PR, and say OK in a comment?
Time spent on a call is time you are publicly perceived as working. Time you spend researching itertools is time during which someone can interrupt you by pinging you in Slack. In that employee's shoes, it seems clear which one of those gives you less of a headache at the end of the day.
Politics aside: Exactly what you describe - the capability to research a library, respond to a PR comment concisely and appropriately - are skills that no one learns during a CS degree, nor doing code monkey work. Ideally, this is the sort of thing a junior engineer gets taught during their first years on the job if supported by a capable mentor. But if they don't have one? Tough.
> Time spent on a call is time you are publicly perceived as working. Time you spend researching itertools is time during which someone can interrupt you by pinging you in Slack. In that employee's shoes, it seems clear which one of those gives you less of a headache at the end of the day.
I think you have a very strange view of development work. At least in my experience, a vast majority of work involves going off on your own and implementing things, which often involves reading documentation. Meeting with a colleague is also considered work, but I wouldn't say meeting with a colleague is somehow considered "more work like" than solo development or that many developers prefer one form of work over the other.
> I think you have a very strange view of development work.
I did not present my view of development work - I presented that employee's view of development work.
> At least in my experience, a vast majority of work involves going off on your own and implementing things, which often involves reading documentation. Meeting with a colleague is also considered work, but I wouldn't say meeting with a colleague is somehow considered "more work like" than solo development or that many developers prefer one form of work over the other.
In my experience, every single developer wishes they could spend less time in meetings and more time "doing real work" (their perspective, not mine). Everyone with the opposite view is promoted out of being an Individual Contributor.
If you work on a healthy team, public comments are better from my POV.
I can remember many times, specially on new teams that I just joined, that by reading PRs, specially following https://conventionalcomments.org/, I get much faster the motto and the spirit of the team.
You have the context and the focused discussions on the same place. You can also check how much time it took to deliver and even connect easier to the outcomes of the deliverables.
If the discussion gets too subjective, use the team private chat, with threaded comms, then a direct call.
I know it depends on the urgency as well, but we should strive for general efficiency, not efficiency only during rush / at the end of sprint.
That's why also I prefer to open WIP PRs with incomplete code. Open discussions beforehand.
Also, repeated questions and similar problems can be retrieved from the chat / comments history.
Now, for early designs, spikes, initial research on an epic/hard tasks, needs some sync comms, followed by some asynchronous comments and questions.
Even things like "yesterday we discussed during a call x, y and z, and we agreed on w. it still holds up? In this case, I will use the strategy N to develop the solution, please comment back if you changed your mind".
It helps me a lot, and the people that I asked about this kind of message are heavily positive on it, because it's neutral enough and consolidates the agreement.
Then after a few weeks working close to someone (same team, for instance), I can make that phrase shorter, because we established a protocol.
Now that said, under my new contract, the entire team is almost silent on chat and everything is a direct call with 4 people on avg. I'm wrecked today because of 5 consecutive 30min~1h meetings to sync information yesterday.
It is certainly the case that in most archives, most messages will never be looked at again.
This is the price we pay for not knowing what's going to be important in the future. If we knew that, we could mark the messages immediately and have them pushed into the FAQ or the wiki or whatever.
By obvious corollary, message archives need good full-text searching or else they are useless.
Our team includes a technician. One of his jobs is to copy important info from email threads to the FAQ wiki. We have a policy to not use one-on-one messages for anything that should be known by the larger team. I preach bus problem avoidance so I am totally on board with that policy.
I agree. The only thing that matters is the change that ultimately gets committed. It’s rare enough to need to go through the commit logs, but optimising for this instead of optimising for getting the job done quickly and well, makes no sense to me. And anything contentious or tricky should be commented in the code itself.
There is a place for everything - PR comments, public slack channels, private DMs, in-person meetings, video calls, 1:1s - even phone calls! - but what’s critical is to use the tool that best gets the job done. And most of the time the job is not “teach everyone all the time”.
I couldn't find the second study I wanted to link to. I recall reading a study on team composition that focused on impact of different types of leaders. Teams that had a leader which got everyone to talk in a group were consistently successful. That was the one constant over time, even beating out visionary/charisma types that weren't inclusive.
Public communication is vital for so many reasons: reducing information silos, enabling async work, increasing decision making consistency. This post from the CTO at Metaview summarises the approach well: https://builds.metaview.ai/pup/
Something that I've found really valuable about private chats is the ability to build rapport and trust with immediate team members in a way that just isn't quite the same in a public channel. You need both. I don't like the idea of setting policies of "almost all communication should be done in public channels". Humans need both types of communication, and I think it's a mistake to try to enforce your team to always prefer one over the other.
This is the answer. There is no better period. There is better depending on the context. Can you imagine having all your conversations with your spouse in front of all your co workers?
Their company size is only 25 people. I doubt they will be giving the same advice if their company grows to 200+ people.
Exactly. The advice doesn't quite scale. I find the better approach is: if this feels like a question that the wider team would benefit from seeing and contributing to, post it in a public channel. If not, then message it privately. Use your own discretion.
At some point you should trust your team to be adults, and to make the best choice for the situation.
The private chats should be for non-work conversations. DMs are for private/personal/rapport-building conversations. There's no reason you can't have both going at the exact same time.
There is a third option. When ever there is a private or out of band discussion, summarize it in the public discussion. Done well, this makes for the best of both worlds in part because it reduces the text that others need to read. However, it requires discipline and extra effort on the part of those having the private conversation.
It comes down to culture. Will you be reprimanded for talking the wrong way about a project, feature or service in your organisation?
I’ve worked at FAANG where I was reprimanded by HR equivalent for raising an issue in chat rather than email because of who was in the channel. I wasn’t rude in my report, I just explained the issue, the impact it had and the likely resolution.
Maybe a VP was having a bad day, but I’ve since learned to keep my mouth shut working for large organisations as an IC.
It’s something I expected from shitty workplaces like Big4, consultancies or FinTechBroCorps but it’s everywhere.
There’s a fine line between promoting a unique work culture and having an authoritarian, micromanaging, infantilizing policy. I’m fine with this as a preferred approach but think I’d hate working at the kind of place that made it a strict requirement.
I think this view is heavily influenced by the fact that the writer is a project manager -- I can see how having full visibility into all communications could make their particular job easier. The same way managers always advocate for more regular write-ups on your progress. The problem is -- they delude themselves into thinking that if their job is made easier, then everyone's must be too. The reality is that people who do the actual ground work need focus and want to avoid cognitive overload.
Extracting useful information from a chat log is tedious and error prone, though. If it's something that should be saved for later, copy it over to a wiki or some such and edit it suitably.
Chat is ephemeral, treat it as such and everyone's life will be better.
But how do you get the information first. You have to look at the chat transcript - and in an international company and a problem requiring thought or research the information could be spread over a couple of weeks SO you still need to scan the transcripts.
Yes Chat is ephemeral and I can't think of cases that involved looking back a year but weeks definitely.
Chat id part of the process - if an issue is raised then the solution will be a permanent change, in my case software code changes, or an email summarising the solution for non computer issues, or chnages to documentation (if you are lucky enough to have documentation)
Another example is if you go on vacation for a few weeks the a quick scan of chat is often useful.
My entire job is focused on communication and visibility, and the answer of MORE COMMUNICATION is pretty simplistic. I think teams would be better to focus on the areas of (1) identifying the correct audience, (2) sharing the right information at the right level of abstraction and (3) using the appropriate tool or communication channel. None of this likely involves adding me to your channel or meeting.
The fundamental issue is that companies often employ people that are just meh about working. Then it is tried to make it work with tools and methologies and whatnot. If your team is alligned and motivated, they will figure out how to efficiently collaborate. If not, no amound of Scrum BS, ceremony, standups and chat-tools will save you.
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.
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.
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.
> 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?
I see this more as a challenge of managing the different threads of communication. Basically, threads, as they are implemented in most chat apps, just suck. If you're not involved in that particular thread, you tend to just skip over it. And most of the time, you have to manually interact with each thread to figure out what's going on.
As a more real-world example, in Slack, you can decide to use more channels instead of having a big channel with lots of threads. But this tends to need a lot of discipline on channel management. Places devise naming conventions, etc. Or maybe they integrate with some other tool to manage the conversations.
So, a lot of my DMs tend to just be me and a "tiger team" on a particular subject. Which is really just a workaround to not having to figure out channel management. It's not a carefully thought through system, it's a workaround to our current crop of chat tools.
Personally, I've found older "discussion forum" systems do a better job of threading instead of a chat-style tool. But maybe I'm just getting to be an old person.
I think this doesn't solve a fundamental problem with chat. chat has a discoverability problem. Even if you force the discussion to public chat, it is hard for someone to discover that. Chat by design is ephemeral. Sure you can scroll back and search for keywords but most probably people end up asking the same questions again.
I've found that people like to DM me when they're asking a question they should already know the answer to, and they like to message me in public when they're accusing me or telling me to do something.
They DM me or publicly message me depending on what's most convenient for their public image.
I agree with the sentiment, but in practice there are plenty of times where it's best to limit the audience. Posting in a public channel with more than a handful of people can lead to multithreaded discussions spiralling in various directions that aren't relevant to the original post.
It can also lead to issues when members of the chat have varying degrees of context. Shared understanding is ideal, but it's impractical for everyone to be aware of everything so there's a balance to strike.
Public chats are somewhere between the extreme of broadcasting everything to everyone and talking only in private chats. There's definitely a lot of middle ground.
I do not agree . Unfortunately, most people lack basic communication skills. I don't think it's good for nonsense to come out of a one-to-one message and be on a channel.
I'm not a fan of DMs. While they have their place, they have some massive problems: they create silos and oracles, and reduce visibility. I know this because I'm an unwilling oracle on my team. Part of this can be solved with documentation, but then you have the problem of people who won't look at the docs sending people DMs that could've been solved by searching the docs for a keyword.
In general I agree, but I have private Slack channels for some projects for a couple reasons:
1. Concern that certain specific people could hijack conversations or take them the wrong way
2. Ability to candidly express frustrations with partners and stakeholders not doing their part
I don't think we are unkind or impolite, but any negativity we express, even for the purposes of effective internal problem solving, can be used against us.
When I know who I'm talking to, I can tailor my message for them. If I talk to another embedded C++ coder about memory management, I can make my request short and concise by assuming that the recipient already knows what the placement new operator is, how it works, and what using it implies. That means I send a quick 10s chat message to ask for one thing.
If I had to include all that background information to make the discussion accessible to people who have different strengths, for example to the front-end Ruby developers, then my 10s one-liner would likely turn into a 30 minute 2 pages email. But the contained information for my target recipient is still the same. So I have just wasted my time and his/her time.
Also, there's the increasing issue of people taking internal work discussions and sharing them publicly. I wouldn't want some of the new hires in the social media team to read our internal discussions about CLV and CAQ, because discussing clients in a purely financial and/or mathematical way would rub more emotionally skilled people the wrong way. There was a huge scandal when word got out that some companies called their Dallas office the "discount" location, even though it had been blatantly obvious to everyone before that SF employees earned much more.
So the simple act of sharing a chat message to a wider audience requires:
1. additional explanations, thereby making things longer and slower
2. additional safety checks, thereby making things slower
You don’t need to do all this extra work up front though.
Start the discussion at the level you want, make it clear who it’s for, and others can read along if they want. They may learn something, they may ask a question or two (and it’s good to answer for knowledge sharing), but also they may decide they don’t need to understand and not bother asking, and you can encourage this subtly if you get too many questions.
It’s also great for reducing comms later as rather than explain a decision or design or something later to each person who asks you can just point them at the original discussion.
You don't have just one company wide chat channel - when I used chats and came to the same conclusion as the article. It was a large company and we had hundreds of group chats. So the C++ Embedded developers and Ruby would be have separate chat channels. ALso in that case you still put out your question without the details and the relevant people will be able to answer others can ignore it, but sometimes it does help for a different expert to see the issue and ask for clarification and then come up with a new solution.
As for repeating to external - I don't see that as a problem - well it fixes itself quickly the leaker would get fired pretty quickly.
> If I had to include all that background information to make the discussion accessible to people who have different strengths, for example to the front-end Ruby developers, then my 10s one-liner would likely turn into a 30 minute 2 pages email.
This is a strawman scenario. Nobody expects you to make your directed C++ discussion accessible to the front-end Ruby developers.
The point is that a team needs to move team-specific discussions into shared team spaces where the relevant team members can observe and be informed or involved as necessary, as well as understand now and where things are decided.
The point isn’t to inform the entire company of every detail of every step.
We go further. We encourage most conversations to happen on our public forum and our youtube show. Documentation and architectural, economic and legal discussion is in the open too. Everyone is encouraged to prepare their thoughts privately, so they do not embarrass themselves publicly, but the cross-pollination of ideas is crucial.
Anyone coming by is able to see what we are working on. We’re gradually moving to self-hosting everything open source, with no reliance on Big Tech at all. We do want to rely increasingly on decentralized networks, though.
Even our clients are encouraged to come on the show to discuss their challenges and their needs, rather than “requirements gathering” in private. They sign a release that we can use clips in our marketing. We explain to them that they get exposure for their community and fundraising, as the clips get shared in the subsequent months. A few clients insist on an NDA - we put them on a waitlist at the back of the line. We prioritize clients who are willing to openly discuss their community and needs. As a result, we also have an endless supply of “reality TV” case studies from beginning to end of testimonials about how they needed our service, and then how we helped them.
By creating a culture of openness and collaboration, we make sure people know what is happening. Our roadmap is public. Our customers are public. I personally interviewed some well known people this past year:
Noam Chomsky, political commentator
Sara Hanks, author of Regulation S at SEC
Ian Clarke, founder of Freenet, the first truly decentralized hosting network
Thomas Greco, community currency economist
And much more. Now in the show’s second season, I plan to organize panels where we have multiple well-known people and have them discuss stuff for 1-2 hours. Sometimes we may use a famous person as a reason to reach out to other famous people to be on the same show.
I used to wonder why I accomplish so much and yet get so little interest. It’s because you have to be public with your successes and grow a snowball around your project, to attract people with clout, reach, resources, and other forms of capital. To build a movement, it’s better to have every member to bring 1 new person a week, than spend $ on marketing on FAMGA in a zero-sum game to strangers. Virality wins in the end, and us far more sustainable.
The goal is about more cross pollination of ideas. We don’t have a big audience (yet). But we will be selling this software and this system, to celebrities, conferences and other projects - including tech startups. If you’re interested, comment below.
But here's the thing: every group is different, has different needs, and will respond differently to different styles of communication. Some people (especially people not using their first language) can find working in public stressful; some people get very stressed by the intensity of 1:1s. It takes all types, and as a manager, understanding how to get the best out of everyone is part of the job.
There is no single, correct way, and we know this because, if there was, then we wouldn't keep hearing about these interminable "solutions".