If you haven’t been living under a rock, you’ve probably heard about Slack, the communication tool that is taking companies by storm. At its heart Slack is a super-slick chat tool. In geek terms it is great for synchronous communication or communication where the various users are willing and able to communicate simultaneously. In turns out that synchronous communication is superior to asynchronous communication (think email) for many types of communication. The rapidity with ideas can be exchanged coupled with the low overhead of sending a message is the primary reason for this. A key point though is the notion that users must be ‘willing and able‘ to communicate synchronously. Why may they not be willing or able?

Why We Still Need Asynchronous Communication

• As the number of users in a conversation increases it becomes harder for everyone to be available simultaneously.
• Being ‘available’ all the time means that you are constantly getting interrupted . As we know, interruption is one of the most damaging aspects to productivity. There are workarounds like ‘Do Not Disturb‘ and ‘Office Hours‘ but these are just a band-aids on the problem.
• If you do need to follow up, a common thing in the asynchronous world, your follow-ups are spread across dozens of ‘channels’. In other words there is no unified inbox.
• As the number of conversation ‘threads’ increase it becomes hard to keep up. Some people stop getting immediate responses. So, now team members start having to wonder when you’ll respond. Asynchronous systems on the other hand are specifically designed around responses coming at varying points in time.
• Once the responses are no longer immediate due to too many ‘threads’, your fellow team members start having to wonder whether you’ll respond.
• Even if a user is willing to communicate, there are many long-running processes (imagine an employee hiring and onboarding process) where the state of the process is spread across time and chatting about it without full context is difficult.
• Team members may be in different time zones, making it hard to overlap.
• Sometimes responses require some deeper thought and may not be amenable to immediate response.
• The discussion requires easy manipulation of content without getting into version nightmare
• The discussion has associated state that needs to evolve with the discussion. For example, if the users are onboarding an employee, a checklist of the onboarding state and personal details of the employee could be the associated state.
• A discussion may need to be goal-oriented (capturing, tracking and achieving). This is difficult to achieve in a synchronous chat system.
• Sometimes, many parallel discussions are needed. Imagine a company which needs to discuss Sales Orders. It would make sense for each Sales Order to have its own discussion thread rather than intermingling these into a single chat stream.

The solution to all of these problems is to invest in an asynchronous communication tool that is tightly coupled with Slack. The main asynchronous communication tool in use today is email. But email is so flawed that it introduces more problems than it solves. What is needed is a next-generation asynchronous communication tool. What might such a tool look like?

The Contours of a Next-Generation Asynchronous Communication tool

Can I have some ‘Real’ Threads Please

One of the major goals of an asynchronous communication platform is to allow multiple long-running topics to be discussed in parallel. The key need here is for the discussion thread to make sense for all parties and look the same for all parties on the thread (” Single Version of the Truth“). Note that this is explicitly not the situation with email threads. In email, each party typically sees a different version of the ‘truth’. The reasons for this are that parties may be ‘dropped out’ of the middle of a thread and then be ‘added back’ later. When they are ‘added back’ later, they cannot be sure that the messages they are seeing are what the senders actually sent as any party could have modified messages without detection! All of this means that email threads are a complete mess and as far from single-version-of-the-truth as possible. In fact half the time email threads are barely comprehensible. So, a single-version-of-the-truth, comprehensible Thread would be the first thing we would want.

A Tracking Number for Threads?

Since these new kind of Threads would have a single-version-of-the-truth, it woud be trivial to give them a unique, global identity or something like Thread Tracking Number (think Fedex Tracking Number). A Unique Thread Tracking Number means that these Threads can now be referred to from anywhere including EMails, other Threads, Chat, Spreadsheets, Databases, Apps etc. So, now Threads are no longer siloed inside the asynchronous platform, but become an interconnected part of the company’s information landscape. Imagine the Internet before the URL and you have a sense for the world of email today and the potential of such a transformation.

But What about Chat?

Since chat is the best current approach for synchronous communication, it is critical that a next-generation asynchronous communication platform integrates seamlessly with Chat. Of course a Thread Tracking Number would go a long way towards making this happen, as it would allow Threads to be easily referred to from any Chat. But the integration needs to go much further. Users in the middle of a chat should be able to easily spawn off an asynchronous Thread with simple chat commands that many chat apps like Slack now support. They should be able to interact with their asynchronous Threads without leaving their chat app.

Help! My inbox is overflowing

