📗 Distributed Collaboration Manual

[edgeryders]

Edgeryders is now offering a service to get organizations started (or upgraded) with distributed collaboration. Get in touch with @mariaeuler (maria@edgeryders.eu) or @nadia (nadia@edgeryders.eu) if you think you want to use this offer.

Content

1. Introduction

• 1.1. About this manual
• 1.2. Editorial overview   ← Best place to start!
• 1.3. Reasons for and against distributed work
• 1.4. The secret of enjoyable distributed work

2. Communicating

• 2.1. Clear, precise, complete
• 2.2. Minimize the receiver’s work
• 2.3. Pull-based communication
• 2.4. Anticipate and avoid back-and-forth
• 2.5. Find the system, follow the system
• 2.6. Make hyperlinks beautiful
• 2.7. Include the source format
• 2.8. No middleman
• 2.9. Allow for peripheral awareness
• 2.10. Add reasonable formatting
• 2.11. Use systematic, beautiful filenames
• 2.12. No redundancy
• 2.13. Be mindful with others’ attention
• 2.14. Data retrieval empathy
• 2.15. Refactor, fix, optimize
• 2.16. Structure data with hierarchy
• 2.17. Separate urgent and non-urgent communications
• 2.18. Healthy calls
• 2.19. Healthy conference calls
• 2.20. Auto-correct reading mode

3. Collaborating

• 3.1. Issue tracker plus coordinator
• 3.2. Let them work but monitor the progress
• 3.3. Agile development
• 3.4. Project management wiki
• 3.5. Warroom
• 3.6. Coordinator role
• 3.7. Information system
• 3.8. Process manuals
• 3.9. Parallel, not fast

4. Socializing

• 4.1. Quality time for both work and socializing
• 4.2. Digital lounge spaces
• 4.3. Pair work
• 4.4. Virtual room extension
• 4.5. Occasional colocation

5. Tools

• 5.1. E-mail: avoid where possible
• 5.2. Online forum
• 5.3. Shared file storage
• 5.4. Collaborative document editing
• 5.5. Collaborative list management
• 5.6. Calls and instant messaging
• 5.7. Issue tracker
• 5.8. Raster graphics software
• 5.9. Vector graphics software
• 5.10. Financial bookkeeping and controlling
• 5.11. Small utilities

6. Building distributed organizations

• 6.1. Use open standards and open source software
• 6.2. Support Open Source
• 6.3. Avoid monopolies
• 6.4. Use conventions
• 6.5. Standardize
• 6.6. Use agile design principles
• 6.7. Eliminate wait states
• 6.8. Educate and hire distributed collaboration experts
• 6.9. Hack your tools
• 6.10. How to choose a collaboration tool
• 6.11. Have a central platform
• 6.12. How to introduce a collaboration tool
• 6.13. Get your incentives right
• 6.14. Make your own tools, but sparingly
• 6.15. Become an office-free organization

---

1. Introduction

1.1. About this manual

What you’ll find here. This manual documents the knowledge about distributed collaboration (also called “remote work”, “telework”) that we developed in our organization Edgeryders OÜ. We are a distributed organization since our earliest beginnings in 2012, that is, including the time before our 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.

Structure. All chapters past the introduction present their knowledge as a collection of recipes / best practices / patterns. They try to be specific enough to be easily understandable and quickly applicable, but general enough to be relevant for most organizations that have to deal with information management.

Content licence. This is an open source document under a Creative Commons Attribution 4.0 Unported licence (CC-BY 4.0), or at your option any later version.

Acknowledgements. This manual has been created with the funding and support of EIT Climate-KIC, a European climate action organization. EIT Climate-KIC is supported by the European Institute of Technology (EIT), a body of the European Union.

In addition, this manual as an open collaboration project received precious contributions from people in EIT Climate-KIC, the Edgeryders company and community, and from the Internet at large.

This is a wiki. This distributed collaboration manual is itself created by distributed collaborators, and you’re welcome to contribute to this open source project. Being a wiki also means that the content is never truly finished: we keep adding to it and extending it also after the end of the initial funding that made us start this manual. For that reason, you will always find some draft sections and TODO markers throughout the document – and you’re welcome to help us out:

