How TMail21 Drives up to 5x Productivity Gains over email
EMail is the lifeblood of many organizations. It is estimated that email takes up to 28% of a knowledge worker’s time. On top of this, most users are frustrated by overflowing inboxes and a lack of productivity.
And yet, email continues to remain the top collaborative tool within teams and organizations. While synchronous chat services have made some inroads, they are applicable for the subset of situations where users are simultaneously available.
TMail21 drives its productivity gains with dramatic impacts on the following key collaborative productivity metrics:
TMail21 | ||
---|---|---|
Average time to Decision/Outcome |
||
Average Inbox Size | ||
Throughput (Decisions/Outcomes per time) |
One characteristic of email discussions is that they are asynchronous in nature or involve a deferred response. Deferred Response refers to the fact that there is an expectation that a responder can respond at a time of his or her choosing rather than immediately. This means that users do not have to be simultaneously available in order for email to be used. This is contrast to synchronous chat apps where users need to be simultaneously available to truly realize the benefits.
In this essay we will refer to email as a Deferred Response Communication system. (Seen in this light, messages piling up in your inbox is a feature not a bug.)
In order to understand how productivity can be improved in a Deferred Response system, it is important to define a couple of terms first. The first term is cycle time which is defined as the time between sending a message and receiving a response. The figure below illustrates this.
A typical email discussion will have many back-and-forth responses in order to make some decision or achieve some outcome. The number of back-and-forths required to make a decision or achieve some outcome is the number-of-cycles-to-outcome. As we shall see, it turns out that the number of cycles to achieve the goals of the discussion is the single most important driver of productivity in a Deferred Response Communication system. The figure below illustrates the concept of number-of-cycles-to-outcome.
So, why are the number of cycles in a Deferred Response Communication system like email so critical? There are several reasons for this. The first is that the larger the number of cycles, the larger the inbox size as shown below.
The second major reason why number of cycles is so critical is that most decisions or outcomes have either formal or informal deadlines associated with them. As the number of cycles increase, the likelihood of meeting the deadline decreases. This relationship is shown below.
As the probability of meeting deadlines decrease, users resort to synchronous escalations such as phone, chat, meetings etc. This leads to further chaos due to the distractions and lack of scale of synchronous methods of communication.
The second important term to define is throughput. Throughput is defined as the amount of useful work (decisions, outcomes etc.) done over some time period.
If all discussions were perfectly parallel then the throughput decreases only because of the incremental work required to make each response. In practice, many decisions and outcomes have interrelationships with other decisions and outcomes. Hence as the number of cycles increases the overall throughput decreases much more rapidly than linearly. These two relationships are shown below.
In summary we can see that the average number of cycles per discussion outcome is the key driver of productivity in asynchronous or deferred response communication systems such as email. Decreasing the average number of cycles per outcome/decision will have non-linear (positive) effects on inbox size, likelihood of meeting deadlines and organizational throughput.
Unfortunately, email was not designed with this critical metric in mind. TMail21, by contrast was designed from scratch to have a substantial (positive) impact on the average number of cycles per decision/outcome (and hence also substantially impact throughput and average inbox size)
In the rest of this discussion we will look at the major drivers of high-average-number-of-cycles in email, and how the problem was addressed in TMail21.
Lack of clarity regarding the state of the discussion.
Either implicitly or explicitly almost every discussion has a Discussion State. The discussion state is the evolving outcome of the discussion. One of the biggest reasons for excessive-number-of-cycles in email is lack of clarity and certainty around the current discussion state.
With email because the latest discussion state is not explicitly represented and thus usually unclear, additional response cycles are often used to resolve the confusion. Sometimes the confusion is not immediately resolved as participants are not even aware of an issue. Only when the issue later manifests are additional cycles initiated to correct the situation.
To further complicate matters, the discussion state is often compound in nature. This means that the discussion state often involves more than one artifact in the discussion state. Furthermore these artifacts are often heterogeneous in nature, for example, Text, Tabular Data, Task Lists, Forms, Documents, Checklists etc.
In an email system there is no explicit state. The state is either captured in the email body itself or in attachments. This leads to vast amounts of confusion since there is no agreed upon current state, no agreement as to how the state got to this point, contradictory state etc. In the context of attachments, this is referred to as attachment nightmare. Users don’t know what the latest state of the attachment is. Users often edit a non-latest version leading to inadvertent branching of state. Lots of additional response cycles are expended to determine and correct the situation. The graphs below show the ill-effects of using attachments to represent discussion state.
TMail21 solves this problem with inline discussion state with the following characteristics
- There is an explicit discussion state such that it is always clear what the latest state is.
- The discussion may start with no state and then add or evolve state over time. In other words a discussion-first approach.
- The discussion state is compound and heterogeneous in nature. (many types of disparate state can be part of the overall state of the discussion, viz. documents, text sections, task lists, check lists, forms etc.)
- The discussion state is inline, and its access control is identical to the discussion itself.
- The discussion state is in synch with the comments of the discussion.
- The different elements of the discussion state are in synch with each other
- All changes across the discussion state and comments are applied in an all-or-nothing (transactional) manner.
With these characteristics, discussions with complex evolving state can be conducted with ease. It is not uncommon to see 2x-10x reductions in unnecessary response cycles. And as we saw earlier, reductions in unnecessary response cycles leads to non-linear benefits in terms of inbox size, likelihood of meeting deadlines, throughput etc.
Lack of clarity on what’s changed.
In addition to lacking a clear discussion state, email does not support the capability of “whats changed” in a discussion. Why is change-tracking so important in a Deferred Response Communication environment?
There are several reasons for this.
1) Every user has typically absorbed (understood) the state till a certain point (let’s call this the last-read point). By showing the user ‘what’s changed’, the user can focus on the (typically) small part of the discussion state that has changed.
This is the same reason we read ‘news’ everyday, rather than trying to understand the state of the world from scratch. By allowing the user to focus on a small subset of the total state, the user is much more likely to understand the current state due to the significantly less time and effort involved. The figure below shows the relationship between the Likelihood of comprehension and the size of the discussion state.
2) Change, often indicates intent which may be absent from the final state. This aids in understanding motives and thus understand the final state better. Again, anything that increases understanding reduces the need for excessive response cycles.
3) Change is often the part we need to act upon. Acting could mean accepting, rejecting, agreeing, suggesting modifications, commenting on, incorporating into another discussion etc. By shining a laser light on exactly what’s changed, these resulting actions themselves will be much more precise. Greater precision in any response prevents a cascade of misunderstanding and its attendant increase in response-cycles for clarification.
Lack of Accountability
The next major problem with email is lack of accountability on who is responsible for what. The closest one can get with email to any kind of accountability is via the concept of To: and Cc:. The idea here being that the users on the To: list are the ones accountable for ‘something’. This is an extremely crude feature to base accountability on. In practice, users try to achieve accountability by putting some language into the body such as “Joe, can you please do XYZ…”.
Because of lack of accountability, users are often unsure who is exactly is responsible for what. Even if the accountability is known (say it was specified in the body of the email) it is easy to shirk responsibility. Lack of clarity on accountability leads to lots of additional response cycles trying to attribute accountability. Furthermore, when things don’t get done (and no one notices) there is massive increase in cumulative cycle time which is equally problematic as we saw earlier.
TMail21 solves this problem by incorporating inline Task Lists right into the discussion thread. Each task has a requester and one or more assignees. Also there is a Unified Task Inbox for each user. Each user knows exactly what is assigned to them and what they have requested in the context of the discussion. The Task List is always in synch with the state of the discussion in addition to any other discussion state there might be. The graph below shows the relationship between the number of tasks in a discussion and the number of response cycles.
Inline Task Lists lead to a massive reduction in the number of cycles and cumulative cycle time. This once again leads to huge benefits in terms of Inbox size, throughput, likelihood of meeting deadlines etc.
Lack of Precision in Referring to the Discussion or parts of the Discussion
The next major issue with email which leads to lots of additional response cycles is the lack of addressability of the discussion or parts of the discussion.
For example, there is no way to precisely refer to a discussion thread or a comment in a discussion thread, or some piece of discussion state etc. The way users compensate is to use rough descriptions as a proxy. For example
- Your email you sent yesterday with a subject something like Acme Corp
- The attachment foo.docx sent around 11am today.
- Your comment “< entire comment quoted >”
All of these mechanisms have the common characteristic of being imprecise. Again this leads to further confusion and additional response cycles to clarify. Of course these additional response cycles themselves are subject to the same lack of clarity and subsequent consequences. EMail today is like the pre-URL Internet!
The figure below shows the relationshipship between Number of cycles and degree of precision.
- Tracking Number for the whole thread (eg. 123-1245-1234 also known as Thread Tracking Number or ttn)
- Tracking Number for each ‘changeset’ in the discussion (eg. ttn/c#15)
- Tracking Number for any piece of discussion state (eg. ttn/s#2)
- Tracking Number for any piece of discussion state at any ‘changeset’. (eg. ttn/s#2/v#3)
- Tracking Number for any Task in a discussion (eg. ttn/s#2/t#12)
- Tracking Number for any attachment in a discussion (eg. ttn/c#15/a#3)
These Tracking Numbers can be used not only within TMail, but also outside of it. For example
• In a text message: “Joe, take a look at c#4 of [‘Acme Sales Cycle’, 123-1245-1234] and give me your feedback”.
Lack of Integration with Synchronous Chat
When users are simultaneously available and the message is worth the distraction penalty on the recipient, Synchronous Chat is significantly superior to Deferred Communication. This is mainly due to the near-zero cycle time. This allows for a rapid back and forth.
Because of the high distraction penalty, this strategy needs to be used sparingly. It is clear that the optimal collaboration strategy is to use synchronous chat and deferred communication where appropriate. The figure below shows the impact of utilizing an optimal mix of Deferred Communication and Synchronous Chat.
This requires that the Deferred Communication system be well integrated with the Synchronous Chat system. Email is very poorly integrated with Synchronous Chat, mainly because it is impossible to refer to email discussions or their portions precisely from Chat (or anywhere else for that matter). With TMail21 it is easy to hop between synchronous chat and deferred communication.
Apps like the TMail21 Slack App take this integration to the next level.
Lack of Clear, First-class, Contiguous Threads
Email threads are anything but clear. One big problem is gaps in a thread. Anytime someone is left off a thread, they have a gap in their thread. This makes understanding a thread potentially very difficult. Lots of back-and-forths result from different members trying to understand the meaning of something because of gaps.
This stems from a critical design flaw in email, viz. the inability to separate out notifications from permissions. This leads to well-meaning but ultimately self-defeating advise like “use reply instead of reply-all”. This advise keeps notifications under control but at the expense of incomprehensible threads and gratuitous lack of transparency.
This also leads to massive balkanization of what would otherwise be a cohesive thread. In order to prevent spamming users, instead of one thread there may be a dozen side threads only a few of which are really needed. Worse still, when the threads are balkanized, the discussion state (implicit in the case of email) is also balkanized leading to further confusion.
Overall, email’s non-contiguous, balkanized threads are a major contributor to excessive-number-of-cycles.
The figure below shows the relationship between degree of thread balkanization and the number of cycles to outcome.
An optimal deferred communication system would
- Allow notifications to be separated out from permissions so the reply/reply-all no-win choice does not rear its ugly head.
- Have distinct operations to add to a thread (equivalent of reply-all, but without the spam) vs. spawn a distinct thread.
- The latter would only be done if the user truly wanted to restrict/change permissions rather than just avoid excessive notifications.
- Support thread-level inbox triage operations to allow much more efficient processing and catch-up on a thread.
- Thread permissions can only be widened, never narrowed.
- In order to narrow (which is effectively restricting of permissions) spawn off a new thread.
TMail21 has all of these characteristics. TMail21 Threads are clear, contiguous and comprehensible leading to significantly lower number of cycles and cumulative cycle times.
Lack of Lightweight Conversational Processes
In a deferred communication environment, processes drastically reduce excessive-number-of-cycles. Processes are designed to reduce cycle times and therefore increase throughput. They do this by
- Up-front considering the needed discussion state to achieve a particular outcome
- Up-front deciding on roles and responsibilities
- Up-front deciding on the desired outcome or output
Of course email has no ability to support these.
The figures below illustrate the benefits of process-orientation
TMail21 supports converting any thread into a reusable conversational process. The conversational process ‘feels’ very similar to a ‘normal’ discussion and hence user adoption is high. Lightweight conversational processes can be created by any user in minutes with no coding required. Through this capability TMail21 further increases productivity over email.
Summary
For many discussions, all of the points above cumulatively lead to large improvements in productivity over email. In many highly collaborative environments, order-of-magnitude productivity increases are not uncommon. Three key metrics of average-time-per-outcome, throughput (outcomes/time) and inbox size are dramatically improved. The Email vs TMail21 comparison graphs below summarize the effects of this.
Email vs TMail21 (# of Cycles and average-time-per-outcome)
For simple notifications (#cycles = 1), both email and tmail require one cycle. However as discussion complexity increases (for example, decisions trying to be reached etc.) the number of cycles rises much faster with email than with tmail.