4 ms·

I must've missed the memo which says any conversation around the globe is waiting for my input before it proceeds.

by mfukar 10y ago

creeble 10y ago
Well put. But you may have missed the memo because you're in the wrong time zone, and with Slack, your possibly-relevant input is ignored because you can't participate in real time. This is my beef with chat. As the OP says, it biases all conversation to those in the same time zone. Fine for some things (like baked goods arriving in some far-off kitchen), but not for others (like a design decision that should have input from stakeholders around the globe). But it's often used for the reverse.
- grx 10y ago
  If a group has the choice between realtime and asynchronous channels there needs to be a guideline for this. If my org takes pride in consensus for everybody, everybody needs to have the time to submit input. It's not uncommon that some active users in a chat go for an ad-hoc decision just because they are more than one and want to work _now_. In the long term this damages the culture, splits the participants and is difficult for newcomers.
  - creeble 10y ago
    I completely agree. Unfortunately, what I've seen more than once is that mgmt (or even someone from the rank-and-file) sees / experiences a new tool like Slack (or Campfire, or Hangouts, or...) and says "hey, great new tool we should use!" and that's the 'decision'. No thought given to how async comms biases development when developers are spread world-wide. I gripe because I am a US left-coaster who works with a team that is increasingly based in Western Europe. By simply deciding to rely on Slack, they have essentially cut me from development conversations other than the weekly live session.
    - grx 10y ago
      I feel ya, it's frustrating. Although I did not yet have a problem with time zones, I experienced being left out simply by joining the chat later in the evening.
- mfukar 9y ago
  I agree, but it's not a shortcoming of the tool (no tool can fix it, anyway) as much as a shortcoming of the process.

I must've missed the memo which says any conversation around the globe is waiting for my input before it proceeds.

by mfukar 10y ago

I must've missed the memo which says any conversation around the globe is waiting for my input before it proceeds.

Well put. But you may have missed the memo because you're in the wrong time zone, and with Slack, your possibly-relevant input is ignored because you can't participate in real time. This is my beef with chat. As the OP says, it biases all conversation to those in the same time zone. Fine for some things (like baked goods arriving in some far-off kitchen), but not for others (like a design decision that should have input from stakeholders around the globe). But it's often used for the reverse.

grx 10y ago
If a group has the choice between realtime and asynchronous channels there needs to be a guideline for this. If my org takes pride in consensus for everybody, everybody needs to have the time to submit input. It's not uncommon that some active users in a chat go for an ad-hoc decision just because they are more than one and want to work _now_. In the long term this damages the culture, splits the participants and is difficult for newcomers.
- creeble 10y ago
  I completely agree. Unfortunately, what I've seen more than once is that mgmt (or even someone from the rank-and-file) sees / experiences a new tool like Slack (or Campfire, or Hangouts, or...) and says "hey, great new tool we should use!" and that's the 'decision'. No thought given to how async comms biases development when developers are spread world-wide. I gripe because I am a US left-coaster who works with a team that is increasingly based in Western Europe. By simply deciding to rely on Slack, they have essentially cut me from development conversations other than the weekly live session.
  - grx 10y ago
    I feel ya, it's frustrating. Although I did not yet have a problem with time zones, I experienced being left out simply by joining the chat later in the evening.
mfukar 9y ago
I agree, but it's not a shortcoming of the tool (no tool can fix it, anyway) as much as a shortcoming of the process.