📗 Distributed Collaboration Manual (DRAFT)

This is a draft version of our manual for spatially 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

3. Collaboration

4. Socializing

5. Tools

6. Building distributed organizations

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 to this open source project. However you obtained it, the most recent version is always a wiki on edgeryders.eu. After opening a (free) account on the edgeryders.eu platform, you can join the discussion thread below that wiki, adding your feedback, reports of problems with the document, or proposed additions. If you feel confident about your contribution, you can also directly contribute it by editing the wiki. The wiki uses Discourse flavoured Markdown for formatting, 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.

1.2. Editorial overview

Welcome to the distributed collaboration manual created as a distributed collaboration. :blush: To give you a smooth start, this section shows the relevance of and connections between the tips and techniques (“patterns”) that appear in seemingly random order in the rest of this document.

What is in it for you? This manual wants to make your distributed work smooth, enjoyable and efficient. Smooth and enjoyable collaboration is a group exercise, you cannot solve it on your own: you will learn how to make your colleague’s experience smooth and enjoyable, which is basically about “being a good citizen” of your organization. Your colleagues will (hopefully!) reciprocate the same to you, and this is how your own work experience becomes smooth and enjoyable. We explore this aspect in more detail in section “The secret of enjoyable distributed work”. A good part of this is the insight how values work: even if it does not profit you personally in the moment, you can still aspire to follow high standards in your collaboration because you anticipate the beauty of the system you’re part of building this way. Admiration for beauty is food for the soul …

On business trips. Let’s say you have a trans-Atlantic business trip coming up but because it’s only 2020 and electric and biogas powered climate-neutral jets are still a matter of the future, you rather want to avoid it if possible. To determine if the trip is necessary at all, we have some tips in our Green Travel Manual, a separate document. and avoid it if possible. And section “Tips for calls” will contain useful knowledge about how to replace that trip – also see “Tips for conference calls” to replace meetings with groups of people.

Advantages of distributed collaboration, and how to unlock them. Calls may not be as pleasant or rich of an experience compared to meeting in person. However, other aspects of distributed collaboration can compensate for that as they can be more enjoyable than long (and often boring) business meetings. In our organization we discovered that asynchronous communication techniques provide many enjoyable freedoms that calls and meetings can never provide: you choose time and place and pace of your work, when to have a break, and interruptions by your cat :cat2: or partner won’t matter at all (if you don’t mind). It will take some time to “get this right” with your colleagues because there is no formal education about this kind of work yet, anywhere. You probably have the tools for it already: more or less any shared file hosting, any chat and any online forum tool will do. When dealing with product development, an issue tracker is also helpful. The challenge is more how to use these tools so that both you and your colleagues will love this way of working. At this point, we recommend you read about “The secret of enjoyable distributed work”: it sets the stage by showing the social dynamics of lovable and horrendous digital work environments. It’s strong stuff, but not meant to discourage you. And we (Edgeryders) are also still far from perfect in following the value-driven approach presented there.

Getting into asynchronous collaboration. Asynchronous work is not enjoyable by default, so to help you get there we gathered our best practices, sharing them with you below (see the “Communication” and “Collaboration” chapters). There is also a whole chapter “Socializing” dedicated to practices that focus on social interaction at work rather than on efficiency. Please consider this a starter kit only – welcome to contribute your own tips.

  Before you dive into all the tips and tricks, remember that best practices here are social: you can’t make your own experience of distributed collaboration enjoyable, but only that of your co-workers, and vice versa.

 Some of the best practices are simple common sense, such as being “Clear, precise, complete” when it comes to communicating – and mind you, you can not not communicate. Other practices are less obviously valuable, but quite powerful: a combination of pull-based communication systematic, beautiful filenames with no data redundancy and with an effort to anticipate where your colleagues will look for the data you want to dump is, taken together, a surefire way to make shared folders an enjoyable tool to use. And maybe that’s a good strategy to beautify distributed work: make one tool enjoyable, only then care about another.