How to contribute. However you obtained this manual, the most recent version is always this 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 that was created with distributed collaboration. 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. Section “Tips for calls” will contain useful knowledge about how to replace that trip. Also see “Tips for conference calls” on how 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 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 “Communicating” and “Collaborating” 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

[TODO]

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.

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 “Provide your data how you want others to provide their data to you.” Whatever you do with data, do it in such a way that other people don’t inherit your mess – but rather have a good time using your data. If memes are a thing in your organization, you can totally meme-ify the Golden Rule for Data in many ways 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. Communicating

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. Your cloud storage account with 100 tebibytes of storage 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. Communication is about coordinating information, 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 For more detailed techniques for clear digital communication, see further below in this list.

2.2. Minimize the receiver’s work

This is a direct application of the Golden Rule for Data (see chapter 1.4.): “Provide your data how you want others to provide their data to you.” Nobody wants to do the extra work resulting from an unclear or incomplete question coming in by e-mail, chat or any other means. So when reaching out to others, it is only fair to avoid any avoidable work for the receiver – in other words, as the sender don’t be lazy.

Let’s look at a few examples:

• Non-activated hyperlinks. Not all tools provide automatic recognition and auto-linking of URLs. For example when writing a HTML e-mail and pasting a URL as plain text, you can’t be sure that the receiver will be able to click on it. Instead, they might have to copy & paste it to their browser’s address bar. That is click work, and “click work is also work” as user interface designers like to say.

• Excess notifications. You can send a long, structured message in two ways in a chat: one paragraph per message, or all paragraphs in one message. The first one creates excess notifications, and looking up notifications is work.

2.3. Pull-based communication

Time spent on back-and-forth communication, and the delays introduced 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

This refers to anticipating responses and difficulties of your communication and solving them already before sending off your communication. This prevents delays and endless back-and-forth communication, which are the worst and most annoying properties that remote work can have.

For example, there is a tendency to use e-mail for very short messages, esp. inside organizations. Each cycle of message exchange induces delays that are at least 1-2 orders of magnitude larger than actually writing the messages. So a better way to use e-mails is like snail mail letters to a pen pal: anticipate what they will say and answer that as well, because this way you will make 2-3 steps of progress with each exchange of e-mails. Instead of half a step because of unclear communication about a single step. There are more details about this example in a topic in our forum.

2.5. Find the system, follow the system

In the ideal case, there should be a system for every aspect of how to organize the data of an organization. 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!

So when you want to add more data to a collection of existing data, your default expectation should be that “there must be a system”. With that expectation, go looking for the system: it might not be documented explicitly, but you can infer it from looking at the existing data in the collection. For example, file names. And then, just follow the same system when adding your data, because anything else would mess things up.

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, comments in Google Docs, Github README files etc… 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

  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
    📗 Distributed Collaboration Manual

    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:

    Climate is missing the point. We have an ecosystem emergency. | by Will Marshall | Medium
    Climate is missing the point. We have an ecosystem emergency. | by Will Marshall | Medium
    Climate is missing the point. We have an ecosystem emergency. | by Will Marshall | Medium
    Climate is missing the point. We have an ecosystem emergency. | by Will Marshall | Medium

    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 ):

    https://www.google.com/search?source=hp&ei=kde1XeTRLI_WwQLTrJmwBw&q=enter+google+into+google&oq=enter+google+into+goo&gs_l=psy-ab.3.0.33i22i29i30l2.1617.13458…14715…2.0…0.89.2401.39…0…1…gws-wiz…0…0j0i22i30.hKIP_UZevZY

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

    enter google into google - Google Suche

2.7. Include the source format

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.

Avoid middlemen wherever possible. For example, don’t let one person in your organization collect and relay requirements for a design contract that your organization wants to hand to a third party. Instead, invite the contractor to join your online forum, Slack channel or similar and discuss with the relevant people in your organization directly.

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 “a single word for a class of activities”: “Communicating”, “Collaborating”, “Socializing”. 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.

