Many people consider synchronous communication to be the new world of real digital collaboration in a digital workplace. I just find it annoying and expensive. I try to avoid synchronous collaboration meetings as much as possible. I have many colleagues who really love working on something at the same time as others. In software development, we call this “pair programming.” And in a business setting, there is no better name than “pairing” as far as I’m concerned. 

For me, synchronous communication methods like conversations and phone calls are a form of escalation. 

I love to use synchronous communication as a method of convincing others of my opinion and engaging in a discourse about why they don’t think my opinion is convincing. And I love face-to-face discussions when I get the impression that we’re not seeing eye-to-eye on a digital level and our views are fundamentally different. A face-to-face conversation is incredibly refreshing, creates real balance, and is generally also worth its weight in gold for getting ahead in a matter. I especially like it, though, when we try to advance things together digitally in the company and only resort to a personal approach when necessary. 

Don’t get me wrong. As I said, I’m a great friend of personal interaction. Currently, we employ more than 190 people, over 180 of them at our offices in Wiesbaden. In our industry, that’s almost anachronistic. Many of our competitors deliberately recruit across the market to be closer to their customers or try to attract talent from around the world. Almost all of them are exclusively dependent on the digital collaboration tools we’re talking about here. 

We also believe in these tools, but more as a complement than anything else. Meeting personally to escalate and resolve conflicts or to reconcile interests is a very powerful tool. At the moment, I can’t really imagine doing without it. We even let our ten or so remote colleagues from the USA, Potsdam, Tübingen, etc. visit us regularly so that they can establish closer contact with our teams. 

We also have 360-degree cameras (meeting owls) we set up in the team rooms, with our remote developers sitting at home in front of the camera so that “they can all share a room.” That looks pretty strange at times, but it clearly works well for them. Things like this develop in the spirit of self-organization at our company and not through control meted out from above. 

But we’ll come back to collaborating over long distances later on in this book. You still have enough time, don’t you? 

Now let’s go back to collaborating on wiki documents. I’ve already described the special effect that content-related messages sent to page observers can have. They increase activity and attention. As a result, they drive the further development of the content. In contrast to Google Docs and ‘Word 365’, the work performed in a wiki takes place asynchronously, i.e. at very different times. The observers respond only when they have time to do so.

Wikipedia is the largest wiki in the world, as well as one of the most successful websites ever. It’s also the undisputed leader in knowledge repositories for lexical documentation. What’s more, interesting research results are available based on activity by participants from the early days of Wikipedia. Around 90 percent of visitors to the website only look and read. Around nine percent make changes to an article here and there, sometimes correcting a small error or making a specific contribution. Around one percent of users are really active authors, some of whom have been involved in Wikipedia for a long time. They write, they get involved in the community, and together they make Wikipedia a successful project. My experience in companies reflects a somewhat more even distribution of labor. But the idea behind it is very similar.

Just a small number of really dedicated people are generally responsible for making a wiki successful (at least at the beginning). If these important multipliers continue to rely on Word, Google Docs, or data silos instead of real collaboration, you’ll have a hard time kicking off your intranet project and establishing a collaboration culture in your company, 

There’s no better home than a company wiki for referencing, documentation, and general knowledge retention applications in a company. 

Establishing a wiki like this is a rewarding affair and has real value in the long term. However, it’s difficult to achieve widespread acceptance for an “internal Wikipedia” of this type – at least compared to setting up a chat service, which can be very simple and done extremely fast. Shall we talk about user acceptance and strategies to increase acceptance letters next?

Link to this page: https://seibert.biz/intranetbooksynchronouscommunication