Zen level: a fully distributed organization. The chapters about communication, collaboration and tools show how to use existing tools and processes for more enjoyable distributed work. Now if you are in the lucky position to have some control over the organization’s processes and tools, you can and should go further. Over time, you can modify the organization so that “being distributed” is embedded into the organization’s DNA. With that in place, much of the friction in internal and external collaboration will fade. On top, the organization will be part of the avant-garde: the new wave of organizations adapted for a low-carbon future. Plus, you can harvest additional benefits like space efficiency, cost reduction and work / life integration. We cover some of this in the last chapter, “Building distributed organizations”.

1.3. Reasons for and against distributed work


1.4. The secret of enjoyable distributed work

How bad work habits are self-stable. Distributed work is a chicken-and-egg problem: as long as it is unenjoyable and unrewarding for themselves, workers are not motivated to put in the extra effort to make it enjoyable and rewarding for their co-workers. That extra effort refers to best practices of communication and collaboration, as described at length in this manual. As a result, the dismal and inefficient nature of distributed work can be a long-term stable condition in an organization. Even short-term investments of the required extra work by one or some workers does not change it: a bit of investment after years of malpractice does not immediately make distributed work enjoyable for everyone, and also making the mental shift towards investing the extra effort themselves takes time. [TODO: There are probably better concepts of metaphors to describe this in social sciences.]

The importance of values. We saw that the necessary condition to move towards enjoyable, efficient distributed work is this: that some of the workers make it an unconditional priority that working with them in a distributed way is enjoyable for their co-workers. An unconditional priority is a moral or professional value. There may be good reasons to have a certain value, but these cannot include a “return on investment” for the individual practicing that value – because that would make it conditional again, unfit to break the self-stable nature of unenjoyable distributed work.

Working like a humble servant. The question remains: Why should I pick up a value that may not pay off for myself, in my lifetime? We can find answers in monastic traditions – independent of the religion, monks and nuns understand how and why to provide an enjoyable environment for each other, just the same thing that we want in digital workspaces and work culture.

  In our organization, we have looked in some detail into monastic practices, as part of a communal living and social innovation space called “unMonastery” – the space it was not religious, but deeply inspired by the rules and best practices of monastic communal living. What we found was the exaltation of service to the community: this is the secret of monastic living. Imagine two monks gardening in a Benedictine monastery, tending to pretty flowers and nutritious plants. What motivates them to do this well, year after year, with no wage at all? It’s not about producing flowers and food, it is about creating the environment for their brethren’s spiritual journey to be successful. The monks need healthy food and restful spaces to tend to their bodies and souls. Every time a monk takes a mouthful of food, he or she is eating the embodied service of fellow monks to them. Every time a monk admires the cloister’s garden, or the monastery’s architecture, he or she is gazing at the embodied work of other monks, most of which are dead for centuries. There is no higher work than that which survives the passing of the worker. By holding up the monastic community, and ultimately God, as the higher purpose within which personal service finds its fulfillment, the monastic community also becomes a self-stable enjoyable environment. There is almost permanent individual gratification by not pursuing individual gratification but instead serving The Whole. When The Whole works well, it also goes well for the individuals. But a group of individuals will never get to that place when valuing their own immediate well-being before that of The Whole.