• Paragraphs, not line breaks. A paragraph is basically a line break plus a small vertical gap separating it from the previous block of text. That gap helps in visual navigation, as it allows to jump between cohesive units of content more quickly. To create a paragraph in plain text or Markdown, use an empty line between blocks of texts. In other word processing software, just don’t press Shift + Return because that’s how linebreaks are made. Press Return instead.

2.11. Use systematic, beautiful filenames

(Source: xkcd 1459, licensed under CC-NC 2.5. See it also at explain xkcd)

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.

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. Use cross-references. Ideally, your word processor or editor will be able to insert hyperlinks with auto-updated chapter numbers and names. However, cross-references can also make a document hard to read, as it is no longer “mostly linear”. A good content structure is the best way to avoid excessive hyperlinks.

• In source code. Usually you would better create a new function (instead of copying inside your own program) or library (instead of copying between programs). More complex techniques can be found in software design patterns (take the well-known “Gang of Four” book as an example here).

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 and should be recognizable as such. See below for example filenames:

  WebsiteInfographic.V01.svg
  WebsiteInfographic.V01.Export.HighQuality.jpg
  WebsiteInfographic.V01.Export.WebQuality.jpg
  WebsiteInfographic.V02.svg
  WebsiteInfographic.V03.svg
  WebsiteInfographic.V03.Export.WebQuality.jpg
  ...
  

• Make redundancy temporary. Let’s say you have to prepare a selection of 10 out of 100 files that should be sent off as a print job to an offset printing company by a colleague. Instead of sending 10 filenames or a verbose description of how to select the 10 files inside their folder, it will be much simpler for your colleague if you just create a new folder with copies of these 10 files inside. Then call it “Print_Job_2019-12-30_(COPIES_ONLY,_DELETE_AFTER_USE)” or similar to clearly indicate that this is redundant stuff for a specific purpose and that the redundancy should be fixed once that purpose is fulfilled.

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 a single 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), 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.

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

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. Healthy calls

[TODO]

2.19. Healthy conference calls

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 () 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. Collaborating

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 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. General project management which is the basis to then create feature request issues, their deadlines, and to assign them to developers.

• Issue descriptions. Describing each issue in such a way that the developer can get it done without any follow-up questions. This is very different from how issue descriptions typically come in from users.

• Issue assignees. Distributing the work between the developers, based on availability and skills.

• Issue deadlines. These would depend on project work deadlines.

• 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. Once an issue is done, the bugfix or feature needs to be tested.

• Documentation. Most developers hate to end user write documentation for their software, but the coordinator can take this on when there is time. Even a little documentation goes a long way.

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

[TODO]

3.4. Project management wiki

[TODO]

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

[TODO]

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.

• Onboarding Plan. Each team should have an onboarding plan template that spans at least 2 weeks for new team members. This should outline the minimum of personal calls and interactions and formulate the most important start information your new team member needs. Give it some thought on how to schedule multiple interactions and how to structure the information that you give to your new team member. Even so, you should have a comprehensive manual somewhere and introduce your new colleague to that, o always only address around 3 new pieces of information in one of those distributed information packages.

• Personal Connection Calls. Schedule a 30-60 min personal connection call for new team members at least with their core collaborators and one with the whole team. The goal of those calls is not to get any work done or to explain the structures, but just to communicate the role of each person in the team and to get some background information about the skills and personality of your colleagues. Scheduling and realizing these calls will take up a lot of time in the first few weeks for a new team member and also need time commitment from the colleagues, but in the long run, it will make the collaboration a lot smoother. Make clear that these are not job interviews or evaluations, but save spaces to connect.

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

A bit of trivia about wolves

Most people know that wolves are social animals as well – after all, dogs are basically small wolves, and they are definitely social. But there is also the story of the “lone wolf”: the rare lupine sociopath, preferring to live and hunt alone. It turns out that this is a myth: “lone wolves” are just adults looking for a mate with whom to start their own pack. And packs of wolves are just multi-generational wolf households. And “alpha male” and “alpha female” wolves are just the oldest wolves of the pack, the parents who started it all. Given how much the “alpha wolf” metaphor has been used to justify strictly hierarchical human relationships, it’s high time to spread how authority actually works among wolves!

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.

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 …

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.

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.

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.

