TMail Productivity

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:

 

Email 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.

Sidebar: Examples of Discussion State:

  • The current set of competitors in a sales cycle (in a Sales Cycle discussion)
  • A list of tasks and their state related to a meeting (In a discussion related to a meeting)
  • The status of a job candidate’s application (In a discussion about a job candidate)
  • The status of a vacation approval request (In a discussion about a vacation approval)
  • The status of an RFP response (In a discussion about a Request for Proposal)
  • The status of an Issue.. Diagnosis, Fixed or not, assigned to etc. (In a discussion about an issue.)
  • The state of a new hire onboarding checklist (In a discussion about a new hire)
  • The current budget proposal (In a discussion about a budget proposal)
  • The state of a software deployment.. deployed or not… release notes, smoke test etc (In a discussion about a software deployment)
  • The current state of a contract being negotiated (In a discussion around a contract)
  • Who has signed a document (In a discussion around a document signing)
  • State of a disputed invoice (In a discussion about a disputed invoice)
  • etc

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.

Sidebar: Example of Compound Discussion State:

For example in a discussion about a Sales Cycle the state may comprise

  • The state of the Request-for-Proposal (RFP) and
  • The current competitor list and
  • The Task List associated with the Sales Cycle and
  • The Demo Script and
  • The Important Dates associated with the Sales Cycle and
  • A Pricing Proposal and
  • A Statement of Work and
  • The state of a Checklist associated with a typical Sales Cycle
  • 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.


Sidebar: What about using external state management? eg) Shared File Systems?:

One seemingly obvious answer to the problem of unclear discussion state is to externalize the discussion state into an external state management systems such as Shared File or Online Document or Task Management Systems and link to those from the email. Unfortunately, this leads to email-integration-nightmare (a cure that is possibly worse than the disease). So, what is email-integration-nightmare?

  • Possibility that the recipient loses access to the shared state at some later time because the owner removed the access.
  • The recipient forwards the email to someone who does not have access
  • EMails, once sent cannot be modified. Thus emails act as a history of a discussion. But with externalized state, a modification to the externalized state, effectively modifies history of the email thread breaking a key aspect of the ‘promise’ of email.
  • The externalized state not synchronized with the state of the discussion. Because the state of the discussion is evolved independent of the comments of the discussion this is a likely outcome. In the example of the Sales Cycle above, the discussion state might be distributed between the email thread, a file sharing system, an online document system, a task management system and a checklist system.
  • Different types of externalized state (eg. Task List and RFP State) are out of synch with each other (in addition to be out of synch with the email discussion).
  • Instead of a single unified history, there are multiple histories.

For this reason, email-integration-nightmare precludes externalized state from being a viable solution to this problem and is the reason why users fall back to attachments despite “attachment nightmare”.

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.

Sidebar: More details on Change Tracking:

For the change tracking to be useful it needs to have several additional characteristics

  • The discussion states (and hence the change tracking between discussion states) must be at logical, semantic points. This means that the state points must be ‘laid down’ or ‘released’ by the end user. They cannot be artificial points like auto-save points, lock-release points, time-interval-based points etc.
  • Change Tracking should be available between any arbitrary set of logical releases (messages). The reason for this is that different users are ‘caught up’ to different points in the discussion. Depending on the nature of the discussion, the user may want to see what’s changed at every point from their caught-up point, or get a summary of all changes or something in between.
  • Users should be able to associate commentary alongside the system-computed change. This associated commentary further increases understanding by allowing the user to make meta-level points that may not be evident from either looking at the end-state or the system-computed change.

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.

Sidebar: What about integrating with a Project Management Tool?:

One obvious solution to the lack of accountability in email is to try to integrate email with project management tools like Basecamp, Trello or Asana. These are great tools for project management, but don’t meet the needs of accountability in discussions for the following reasons

  • They are project oriented. For every discussion one would need to either create a project or decide which project the discussion’s tasks should go into. This is a huge cognitive overhead for something as simple as a discussion.
  • Projects have static permissions unlike discussions which are much more dynamic. And furthermore each discussion thread will likely have a different dynamic set. This leads to huge conflicts in permissions.
  • It will be difficult to keep the project state in synch with the discussion state since they evolve independently.
  • They are owner-centric unlike email (and TMail21) which are ‘democratic‘. Owner-centric models are fundamentally incompatible with ‘democratic’ discussion systems.

In summary project management tools are great for managing projects but are an extremely poor fit for providing accountability and task management for lightweight, democratic discussion systems such as email and TMail21.

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.

TMail solves this by giving user-friendly Tracking Numbers to all parts of the discussion. This dramatically increases precision and decreases response cycles.

  • 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.

EMail vs. TMail (Throughput – Outcomes/time)

EMail vs. TMail (Inbox Size as function of team size)