Practicing the secret. We discovered which mindset can make distributed collaboration (or any collaboration, for that matter) an enjoyable experience for everyone. It’s basically the Golden Rule, “the principle of treating others as you want to be treated”. But how can we encourage that mindset in an organization? Ultimately every organization will have to find its own path here. Here are some inspirations, and you are very welcome to add your own in the comments:

  • Lead by example. A core group of collaborators who internalized this “secret” can decide to show its benefits by example. This is much better than starting alone, as every member of that core group can already see glimpses of the enjoyable work environment whenever they are “digitally treated well” by their co-workers in distributed collaboration.

  • Provide time to appreciate organizational beauty. The appreciation of beauty is perhaps the best way how humans can understand and internalize values that pay off only in communal terms. You could provide space and time in your organization for all workers to visit or explore value-driven organizations like monasteries or post-capitalist companies that thrive in distributed collaboration. Ideally these would be extended site visits so that the experience can sink in, but documentaries or books can also be good mediums, depending on the person. Once members in the organization realize that “it would make a beautiful workplace / society / country / world if everyone adhered to this value”, you are already close to the goal.

  • Organization-building with memes? The Golden Rule and everything said above stays abstract theory until you find ways to express and embody it in the context of your organization. The Golden Rule applied to data is basically “Whatever you do with data, do it in such a way that other people don’t inherit your mess but have a good time navigating and using your data, the same way you would like to find and use others’ data.” If memes are a thing in your organization, you can totally meme-ify the Golden Rule for Data and see if that helps.

  • Hire a wizard. In our organization, we are glad to have @johncoate as our “wizard” of community building. If you can find one, hire a wizard for distributed collaboration. A wizard is a person of calm natural authority and extensive wisdom in their area, not afraid to share that wisdom with others whether they want or do not want to hear it at the time. The wizard may take on some roles in projects of the organization, but mostly to analyze and understand the pitfalls of the current work culture. He or she would then influence tools, practices and processes to improve that, both via formal and informal (trust based) channels. It will only work when you give your wizard a lot of freedom to do their magic.

  • Introduce best practices. The Golden Rule for Data is still abstract, and nobody will be able to immediately see all that it entails for their day-to-day digital communication and collaboration. For that reason, a set of best practices is the second and last essential ingredient for enjoyable distributed work. We provide our own collection of best practices in the remainder of this document, and you are welcome to mix and match them with your own and use them in your organization.

2. Communication

Our “educated guess” as distributed organization of 7 years is that 70% of the efficiency and enjoyability of remote works comes from good 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. 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.

2.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 to express what they have to say. This is especially valuable in a professional context and even a selection criterion when hiring (“presentation skills”, “fluent English” etc.).

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

As a (somewhat specialized) example, let’s look at what makes a good problem report about a software issue, either to customer support or to the developers:

  • what you were trying to do, step by step
  • what you expected to happen
  • what happened instead
  • if and to what extent the issue is reproducible
  • exact text of error messages or logfile entries
  • additional diagnostic insights from verbose logging, debugger use, core dumps etc., if you have
  • workarounds, if you found any
  • proposals for how to fix the issue, if you have
  • version of the software you are using
  • version of software dependencies like browser and operating system

This is not meant as instructions but to sensitize you to the problem; namely that “dear devs, please improve the general user experience” is not a complete or actionable problem report :slightly_smiling_face: For more detailed techniques for clear digital communication, see further below in this list.

[TODO: Reference a good, well-known short book about clear, short, precise writing in English.]

2.2. Minimize the receiver’s work

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

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

2.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.]

2.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!]

2.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.]

2.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.]

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


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

2.10. Add reasonable formatting

Text formatting is not just eye candy – a good visual and logical structure is rather the “user interface” of your text. As with software applications, a good user interface supports navigation, and a bad user interface inhibits it. Supporting “navigation” in a text means to provide adequate visual cues for a reader to be able to skim through the text – which means, getting all the important points and where to find them again in 10% of the time it would take to read everything.

There are a thousand ways to build a user interface, and text formatting is no exception. However, here are some best practices to support skimming, with the limited formatting options of Markdown:

  • Obvious heading structure. After jumping to any random location of the document, a reader should be able to determine if they are in a chapter, sub-chapter or sub-sub-chapter, from just looking at the nearest heading. The simplest way to achieve this is to preface every heading with a chapter numbering using decimal classification such as “1.”, “1.2.”, “1.2.1.” and so on.

  • Table of Contents. To get a quick overview of a document’s content, a ToC is one of the simplest and most effective ways. Hyperlink the ToC entries to the chapters, if possible. A ToC becomes even more useful when you take care to formulate your headings with a system. For example, this very document has three chapters where the naming scheme is “one word that describes a class of things”: “Communication”, “Collaboration”, “Tools”. That makes it simple to infer that these chapters probably have a similar sub-structuring, and once that is understood, navigating the whole document becomes much simpler because the reader can make an educated guess what to find where. Compare that to a case where the top-level chapters have random, confusing, wordy names:

     1. Abstract
     2. Communication skills are the manners of the Digital Millenium
     3. Techniques for Distributed Collaboration
     4. Let’s now select the right software
     5. Modifying the whole organization

  • No formatting without a style. Most word processing software allows to create custom formatting styles, which makes formatting text semantic. You could for example create a character style called “line header” and the software would make sure that it looks the same whenever you apply it. A reader will recognize such recurring formatting and learn from these examples about the role you use it for, which again helps the reader to navigate the text – by reading only the line headers while skimming, for example. In simpler software such as online forums, custom styles are usually not available, but you can make sure by yourself to use formatting options in a consistent way. In this document for example, all line headers such as at the start of this paragraph are simply formatted with bold print.