• 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 got support for real-time collaborative editing, the feature you know from Google Docs. For example, Atom Teletype. This means that remote pair programming is possible now.

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

By spending time together at the same place rarely but then for extended periods of time, you avoid 90-95% of business travel and commuting, which is 90-95% of the solution to its greenhouse gas emissions. The benefits of socializing for an extended time last for quite some time into the future, as it allows to establish “rapport” with each other, a deeper sense of understanding, interpreting and anticipating each other’s behavior and communication. By including more intense and unusual formats from the list below, that rapport can even go much beyond what co-workers in a typical office setting can have.

A list of ideas for how to do “occasional colocation” follows – most of these ideas we tried in our organization, but some are just ideas so far:

• Presence time. Temporarily requiring the physical presence of one or some colleagues in the offices of an otherwise distributed company can be very useful. Uses include: “acclimating” or “re-syncing” these collaborators with the processes and events in the organization; coping with a time of intense workload; and assisting people who struggle with self-organization when working only remotely. In the latter case, the organization might require 20-50% of presence time, for example one fixed day per week in case the colleague lives in the same city anyway.

• Guestroom. When the organization provides one or more guestrooms at its office location or very close to it, it greatly facilitates the “presence time” technique above, and collaborators can also stay around for some time when traveling through the city anyway or being present for an unrelated reason. Ideally, the guestroom would be permanently paid for by the company, or would be available as an unused part of the office. Then, cost and budgets do not have to be considered at all when inviting somebody to stay. When not in use, the guestroom can be rented out on platforms for short-term accommodation, like AirBnB.

• Retreat. The whole organization or a core group travels to a nice house in the countryside somewhere and lives together for 5-7 days while also having a lot of meetings, discussions and unplanned time together.

• Walking retreat. Like a retreat, but organized as a light hiking trip with 4-6 hours of walking per day plus an extensive lunch break. Walking is a natural way to have conversations in sub-groups of 2-4 people in ever-varying configurations and with natural privacy provided by distance to the rest of the group.

• Coworking with coworkers. If colleagues in a distributed organization happen to be in the same city, at least for a time, it’s a good opportunity to share time together. Even where that means mostly mostly working alongside each other silently, it creates more of a social connection than working in different places, and thus benefits the future professional relationship of these colleagues. It is also better than just working in a coworking space or café alongside random strangers, as the social connections developed there do not benefit the worker’s organization. Coworking among colleagues can take many forms, depending on what is socially adequate for each context, including: meeting in a co-working space or café to work there together; meeting at a colleague’s flat to work together; working plus a shared meal; stayovers.

• Coliving with coworkers. A flat-share community of co-workers, perhaps even with a dedicated workspace inside the flat, provides certainly an intense amount of socializing between some co-workers, compensating for the lack of socializing with co-workers in other cities. It is not unrealistic: three co-workers of Edgeryders OÜ have been practicing this for three years in Brussels. It comes with its own challenges though, largely around work / life integration, so they are taking a break from this in 2020 but want to re-group and continue later. To learn more, visit The Reef’s project space.

  Living with your co-workers does not have to be a permanent thing, though. A distributed organization will involve quite some traveling, and whenever that involves colleagues staying in the same city, it is an option to book a multi-room apartment or suite for them rather than individual hotel rooms. Just as living together permanently, this is a behavior setting that promotes socializing, just because you run into each other frequently instead of having to schedule and organize every meetup. It’s valuable, and at Edgeryders we made only good experiences with this, so far. It needs a good amount of pre-existing trust between colleagues to be comfortable living together – so don’t push this as an organizational policy, but let the trust develop slowly in other ways, and make sure people know that the company supports temporary co-living even if it increases accommodation costs.

5. Tools

5.1. E-mail: avoid where possible

