📗 Distributed Collaboration Manual (DRAFT)

This is a draft version of our manual for distributed collaboration (or “remote work” / “telework” as it’s also called). It will be under heavy development throughout the rest of 2019 – check back for updates!


1. Introduction

2. Communication techniques

3. Collaboration techniques

4. Tools

5. Building distributed organizations

TODO: general tasks
  • Include graphics, videos and other material where relevant.

  • Use embedded XKCD comics where relevant (file names, …).

  • Add references to other Edgeryders manuals: Zoom manual for “how to do video conferencing” etc…

  • Include several interesting calculations that show how remote collaboration is much more energy efficient and prevents greenhouse gas emissions. Including by avoiding the need for two sets of buildings (one for the home, one for the workspace).

  • Recommend to avoid e-mail as much as possible. And give the reasons for that.

  • Include a special section about distributed collaboration for developers. With things like “you don’t write source code to be understood by computers, you write it to be understood by the developer after you”.

1. Introduction

1.1. About this manual

What you’ll find here. This manual documents the knowledge about distributed collaboration (“remote work”, “telework”) that we developed in our organization Edgeryders OÜ. We are a distributed organization since our earliest beginnings in 2012 (before spin-off and incorporation).

Motivation. Distributed collaboration can avoid a drastic amount of greenhouse gas emissions from business travel (esp. air travel), from daily commuting to work, from the energy consumption in commercial buildings, and from the embodied emissions of constructing new office buildings. But distributed collaboration is not easy, often frustrating, and therefore not nearly as widely adopted as it should be. We believe that, as an organization with 7+ years of experience in this area, we have an obligation to share our expertise freely and widely – it is our best possible contribution to help fighting the climate crisis.

Content licence. [TODO: Mention that this is an open source project under a CC-BY 4.0 Unported licence, and any later version. Add the CC-BY logo.]

Credits. This manual was made possible through funding by Climate KIC. [TODO: Describe the project that made this manual possible. Add the Climate KIC logo to this manual.]

How to use this manual. [TODO]

How to contribute. This distributed collaboration manual is itself created by distributed collaborators, and you’re welcome to contribute because this is an open source project. However you obtained it, the most recent development version is in a wiki on edgeryders.eu. After opening a (free) account on the edgeryders.eu platform, you can edit that wiki, or if you are less sure about your contribution, make and discuss proposals in the comments below it. The wiki uses Discourse flavoured Markdown as its markup syntax, all of which is documented in our Discourse User Manual.

How to work with us. If your organization faces challenges around distributed collaboration that are not addressed in this manual, and you want our help to solve them, you are welcome. Edgeryders OÜ is available for consulting in this area as long as we can also include the resulting knowledge into this manual – under an open content licence, and of course in a general, anonymized form. You can talk to @matthias about this: either send a direct message here on the platform, or an e-mail to matthias@edgeryders.eu.

2. Communication techniques

We estimate that about 70% of both the efficiency and enjoyability of remote works comes from the difference between good and bad communication and collaboration techniques, and the last 30% from the tools. Also, good technique can make up for less than optimal digital tools. Among other things, this allows to use open source tools – often less sophisticated than commercial alternatives, but providing all the freedoms of free software.

To illustrate the limited role of tools, just remember the worst directory structure and file naming you ever encountered in shared online file storage. 100 tebibytes of storage space is worth nothing at that point because you can’t even find a single byte of what you’re looking for.

So let’s start with the basics: below is a collection of tool-agnostic best practices for digital communication. Digital communication is about coordinating data, while collaboration is about coordinating action.


  • Provide one example and one counterexample for every listed communication technique.

1. Clear, precise, complete

People appreciate it when verbal communication is coherent, in full sentences and with a clearly understandable pronunciation. In other words, when somebody puts in effort when they say something. This is especially valuable in a professional context and even a selection criterion when hiring (“presentation skills” etc.).

The same is not yet true for non-spoken digital communication like instant messaging, online forums, comments on collaborative documents etc… On average, collaborators put in little effort to make their communication here clear, precise and complete as well, and when this becomes part of the workplace culture, it becomes self-affirming (“My colleagues write the same way, why should I put in extra effort when writing them?”). But as a result, this lack of digital communication culture makes distributed collaboration inefficient, unenjoyable and often enough unworkable.

For details on techniques for clear digital communication, see further below in this list. This first point is just to sensitize you to the problem, which is already half of the solution.

2. Minimize the receiver’s work

[TODO. And mention that “click work is also work”.]

3. Pull-based communication

Time spent on back-and-forth communication, and the delays introduces by it, is the biggest inefficiency in distributed collaboration. And documentation is the major way to solve it.