2.11. Use systematic, beautiful filenames

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

[TODO: A complete manual for naming files.]

2.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]

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

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

2.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.]

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

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

2.18. Healty calls

[TODO: When to use calls, when not.]

[TODO: Tips when inside a call.]

2.19. Healthy conference calls

[TODO: When to use conference calls, when not.]

When inside a conference call, here is a list of tips to make it an enjoyable experience for everyone. All the tips for calls apply as well, but there are additional tips specifically for group calls:

  • Conference calls are a listening exercise. In this way, they are no different than healthy in-person meetings: in a call with 10 people, mathematically everyone has 10% of speaking time and 90% of listening time. When that ratio becomes skewed too much for some speakers, the call is very likely not productive. Some people naturally like to speak a lot and may not notice they are cornering the other participants – a software tool that calculates and shows the speaker time percentage in real-time may help. It could show that privately to each speaker, or as a public list to the whole audience, providing an interesting cue for healthy communication. We did not yet find such a tool.

  • Mic off when not speaking. This is probably something that everyone learned by now about conference calls with more than three or four participants: unmute yourself when you’re speaking, and mute yourself again afterwards to spare everyone your background noise. Still, people regularly forget one of the two; a PTT (push-to-talk) functionality in a video conferencing application would solve this, but we are not aware of any tool that can do this.

  • Cameras on. Depending on the type of call, asking everyone to switch their camera on can be useful to provide additional social cues. For example, a team leader may find it helpful to check in on the wellbeing of their team in a weekly call. (contributed by: Lisa, here)

  • Cameras off. The freedom to keep ones camera off is also valuable, and often the “not so social” people prefer it as their default. In internal team calls where at least some people participate as listeners (“for peripheral awareness”) rather than actively most of the time, “cameras off” is a good option as it gives additional comfort and freedoms to participants. It makes it ok to answer the door, to grab a coffee, to take a phone call in parallel, to answer e-mails, to have a short talk with a flatmate or colleague when necessary, and similar relaxations compared to in-person group meetings. The important aspect is to use these freedoms for efficiency, not for hiding ones complete non-participation. In the latter case, the problem is rather that the organization is forcing people to be on calls for no reason at all.

  • Finger up gesture. The gesture of sticking up a finger in a video call can be used to indicate that you want to speak but not interrupt the current speaker. It still gives the current speaker a good cue like “if in doubt, please keep your contribution short”. (contributed by: Lisa, here)

  • OK gesture. Similarly, showing the “OK” gesture with thumb and index finger (:ok_hand:) can be used to show silent approval of what somebody said, and also to give a silent affirmative answer to a question. For example, asking for remaining questions before ending the call can be done in a nice way that does not result in awkward silence: “Does anyone have a further question for the group, or are you all ok now?”

  • Moderator role. Depending on the context and occasion of the call, in any group call with more than 4-8 participants one of them should hold a moderator role.

  • The chat is your friend. Most video conferencing tools provide a side channel text chat, both for the whole group and pairwise between participants. This is an additional communication channel that can be used to partially overcome the narrow bandwidth of group meetings aka “only one speaker at a time”. For larger conference calls such as webinars or brainstorming sessions, it makes sense to even assign a separate moderator to the chat, in addition to the video call moderator. That moderator would relay questions to other speakers at the right moment, would gather input for a written protocol / transcript etc…

2.20. Auto-correct reading mode

Understanding communication is mental work. Even with all the best practices collected in this manual, it will remain an effort, in part because communication will always be imperfect: people will be tired, make spelling mistakes, have and express unclear thoughts, forget to include links, apply messy formatting and so on.

Here, active reading with a kind of mental auto-correct mode helps to reduce the delays of back-and-forth communication. For example: instead of asking back what an unclear sentence means and waiting two hours for the answer, two minutes of going through the paragraph in detail and trying to find and follow its internal logic may already solve the mystery.