E-mail is the one, ancient communication tool that really everyone has, and that widespread adoption makes it valuable: you can shoot an e-mail to anyone, just like that, without installing and learning a new tool first.

However, e-mail these days is also a pretty broken system. For example, there is the annoying presence of spam messages, and the risk that your own e-mail will never arrive because spam filters. Also, most people nowadays use top-posting as their standard reply style, generating a lot of ugly redundancy in e-mail messages. On top of that, e-mail software will either show messages from all threads in a single list, or show them as a hierarchically nested thread, requiring complex navigation. Compare this to threads in a modern forum, esp. those in Discourse (also used here on edgeryders.eu) which uses a semi-flat threading model that makes forum threads look nice and clean.

In total, we think that e-mail is better avoided wherever possible. In the Edgeryders organization, we even have a no-email policy, applied to all internal communications.

To wean people off e-mail, here are some tips:

• E-mail interface in Discourse. The open source forum software Discourse provides extensive support to interact with the forum via e-mail, while providing a nice web interface to everyone who wants to enjoy it. Those who still want to stick to e-mail for a time can (1) receive notifications from the forum in mailing list mode, (2) add replies via e-mail, by replying to a post notificiation e-mail, (3) create new forum threads (“topics”) by writing to a certain e-mail address, (4) even participate in a forum discussion purely from e-mail and later, when then are ready to join the forum, their content will be attributed to them when they register an account with their e-mail address. The last feature is called “staged users” in Discourse.

• Discourse as personal mailbox. If you’re feeling adventurous, you could even configure Discourse to get rid of the last few e-mails people send in an e-mail free organization – namely personal e-mails to people outside the organization. This would work by letting Discourse create a personal message to between a staged user and yourself whenever an e-mail comes in, and then you can reply as usual. We did not try this yet, just had the idea; but if your organization is built around an online forum as its central tool, this certainly makes sense to try.

5.2. Online forum

Using an online forum rather than an office building as the center / home base of a company might have been our biggest gamble as Edgeryders. By and large, it worked out. Since 2012, the edgeryders.eu forum, now based on the open source software Discourse, serves as the central communication and collaboration tool in our organization (see also the central platform pattern).

5.3. Shared file storage

[TODO]

5.4. Collaborative document editing

[TODO]

5.5. Collaborative list management

According to some people in our organization, collaborative list management software has a huge potential as a lightweight task and project management tool. We have not yet been able to unlock it fully. However, our current favourite tool here is Dynalist and we provide a full manual that documents its use in our organization and our custom modifications and conventions for using it as a task management software in our teams:

Dynalist Manual

(Initial writeup of this documentation by @matthias; welcome to contribute.) Content 1. Introduction 2. Getting started with Dynalist 3. Creating tasks 4. Get notifications about new tasks 5. Working on tasks 6. Managing a project 7. Dynalist tips and tricks 8. Adapting the Dynalist appearance 9. Keeping backups 10. Design rationale 1. Introduction After failed attempts at task management with OpenProject and Discourse wikis , we finally found Dynalist. Dynalist is a rea…

5.6. Calls and instant messaging

Calls. Calls and conference calls are the most direct replacement for business travel and commuting, so this is clearly an important tool. In our organization (Edgeryders), we subscribe to Zoom, a state-of-the-art video conferencing service. We provide our own manual for Zoom.

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. In our organization we use Riot for instant messaging, an open source framework; the Riot mobile app supports voice messaging, but not the Riot web application. WhatsApp supports voice messages well, in both their mobile application and web application, but it might not be the best choice in a professional setting

Not for permanent content. In our organization we make a clear distinction between tools for ephemeral and permanent communication. Every tool where content is not archived at all (as in calls and conference calls) or where the archive is such as mess that nobody wants to go in and look for something (as in instant messaging) is assigned the “ephemeral communication” label. Everyone is welcome to use these tools freely but posting content there that should be preserved is frowned upon. This content should rather be posted in a high-quality, retrievable form in one of our tools for permanent communication – in our case the online forum and shared file storage. This practice helps to make quick interactions more efficient (via the ephemeral tools where sloppy usage is ok) while raising the average quality of content posted to the spaces with permanence. For this reason, we are not a big fan of tools that mix both functions, such as Slack – your mileage may vary.

  To motivate people to not abuse instant messaging for content that is meant to be permanent, it should not be archived. Old messages should be deleted automatically after 2-4 weeks.