Ideally all relevant organizational knowledge and project knowledge is available online to all collaborators, in a well-organized and well-maintained form. Together with “read the friendly manual” as organizational culture, this creates pull-based communication as the default.

As a result of having everything in the manuals, people get stuck less often in their work, and interrupt each other’s work less often. And when an avoidable question is still asked, then answering it is now fast, with a link to a manual section.

Pull-based communication also implies that spelling new organizational knowledge out into the manuals is an important task for every collaborator. In addition, manuals require updates and “debugging” just like software. We found that a comment section below the manual for questions about unclear or missing manual content serves this purpose well.

4. Anticipate and avoid back-and-forth

_[TODO: Write this section. Refers to anticipating responses and difficulties of your communication and solving them already before finishing your communication. This solves time lags and back-and-forth.

Include the discussion of the “critique of e-mail”, and how to use e-mail right: so that you get 2-3 steps of progress with each exchange, not half a step because of unclear communication about a single step. I wrote about that here.]_

5. Find the system, follow the system

[TODO: Write this section. Refers to the desire that there should be a system for every aspect of how to organize your data. And when contributing data, one should first observe the conventions that make up this system, and then follow them. Only with a system, data is retrievable and re-usable. Without a system, a collection of data becomes more entropic and less useful the more data you add. Data without order is noise!]

6. Make hyperlinks beautiful

When you copy & paste a URL into almost any digital collaboration tool, it will be automatically linked (“made clickable”) by the tool. People quickly find this feature, and because it is so convenient, it’s the default how links are sent around.

But straightforwardly inserting a URL creates the most ugly form of a link: it’s a long, confusing string of characters that is highlighted to grab attention but has often no meaning of its own, so the reader has to look around in the text to understand what it is for. It looks ugly on screen and on print, it can have privacy issues and it breaks the flow of reading a sentence. All this makes digital collaboration a bit more frustrating and less enjoyable for the recipient. Once, it’s not a big deal. Over years, it adds up.