When this is about written communication within a whole group, such as in an online forum, it makes sense to then just edit the original author’s contribution by fixing the mistakes. Even just fixing spelling mistakes or messy formatting or adding missing links will reduce the work of understanding of everyone who has to read this afterwards. In our organization, we practice this informally to various degrees in our Discourse forum, supported by automatic edit notifications. This way, the original author can catch the rare case of disimprovement edits – where the edit does not express what they wanted to say.

3. Collaboration

The last chapter dealt with the basics of digital communication: how to use the digital tool at hand in the best possible way? Now this chapter goes a step further, dealing with collaboration, the coordinated action to get stuff done.

Collaboration always involves multiple processes and tools, which together form an interface of a worker, both to other workers and to the organization. The challenge is to select the interface adequately, suiting both the task at hand, the timeframe, the organization and the worker’s personality. Collaborators in an organization can have different interfaces, but it is a good idea to have overlapping elements that apply to all (such as instant messaging). Also note that the chosen interface in turn shapes the style and results of somebody’s the work.

The sub-chapters below discuss multiple best practices for these collaboration interfaces. Which one 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 distributed collaboration in sight, anywhere. In general, choose the most narrow interface that is suitable for a person’s role and personality: fewer tools equate to less coordination overhead and better self-organization on the collaborator’s end.

3.1. Issue tracker plus coordinator

Issue trackers have been developed for managing software development, esp. related to bugs (“issues”). Software development is basically always an exercise in distributed collaboration between software users and developers.

In addition, issue trackers work 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.

With respect to personal suitability, we found that structures people (“people who love lists”) who do not crave human interaction much are good candidates for using an issue tracker as their main “interface” in a distributed organization. It can provide a well-structured, stress-free job of just working through the issue list, always picking the most pressing issue next. There are no calls or meetings to attend, so it is also very suitable for digital nomads.

3.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.3. Agile development


3.4. Project management wiki


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

3.6. Coordinator role


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

3.8. Process manuals

This is a bit like the technique of collaborating via 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.

This technique is not easy to apply in practice because in general, people hate to RTFM (“read the friendly manual”). However, the following tips will help:

  • Write it all down. Do not expect a collaborator to know how to do a certain thing “because she’s accustomed to our organization’s culture by now”. Rather all your organizational knowledge must be in your manuals. If it’s not there, it should be considered non-existent and your collaborators are right to say that they “don’t know how to do this”.

  • Onboarding course. People hate reading manuals end-to-end, but there is one moment when an organization can successfully make them do it: when they want to get the job. So after accepting a candidate they would go through a short, week-long paid test period, with an “entry exam” at the end. The entry exam can be a multiple choice form with automatic evaluation, where their knowledge of the company processes is checked upon in detail. They would have any amount of time to finish the form, so that they can go to the manuals and look for the relevant information. That hopefully will create a habit that the will stick to later.

  • Answer with links. People will still ask a lot of questions to IT support and other colleagues that have answers in the manuals – it’s just less effort. But now, the answer can consist of a link to the right manual section and a friendly reminder like “Did you try to find it in the manual yourself? Do you know why you didn’t find it there, so that we can improve our manual structure for the future?”. After about six months of this strategy, looking into the manual first will become a habit for most regular collaborators in the organization – at least that’s what we observed when trying to implant similar habits in our organization.

3.9. Parallel, not fast

Delays are the single biggest annoyance in distributed collaboration, and even after doing your best to eliminate them, there will always be delays. In part, these delays are inherent in the use of tools for asynchronous communication, and part they result from people using their freedoms to work “whenever, wherever”. These freedoms are however highly valuable and should be preserved – in part, they compensate workers for the partial loss of social interaction.

In total, distributed collaboration is just not good at “fast” in the “fast, good, cheap” triangle. As the saying goes: you can choose any two, and for distributed collaboration it would be “good” and “cheap”. This means you should avoid ever doing time-critical, tight-deadline work in a distributed organization. If you really have to do that, there are some collaboration techniques that support urgent, fast work (like “warroom”) sparingly. But it curtails collaborator freedoms, so us these sparingly.