Call recording. Sometimes, for example when having interviews, recording an audio or video call for later perusal is a very useful feature.

5.7. Issue tracker

[TODO]

5.8. Raster graphics software

[TODO]

5.9. Vector graphics software

[TODO]

5.10. Financial bookkeeping and controlling

[TODO]

5.11. Small utilities

[TODO]

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

The following sections provide best practices and principles as assistance for designing your own tools and processes for distributed collaboration.

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.

Example: Graphics file format interchange. PhotoShop (.psd) and Adobe InDesign (.indd) files are useless for those who don’t have these (expensive) tools 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 sometimes impossible. Creating everything in SVG from the get-go solves it. This is a good example how using an open standard format from a proprietary tool provides not even half of the desired solution.

6.2. Support Open Source

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: donate, contribute code, contribute documentation, contribute open source plugins and extensions to the tool’s ecosystem, answer questions about an open source tool on Stack Exchange and so on.

6.3. Avoid monopolies

Sometimes there is no efficient enough open source alternative, and then it makes sense to use a commercial product until there is one.

Now when you can’t avoid to use a commercial product, try to not choose one supplied by a monopolist or oligopolist supplier – this especially relates to GAFAM. Such software is the opposite of free, open and open standards based collaboration that is the optimum for distributed organizations with lots of external partners and suppliers. Expect a lot of vendor lock-ins and hidden costs from monopolists.

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. It does not matter in what language people in your organization talk, as long as it is a common language. However, any permanent communication (files etc.) should be in the same language as much as possible, because remixing and combining useful older materials becomes quite impossible otherwise.

• Calendar system. The Gregorian calendar is still far from the only one in use worldwide. For example, Nepal has three calendar systems in parallel use (AD, BS, Newar). But one organization should only use one!

• Date format. We propose to settle on the yyyy-mm-dd ISO 8601 date format, the only international standard for a date format. Also it is a beautiful and logical one, and when used in filenames it let’s you sort them by date using your normal file manager application.

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

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.

6.6. Use agile design principles

[TODO]

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.

There is a great and already somewhat dated example about a technique called “Xtreme Collaboration”, invented and practiced at NASA in their Jet Propulsion Laboratory (JPL) for space mission planning. It combines a three-week preparation tmime and a four-hour co-located session together with digital tools into a technique that is very effective at eliminating wait states. It also required minimal presence – for one space mission, just one afternoon in the “warroom” meeting environment.

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

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.

Examples:

• 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. Markdown does not provide a table of contents feature. But as you can see above, this manual (which is written using Markdown) has a table of contents. We just created it from more basic building blocks, with additional tools external such as pandoc.

• Use Good Metaphors. In digital spaces names and methophors can be key. Metaphors allow us to communicate athmospheres and “vibes”, which is something virtual comunication especially is in need of. Addtionally it allows us to decrease technical jargon. Deliberately use parallels like for example “Virtual Room Temperature” to describe the intended or perceived atmosphere of a meeting. If you think of a temperature scale from 0 to 30 it is intuitive that below 15 is too cold (un-personal), above 25 is too hot (too much pressure), and that we should aim for a comfortable 20 which is slightly above the middle. It is a useful shorthand to communicate a complex balancing act. The right name for your chat could make a difference as well. People behave differently in the “All Team Chat” than in the “Lunch Break”. As stated before, many of our learned social cues do not work in virtual spaces, but the right metaphor can help us to bridge that intuitive gap.

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 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, though.

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

[alberto]

This rocks already .

[alberto]

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

[matthias]

@alberto

I would like to suggest an editorialized intro about the why […] in human terms

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

[MariaEuler]

@edgeryders

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 .

