If it will matter after today, don't talk about it in a chat room(critter.blog)
critter.blog
If it will matter after today, don't talk about it in a chat room
https://critter.blog/2021/01/12/if-it-matters-after-today-stop-talking-about-it-in-a-chat-room/
315 comments
I can't agree with this essay more.
In the early days of the Ethereum community a lot of open coordination was done on reddit and a threaded forum hosted on Vanilla Forums. Initially for privacy and convenience, Skype, gitter, Discord, and Telegram began to take hold, and later became the primary place for open, public discussions and some decision-making as well.
Threaded forums were still used but not central. It was a difficult era (but a lot of work still moved forward)! There emerged a kind of opacity due to ability to put attention on real-time threads, and IMO sometimes key voices were missing because they could not weigh in effectively.
What changed the dynamic was the introduction of Discourse for the critical https://ethresear.ch discussions (set up by Virgil Griffith), and later https://ethereum-magicians.org (something I worked on). I was pushing for threaded at the time because of experiences I had here on Hacker News, reddit, and Slashdot. The person I collaborated with, Greg Colvin, wanted discussions like the threaded emails he was used to from the IETF and c++ communities.
We each knew from long experiences dealing with coordinating on tech issue remotely that the quality of the message is the medium.
From those successful experiments / re-introductions, many teams then began to adopt and host Discourse instances. Later, DeFi picked it up for their governance / coordination discussions. Of course, real-time never went away, with more gravitating toward Telegram and Discord. But tracing the emerging thinking, hashing out differences on what to do, and re-activating stale discussions improved a lot.
Threaded discussions are a core part of the community and work again.
In the early days of the Ethereum community a lot of open coordination was done on reddit and a threaded forum hosted on Vanilla Forums. Initially for privacy and convenience, Skype, gitter, Discord, and Telegram began to take hold, and later became the primary place for open, public discussions and some decision-making as well.
Threaded forums were still used but not central. It was a difficult era (but a lot of work still moved forward)! There emerged a kind of opacity due to ability to put attention on real-time threads, and IMO sometimes key voices were missing because they could not weigh in effectively.
What changed the dynamic was the introduction of Discourse for the critical https://ethresear.ch discussions (set up by Virgil Griffith), and later https://ethereum-magicians.org (something I worked on). I was pushing for threaded at the time because of experiences I had here on Hacker News, reddit, and Slashdot. The person I collaborated with, Greg Colvin, wanted discussions like the threaded emails he was used to from the IETF and c++ communities.
We each knew from long experiences dealing with coordinating on tech issue remotely that the quality of the message is the medium.
From those successful experiments / re-introductions, many teams then began to adopt and host Discourse instances. Later, DeFi picked it up for their governance / coordination discussions. Of course, real-time never went away, with more gravitating toward Telegram and Discord. But tracing the emerging thinking, hashing out differences on what to do, and re-activating stale discussions improved a lot.
Threaded discussions are a core part of the community and work again.
I find this somewhat incomprehensible. Why the bias for seeing and archiving everything? The implicit model, which is right there in his title, is "talk", which is not naturally archived.
I've built products just fine using verbal communication nearly exclusively. [1] We don't need to create some sort of panoptic archive of every conversation ever had to get things done. If people miss things, they miss things. We can catch each other up on the parts that truly matter.
Forgetting and repetition can be negative, but they can also be highly positive. We don't have to carry with us the weight of every word ever spoken about a project.
[1] The main exception being index cards with a few words on each. https://williampietri.com/writing/2015/the-big-board/
I've built products just fine using verbal communication nearly exclusively. [1] We don't need to create some sort of panoptic archive of every conversation ever had to get things done. If people miss things, they miss things. We can catch each other up on the parts that truly matter.
Forgetting and repetition can be negative, but they can also be highly positive. We don't have to carry with us the weight of every word ever spoken about a project.
[1] The main exception being index cards with a few words on each. https://williampietri.com/writing/2015/the-big-board/
I have always thought that Slack is designed to make information go away, and that's why people like it. Email never goes away unless you archive the thread. If you have a bunch of things that are going on, you open your inbox and realize just how behind you are, every time you open it. Slack, conversely, scrolls up and always looks the same. If you miss something, the world moved on without your input, and you feel the same.
The article is right that the problem is when the information doesn't want to be deleted. Now you have to do extra work. (Specific example; a long time ago, I figured out how to get Github to notify me on Slack when a code review was assigned to me. It is not easy to find in the UI and took me a while to set up. I wrote down the instructions in Slack... and that helped people that were reading it then, but it doesn't help me tell someone how to do it that asks me today. Should have written a runbook!)
Remembering to persist information is always something you have to do, and it's not specific to Slack. Your shell history is useless to your coworkers. Your design discussions is useless to someone that just joined the team today.
The article is right that the problem is when the information doesn't want to be deleted. Now you have to do extra work. (Specific example; a long time ago, I figured out how to get Github to notify me on Slack when a code review was assigned to me. It is not easy to find in the UI and took me a while to set up. I wrote down the instructions in Slack... and that helped people that were reading it then, but it doesn't help me tell someone how to do it that asks me today. Should have written a runbook!)
Remembering to persist information is always something you have to do, and it's not specific to Slack. Your shell history is useless to your coworkers. Your design discussions is useless to someone that just joined the team today.
Despite the “asychronous” claim, you have to keep a steady eye on it and reply in realtime or the conversation will move on without you. Anyone who takes the time to ponder and respond thoughtfully with context and explanation will find that they’re too late.
I like the idea of a time-limited channel. You can only reply to it during the meeting, and up to 15 minutes after. Theoretically it would force everyone to communicate succinctly and not drag meetings on indefinitely over the course of a day.
Alternatively, have a channel that only allows one message per hour. Call it #deep-thought. You’ll really need to think about what to say before you write it down.
I like the idea of a time-limited channel. You can only reply to it during the meeting, and up to 15 minutes after. Theoretically it would force everyone to communicate succinctly and not drag meetings on indefinitely over the course of a day.
Alternatively, have a channel that only allows one message per hour. Call it #deep-thought. You’ll really need to think about what to say before you write it down.
I think part of the problem is not all conversations are obviously 'short and shallow' or 'long and broad'. What starts out casual might unearth something that needs going into deeper, and going in deep on something might not have results worth documenting yet.
To me this points out a gap in our software for knowledge archival. The closest concept Slack has is "pinning" a message to a channel, which has very limited use for this. Really what you want is to be able to have a conversation with someone in any manner (casual or formal meeting) and be able to easily extract the conclusions and decisions made into a different location, ideally through an easily discoverable UI in the software already being used.
In an ideal world my chat software has knowledge of the projects I'm working on (through some protocol to something else that acts as a source of truth) and I can select a message/file upload in chat and tell it to archive it against a project. It can easily fill in the details for me about who made this decision and when. Ability to effortlessly organise information arising from a connversation should a priority I think, this might remove the need for having seperate software depending on how "deep" you think a conversation is going to be.
To me this points out a gap in our software for knowledge archival. The closest concept Slack has is "pinning" a message to a channel, which has very limited use for this. Really what you want is to be able to have a conversation with someone in any manner (casual or formal meeting) and be able to easily extract the conclusions and decisions made into a different location, ideally through an easily discoverable UI in the software already being used.
In an ideal world my chat software has knowledge of the projects I'm working on (through some protocol to something else that acts as a source of truth) and I can select a message/file upload in chat and tell it to archive it against a project. It can easily fill in the details for me about who made this decision and when. Ability to effortlessly organise information arising from a connversation should a priority I think, this might remove the need for having seperate software depending on how "deep" you think a conversation is going to be.
I disagree with this article.
This is what was said about GMail when it first came out - you need folders, without folders you can't keep organized, etc.
Turns out indexing and mechanisms to make use of that indexing (labels, advanced sorts, filters) work better than folders.
Persistent chat that can be labelled, indexed, searched and filtered is amazing for work related chats, or any chat that becomes part of a long running context.
We do this where I work, and it works well, mostly - as long as people use the tags.
This is what was said about GMail when it first came out - you need folders, without folders you can't keep organized, etc.
Turns out indexing and mechanisms to make use of that indexing (labels, advanced sorts, filters) work better than folders.
Persistent chat that can be labelled, indexed, searched and filtered is amazing for work related chats, or any chat that becomes part of a long running context.
We do this where I work, and it works well, mostly - as long as people use the tags.
I can find useful discussions from 10 or 20 years ago because they were crawled and archived. IRC, Usenet, web message boards, mailing lists...
Every single discussion happening on Slack or Discord will probably be lost in a year or two and is impossible to find unless you happen to be already aware of it.
Developers should not use these platforms for anything with any value. This is not the way to share information.
Every single discussion happening on Slack or Discord will probably be lost in a year or two and is impossible to find unless you happen to be already aware of it.
Developers should not use these platforms for anything with any value. This is not the way to share information.
It’s probably an unpopular opinion, but the best online technical discussions I’ve ever seen in a company were done in Bugzilla.
Every bug or feature request was a ticket. Tickets sometimes had quite long discussions.
The advantages were:
* Permanent, so you thought about what you wrote.
* Public, same effect.
* Sequential, so it was very rare for people to reply over each other.
* Goal-oriented, you wanted to move towards resolution, which was then archived forever.
* Opt-in for following, so you had some control over your attention.
* Available, so you could search and see old attachments etc etc.
* Safe, Local, easily self-hosted and backed up.
* Customizable, e.g. easy linking to the repo even if you change repos.
The more things moved to various forms of the all-consuming Jirapoly, the attention sink of Slack, the anarchy of mail+chat, the less useful and (importantly) the less productive these conversations became.
Every bug or feature request was a ticket. Tickets sometimes had quite long discussions.
The advantages were:
* Permanent, so you thought about what you wrote.
* Public, same effect.
* Sequential, so it was very rare for people to reply over each other.
* Goal-oriented, you wanted to move towards resolution, which was then archived forever.
* Opt-in for following, so you had some control over your attention.
* Available, so you could search and see old attachments etc etc.
* Safe, Local, easily self-hosted and backed up.
* Customizable, e.g. easy linking to the repo even if you change repos.
The more things moved to various forms of the all-consuming Jirapoly, the attention sink of Slack, the anarchy of mail+chat, the less useful and (importantly) the less productive these conversations became.
Slack has fantastic search. It has good filtering, sorting, and pagination, and has the right degree of fuzziness.
I use it on a daily basis to discover the reasoning for things that happened before my time. I've never known anyone else who does this, and I've never understood why.
I use it on a daily basis to discover the reasoning for things that happened before my time. I've never known anyone else who does this, and I've never understood why.
It sounds like the author was mostly thinking about INTERNAL discussion, but I think the real tragedy is in using chat like Slack for your public customer community forum.
Think of all the knowledge and employee-time locked away in the scrollback of a chat based community forum.
Better to have chat for informal community discussion, but when someone asks a question that others in your community might find useful in the future, politely direct them to post it in a more permanent (read: accessible via google search) medium.
Think of all the knowledge and employee-time locked away in the scrollback of a chat based community forum.
Better to have chat for informal community discussion, but when someone asks a question that others in your community might find useful in the future, politely direct them to post it in a more permanent (read: accessible via google search) medium.
This is one of the things that drove me nuts at my last company. I had been remote all along, which meant I was left out of many discussions. Chat was my lifeline, because it was the only thing both I and others on the team used. When everyone went remote, we had an opportunity to make a change for the better, but instead nothing at all changed. Meetings were done via video chat instead of in person, but they were just as un-findable and ephemeral as before. If you mapped out the lines of communication before and after, there'd be no difference. In person vs. online matters far less IMO than ephemeral and closed vs. open and permanent.
The irony is that the company happens to be the world's largest platform for easily findable/joinable permanently archived conversations. Go figure.
The irony is that the company happens to be the world's largest platform for easily findable/joinable permanently archived conversations. Go figure.
I haven't yet seen anything better than NNTP (the protocol of Usenet) and a decent news client, which used to mean tin on Unix and MT-NewsWatcher on MacOS. We used to have patches and CVS commit messages on code review groups and fork discussions seamlessly into dev groups. Mailing list email to NNTP gateways allowed ready collab with workers outside the group. Common NFS share allowed easy joint work without huge amount of code & build duplication. And it was possible to just grep every message in the News spool.
This was much better than Slack + github + email + Confluence + Teams + file shares + SharePoint -- no one knows where anything is or which chat system a conversation was on. Searching Slack is a fool's errand.
I attribute the failures of these systems to be their reliance on the pattern of centralised SQL+httpd+templated crud+js vs federated standardized exchange+text.
In modern web apps the client is embedded in the app by its very nature, and so the proprietary nature of each system makes community contribution impossible.
This was much better than Slack + github + email + Confluence + Teams + file shares + SharePoint -- no one knows where anything is or which chat system a conversation was on. Searching Slack is a fool's errand.
I attribute the failures of these systems to be their reliance on the pattern of centralised SQL+httpd+templated crud+js vs federated standardized exchange+text.
In modern web apps the client is embedded in the app by its very nature, and so the proprietary nature of each system makes community contribution impossible.
I don't know, it is quite easy to search a well indexed chat for keywords in order to find important information.
I disagree with the conclusion of the article. Using this logic, one could say that you shouldn't speak about long term projects during voice call meetings. I agree that the quality of conversation drops when speaking over chat, but I would also say that communication increases. In my opinion, the increased communication more than makes up for the decline of message quality. I also feel that the author of this article is focused on Slack and Teams. Teams or a poorly implemented slack group can feel very disorganized, so I can see how the author came to the conclusion that they did.
I disagree with the notion that "live chat is for the things that can get lost." If the chat platform you're using has advance search features, announcement channels, and message pinning you can easily find information you're looking for and, in my personal experience, this is usually faster than searching through emails. Despite their major privacy concerns, Discord has an amazing search implementation that I wish more developers would take inspiration from.
Perhaps my view is influenced in part by my young age and by the culture of the company I work for, but I've always felt that people around me waste valuable time formulating emails to try to capture all edge cases of the reply. And usually this doesn't work, so multiple follow up emails over the course of an hour or even multiple hours are needed for something that could have been solved over text chat in mere minutes.
I disagree with the notion that "live chat is for the things that can get lost." If the chat platform you're using has advance search features, announcement channels, and message pinning you can easily find information you're looking for and, in my personal experience, this is usually faster than searching through emails. Despite their major privacy concerns, Discord has an amazing search implementation that I wish more developers would take inspiration from.
Perhaps my view is influenced in part by my young age and by the culture of the company I work for, but I've always felt that people around me waste valuable time formulating emails to try to capture all edge cases of the reply. And usually this doesn't work, so multiple follow up emails over the course of an hour or even multiple hours are needed for something that could have been solved over text chat in mere minutes.
When we were first growing our team out remotely, we really tried to emphasize this style of thinking. All decisions and larger discussions would need to be written down so the conversation could be easily referenced for long-term context - we chose Threads for this purpose. Any quick questions or one-off communication could live in Slack. Any documentation needed to live in Notion.
Over time, our usage of Threads quickly decreased. If decisions needed to be made, we had a meeting to cover it. Meetings always had a few days notice with a written agenda and problem context so that everyone could think through their ideas beforehand. The end of a meeting usually resulted in a decision, which would then get documented in Notion for posterity. The documented decisions and reasoning would be circulated for approval by everyone that was a part of that meeting to verify that nothing of importance was missed. Once everyone approved, the decision was locked in.
As our process developed, we found that the need for written back-and-forth on decisions was less necessary. Instead, when we identified that an issue needed to be solved, we identified the key components of the problem, gave everyone some thinking time, and knocked it out over the course of a call. We rarely need to revisit the decisions since we write out the reasoning afterwards.
I still love the concept of having a tool specifically for asynchronous discussion. However, I think these tools assume that the conversation is the important part when in reality, the only part that matters is the decision and the reasoning. If you can get your team to document those, you'll be just fine.
Over time, our usage of Threads quickly decreased. If decisions needed to be made, we had a meeting to cover it. Meetings always had a few days notice with a written agenda and problem context so that everyone could think through their ideas beforehand. The end of a meeting usually resulted in a decision, which would then get documented in Notion for posterity. The documented decisions and reasoning would be circulated for approval by everyone that was a part of that meeting to verify that nothing of importance was missed. Once everyone approved, the decision was locked in.
As our process developed, we found that the need for written back-and-forth on decisions was less necessary. Instead, when we identified that an issue needed to be solved, we identified the key components of the problem, gave everyone some thinking time, and knocked it out over the course of a call. We rarely need to revisit the decisions since we write out the reasoning afterwards.
I still love the concept of having a tool specifically for asynchronous discussion. However, I think these tools assume that the conversation is the important part when in reality, the only part that matters is the decision and the reasoning. If you can get your team to document those, you'll be just fine.
I don't know what to call it but some kind of training course, a spec or some other conditioning seems needed to get the best out of email. If the participants know 10 basic things like how and where to insert their responses and do not add 100 graphical signatures to each mail it gets 1000 times more wonderful and enjoyable. Long form doesn't become all that desirable that way. (It seems forums played a major role teaching how to quote to and gmail did a good job making it impossible.) Even on HN we rarely see quotation go on for more than one level.
<- your comment never goes here
> > > > person 1 original message paragraph 1
> > > person 2 first response to paragraph 1
> > person 1 response to person 2 first response
> person 2 response to 1's response
<- your comment goes here (the context is still paragraph 1, anything about this goes here not some place else)
> > > > person 1 original message paragraph 2
> > > person 2 response to paragraph 2
> > person 1 response to above
> person 3 response to above
<- your comment about p2 goes here
> > > person 2 elaborates
> > 1 responds
> 3 responds
<- your comment on p2's elaboration goes here
<- if it cant fit the 3 previous topics it goes here.
<- your comment never goes here
> > > > person 1 original message paragraph 1
> > > person 2 first response to paragraph 1
> > person 1 response to person 2 first response
> person 2 response to 1's response
<- your comment goes here (the context is still paragraph 1, anything about this goes here not some place else)
> > > > person 1 original message paragraph 2
> > > person 2 response to paragraph 2
> > person 1 response to above
> person 3 response to above
<- your comment about p2 goes here
> > > person 2 elaborates
> > 1 responds
> 3 responds
<- your comment on p2's elaboration goes here
<- if it cant fit the 3 previous topics it goes here.
I forget which podcast it was on, but Automattic's CEO (Matt Mullenweg) talked about how they use blogs internally for much of their communication, so there's a huge searchable archive of information back to the early days of the company. People occasionally write posts to collect useful information that's fallen too deep.
It was probably either in his interview[0] on The Knowledge Project or a recent episode of his own podcast[1]. Probably the former since the latter usually focuses on what other people are doing instead of his own company.
[0] https://fs.blog/knowledge-project/matt-mullenweg/
[1] https://distributed.blog/podcast/
It was probably either in his interview[0] on The Knowledge Project or a recent episode of his own podcast[1]. Probably the former since the latter usually focuses on what other people are doing instead of his own company.
[0] https://fs.blog/knowledge-project/matt-mullenweg/
[1] https://distributed.blog/podcast/
The way I've always heard this is:
If it's important, it needs to have a URL.
Your issue tracker works, assuming you're not constantly changing your tracker. SharePoint may work but is super clunky for this purpose. Confluence or Notion or something work just fine.
Email doesn't work by itself. With some mailing-list interface on top it may, but that seems like you're stretching a bit. IM/IRC/Slack/whatever chat also don't work for this purpose.
I always think: if I want to put a link to this project's design docs, maybe some meeting notes, so new hires can come up to speed on what we're trying to do, I want it to be a URL that makes some kind of human sense, and I want the format to be conducive to communicating the right details.
If it's important, it needs to have a URL.
Your issue tracker works, assuming you're not constantly changing your tracker. SharePoint may work but is super clunky for this purpose. Confluence or Notion or something work just fine.
Email doesn't work by itself. With some mailing-list interface on top it may, but that seems like you're stretching a bit. IM/IRC/Slack/whatever chat also don't work for this purpose.
I always think: if I want to put a link to this project's design docs, maybe some meeting notes, so new hires can come up to speed on what we're trying to do, I want it to be a URL that makes some kind of human sense, and I want the format to be conducive to communicating the right details.
Or, discuss in chat but make sure to end with a summary email detailing the relevant decisions. Maybe include a link to the chat so you can find it in the future.
We use Discord, and have 2 channels for each game we're workin' on. 'Updates' and 'Chat'
Announcements you want everyone to see go in 'Updates' So if you finished a feature or are starting work on a feature, or have a doc to show everyone... ... Everyone working on that project will have notifications turned on for the projects 'Updates' channel and will read everything on it.
All general chat about the project and also responding to and chatting about stuff in 'Updates' channel happens in chat channel.
Announcements you want everyone to see go in 'Updates' So if you finished a feature or are starting work on a feature, or have a doc to show everyone... ... Everyone working on that project will have notifications turned on for the projects 'Updates' channel and will read everything on it.
All general chat about the project and also responding to and chatting about stuff in 'Updates' channel happens in chat channel.
I have to agree with this. When we started using MS Teams, it worked really well to replace person to person chats, email etc..
But since it's become commonplace, it's become a crapbucket of stuff that I can't find anything back in. I have too many channels, too many teams (and you can't opt in to channels like you can on Slack, you have to join them all). And the search function is even worse than Outlook's. It's all just too unstructured. Even if I search for someone's name plus a keyword I know it's there it can't find it back for me.
Such an app (not just Teams) is just not the right tool for everything related to communication, even though Microsoft is pushing it as exactly that.
A forum though is too '2000' for me. I would see more in a managed wiki, provided people can stomach working in a structured way. Enforcing that will be an issue but it will result in a beautiful oracle of information. I've seen it happen before (and I've seen it fail many more times, sadly).
But since it's become commonplace, it's become a crapbucket of stuff that I can't find anything back in. I have too many channels, too many teams (and you can't opt in to channels like you can on Slack, you have to join them all). And the search function is even worse than Outlook's. It's all just too unstructured. Even if I search for someone's name plus a keyword I know it's there it can't find it back for me.
Such an app (not just Teams) is just not the right tool for everything related to communication, even though Microsoft is pushing it as exactly that.
A forum though is too '2000' for me. I would see more in a managed wiki, provided people can stomach working in a structured way. Enforcing that will be an issue but it will result in a beautiful oracle of information. I've seen it happen before (and I've seen it fail many more times, sadly).
Slack isn't a bunch of chat rooms, it's a database disguised as a bunch of chat rooms. I've never had a problem pulling up some random conversation from three years ago as long as I remember the general topic.
In that regard it's no different than using email, everything is indexed and you're just searching a different database.
In that regard it's no different than using email, everything is indexed and you're just searching a different database.
Twist (https://twist.com) solves this problem entirely. Instead of chat rooms where everyone chats about everything, it organizes discussions around tasks. Each task gets its own chat room. When you work on task X, you chat in task X's chat room. If you work on multiple tasks, you have multiple rooms, one per task. When you come back to a task, you just open the task's room and continue where you finished. When the task is finished, that conversation is pretty much over. It's a get things done product. No useless chatting and conversations don't overlap. Go use Twist!
I really hope the word e-mail is replaced with something else (like 'memo') and a new paradigm is introduced around the concept of offline discussions, like forum board or stack-overflow.
The purpose of such a system would be to save discussions and understandings in discussions for a long term.
I read Stack Overflow threads now and have a pretty good idea about the thought process from problem -> approaches -> solution, including solutions or approaches that were rejected.
Real-time chat is not a replacement of a meeting, because meetings have substantial outcomes and key decisions taken, that are usually recorded as Minutes of Meeting / Meeting notes.
The purpose of such a system would be to save discussions and understandings in discussions for a long term.
I read Stack Overflow threads now and have a pretty good idea about the thought process from problem -> approaches -> solution, including solutions or approaches that were rejected.
Real-time chat is not a replacement of a meeting, because meetings have substantial outcomes and key decisions taken, that are usually recorded as Minutes of Meeting / Meeting notes.
I actually think Zulip is an exception to this, because its Stream>Topic hierarchy encourages organized conversations.
At my org, we consider Zulip to be an archive of sorts, and make an effort (a small one, because Zulip's UX makes it natural) to organize our communication such that it serves as a source of information for a future date.
I wrote a whole article about this a while back:
https://monadical.com/posts/how-to-make-remote-work-part-two...
At my org, we consider Zulip to be an archive of sorts, and make an effort (a small one, because Zulip's UX makes it natural) to organize our communication such that it serves as a source of information for a future date.
I wrote a whole article about this a while back:
https://monadical.com/posts/how-to-make-remote-work-part-two...
Teams trying to enforce conversation threading in a (semi-)recent update pretty much put a halt to me and my coworkers using Teams for anything but voice for our morning sprints. Trying to follow even slow conversations in Teams is just way too much work, we instead chat on Telegram where chat works, you know, normally.
Luckily we were never in the habit of tracking anything through chat, we stick to our issue tracker, but I can absolutely imagine the frustration we'd have felt after that change had we relied more heavily on chat.
Luckily we were never in the habit of tracking anything through chat, we stick to our issue tracker, but I can absolutely imagine the frustration we'd have felt after that change had we relied more heavily on chat.
I’ve never been much of a fan of realtime chats.
Heck, I even had a personal policy of never scheduling regular meetings (they all needed to be “as-needed”).
However, I worked for a Japanese company, so regular meetings were a part of my life; whether or not I liked it.
I prefer “store and forward” communication (email is the classic form). Working for a Japanese company actually helped, there, as it was damn near impossible to have realtime chats with Tokyo.
If I use Slack that way, I do miss stuff in noisy channels, but I’ve learned to live with it (so have people I work with).
Heck, I even had a personal policy of never scheduling regular meetings (they all needed to be “as-needed”).
However, I worked for a Japanese company, so regular meetings were a part of my life; whether or not I liked it.
I prefer “store and forward” communication (email is the classic form). Working for a Japanese company actually helped, there, as it was damn near impossible to have realtime chats with Tokyo.
If I use Slack that way, I do miss stuff in noisy channels, but I’ve learned to live with it (so have people I work with).
How does this differ from spoken conversation?
Not really related to the article but at my work they are testing deployment of 3 different systems. They were deployed at different times so X was first then followed by Y about 1 year later, then finally Z ~6 months after deployment of Y. Z is expected to be fully adopted and Y and X will be phased out, eventually.
Depending on when the person joined they tend to have a proclivity towards a specific chat application. The oldest person on the group used X almost exclusively. The newer group members tended to use Y and Z apps.
So you would get pings from all of these apps and the points describes in the article are amplified times three.
In order to reclaim some sort of sanity, I decided to just log off from X and Y chat platforms and only use Z. I figured if that person really wanted to get ahold of me then they would figure it out themselves that I only use Z. Also I did send out e-mails and set statuses on X and Y indicating my preference for Z.
I would say thus far it is a success. Haven’t had any complaints for the past 6 months :)
Depending on when the person joined they tend to have a proclivity towards a specific chat application. The oldest person on the group used X almost exclusively. The newer group members tended to use Y and Z apps.
So you would get pings from all of these apps and the points describes in the article are amplified times three.
In order to reclaim some sort of sanity, I decided to just log off from X and Y chat platforms and only use Z. I figured if that person really wanted to get ahold of me then they would figure it out themselves that I only use Z. Also I did send out e-mails and set statuses on X and Y indicating my preference for Z.
I would say thus far it is a success. Haven’t had any complaints for the past 6 months :)
The real answer is: just fucking use email. Why is email not one of the options suggested in the TFA? It's universally available, durable, allows long-form conversation and thoughtful deliberation, doesn't tell you that "someone is typing," and offers you the luxury of checking it at a set interval only a few times per day.
The way many organizations have collectively abandoned email in favor of instant messaging is a travesty.