To achieve a high output, the better alternative to speeding up the work is to 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. Socializing

We included tips to make distributed work practices more social into the patterns mentioned under “Communication” and “Collaboration”; see for example “Healthy conference calls”. This chapter however is about techniques that focus on socializing and not on productivity and efficiency. In the short term, they may be less productive than not-so-social techniques. Why would we still want them? Humans are social animals – by varying degree of course, but averaged over a whole workforce it’s safe to say that making everyone work in isolation all day long is torture.

Socializing in the office. The socializing aspect of office culture is well established: you can meet at the watercooler or coffee machine for a chat with your colleagues etc… In literature about workforce management, it is also established knowledge that 20-25% of daily worktime should be deducted for “non-productive” activities like socializing in the office and toilet breaks. Still, that time is paid as worktime. It seems that there is a general understanding that, for humans, “working at 100%” must include these kind of activities to be a long-term sustainable way of working. They are only superficially “non-productive”. For short times though, they can be avoided, resulting in work output of more than 100% for a matter of hours or days – it’s just not sustainable or healthy when done on the long term. [TODO: Add a source for this from management literature.]

Why is socializing neglected in distributed work? Unlike in the office, when working remotely there is no watercooler, coffee machine or other social hotspot for meeting your colleagues. It is not too clear why this is the case: Does management consciously or unconsciously consider these activities still as “unproductive”, now using distributed work practices as a new way to eliminate socializing at work? Or does work culture develop at such a slow pace that it simply has not yet invented the equivalent of a coffee machine for remote work? Or maybe even the coffee machine at work has never been a conscious exercise to support socializing, so that we have a hard time putting the finger on the problem of distributed work practices being anti-social? We will now leave these interesting questions to the social scientists (and to you, if you like to think about them) and move on to solutions … :blush:

The economic impacts of socializing. Making paid worktime available for socializing activities at first sounds like it will negatively impact the financial standing of an organization. However, it is not that simple: if people spend 10% of their time socializing at work it does not mean that they will now take (100%)/(100%-10%) = 111% of time to get 100% of their work done. They might get good tips or discover other synergies with co-workers while socializing with them. They might also be happier and more motivated at work, increasing their productivity. They might also have ideas with their co-workers while socializing that generate lots of additional revenue for the company down the line. So in total, allowing for “paid socializing” may even have a positive financial impact, but it’s very difficult to measure. To cut through this, an organization should just decide to support paid socializing because it makes everyone happier and “probably” has no significant impact on the bottom line. After some experimentation, practice will show what forms of socializing are more “productive”, and then the company can focus on supporting these.

Warning: this is experimental. The following list provides ideas how to use existing tools in more socially rich ways. This list is much more experimental than the lists of communication and collaboration techniques, as we (Edgeryders) are discovering this area as well. So please be more patient and more careful when trying out these techniques in your organization – some may not work at all, some may require weeks of experimentation to find out the fine points of how to make an idea workable in practice. As always, your additions and your feedback are very welcome!

4.1. Quality time for both work and socializing

Offices mix it all together. In an office setting, the typical approach is to have work and social interaction mixed together all the time, to various degrees. For example, meetings are often used as a more relaxed and slightly fun time compared to individual screen work. Or if a co-worker comes over to your place to ask or discuss a small question, it is often also a bid for your attention to them as a person.

But mixing is inefficient. However, these examples also show how mixing individual work and social interaction leads to inefficiencies: meetings are often boring and last longer than they should because some people enjoy talking and receiving attention. And if your colleague interrupts your flow with their little question for three minutes, you may need an additional 15-30 minutes to finish your work as you’ll need to get back into the flow first.

Let’s not mix, let’s split! Mixing individual work and social interaction no-matter-what is not good practice. Rather, the principle would be to split time at work into “mostly work” and “mostly social” activities, as it makes both more enjoyable and also more valuable for the organization. This is just the basic idea of course, and you will need a good deal of experimentation to find out how to apply this to your organization. The major challenge is to find low-overhead ways for remote workers to socialize at moments when their activities allow for a natural break – basically the digital equivalent of the office’s coffee machine.