what do you think about template project folders? It would be useful to establish a coherent structure in an organisation, but when I go experience I have seldom seen carefully created structures properly used, since most of the time people do not take the time to understand the structures someone has already set up and instead set up their own, or just save and share without structure. Do you have different experiences, examples of template folder structures that worked well?

[MariaEuler]

@edgeryders

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.

Here I would like to add that when having written communication we should also be aware that it is estimated that between 5-10% of the population has dyslexia, but this number can also be as high as 17% and in certain professions, such as design for example can be even higher (My University paid for students tests and measured up to 30% in some courses). With this knowledge we should also stress that misspelled words are not to be understood as a lack of caring or lazyness of not using a correction tool. For people with some form of dyslexia it could be very time-consuming or even impossible to make sure to get all words right.

[trythis]

If I can comment on this from my experience:
I used to have a pretty rigid and fairly simple structure.

Main goal oriented activity categories (e.g. presentations, scientific publications, research results) and main organizational / ongoing operations things (usually under: orga, or things like literature research)

Within goal oriented folders I would differentiate by project (e.g. collaboration partner, or funding source) and in some cases by type of work (e.g. microscopy).

Below that I would have only the main folders: prep and final. If I had to collaborate a lot (by sending stuff around in mails) I would also track incoming and outgoing versions in respective folders.

That said, I have worked with people who do a lot of design / editing work, and they generally depend much more on control of their folder structure, often 10 levels or more deep, and can’t be asked to compromise.

Similarly with the advent of cloud based work I have fully transitioned to a pile-and-search approach, which is much more shareable, but also profit from some degree of coordination on the naming schemes.

In my opinion working with someone else’s (or rigid) folder structure will invite more trouble through non-compliance. It is not a hill I would want to die on with work becoming rather more than less organic.
Naming (or tagging) better is more what I’d lean to.

[matthias]

@trythis

I used to have a pretty rigid and fairly simple structure. Main goal oriented activity categories […] and main organizational / ongoing operations things […] Within goal oriented folders I would differentiate by project

That’s nice because I have arrived at the very same structure, with slightly different names for the same concepts. Nice mutual confirmation that the basic distinction between project folders and data store folders is relevant and meaningful.

My system goes like this: All my goal oriented activities are in ~/Projects/ and ~/Projects.Closed/ for finished ones. All my other data is sorted into main folders by data type. That other data can be non-project data, cross-project data, and also project data whenever there is a reason why putting it into a cross-project, database-like folder is better than the default of placing it into the project’s folder.

So taken together, my home directory looks like this:

Contacts
E-Mails
Geodata
Literature
Manuals
Media.Audio
Media.Movies
Media.Music
Media.Photos
Media.Videos
Mindmaps
Money
People
Projects
Projects.Closed
Settings
Software
StateProcesses
Telecommunication
Templates
Things
TimeTracking

@trythis

I have fully transitioned to a pile-and-search approach

For team collaboration on files, honestly, I am still not convinced that this is the way to go. You can only search for what you know exists. And you cannot search for content of videos or audio files (given current technology). So at some point, you can either browse messy folders, or ask a colleague who knows what they put where (which is exactly what a collaboration tools should avoid).

[trythis]

Ha - this could almost be my “non-work” folder exactly.

Only thing is that I have a Media.text folder for copy / backup convenience as well (usually the most expensive content per bit).

I am still not convinced

Yeah the pile-and-search thing is because I had to work with the google suite. And without plug-ins their (web interface) folder system is such a farce that I can only explain it by them having taken a strategic decision to deprecate folders as soon as they can. And my opportunistic (career guided) self wants to be ready for that moment to have a competitive advantage.

[trythis]

@matthias

You can only search for what you know exists.

That is an interesting point I would like to contend. What I do once in a while is just sort everything by “last modified” and go down that list for a few dozen entries.
That is in my opinion an extremely fast way to get an idea of where everyone’s head is at currently (provided all is visible and shared).

[matthias]

That’s a nice trick, I’ll edit it into the manual somewhere

(Also it means “one big folder for everything” in a project. Wow, I had not imagined that anyone would take pile-and-search to such an extreme.)

[trythis]

@matthias

