> I’m not saying live chat is useless. It’s great at some things:
> - Quick answers to quick questions
> - Low-stakes status updates
> - Swarming around red alerts or outages
Well OK, but the problem is that sometimes those things also matter after today. So in practice, it often does end up being better to just save everything in an indexable form, because you can't realistically decide in advance to every conversation whether or not it's going to be important. You can pretend to, you can put every conversation you're going to have in one of those bins -- but you'll just be pretending, you're not going to get the prediction right every time.
The second problem is that sometimes conversations fluctuate and change form, and it is not uncommon to have a good long-form conversation that needs to occasionally dip into quick questions and status updates. When the boundaries between your chat environments are too rigid, you can have the same productivity losses because people delay having important conversations or just avoid them entirely. This kind of categorization of communication often ignores that communication is extremely fluid. You can change between longform training and technical discussion, quick status updates and questions, and even affirmation multiple times during the same conversation.
Most people on HN already understand how much harm context switching and interruptions can be for productivity in programming. But the same can also be true in communication. If you're in the middle of a chat and there's a clear opportunity in-line with what you're already talking about to explain something or reach a decision, you are basically imposing a giant context switch if you say, "well, no, don't talk about it. Let's all schedule a meeting." Or even if you just say, "keep it in your head until you get back to your desk and then email me."
Sometimes that interruption is warranted, and sometimes it costs a lot of focus/productivity for very little gain. It's situational.
I'm not sure it's wise to have binary rules about how and where people on your team should communicate. A lot of the advice I see around team organization and management ends up being generally good advice but taken to the extreme, where it wraps back around to being a barrier to actually getting stuff done. Encouraging people to use email for longform technical discussion is a good idea, but I suspect that trying to make some kind of policy about may be a bad idea for most orgs.
> - Quick answers to quick questions
> - Low-stakes status updates
> - Swarming around red alerts or outages
Well OK, but the problem is that sometimes those things also matter after today. So in practice, it often does end up being better to just save everything in an indexable form, because you can't realistically decide in advance to every conversation whether or not it's going to be important. You can pretend to, you can put every conversation you're going to have in one of those bins -- but you'll just be pretending, you're not going to get the prediction right every time.
The second problem is that sometimes conversations fluctuate and change form, and it is not uncommon to have a good long-form conversation that needs to occasionally dip into quick questions and status updates. When the boundaries between your chat environments are too rigid, you can have the same productivity losses because people delay having important conversations or just avoid them entirely. This kind of categorization of communication often ignores that communication is extremely fluid. You can change between longform training and technical discussion, quick status updates and questions, and even affirmation multiple times during the same conversation.
Most people on HN already understand how much harm context switching and interruptions can be for productivity in programming. But the same can also be true in communication. If you're in the middle of a chat and there's a clear opportunity in-line with what you're already talking about to explain something or reach a decision, you are basically imposing a giant context switch if you say, "well, no, don't talk about it. Let's all schedule a meeting." Or even if you just say, "keep it in your head until you get back to your desk and then email me."
Sometimes that interruption is warranted, and sometimes it costs a lot of focus/productivity for very little gain. It's situational.
I'm not sure it's wise to have binary rules about how and where people on your team should communicate. A lot of the advice I see around team organization and management ends up being generally good advice but taken to the extreme, where it wraps back around to being a barrier to actually getting stuff done. Encouraging people to use email for longform technical discussion is a good idea, but I suspect that trying to make some kind of policy about may be a bad idea for most orgs.