One of the biggest problems with email is that it leads to overflowing inboxes. In a next-generation asynchronous platform this would be mitigated with a multi-pronged attack. With first-class threads, triage operations can be done at the thread-level rather than the individual message level. One click and you are up-to-date with 30 messages in a thread. With versioned content (see below), the back and forth of attachments would be eliminated. By clearly representing the latest state of the thread (see below), team members can come up to speed on a thread at glance without having to scan the whole thread. This eliminates a lot of the back and forth chatter of members trying to comprehend the ‘state’ of the thread. Of course with the deep integration with chat, all of the synchronous communication would be offloaded to the chat system but still link back. Micro-transaction costs could be applied to bulk messages to discourage spamming. The clarity of single-version-of-the-truth thread itself eliminates a lot of chatter. Shared Task Lists in a thread would eliminate the confusion of who is supposed to do what and further eliminate chatter.

And even after messages are massively decreased due to the aforementioned reasons, a powerful triage system (based on something like Kanban) would be necessary so that dealing with, delaying, following up, etc. is a breeze.

Please save me from the nightmare of attachments

Discussion threads, especially longer-running ones are often threads that manipulate content. For example in a Sales Cycle thread, the content being manipulated may be a Pricing Spreadsheet, a Competitor List, a Calendar of important events, an RFQ that needs to be filled out, a Demo script etc. A next-generation asynchronous communications platform would allow content to be inline and ‘democratic’ like email attachments (so users don’t need to worry about losing access to the content which is a constant possibility when linking to a separate system like a shared document system). Unlike email attachments, this type of content would need to be versioned and always lead the user to edit the latest version. This would avoid the nightmare that results from trying to use attachments as a means of content collaboration. Further, users will always be able to see the latest state at a glance and won’t need to scan the entire thread to ‘compute’ this.

Hey, What did you change?

In an asynchronous system, its not sufficient to know just the latest state of inline content, but it is absolutely critical that users can see what has changed. To continue the Sales Cycle example, if a user changed the Pricing, then other users will often want to see not only the latest pricing, but how the Pricing was changed from the previous version. So, a ‘diff’ capability for all inline content types becomes a critical aspect of any new asynchronous communication platform.

‘Meaning’ in life (and conversations) is a good thing

It should be possible to move the discussion from one meaningful state (of its inline content) to another. This will allow the thread to make sense at any given point in time. For example in the Sales Cycle example above, the sales team may revise their strategy and this may require the Pricing, Demo, and RFQ to all be modified in a single change.

Meaningful States in a discussion bring many benefits like advanced integration, forking the discussion at precise points, editor-suggester type collaboration, templatization of threads, instantiation of processes, Signing the discussion at specific points etc.

The key enabler of this would be the ability to have meaningful changesets . A meaningful changeset may range from just a simple comment to a comment with multiple content pieces added, updated or deleted in a single atomic operation.

Is there a point to this discussion?

One of the problems with current asynchronous communications approaches (such as email) is there is nothing that tends to drive the thread to a conclusion. This leads to a lot of pointless back and forth and lost productivity. A next-generation asynchronous communications platform should be goal-oriented. This means that all parties on the thread should be able to see the the goal being sought and the progress towards that goal. The goal may take the form of a Plan, Checklist or a Task List or some other form.

Sometimes a little structure is not a bad thing

With support for inline, versioned content, there is no reason why Structured Content could not be supported. Structured content like Forms would allow asynchronous discussions to be more structured. Users could be asked to fill in Forms as part of the discussion. This would lead to natural form-collaboration-type discussions.

Hmmm… Maybe I can institutionalize this discussion into a Conversational Process

Between meaningful changesets and structured content, all the building blocks would be present to support Conversational Processes. Conversational Processes would allow users to interact in a guided manner with each other and with apps in a conversational manner. Conversational Processes could go way beyond what chat apps currently support because of the presence of structured, meaningful state as part of the asynchronous discussion.

I never got that 🙁

With email, there is always plausible deniability on having received a message. Sometimes this is a good thing, but in general with business, especially B2B there should be no room for ambiguity on this subject. Imagine contracts, invoices, orders etc. with this kind of ambiguity. Accordingly a next generation asynchronous communication platform should provide the equivalent of certified mail. In fact it could even go beyond what a Postal service provides and certify the content too. Discussion threads and related content changes should be non-repudiable.

Slack + an Async. Communication Tool: A Match Made in Heaven

In summary, Slack, when coupled with a next-generation asynchronous communication platform can overcome the biggest pitfall of Slack. Use Slack for synchronous communication and spawn off powerful threads for asynchronous communication.

What? Such a System Exists??

Yes, such a system does indeed exist! It’s called TMail21 and is an asynchronous communication platform for the 21st century deeply integrated with Slack. You can register with TMail and check out our Slack App. This is Part 1 of a two part series. In Part 2 (coming soon) we discuss specifically how TMail21 and Slack can be combined to create communication nirvana.