Our example. In our organization, even the work in our small office for the core group often looks like the distributed work everyone else in the organization is doing: people staring at screens, not talking at all. At times even using instant messaging with their immediate seat neighbor, to avoid interrupting their flow. That’s quality worktime, as it is uninterrupted and without background noise – it admittedly looks weird, though. In exchange, there are quite some freedoms to socialize during work, usually in the form of extended 1.5-2 hour lunch breaks where nobody insists that people go back to work after the usual one hour break. In total, both the work and the free / unstructured time become more enjoyable. We are however at the beginning of this particular journey ourselves, still experimenting to find the right balance.

About co-working. Working from co-working spaces or cafés is a favourite way for many remote workers to make their work more social. However, this has a limited value for the worker as they will largely share a space with people with whom they do not interact much because they do completely different work for completely different organizations. And it has zero value for the organization itself, as this kind of socializing will hardly result in unexpected ideas, collaborations and synergies that help the organization along.

The following sub-sections of this chapter provide more specific ideas for how to provide quality social time at work in a distributed organization.

4.2. Digital lounge spaces

This is a simple and effective way to open up a space for social interaction in distributed work: simply create a dedicated space for it in the digital tools you use:

  • Chat lounge. Chat or instant messaging tools allow to create separate rooms, and one can be assigned to be the “lounge”. It would be permanently open to chat alongside work, and people probably would share lighthearted and funny things there.

    Naturally, this lounge would be considered internal communications and not be publicly available on the web. Plus, it can be a good idea to automatically delete all messages older than a certain number of days – both to discourage misusing the room for “real work” that should not be forgotten, and to accommodate people who don’t feel comfortable sharing funny or personal stuff when it would go into a permanent record.

  • Forum lounge. An online forum provides a more structured and less ephemeral way of written communication. A lounge space can be created from both a public or an access protected category, and there are benefits to both approaches. To start activities in this forum lounge, you can take inspiration from long-running threads that serve socializing purposed in Internet forums. [TODO: Include examples, with links, for example a “what I built today” thread.]

  • Audio and video lounge. In a video conferencing tool, you can assign a certain room name or room number to be permanently available as “the lounge”. In small organizations, this will probably not be enough for people to bump into each other there, so you can support it further by setting times for organization-wide digital lunch breaks. A lot of ideas can be explored, for example a semi-random grouping of people together into small 3-5 person “table sized” calls during lunch, simulating how people typically meet in the office’s canteen. Compared to chat and forum, video is the most effortless and most socially rich way of social interaction, so if done right it could provide the best socializing experience in a distributed organization.

Simply knowing that non-work-related interaction, even during worktime, is not just ok but encouraged in these spaces by the organization will help collaborators get over the impression that they would provide a public and permanent display of slacking by including non-work activity in work-related digital spaces.

4.3. Pair work

Pair programming was invented as a way to improve software quality but also because programmers felt isolated working just with the machine all day. Later, some programmer text editors added support for real-time collaborative editing (“like Google Docs”), which now allows for remote pair programming. For example, see Atom Teletype.

The principles of pair programming can also be applied to collaborative document writing, in the same room or remotely. This is different – more social – than the typical way how Google Docs is used in organizations. Rather than assigning sections to collaborators and then commenting on each other’s work, two collaborators write their sections together, connected with an audio call, screen sharing and a collaborative real-time editor like Google Docs. As in pair programming, one person will be the lead: only that person will type, but roles can be reversed after some time. The second person will read, give feedback and ideas, propose improvements, research information, and make the occasional direct edit where this is the fastest way to fix something.

4.4. Virtual room extension

You can connect two distant rooms with a permanent video call as follows: put a video projector on one wall of each connected room, and a camera on that same wall, facing the projector. This will make the room appear larger than it is, with people on the other side, separated just with a “glass wall”.

This idea is not suitable for collaborators working from home, but well suitable to connect multiple offices of one organization or to have a large, multi-location party.

To allow people on different sides of this wall to talk in spite of background noise and without disturbing others much, providing several wireless headsets on each side of the video wall seem to be the most practical approach. You can experiment with variations of this idea, for example headsets for one-on-one talks rather than group talk, perhaps placed on a “connected table” that is located at the “virtual glass wall” and extends into both connected rooms.