in a project

Not project, company. Yeah people have all kinds of folders but when the “official” folder names repeat in their respective sub-folders you know - if you get into those trenches you’ll be there a looong time. Just move on.

[matthias]

@trythis

Not project, company.

Ok I understand it will work better than infinitely recursive subfolders and what-have-you. So it would qualify as a best practice for the extreme cases … I mean, different cases, different treatments …

[trythis]

Move fast and break things.
Folder structures will be in the first 10% of casualties - unless you have a very specific kind of CEO.

[alberto]

@trythis

Not project, company. Yeah people have all kinds of folders but when the “official” folder names repeat in their respective sub-folders you know - if you get into those trenches you’ll be there a looong time.

Sam, could you explain this, please? I don’t get it.

[unclecj]

Oh, this is mind-blowingly good, and useful! I will digest it as soon as possible and most likely pass it on in my day job.
I’ve been working close to this domain recently, trying to capture my common sense in distributed collaboration, coaching colleagues who can’t seem to play nicely with Office 365 nor a wiki.
Of course I have a couple of items I hope to contribute as well. Oh and while I’m writing (I’m here infrequently at the moment) I saw an edit comment from @hugi indicating he may like to use one of my posts in some blog - to which I say, go ahead! Attribution is appreciated, beware that the Minecraft info is dated (though may still be fairly accurate). Revise language and content as you see fit. Lots of love /CJ

[matthias]

Thank you for the positive feedback, much appreciated!!

Of course I’m curious about your own experiences and common sense knowledge about this topic. (Welcome to just dump it here in comments, I’ll do the service to everyone with little time on their hands and integrate it into the wiki. Of course, also welcome to edit the wiki directly.)

Unrelated side note: I am tempted to rename this document temporarily to “The ultimate weapon to beat coronavirus at your workplace” or something similar It certainly does not get the attention it deserves right now, where the document only argues for remote collaboration as climate protection …

[unclecj]

While I care more about memetic epidemiology, knock yourself out

Pasting my current list of principles below. Beside these I have also pondered the various qualities of communication / information - it is difficult, but not homogenously so in for instance how what needs to be kept up to date need not necessarily be very detailed, and vice versa. The “as if continuously publishing for someone” below touch on a thought yet to be formulated, about calls to action and cherishing attention, similarly to how you make it easy for me suggesting I just contribute, regardless that I have not yet checked whether I have overlaps with what is already written

Guiding principles / fundamental assumptions

• We operate in an information-rich world, facing that successfully is key (see Fred Brooks, Herbert A. Simon, Melvin Conway)
• Set standards, learn the methods to sustain them. Sophisticated solutions codified in accessible culture
• Most problems are solved in some places, scale solutions and learn from what works
• Invest in sharpening your most frequently used tools
• Disorder accumulates, accept and continuously work to mitigate it. Reduce complexity, avoid incidentally increasing it. Manage groups of people and things rather than individuals, automate and generalize
• Information exists in networks, both tangible and abstract such. Links are what define network structures and thus significantly affect characteristics – if the network is useful or not. Use ubiquitous linking (only adhering to common sense) to manage information
• Consider other reasonable information practices (e.g. “upstream first”, originator, authority, audience, attention capacity / efficiency, review, transience / permanence, development / in the moment / maintenance, relations (links), location, medium / tools, overview, collaboration, cognitive funneling). Even that little extra effort goes a long way
• Some accurate information now is better than all inaccurate information until later. Work with transparence, as if continuously publishing for someone
• Be bold but strive to respect policies and collaborators
• You are one person in a great team

Edit 2021-08-30: Gentle revision - this is largely originating from my old presentation Staying afloat or aiming for the stars - maintaining and improving your development environment for Ericsson Software Craftsmanship Community

[alberto]

@matthias

Unrelated side note: I am tempted to rename this document temporarily to “The ultimate weapon to beat coronavirus at your workplace” or something similar It certainly does not get the attention it deserves right now, where the document only argues for remote collaboration as climate protection …

If you share it with the right hashtag on social media…

[alberto]

And indeed…