This article is an early version of a chapter that was included in the book “How to Communicate Effectively With a Remote Team”.
You can buy the e-book from Amazon.

Choosing the right tool is a weird thing to do, because it’s at the same time the most important choice and the least important choice you can do. It’s a paradox because without a tool you can’t collaborate – and mind that: a tool isn’t necessarily a software tool – but at the same time if you have clear what you are trying to do you might find yourself choosing something that isn’t even software, or isn’t even specific for collaboration.

The Implied Process

If you look around to find advice, most of the time you find recommendations of specific tools with lists of benefits and gains of using one or the other, with the promise that they will deliver a certain set of results.

Nothing could be further from the truth. The first thing to understand is that every tool has been build with certain cultural assumptions and processes in mind. This is a good thing, but has to be acknowledged, if it’s not clear then there’s a big misconception of what a tool can achieve and how. There’s no such a thing as a neutral tool, and any tools that claims to be neutral is just trying to sell to a wider audience – creating collateral damage in the process.

This underlying process can’t be easily dismissed because each team has a specific set of processes, culture, habits, formal and informal, that are adopted and in place. Even new teams have this, mostly due to the composition of individuals’ assumptions.

Now, there are three scenarios possibles:

1. The tool processes and the team processes match: this is a perfect fit.
2. The tool processes are different from the team processes, and the team is willing to experiment and adapt.
3. The tool processes are different from the team processes, but the team doesn’t want to change.

Unfortunately, what happens often is the third scenario. A tool is chosen either for political reasons or personal taste without an understanding of formal and informal processes in places, and this leads either to abandonment of the tool after a short while; or to costly refactoring of perfectly nice tools that would have thrived in a different organization.
These refactoring costs will lead to an increase of costs for the overall tool and maintenance costs down the line, to the point that if the tool is changed too much, the overall result will be actually a decrease of collaboration in the whole team.
This is incredibly evident in bigger corporations with big implementation budgets that instead of choosing a tool with a new process that would improve their way of work, they choose a tool and bend it to their process, often borking it.

The second scenario isn’t common because often people perceive a tool as a solution in itself. But since we have here acknowledged the implied processes in a tool, we are now able to see clearly that to do the second scenario we need to get the acceptance by the team and the willingness to try and adapt.

This scenario is the one that is pushed by Basecamp for example, where they have a company that doesn’t just promote the tool, but also a specific way of working.

“We don’t use Basecamp to plan, we use it to communicate. That’s a deep difference in approach.”
– Ryan Singer, Basecamp

Also methodologies like GTD (Getting Things Done) by David Allen starting from the methodology side address this issue even before to getting to the specifics of which tool to choose.

“Anything that you trust will feed back what you want to be reminded of, and when, will work. It’s not the tool, but the contents and how appropriately you engage with it.”
— David Allen

They both declare explicitly a specific way of doing work, so you can more easily understand that the tool is just part of the adoption, the other part is the processes adaptation.

To address properly this first critical moment of choice ask yourself two things:

1. What is the underlying process that this tool embody?
2. What are our processes that will translate well into the tool?

Formal and Informal Processes

The other trap most people fall in when choosing a tool is exactly that: choosing a tool, with emphasis on the “a”. Any over-focus on a single, individual tool will miss the big picture and, in the end, will lead just to adoption by luck.

Approximately 70% of projects fail because of lack of user acceptance.
— Forrester Research Report

There are two reasons leading to this perception:

• People view certain tools that have been used clearly and historically as collaboration tools as given and do not include them when making their choices. The email is one such overlooked example.
• People hope that a single tool will solve all the needs.

This world view of course fails in reality, where most of the time we find a multitude of different tools that work one with each other in different ways.

The first thing to understand is the difference between the formal processes and the informal processes. Between model and reality:

• Model: includes the formal rules of the organization on how to do things. Best practices, laws, gatekeepers, hierarchy, approval processes. All of these are formal, slow to change and to a certain extent, well understood (or at least, it’s possible to communicate them).
• Reality: most of the people however follow practices that exist beyond the formal processes. Yes, maybe you have to send that email for approval, but you actually ask first every time in person to make sure it will go through. Or maybe there’s that way to start a new project, but there’s also another way, faster, that can be fit as long as the project stays small. In short, people work around processes every day with a network of actions that isn’t mapped.

