Some people get it. But overall in the cultures I've done it in, it mostly gets me branded as difficult.
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.
"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.
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.
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.
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.
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.
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.
But people get lazy because Slack is there and it's "easier" (really, more immediate) than looking at the PR.
Opened a feature request: https://github.com/integrations/slack/issues/1433
"Discussed A, B, C with <@person> and we agreed on <plan of action>"
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.
> 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.
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.
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.
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”.
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".
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.
So you know, both cases happen.
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.
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.
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.
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.
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?
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.
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)
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.
Closed channels for teams are good but not everything is a democracy. I let my team make decisions but I can veto any of them, if needed.
So, you are saying that yours is the only way? And that being flexible and working out what’s right for your team… is wrong?
Their company size is only 25 people. I doubt they will be giving the same advice if their company grows to 200+ people.
At some point you should trust your team to be adults, and to make the best choice for the situation.
The real crazy thing is how slow our nontechnical progress is.
"I don't think it's good for nonsense to come out of a one-to-one message and be on a channel."
I have no idea what you tried to convey there (did auto-correct mangle the words?).
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.
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.
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.
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?
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
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.
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.
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.
Use something that can be searched, and doesn't require one to have an account to read the messages and/or search.
And setting up search on the chat is not difficult, we had search on chat 25 years ago.
Chat is ephemeral, treat it as such and everyone's life will be better.
If you are interested in learning more on it here are a few resources!
1. Project Aristotle - A study from Google https://rework.withgoogle.com/print/guides/5721312655835136/
2. Good to Great had a couple chapters touching on safety, but also making company information easy to access.
http://www.squeezedbooks.com/articles/good-to-great-why-some...
3. A more sciencey approach https://www.ncbi.nlm.nih.gov/books/NBK310384/
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.
They DM me or publicly message me depending on what's most convenient for their public image.
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.
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.
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.
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.
It does not scale.
I stopped reading there -- maybe it's prejudice, but it's also my spam filter.
The result is here:
https://community.intercoin.org
https://youtube.com/c/intercoin
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.