4.5. Occasional colocation


  • organizational retreats
  • day-long free-flow ideation and talk sessions
  • invitations to each other’s home (if that’s acceptable)
  • multi-week visits or gatherings in a certain city (then also living together with co-workers for that time, which can form a precious bond and mutual understanding that helps to collaborate in the future)

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

    “In our organization (Edgeryders), we subscribe to Zoom, a state-of-the-art video conferencing service. We provide our own manual for Zoom.”

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

  • Voice messaging. This is very useful for people who are not made for written but rather for verbal communication. It is also a faster alternative to instant messaging in text. Not many tools support comfortable voice messaging – WhatsApp does, but might not be the best choice for a tool in a professional setting :smile:

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

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

6.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.]

6.2. 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: […].]

6.3. 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.]

6.4. 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.5. 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.]

6.6. 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.]

6.7. 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.]

6.8. Educate and hire distributed 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 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.]

When you are about to hire new people anyway, it is of course advisable to hire those who are already at an expert level in distributed collaboration. It’s the skill of the future, when air travel will be hopefully highly taxed and rationed. There is no formal qualification in distributed collaboration yet, so when hiring, you will have to check for “proxy indicators”. For example, several years of distributed work experience would be a plus, for example working in customer support or remote IT support. Still, it is hard to know if a candidate is experienced in good or bad work practices of distributed work. So a better indicator could be when somebody has been a regular contributor to amateur open source projects for years. Because here, money is no motivator, and people drop out if they don’t enjoy the work for what it is.

6.9. 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) or 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]

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

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

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

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

6.14. Make your own tools, but sparingly

For cases where you cannot find an existing tool that suits your needs and you also cannot adapt or hack an existing tool to fit your requirements, you can also build you own software tools for use in your organization. This should however be the last option, because it also contributes to tech legacy of an organization:

  • A custom tool will require constant maintenance and adaptation to stay fit for its purpose, to adaptto organizational changes, and to adapt to technological changes of Internet technology.

  • A custom tool has to be of good software quality to actually improve collaboration. If it just supports some custom workflows but with a lot of errors and crashes, it may be better to keep using a generic off-the-shelf tool in spite of its inefficiency.

After you decided to build a custom software tool, its software architecture and design (the choice of technology and exact feature set) is the next challenge. This is not the place to treat this at length, but here are some best practices we found as a small to medium sized businesses:

  • Don’t fracture your IT environment. You want internal IT skills to be re-usable, so standardize the front-end JavaScript framework to use, the CSS framework to use, the serverside programming language and framework, and the mobile application framework and languages.

  • [TODO]

6.15. Become an office-free organization

This is one of the clearest but also most extreme ways to support distributed collaboration in your organization: become a completely virtual, office-free organization.

The idea is here that office-free collaboration is a behavior setting that constantly pushes collaborators towards better practices of distributed work.

In particular: having an office means that working over to a colleague is a more comfortable and slightly faster way to communicate, compared to written communication. Due to that, it will be a default mode of office communication, and it will be hard to root this out. As a result, colleagues who do not work in this office will find the information shared with them in files and in writing incomplete, which makes their own work more frustrating. The same applies when an organization has multiple offices that work together: information sharing between offices will never be complete enough. But when everyone works distributedly by default, everyone has the same incentive to make distributed work efficient and enjoyable.


This rocks already :slight_smile:.

1 Like

@matthias, I really like the work you are doing! I see a lot of gems somewhat buried in the text: “Waiting for required input from another party is the worst possible friction of collaboration”; “Once you found a tool to solve a collaboration challenge, your challenge is to get people to use it, and to use it properly”; " Minimize the receiver’s work". It is going to be a challenge to get it to stand out.

Moreover, I would like to suggest an editorialized intro about the why. Why should people do this? What is in it for them? And the why should be in human terms: serving your org as a community, helping your colleagues to work in a more pleasant and effective way, holding yourself to high standards, because it’s good for the soul.

1 Like

I agree! Added “§ 1.4. The secret of enjoyable distributed work”. I integrated your monastic metaphor from a different thread there. Probably it’s not as much in everyday, human terms as you’d like though … so I think I’ll revisit it later. Or even better, I should add that to the top of “§ 1.2. Editorial overview”.