This disconnection leads to many problems in the choice of tools: if you choose a tool that maps a process that people worked around every single time, your tool will simply be ignored because that’s not how people were doing things before.

Many people that love structure and organization react to this reality with more structure and rules. This is clearly the wrong choice, because models are slower to adapt to change – and things keep changing all the time. The end result is usually bureaucracy and a company that becomes trapped by itself.

However, if you just acknowledge these two distinct levels, then you can correctly build upon them, and get how they can guide your decision. In short: do not be blinded by formal processes, acknowledge the informal ones as well when you choose new tools.

By the way, this doesn’t mean to translate the informal ones to formal. It would be an error: it would just make your company more rigid.

The Three Speeds of Effective Collaboration

In my experience with small startup teams and big corporations I always found a pattern, over and over. I’m still not sure if this maps to some kind of underlying human nature or not, but after more than 10 years of design work and 5 years of enterprise consulting to companies in how to become more social and collaborative, I have been able to outline a model that worked thus far.

The model is based on the idea that collaboration has three speeds upon which it’s based and that these speeds must all exist and can’t be conflated into one to be effective.

You often find that a team has a need to discuss certain things quickly, in short but intense exchanges. This can be just a question that requires a simple answer, or complex arguments to clarify something specific. This usually happens in chats.

Not everything however requires this kind of quick turnaround. Certain discussion can happen in a longer timeframe, or can be delayed, or aren’t as important. Maybe the person isn’t even there at this time. This is the realm usually covered by email.

Finally certain kinds of content communicate by themselves.
The third speed is the slowest one, that is the archive. Documents stored for future use often don’t seem part of the collaboration side of things, but it’s very important to have them accessible and stored somewhere.

These three elements make the complete model of the three speeds of collaboration: realtime, async and storage.

Realtime

This is the speed where you must be there to engage in the conversation. This kind of collaboration happens often in one-to-one discussions, with a lot of messages exchanged in a short amount of time and quick replies. Sometimes this can happen with more than 2 people, but it’s unlikely to reach a large team. For this speed to work well it’s very important to have a good notifications system in place.

The characteristics of the realtime speed are:

• Fast: the interface reacts instantly, within milliseconds.
• Synchronous: everyone must be present at the same time.
• Interactive: replies are delivered in a short time, ideally in under a minute, usually less.
• Ephemeral: what’s said is valuable for the people involved, but don’t persist beyond that.

In terms of signal to noise ratio, these interaction have a good level of signal but it’s very contextual to the situation, and it becomes noise in the longer term: imagine for example a discussion where a team clarifies how to approach a problem. It’s something that might take a while and it’s incredibly valuable, but once it’s done, the only value that needs to be communicated resides in its results.

This is also the ideal speed where to communicate social aspects that creates better social connections beyond the day-to-day work, something that is often underestimated, but invaluable

Examples of real-time tools include:

• Microsoft Skype
• Google Hangouts
• Atlassian HipChat
• Slack
• Microsoft Lync
• Phone and Conference Calls
• Meetings
• IRC
• Any chat software

Async

This is the speed where you will be there at some point to reply in the conversation. This form of discussion involves small groups of people. Usually, the groups consist of 1– 3 participants but not often more than 10 or conversation becomes very difficult. It is frequently represented by content displayed in an activity flow.

The characteristics of the async speed are:

• Slower: the interface can take a few seconds to get the communication across.
• Asynchronous: the other person isn’t necessarily present at the same time.
• Delayed: there’s no expectation of immediate answer, even if if you know the person there’s usually a timeframe you can expect. It’s usually in the range of hours or days.
• Persistent: it creates a track record that can be easily re-read.
• Linear: the structure is often chronological.

Async tools are:

• Email
• Socialcast
• Microsoft Yammer
• Atlassian Jira
• Facebook
• Any forum software

Storage

This is the speed where you are not there anymore in the conversation after you wrote it. This is a form of broadcast communication: one person writes, many people listen, often in a long timeframe. It’s often a piece of content that is able to stand on its own, covering a specific topic or subject.

The characteristics of the storage speed are:

• Slow: publishing content it might even take days, with an editorial review in between.
• Completely asynchronous: the author might even not be with the team anymore.
• Autonomous: no answer is required. The content is self contained and communicates by itself.
• Timeless: it is very persistent. Documents stored can stay for years.
• Organized: there’s a multi-class structure with hierarchies, categories, tags and metadata.

