3 ms·

I don't think the fundamental problem is one of sync vs async communication. Of course synchronous communication is a flow killer, and of course having it as a

I don't think the fundamental problem is one of sync vs async communication. Of course synchronous communication is a flow killer, and of course having it as a team-wide or company-wide means of communication aggravates its problems. The async nature just makes it worse, as it has more bandwidth, and consumes more brain bandwidth as a result of more content than email and wider distribution than email. The problem lies between unstructured and structured information. The problem is one of process vs flying by the seat of your pants. Ideally, you want processes for every repeatable action, and more flexible means of communication for new events that need to be handled quickly by those empowered to solve them. However, every repeatable process starts as an one-off event: Customer requests for the same actions pile up until the moment you realize your app needs a new feature; Faults occur and get solved up until you realize you need to engineer a solution that prevents or automatically fixes them; Internal processes get lost and hang until you decide to redefine the internal workflow. What is missing is a simple way of moving unstructured communication (sync and async), onto structured communication. Chats should end up as feature requests, bug reports, documentation or some other permanent medium that fits into the process. If the unstructured->structured bridge is solved, you don't have to monitor chats (or mailing lists, or forums). If they result in something meaningful, they will appear in the structured, process-oriented flow. Monitor that, and get involved in chats where you are directly mentioned. (and skip all gif chats, really)

tmail21 9y ago
These are some great points. You might want to check out https://tmail21.com https://tmail21.com. We built this around what we called Deep Collaboration (a riff on Deep Work). We built it to be Thread First AND have a thread-first inbox as well. However, more importantly we realized that just thread-first is not sufficient. We saw three major problems with synchronous solutions like Slack and asynchronous solutions like email. 1) Lack of support for updatable content 2) Lack of support for easily moving from unstructured to structured content. 3) Difficulty catching up So we added the notion of Updateable "Sections" to threads (in addition to conventional attachments). These "Sections" come in various types, some of which lend themselves to making your thread structured. 1) Text 2) Form (structured) 3) Task List 4) Checklist (process) 5) Word, Excel, Powerpoint etc. This allows one to create threads that have structured content. However, this still doesn't solve the "one-off" problem you described. So, we made it easy to take any thread and make it a "Template" that can be easily instantiated. This allows one to naturally to evolve towards lightweight processes starting from regular threads. For example, here is one of the "industry solutions" pages which gives ideas for structured threads in a particular industry (in this case Manufacturing and Logistics) https://tmail21.com/solutions/industries/manufacturing-and-logistics/ https://tmail21.com/solutions/industries/manufacturing-and-l... Lastly for the "difficulty catching up" problem, we took inspiration from the way git et al are built and decided to make "diffs" central to the catchup metaphor. We're talking not only diffs for Text, but also for Task Lists, Grids, Checklists, Forms and other "Sections". We hope to make communication and collaboration significantly more productive. Would love to get any HN feedback. ps) We integrate with Slack to marry their synchronous model with our asynchronous model.

tmail21 9y ago

These are some great points. You might want to check out https://tmail21.com https://tmail21.com. We built this around what we called Deep Collaboration (a riff on Deep Work). We built it to be Thread First AND have a thread-first inbox as well. However, more importantly we realized that just thread-first is not sufficient. We saw three major problems with synchronous solutions like Slack and asynchronous solutions like email. 1) Lack of support for updatable content 2) Lack of support for easily moving from unstructured to structured content. 3) Difficulty catching up So we added the notion of Updateable "Sections" to threads (in addition to conventional attachments). These "Sections" come in various types, some of which lend themselves to making your thread structured. 1) Text 2) Form (structured) 3) Task List 4) Checklist (process) 5) Word, Excel, Powerpoint etc. This allows one to create threads that have structured content. However, this still doesn't solve the "one-off" problem you described. So, we made it easy to take any thread and make it a "Template" that can be easily instantiated. This allows one to naturally to evolve towards lightweight processes starting from regular threads. For example, here is one of the "industry solutions" pages which gives ideas for structured threads in a particular industry (in this case Manufacturing and Logistics) https://tmail21.com/solutions/industries/manufacturing-and-logistics/ https://tmail21.com/solutions/industries/manufacturing-and-l... Lastly for the "difficulty catching up" problem, we took inspiration from the way git et al are built and decided to make "diffs" central to the catchup metaphor. We're talking not only diffs for Text, but also for Task Lists, Grids, Checklists, Forms and other "Sections". We hope to make communication and collaboration significantly more productive. Would love to get any HN feedback. ps) We integrate with Slack to marry their synchronous model with our asynchronous model.