Here is everything we know about communicating with hyperlinks in the best possible way:

  • Find out how to use a link text. If you don’t want to send the bare URL but give your link a readable link text like here like here), you have to somehow add information to the link text to make it “special”, transforming normal text into a link. How to do this differs between the different tools, so just google it or look into the manual. Most up-to-date tools however use one of two ways. The first is a rich-text editor where you highlight the text and click a button that opens a dialog where you enter the link target URL. The second is Markdown where you write your link like this:

    Regarding [our recent discussion](https://example.com/) about …

    to get this:

    Regarding our recent discussion about …

    It works in a surprising number of tools, including Discourse, Riot, [TODO]. Just try it to find out if your tool understands Markdown.

  • Support skimming. Naturally, a cross-reference is an important part of a text, and a hyperlink is also visually highlighted. So when you choose your link text appropriately, hyperlinks support both fast comprehension and fast visual navigation by letting the reader skim through, reading only headings and links.

  • Do not use link shorteners. Link shorteners like Bitly give URLs a shorter alias and were originally used where only URLs and not proper hyperlinks could be posted, and esp. where an additional character limit applied (Twitter). Nowadays, link shorteners are rather used to get insights about who visits the link, so some people consider them a privacy intrusion and don’t like them. Also, when hovering over a link one can no longer see to which site it finally goes, hiding information from a user that would help her judge if to visit the link or not. There are exceptions where you really need a short URL (see below), but in general link shorteners are not a good idea to use.

  • Use short URLs. The URLs of hyperlinks are often very long. That looks ugly when you have to send them as a URL and also when the reader hovers the pointer over a link to look at the target URL. Without the clutter, it is often easier for a user to judge if they want to visit that URL. In addition, long URLs often contain information that you don’t want to share (such as your username or account ID so the website can track who shared the link). So where possible, remove any parts that are not essential for the functioning of the link. This can be done in roughly 70% of cases to some extent, but requires an understanding of URLs and some guesswork:

    The different parts of a URL and how to omit them

    [TODO: Maybe outsource this part to a Q&A on Web Applications Stack Exchange.]

    In the order of appearance, URLs consist of the following parts:

    • Protocol. This is either http:// or https:// and is always needed. The exception are relative links inside the same website: then both the protocol and the domain part can be omitted because they don’t change. The reader will still see the protocol and domain part when hovering over a link, because the browser adds them automatically. But omitting them when writing content is still better because (1) it makes your text more readable and shorter if written in Markdown or other source format rather than a rich-text editor, (2) it will not break if the website, such as your blog, is ever moved to a different domain. For example in Discourse, a popular forum software, relative linking enable very short internal URLs to other forum posts like this: /t/1234/12.

    • Domain. This is for example example.com or any other hostname. Sometimes it includes one or more levels of sub-domains before that, for example blog.example.com. All this is required, except for relative links (see above).

    • Path. The path always starts with / and contains multiple directory names and optionally a filename. It ends at the end of the URL, or one of the special characters # or ?. Originally this referred to directories and files in the filesystem on the webserver, and often it still does, but websites also use this more freely in the sense of a logical rather than physical path to information. In that case, redunant path elements can often be omitted because the software does not use them. For example, in Discourse a typical path is /t/topic-title-here/1234/12. Here, the correct guess is that 1234/12 are topic and post ID and sufficiently identify the content. The topic-title-here part can be omitted, and the link keeps working. As an example from our platform, consider the following links to this manual, both of which work:

      📗 Distributed Collaboration Manual (DRAFT)

      Sometimes, only parts of a path elements can be omitted, because the website splits the element into an essential and an ignored part (that is only there to inform search engines and the like). For example, only the last part of a medium.com article link is the article ID and essential, while the title can be avoided. All of these links work:


      The third and fourth option show what you can do when the title is clearly not completely avoidable, but also not essential. Instead of just a you could also insert anything else and the link would still work. Medium does not need this trick, but many newspaper websites do.

    • Subpart marker. A subpart marker is an optional string of the form #name that follows the path. It identifies the part of the website to scroll or otherwise navigate to after loading the page. It often changes automatically while scrolling, so you might inadvertently copy a URL with a subpart marker while wanting to refer to the whole page, starting with the top. In that case, just delete the subpart marker.

    • Query string. The query string is an optional string of the form ?name1=value1&name2=value2&name3=value3&…, that is, multiple pairs of variable name and value, connected with &, and all starting with ?. It may or may not be essential: if the path already identifies the content, you can try omitting it, as it probably not needed for anything. For webpages where you filled form elements beforehand to see what you want to link to, these parameters are important though because they contain this input. But even then, there are often individual variables that are either at their default value, have an empty value, or are outright useless. You can try omitting them. As an example, when googling for “enter google into google”, the resulting URL is at first something like this (sooo ugly :worried:):


      Nearly all of the query string variables can be omitted. This still works and looks so much better:


  • [TODO: How to integrate hyperlinks into natural language text seamlessly.]

  • [TODO: Tips to find the right URL in various applications, esp. in Google Drive for PDF files Could be a Q&A on Web Applications Stack Exchange.]

  • [TODO: How to use hyperlinks to make your communication shorter and more relevant in the future. For example, if you are a tech support person answering a question that probably will appear again, and where the answer does not contain anything confidential, you can post a Q&A combination on a suitable Stack Exchange platform, and post the link as your answer.]

7. Include the source format

[TODO. Basically: provide freedom to operate to the recipient of a work by also enabling them to make changes as desired. For a PDF with text, include the word processor source format as well (at least as a link). For graphics, include the XCF (GIMP native files, like PSD) resp. SVG files as well.]

8. No middleman

If somebody has to communicate or negotiate on your behalf, it hardly ever increases efficiency. Rather, it results in misunderstandings and delays.


9. Allow for peripheral awareness

Keep all communication within your organization as open as reasonably possible. This is easy to do with a central online forum accessible to all your collaborators. Over the medium term, peripheral awareness by following others’ communication from afar gives collaborators context and learning opportunities, which prevents misunderstandings and delays in the future.

10. Add reasonable formatting


11. Use systematic, beautiful filenames

[TODO: Embed https://xkcd.com/1459/ ]

[TODO: A complete manual for naming files.]

12. No redundancy

Redundancy can be good or bad: redundant checks and calculations can protect against mistakes, and backups can protect against data losses. But redundant live data is a major source of inefficiency in collaboration:

  • It creates confusion as your collaborators have a hard time knowing which version of a file is in use, or which is the most up to date.

  • It creates synchronization problems when people accidentally work on different versions, thinking theirs is the last one. Ever tried comparing two lengthy Google Docs documents to make a common version?

  • It creates duplicate work, as the same errors have to be found and fixed in multiple versions.

  • It takes up more storage space. Not just once, but multiplied by the number of backups you keep.

[TODO: Better text than a list for the above.]

Before you copy any data, take a second and think if this is really the best solution to your problem. Avoiding redundancy applies to all types of copying data:

How to avoid redundancy. In 90% of cases, redundant data is not the solution. Here are ways to avoid it.

  • In documents. [TODO]

  • In source code. Often you would better create a new function (instead of copying inside your own program) or library (instead of copying between programs).

  • [TODO]

How to use redundancy. Sometimes, redundancy is the best available solution. That applies whenever the maintenance effort of the new structure you would have to introduce to avoid redundancy is higher than the effort added by the redundancy itself. So when you minimize the additional work created by redundancy, redundancy can be the best solution to a problem. Here are some tips for “effortless” redundancy:

  • Clearly mark any redundancy. For files, a numeric version number as a filename element, just before the extension, is a good tip. Use enough leading zeros to make your file manager show the last version last. In addition, any exported versions from source formats are also redundant an should be recognizable as such. See below for example filenames, and see about using good filenames for more details [TODO: link].

  • [TODO]

13. Be mindful with others’ attention

Attention is work: the work of reading the message or notification, going to the place it points to, understanding the context, if it is important, and thinking about the appropriate (re-)action.

So when attention is wasted on unimportant matters, it lowers collaboration efficiency. That doesn’t mean that you have to avoid any single “thank you!” message in chat, but to be aware of what could be annoying rather than helpful communication, partially by observing your own reactions to notifications, and by observing how your digital tools work in detail.

Little tricks include:

  • Line breaks. Learn how to make a line break when instant messaging. Usually it’s pressing Shift + Return. This allows you to write on message per request / issue / occasion, not one per paragraph, and correspondingly you’ll also only cause one notification rather than a lot of them in quick succession.

  • Reacts. In several instant messaging systems, there are now ways to react to a message with an icon (thumbs up, heart, …). These do not cause a notification so do not demand immediate attention but still allow you to express gratitude, agreement, sympathy and so on. Especially in a group chat situation this is helpful, as each additional notification there demands the attention of several people. There is some subtlety to their use though: they are used for a mild expression of emotions, because the receiver knows that you know that the receiver might not see them because they don’t cause a notification. So if you want to confer a strong reaction, want to say something loud and strongly and powerfully: use something that does cause a notification.

  • Ask before calling. Of all forms of communication, audio or video calls demand the most attention because one can hardly do anything aside and one has to react the moment the call comes in. So it seems to become established culture slowly that before making a call, it is respectful to ask via instant messaging when is a suitable time. This is an inversion of former “phone culture” when the phone was the main means of telecommunication – it doesn’t mean that people forgot how to use the phone properly, but that we have now more tools in the toolbox and are slowly learning how to use each for its purpose.

14. Data retrieval empathy

When collaborating in a way so that all relevant information is available to all collaborators in a shared repository (see: pull-based communication [TODO: link]), the big challenge is how to enable others to find what you put in. If, on the other hand, every collaborator keeps all their information on their own computers, that is not the challenge – they hopefully know how to find information again on their own computer when being asked by a collaborator. But these requests for files and other data consume worktime and produce delays, so it’s worth facing and solving this challenge.

The best principle is, in our view, what could be called “data retrieval empathy”: imagine where your collaborators would look for the piece of information you want to sort in, and then place it exactly there in the shared information repositories. For this, a good technique is to think about where you yourself would look for this piece of information, had a collaborator created it.

After some practice with this, you will notice some patterns, which can also help you to find the right place for information:

  • High cohesion. In each repository of information, there are multiple mechanisms to structure information. In a file system for example, these are folders, files, and the various ways to structure files (which depend on file type). In a Git repository for source code, these are in addition branches, forks and tags. In almost cases, these mechanisms form a hierarchical data structure: text is structured inside files, files inside folders. This means, the mechanisms differ by granularity. Now the general principle to sort in a new piece information is to use the most granular (most “low level”) mechanism that is suitable for the task. Because this keeps the information as close to its most related information as possible, which in turn makes it well findable because collaborators will look first into places “where similar stuff is found”. Keeping related information close together in this way is here called “high cohesion”. Note that this is a rough rule of thumb with many exceptions, but still a useful guideline.

    Here is an example to flesh this out: Let’s say you created an expense registration spreadsheet for a new project and want to place it somewhere in a shared file repository like Google Drive. The most fine-grained mechanism to structure data in this repository that you have available is “inside the files”. The rule says you should consider that first to place your spreadsheet somewhere – which would lead you to consider putting it into a new sheet (“tab”) in an existing budget spreadsheet file of that project. If that is not suitable for some reason, then the next more granular mechanism is the level of files: you could place it as a new spreadsheet file into the same directory as the budget spreadsheet, with the filename indicating its relation to the budget spreadsheet. By letting both filenames start with the same prefixes, you keep them close together when a user looks at the containing folder’s file list. “Close together” means more cohesion, and more cohesion means better findability. The two filesnames could be for example Finances:_Budget and Finances:_Expense_Registry.

15. Refactor, fix, optimize

Refactoring is a technique used in software development to improve the quality and structure of a program’s source code without changing its behavior. We use it here in an analogous sense of improving the structure of documentation, a file system or other data without changing what it means. Corrections and optimizations of documents on the other hand are improvements that will change their meaning.

Ideally this “digital housekeeping” becomes a constant habit for every collaborator for dealing with shared data like manuals, spreadsheets and files in general. It basically means: when you see a quick way to improve shared data, do so immediately. When you see a way to point out shortcomings but don’t know how to fix them, add a comment. Of course manuals and documentation have to be editable for all collaborators for this process to work. If the organization is concerned about data integrity and correctness when giving even new collaborators full edit access, it can use a versioned editing system where all changes can be inspected and if necessary rolled back.

Benefits of such a habit of constant improvements of all shared data include:

  • Collaborative issue discovery. Processes in an organization change quite often, at least in parts, and it is hard to update all references to the old process accordingly in the documentation. But if readers catch and correct inconsistencies while using the documentation, these inconsistencies are fixed the first time they cause an issue to somebody. It’s the equivalent of Linus’s Law, just for distributed collaboration that is not limited to writing software: “Given enough eyeballs, all bugs are shallow.”

  • Collaborative copyediting. Copyediting is about the clarity of the words and explanations. For example: A sentence or paragraph in shared process documentation is unclear to one reader, but the meaning becomes evident after thinking about it for three minutes. By editing the text to clarify that meaning, the collaborator saves the same three minutes for every collaborator who would have the same issue with the same passage afterwards.

  • Collaborative structuring and formatting. It is unreasonable to expect that every collaborator has all technical writing skills, but everyone can contribute something: the content, the wording, the structure, the formatting, or the illustrations. Writing starts with the raw content of course, and if the author does not have the time or skills to add well navigable structure and formatting, it’s ok to leave the content like that. Others will come in afterwards, be grateful to find the content documented at all, and contribute improvements to wording, structure, formatting and so on. [TODO: Split this out into its own point: “Incremental writing”.]

  • Growing the structure with the content. When organizing data, it is very often not clear at the start how many records of the same type will have to be added: 10, 100, 1000, 100 000? Starting with a structure that is suitable for 5000 (like a database) means a lot of overhead effort in setup and access when it turns out that only 200 records are added. So it is generally better to start with a structure for a lower estimate and migrate the data to a different structure when the need for that arises. That migration also is overhead effort of course – so try to shoot for a structure with the lowest expectable overhead over the lifetime of the data. [TODO: Split this out into its own point.]

16. Structure data with hierarchy

The human mind has some rather severe cognitive limits. For example, psychologist George A. Miller found in his highly-cited 1956 paper “The Magical Number Seven, Plus or Minus Two” that 7±2 is a useful heuristic for the maximum number of list items that the human mind can remember and process simultaneously. Beyond that limit, the mind will sub-structure the list and use other techniques to process it, requiring much more processing effort per list item.

That’s makes hierarchy probably the most useful data structure for comfortable and fast processing of information by the human mind. For example, generally you would present a table of contents for a document not as a long linear list of sections but structured into chapters and sub-chapters, with ≤9 sibling items at each point of that hierarchy.

There are some caveats. You only need hierarchy in data data meant for immediate processing by humans – for example in documents, books, team lists. You do not need it for data that is only accessed by a computerized information retrieval system, such as a search in a knowledge base with thousands of Q&A articles. You also do not need it for lists that can be used without keeping all items in mind simultaneously, such as lists of alphabetically sorted glossary entries, or lists of instructions meant to be followed one by one. Also note that, while hierarchy works to structure both data and people, we recommend it for data only because it generally causes suffering when applied to people.

17. Separate urgent and non-urgent communications

Like others, this technique follows from the same principle of using the attention of your collaborators sparingly. Where urgent and non-urgent communication happens in the same channel such as one chatroom, collaborators are forced to look up each notification immediately because it could be an urgent message.

That is solved where urgent communication has its own channel, resulting in dicernibly different notifications. Then, collaborators can let non-urgent notifications pile up until there are enough to deserve looking at an until there is a good opportunity to read and answer the messages. That makes a big difference in the amount of attention that the notifications deserve: instead of 100 notifications interrupting ones workflow 100 times a day, now there are perhaps 10 interruptions in good moments, each to process an average of 10 messages.

18. Conference calls

[TODO: When to use them, and how.]

3. Collaboration techniques

While the last section dealt with the basics of digital communication, this section is more specifically about collaboration: coordinated action to get things done.

All of these best practices apply only to specific circumstances, based on the tasks, people and timeframe of the project. Which technique is best under which circumstances is often not obvious. It becomes easier after several years of practicing digital collaboration, but will still require experimentation. And that’s ok: there is no solid management theory for digital collaboration yet, it’s still a matter of experimentation and intuition.

1. Issue tracker plus coordinator

This technique was developed for fixing reported errors in software – basically always an exercise in distributed collaboration, between software users and developers. It works well for any well-defined task, especially purely technical tasks that change only products and documents but not people and their activities. It is also well suited to work truly globally across time zones, and to integrate people into a distributed team who come from a different culture and background.

This works because an “issue” should be a self-contained task that the assignee can work on without any further back-and-forth communication. For this to work, such issues should not be created by end users of a product who want to report a problem, because that results in unclear and incomplete reports and a lot of back and forth communication. Instead, a team leader (or rather: team coordinator) who is skilled in digital communication techniques and also knows the project or product very well should take on all this communication work for their team. It includes:

  • Task coordination and time planning. TODO

  • Issue descriptions. TODO

  • Issue assignees. TODO

  • Issue deadlines. TODO

  • Outward communication. Or at least be the first to react to issue reports by users and other people inside the organization, taking off the mental load of error analysis from team members.

  • Testing. TODO

  • Documentation. TODO

Doing this for a team of 5-8 people is already a full-time job – this is also the drawback of this technique: it just does not scale well. Also it is obvious that the team leader’s task here is to serve their team members, making their workflow as smooth and friction-less as possible. Ideally, team members will have very little mental load with work coordination: when they finish one task, they will just pick the next task from the top of their list. They will also have very few interruptions, the exceptions being @mentions in the issue tracker and occasional instant messaging with the team coordinator. This allows them to focus and be productive in their work.

In an ideal organization, there would not have to be a team coordinator and instead everyone who needs something done that is to be managed with an issue tracker would follow the guidelines from above. However, that’s asking for superhuman abilities: due to a lack of domain knowledge and due to a lack of long-term interest in the product, the average person just cannot care enough. Instead, choose the person as team coordinator who has the deepest expertise about a product and the deepest personal interest in its future, long-term development. You want a person interested in product quality and with a vision for the concerned product. Otherwise product development can quickly deteriorate into a messy assortment of quick fixes.

2. Let them work but monitor the progress

This technique applies for work that has a natural scalar metric. For example, the progress of editing or translating or otherwise processing text can be measured in the amount of words that were already progressed. If all tasks are different from each other, the “issue tracker plus coordinator” technique will be more suitable.

For this technique, the team leader or manager needs a software tool that can measure and visualize the progress of team members along the chosen metric. Team members get their task in the beginning of the collaboration, and get occasional feedback about their performance from the team leader, based on insights gathered from the digital monitoring tool. If the tool shows that progress is blocked in a major way, the team leader will have to call a meeting or otherwise investigate the issue.

The advantage of this technique is that it scales well. Depending on the task at hand and the sophistication of the monitoring software, one team leader can guide anywhere from 25 to several hundred team members.

3. Agile development

4. Project management wiki

5. Warroom


For some work, “fast” will be the first priority within the “good, cheap, fast” triangle. A “warroom” environment is a technique to get this done with distributed collaborators. Unlike most other techniques, this is synchronous communication: distributed only in space, not in time. It’s basically about simulating a busy office environment with a permanent video call, with a few extra features to allow side channel communication, group decision making etc…

There are disadvantages, of course. Collaborators lose the freedom to work when they choose to, and also the freedom to work from any place they choose to because a constant video feed requires a high-bandwidth, low-latency Internet connection, making people stuck at home and a few places they know with a reliable connection. So use this sparingly – only when the benefits outweigh the drawbacks.

6. Coordinator role

7. Information system

This is the gold standard for efficient distributed collaboration. Unfortunately, information systems are expensive and time consuming to create and to change, so that only large organizations with few, well-standardized, repetitive processes can reasonably get one. For example, the booking systems of airlines and travel agents. Organizations that do more fuzzy and always slightly different work will have to make do for many aspects of their work with ad-hoc processes based on various, less integrated tools. For example, consider organizations doing consulting and international collaboration / development assistance: compiling and sending a document will always be a manual task, as activities are never standardized enough for the system to know what information to send to whom.

8. Process manuals

This is a bit like the collaboration technique centered around an information system, but much cheaper, more agile, and applicable to hard-to-automate, ever changing work environments.

Instead of letting computers (and other machines) execute all processes while humans only do data entry, here humans execute the processes according to process manuals. Similar to how an information system is programmed by its software, humans are programmed with process manuals – with the huge benefit that they can understand what they are doing, if necessary adapting manual instructions on the go to unforeseen cases.

To apply this technique in a distributed organization, all your organizational knowledge must be in your manuals. If it’s not there, it should be considered non-existent until it’s there. Do not expect a collaborator to know how to do a certain thing “because she’s accustomed to our organization’s culture by now”.

9. Parallel, not fast

Distributed collaboration provides freedom to choose ones own place and time of work – this is highly valuable and should be preserved. For this reason, use collaboration techniques for urgent, fast work (like “warroom”) sparingly.

To achieve a high output, instead of trying to speed up the work rather parallelize multiple non-urgent work streams. This is where distributed collaboration plays its strengths: because the project context in distributed collaboration is much better documented, switching between projects is quite comfortable and fast for a collaborator, making it possible to work on more projects in parallel. With parallel work streams, the always-present delays and waiting times in the communication and collaboration flow of one project don’t reduce the overall output, as collaborators will switch over to another project until the first one becomes unblocked again.

4. Tools

TODO: Integrate this ideas collection.
  • Online file storage. Should include best practice techniques for file naming that make files findable and re-usable.

  • Collaborative document editing.

  • Distributed financial bookkeeping and controlling.

  • Live calls. Elaborate on this one, as it is the most direct replacement for business travel. Include ways how to make these calls enjoyable experiences (work from the comfort of home, grab a coffee, …). Also elaborate how live calls can replace commuting to office (incl. a comparison of energy efficiency: energy to transfer video feeds vs. energy to transport people.

  • Recordings of voice, screensharing and video.

  • Instant messaging. To motivate people to not abuse instant messaging for content that should go elsewhere, it should not be archived. Old messages would vanish after 2-4 weeks.

  • Online forum.

  • E-mail.

  • Raster graphics software. Proposal: GIMP.

  • Vector graphics software. Proposal: Inkscape.

  • Software issue tracker.

  • Process manuals.

  • Online list management software (Dynalist, Workflowy or similar).

  • Meeting coordination (Doodle etc.).

5. Building distributed organizations

Every organization is different, so the above, rather generic tools and techniques will not fit every organization. As an organization developer, you’ll have to adapt them, or even invent your own. If you do not have an organization developer in your organization, you can also use distributed collaboration among staff to create processes for distributed collaboration. This is necessarily a complex (as in: self-modifying) process, so be prepared that “there will be a mess”. If nothing else, a morbid sense of humor helps to get through that time :smile:

Before you start designing your own tools and techniques for distributed collaboration, some background theory is helpful. The theory is here presented as a collection of design patterns to build processes for distributed collaboration. They sum up the examples of tools and techniques presented earlier, and only that context makes these patterns useful – otherwise they stay in the abstract.

1. Use open standards and open source software

Commercial proprietary solutions that are not based on open standards create vendor lock-in of various kinds, which translate to more friction in distributed collaboration. This is different when using open standards based products, as then there are always multiple tools to choose from, usually including free options and ideally open source options. It is also different for open source software in general, even when it uses its own proprietary file format or communication protocol. This does not create friction, as any collaboration partner can just download and install the tool.


  • Graphics file format interchange. [TODO. In short: PSD and InDesign files are useless for those who don’t have the (expensive) tool to open and modify them. In the case of InDesign, exports to an open source standard format (SVG) are also nearly useless because they contain so many artifacts, object groupings and corner cases that editing these as SVG files with Inkscape is really inefficient and often even crashes the software. Creating everything in SVG from the get-go solves it.]

3. Support Open Source

[TODO: The open source software movement is an exercise in distributed collaboration that, among other things, produces freely available, standards based products for better distributed collaboration. That’s the best type of products to use for distributed collaboration, but you also have to support the movement in order to make this a long-term sustainable solution. You can support open source in many ways: […].]

4. Avoid monopolies. Especially GAFAM.

[TODO: When you can’t avoid a commercial product, at least don’t get it from GAFAM. Sometimes there is no efficient enough open source alternative, and then it makes sense to use a commercial product until there is one. Example: Zoom.]

5. Use conventions

Conventions are agreed-on, voluntarily followed best practices to make collaboration more efficient. They help to cut through the vastly different, ambiguous and redundant ways how humans of different cultures express information. Here are some areas for which an organization should probably have conventions in place:

  • Language of communication.

  • Calendar system.

  • Date format.

  • Time zone format. In our experience, time zone abbreviations (“EST”) or names (“Eastern Standard Time”) are useless, as most recipients will need digital tools to figure out what a meeting time is in their own timezone. Giving multiple times using city names (“Berlin time”) of major cities in the recipients’ area is more intuitive.

  • Time zone use. In truly global distributed organizations, it will be simpler to give all appointment times in UTC, the worldwide standard time zone. Collaborators would then use two clocks in parallel, one displaying local time and one displaying UTC. Where smartphones, tablets or computer screens are used as watches, this is simple to do with small software applications (“widgets”).

  • [TODO]

6. Standardize

Standards are different from conventions in that conventions are voluntarily followed best practices but standards are enforced in the organization. Use this more drastic measure more sparingly to preserve individual freedoms . But definitely use them where the benefits outweigh the price to pay (which is, fewer degrees of freedom). Examples include:

  • Software development technologies. There is a large amount of redundancy between competing software technologies: many of them do exactly the same, but in a different way. And mastering a new programming language, framework, package manager or other programming tool always is a major amount of “unproductive” time. So by all means possible, make sure that the different software tools that you develop or modify in your organization use the same technologies as much as possible. It does not matter for software that you will only install but never adapt in your organization.

  • [TODO: Complete the list of examples.]

7. Use agile design principles

[TODO: List and explain the 10 principles of agile design in manufacturing. This comes from industry, but will also help eliminating friction in any form of collaboration.]

8. Eliminate wait states

Waiting for required input from another party is the worst possible friction of collaboration in general. This might be especially true for distributed collaboration: wait times might be longer here, as the lack of presence and interaction provides fewer cues that would serve as reminders to get something done in time.

[TODO: Refer the great example of Xtreme Collaboration invented at NASA, which was very effective at eliminating wait states. It required minimal presence: one afternoon in a warroom environment, and multiple weeks of distributed collaboration before that.]

9. Educate remote collaboration experts

This manual might seem like a long collection of rules to follow. That is not the case: these are best practices that one would follow voluntarily in order to (collectively) unlock great, enjoyable distributed collaboration in an organization. They will only appear as rules to those who don’t understand why these are the best practices – that is, to the novice.

So to support voluntary and enthusiastic adoption of these best practices, invest into educating all collaborators of the organization to become more and more experts in distributed collaboration.

One added benefit is: the expert is somebody who can break the rules. Because the expert knows what will happen when doing that, they can achieve efficiencies beyond what rules can make possible. Because rules are always oversimplifying and generalizing, leaving some latent efficiency untapped. And if only efficiency in worktime by knowing when it’s ok to cut corners and be more sloppy in applying “the rules”.

[TODO: Give examples of how experts can break the rules.]

10. Hack your tools

Hacking means using a product beyond what it was originally designed and made for. Often, hacks are a combination of small changes to the technology and conventions on how to use it. A usage convention for software can itself be a hack.

Such hacks make changes to software tools cheaper and faster. Adapting software to an organization’s needs is difficult (for open source software) to impossible (for commercial products). It requires access to the source code, technical expertise in the particular software development stack that the tool uses, takes time and patience and repeated testing, and it can become expensive. Hacks are cheaper and faster and often provide a good enough solution, or at least a way to test a new function before deciding to get it properly implemented or not.


  • TODO markers. Let’s say your online forum software does not have a feature to create tasks for editors or for your future self to a draft text. A hack to “create” this feature is simply to start each to-do item with a marker string only used for that purpose, such as “@TODO”. This way, you can get a good overview by searching for that string in the document – the web browser will show how many to-do items are there and let you navigate through them with the “Find Next” function (often on F3). At least Chrome also shows where the to-do items are found, by means of small colored lines in the scrollbar. And when you add attention-catching formatting to the to-do items, such as red text color, you have a quick way of visually navigating between to-do items by scrolling through the document.

  • Table of Contents. [TODO]

  • [TODO]

11. How to choose a collaboration tool

Know the price. Every new tool that you introduce to your organization creates long-term obligations for user support, security updates and other updates and possibly paying for necessary extensions. Not to mention licence costs in case of commercial tools. So, choose your tools wisely, and limit the number of tools. Before settling for a completely new, standalone tool, check if any of your existing tools can be extended with a plugin or hack (see above).

Dealing with friction between tools. Another disadvantage of too many tools is that it becomes impossible to have an integrated, coherent communication. There is always friction when bringing different tools together. For example, there will not be a search function that looks through both a forum and chat platform – such friction is acceptable only if a new tool is still a net benefit when adding it to your existing toolkit. But when you already have 100 collaboration tools around, every new tool will be so similar to an existing one that the added friction will outweigh its benefits.

12. Have a central platform

Preferably, one of the tools would be the central communication platform, and the other tools the periphery. At Edgeryders, we use Discourse as our central platform, and we love it for that purpose.

13. How to introduce a collaboration tool

Once you found a tool to solve a collaboration challenge, your challenge is to get people to use it, and to use it properly. We made experience that patience pays off. It took us about six months to introduce our own instant messaging platform, during which time we had to constantly remind our collaborators to not use Facebook Messenger, WhatsApp etc. and also to not abuse our chat platform for long-form or complex content, which should rather go into our existing forum.

14. Get your incentives right

Efficient distributed collaboration requires certain behaviors that provide no immediate, personal benefit and thus often need extra encouragement.

For example, most people hate writing or maintaining documentation for this reason. In response, you could either try to find and hire the rare person who loves writing documentation, or experiment with incentives. For example, Stack Overflow pioneered a type of Q&A sites where documentation authors are rewarded with “reputation”. They also offer this as an internal tool for organizations, and it might be a the right tool for some types of larger organizations.

1 Like

This rocks already :slight_smile:.

1 Like