Notice how only the storage level is the one that acquires a structure beyond chronological ordering and basic searchability. It’s also the speed that is likely to require gardening to be kept in order over time. This doesn’t mean gatekeeping the content: it could be open as a wiki, so the gardening process happens after the editing is done to ensure not just up-to-date content, but also good structure and findability.

Storage tools are:

• Atlassian Confluence
• Microsoft Sharepoint
• GitHub
• Box
• DropBox
• Google Drive
• Any database and storage software

In Practice

I work in Automattic – the maker of WordPress.com – one of the biggest, fully distributed companies. We have over 300 people spread across about 30 countries (as of 2015), something that makes even more evident the needs and constraints of fully distributed teams.

WordPress is at the core of the technology side of our infrastructure, clearly:

• Realtime: Slack
• Async: WordPress with P2 theme
• Storage: WordPress

It’s even more interesting to note that until early 2014 Automattic used an even more basic tool: IRC – in place of Slack. The reason was mostly historical, it was chosen more than 10 years ago and it was thus well integrated over time with every other internal tool. Given the size of the company, the simplicity of this approach often surprise people, but it’s also clear evidence of how much more important are the internal collaboration practices and how simple tools can go a long way.

The company is mostly flat, and structured in independent groups, each one having a Slack channel and a P2. This means that if you need something specific, what you have to do is to write a post or have a chat in the right space and you’ll get the answer you need. There are no hierarchies to overcome, bosses to consult, or procedures to follow.

Also, everything is visible to everyone, from the code committed to the discussions around the company strategy. Any level of detail. This means that the need for access control, blocks, limitations and so on is almost non existent, removing a huge burden from both our processes and tools.

This is especially interesting because in a previous company I worked with we were trying to change to a more collaborative environment, but the pool of enterprise tools we had at our disposal were all “obscure by default”. This meant that every time you had to setup a new group or space the default setting was fully private and restricted and you had to manually add everyone. Having such a setup by default does just setup silos and harms collaboration, but on the other side you’ll notice that committing to transparency is a cultural choice, a management choice, that impacts multiple levels: the tool is just a consequence.

If you want to read more about Automattic you might like to check “The Year Without Pants” by Scott Berkun, which gets into the day-to-day detail of working with us.

Let’s see a few more examples…

Example: Google-centric

Google is able to cover all the three speeds with the following tools:

• Realtime: Hangouts
• Async: GMail
• Storage: Drive

Google is doing a great job here in terms of Google Apps, they cover every side very well with a good degree of integration. Having it available both as private and businesses is also a great addition.

Example: Microsoft-centric

A solution completely based on Microsoft tools can follow this pattern:

• Realtime: Lync
• Async: Socialcast
• Storage: SharePoint

This kind of approach can often found in companies that are completely Microsoft-centric and are usually more on the side of big corporation. They get clearly an advantage in terms of systems integration.

Example: Atlassian-centric

Atlassian is an excellent company very focused on collaboration and even remote team collaboration specifically. Their suite is very well done, and you can find a good solution in the following set:

• Realtime: HipChat
• Async: Confluence (the activity stream view)
• Storage: Confluence

Example: WordPress-based

Of course, the important thing is to cover all the aspects and get them interacting with each other well. You can cover a lot with opensource tools, for example WordPress.org, the opensource project, uses:

• Realtime: Slack
• Async: WordPress with an “activity stream” theme
• Storage: WordPress used as a wiki

While of course WordPress doesn’t have a realtime part, that part gets complemented by Slack, which offers a lot of different levels of integration.

I’ve made symbolic examples above that map to specific sets of tools, but of course the most important thing of the three speeds approach is that you can mix different approaches well, and without any problem. Often basic integrations between these tool can solve many different problems.

For example, mixed approaches could be: IRC + Confluence + SharePoint, or Slack + GMail + DropBox, or HipChat + WordPress P2 + Confluence. The important thing is that these solution map well to how your team already work in term of formal and informal processes.

Don’t overthink it: put more effort in the testing, adoption, practice and roll-out of the collaboration platforms than in the selection and configuration of the tool. Don’t try to get it right from day one, but plan to experiment with it and have multiple incremental steps of adoption.