2 ms·

One interesting challenge with this real-time vs. async communication challenge is that different job roles have different needs. At my company, most of our emp

One interesting challenge with this real-time vs. async communication challenge is that different job roles have different needs. At my company, most of our employees have been on the customer service side until recently, and Slack is great for them. Almost everything they need to talk about is urgent (even if it's not important) and temporary. They rarely have long-lasting high-level conversations. Now we're starting to hire more developers and I'm realizing how disruptive it is for them to be pulled into Slack conversations all the time. So I've started using email more for communicating with the devs, and that seems to work reasonably well. The questions I have are: (a) is it possible to have a single communication tool that handles both real-time and async properly and (b) does that even matter? Maybe email+Slack is a perfectly fine solution. Either way, it's obvious that only using Slack isn't a viable option.

tmail21 9y ago
I don't believe that one should try to create a single tool that covers both synchronous and asynchronous. Their UX is too different. It seems to me a better idea to create an asynchronous deep collaboration tool and integrate it with synchronous tools like Slack. The bigger question to me is what should an asynchronous deep collaboration tool do (if anything) beyond first-class threads. In my mind the opportunity lies on three dimensions 1) Bringing updatable content and structure to threads. This makes threads vastly more useful for real collaboration (not just communication). 2) Making "catchup" much more efficient as this is the main problem with email. If you think of one of the most successful asynchronous collaboration approaches, it's source control like git. The key thing that these tools to is make changes "diffable". That allows users to work at completely different points in time and still easily "catchup" with what's changed. 3) Allow regular users to easily convert unstructured one-off threads to semi-structured template threads. This naturally and gently moves teams to greater process-orientation.

tmail21 9y ago

I don't believe that one should try to create a single tool that covers both synchronous and asynchronous. Their UX is too different. It seems to me a better idea to create an asynchronous deep collaboration tool and integrate it with synchronous tools like Slack. The bigger question to me is what should an asynchronous deep collaboration tool do (if anything) beyond first-class threads. In my mind the opportunity lies on three dimensions 1) Bringing updatable content and structure to threads. This makes threads vastly more useful for real collaboration (not just communication). 2) Making "catchup" much more efficient as this is the main problem with email. If you think of one of the most successful asynchronous collaboration approaches, it's source control like git. The key thing that these tools to is make changes "diffable". That allows users to work at completely different points in time and still easily "catchup" with what's changed. 3) Allow regular users to easily convert unstructured one-off threads to semi-structured template threads. This naturally and gently moves teams to greater process-orientation.