Remote teamwork – experience report from a distributed team

This blog post is something we had on our to-do list for such a long time that it feels like forever: sharing all the learnings about day-to-day remote work in our codecentric Digitization Labs teams. Now that COVID-19 hit Europe and everyone needs to adapt to the given situation, it seems like there never was a better time to finally write it. So here we go…

Our context of remote work

In our codecentric Digitization Labs teams, we have the additional challenge of not only working together remotely but also bringing our clients into the same work mode. To make it even more challenging we made immersion one of the core principles our service is built on. We want our client to immerse into our process of discovering a new and magical digital product. To immerse into the experience of shaping their own idea into something their customers will use and love. To immerse into a team highly trained for this particular purpose.

Doing this while working remotely seems counterintuitive at first sight and requires some rigid and well-honed tools and principles.

About codecentric Digitization Labs

Our day-to-day work in the team and with clients requires four main ways of collaboration that we need to transfer to the digital world: organizing the work, communicating synchronously or asynchronously, and generating ideas. Let’s have a look at the tools and tactics that help us to achieve an experience that is as close to feeling co-located as possible.

Organizing work

The first thing we want to look at is how we organize our work in a remote team. This is the task that kicks off the start of a new assignment as well as every new day when we get together in order to discuss the next most important thing we need to work on, who will do it, and what to do.

Without going too much into the details about Kanban and the likes or the theory behind it: in codecentric Digitization Labs we use a flow-based process in which we see tasks we work on move through our system from left to right. This helps us to assess the number of tasks in any given state at any given time so we can easily decide what to do next in order to complete the next task.

We like to use Businessmap as a tool because it gives us great metrics about our process (e.g. the cycle time: the average time it takes to get a unit of work done). But if you are not interested in a metric-driven flow then Trello will do the trick, too. The picture below shows an example of a very simple process in Trello, whose free plan probably suits most teams doing their first steps of organizing their work remotely.

Now that we have one single point of truth for the tasks, how do we organize the tasks, ask questions, communicate when working on a task together and so on? In short, how do we solve synchronous communication?

Synchronous Communication

Advocates of co-located work models argue that for synchronous communication you need to be able to walk up to people and just talk to them. When you are co-located, you can easily enter an open plan office with the people you need to talk to, enter a team member’s room, join for a coffee break, or sit next to each other anyway. Especially the latter case provokes situations where you are listening to others discussing a topic that you are familiar with and being able to jump in spontaneously and bring value to that discussion.
Another aspect of being co-located is that you can assess who is available at a glance: someone is having a coffee, another person is outside for a smoke, a third is on the phone or in a meeting, and some people might just not be at their table at the moment.

In our experience, it’s easy to copy those patterns to digital tools and enable almost the same effortlessness in our remote team (it might even be more effortless since we don’t even need to get up and walk 😉 ).

We use dedicated channels that help us to signal the different “work modes” of a person that we described above (see picture below).

The most important agreement we have: we always wear our headsets and are present in the virtual office when we are doing regular work. As a consequence, colleagues can just shout out to the person they want to talk to in case they have a question. At least we always have an eye on whether our communication tool is indicating that someone is talking or has joined our room, so we can quickly join in to listen – pretty much the equivalent of taking off the headset we might be wearing in an open plan office space for the same reason.

There are plenty of tools supporting this kind of setup. We were quite happy with Discord , which has its origins in the gaming scene – in the last years. But there are other alternatives like TeamSpeak , Mumble , and the all-new Tande m. A piece of advice: check privacy agreements, statements, and security in order to be aligned to your company’s compliance. This holds true for all the tools mentioned in this article. There probably isn’t a “one-fits-all” solution for voice chat as well as for the other use cases.

In our experience, verbal communication covers most of the day-to-day interaction in the team or with the client. This is arguably specific to our industry since we are mostly working on virtual products and there are great tools you can use to work collaboratively on code. Our preferred choice here is Floobits, but some IDE offer features for collaboration out-of-the-box nowadays.

Still, there are occasions when we feel the need to have a video chat, for example when we need to show and talk about something physical (e.g. an IoT device) or when we brainstorm or revisit something with our client that requires visual support (e.g. design decisions). In that case, we follow one very important rule: everybody needs to be remote. Even (or especially) if we are sitting next to a colleague in the office, we grab our own computer and headset and turn on the camera. Our tools of choice for video chats, videoconferences or screen sharing are either Slack or Zoom .

Be aware that having multiple larger groups in a few different locations has a higher risk of destroying the energy in your virtual room. There is a good chance that factors like side talks on-site, bad audio quality from a conference phone or a distant camera may decrease the outcome of these meetings. Most of the time we had better experiences when everyone used a remote setup as described before.

Building a digital product contains tasks that sometimes require a strong focus, a state of “flow” that we don’t want to interrupt if a colleague is in this state of mind. So as for co-location as in a remote setup: be careful and deliberate about it.

If an immediate answer is not necessary, consider an asynchronous way of communicating. But there are also other good reasons for that, and we will have a look at these in the next section.

Asynchronous Communication

Arguably the most common reason for asynchronous communication in our case is sharing results we need to get feedback on from a colleague or client which does not need to be immediate. New mockups for a screen, new functionality or suggestions for texts, labels, and wording are just some examples where we prefer the non-disruptive nature of asynchronous communication. In the era of WhatsApp and the likes, this is probably something everyone is most familiar with and knows how to handle. Still, there might be some recommendations that might help in the work environment.

When we use asynchronous communication, we are well aware that we don’t expect a person to react immediately because otherwise we would undermine the non-disruptive nature that (hopefully) made us deliberately choose this way of communication in the first place. Answering at least an hour or two later should be fine. This also requires that everyone handles their notifications carefully. When someone grabs their phone or opens their messenger every time they get a message, asynchronous communication is not supporting the teams’ communication the way it should. Make sure you mute or shut down your messenger when you need to focus and/or use the “status” functionality most messengers have to signal “flow” or “focus” to your colleagues.

For the case of deliberately deciding when to use asynchronous communication instead of synchronous communication, let’s take a look at a non-work related example: shopping for clothes. Let’s assume you are in the changing room of an apparel store and are not quite sure whether to take the jeans you’re trying on or not and want to get feedback from a good friend or your spouse. The store is about to close and you need to make this decision immediately. You will probably send them the obligatory mirror selfie on WhatsApp but dial their number immediately after that, right? It’s late so they are at home anyway and might not exactly be bored and wait for your call but probably won’t mind giving you quick feedback. Now consider you are sitting at home on a free day doing some online shopping and find shoes you like but are not sure about. You can send them the link and easily order the shoes later after they gave their opinion on them. Especially since you know that they are at work right now and probably have more important things to deal with at the moment.

If something at work needs immediate clarification (e.g. which task to do next) and thus falls into the “apparel store” category and you know the impact of disrupting the other person won’t be too bad: go for the synchronous communication. In any other case (e.g. a small UI design decision) like the “online shopping” case, write a message. No matter what you decide for, being deliberate about the choice will already help a lot.
By the way: our “business messenger” of choice is Slack, and we are still happy with it.

Generate Ideas

The last type of collaboration we want to look at, that is part of our day-to-day work, is probably the thing most people have the hardest time imagining in a distributed team: the generation or discussion of evolving ideas, e.g. through brainstorming sessions or workshops.

In this particular case, the tooling is probably a more decisive factor than it is in the other cases we mentioned so far. Our colleague Victor Volle posted a great article on his experience with a digital whiteboard lately.

Our tool of choice for this purpose is Miro because it is as close to a physical whiteboard as it gets. You can place text, stickies, drawings on it collaboratively. There are two huge benefits over a physical whiteboard: digital whiteboards offer an unlimited canvas to write on, you can “carry” them around all the time, and you have your digital documentation in place just when you’re done with your session. Especially the latter is such a big benefit for us in a distributed team that we even use our digital whiteboard in on-site client workshops. No more taking pictures, trying to read somebody else’s handwriting after a workshop and trying to put the widely spread results into some readable and usable digital document.

Although the “right tool for the job” might have a bigger impact here as in the other abstracts, in the end, it is not about the tool. In our experience, the most important thing for the success of such a session is to come prepared. Sketching out the necessary templates for a workshop format or retrospective is a hassle and something that might be possible on a flipchart or whiteboard but something we’ve tried several times and failed to do on a digital whiteboard.

The good news is tools like Miro provide a great variety of predefined templates you can use for your workshops. We learned valuing having a good structure and agenda for your workshops in order to guarantee great results anyway.

Limitations of remote work

This might sound like an exaggeration but we face very little limitations that can be attributed to the fact that we are a distributed team. This is also very likely due to the fact that we had plenty of time to train and hone our way of working together remotely. There is one thing worth mentioning when it comes to the boundaries of working remotely. Interpersonally difficult situations like strongly conflicting views and opinions in a workshop or emotionally heated discussions are without a doubt harder to handle when you can’t solve them face-to-face. So for cases where we expect something like that, we will invest the time and money to meet at an on-site location. Most of the time these things are prone to happen in workshops with clients, especially when different stakeholders are present, so we try to do those on-site per default if possible. This also makes sense because we will work together with the client at least for a couple of weeks and this is a lot easier if you have met in person at least once before.

To refresh this in the team we try to meet at least once but preferably several times a year to make sure we maintain a good relationship with our teammates. This helps us to avoid these kinds of situations in the team almost completely and makes it more likely that we can solve them in a remote setup on the rare occasions they happen.

From our experience in the codecentric Digitization Labs teams we observed one interesting thing: as we got used to working as a distributed team during the whole week, the team experience is so intense that it sometimes feels more personal than a co-located working experience. Vice versa it becomes something special when we meet in person.

If you are used to working on-site, and now you are suddenly confronted with having to work with your colleagues remotely, the good news is that you (hopefully) already established a good relationship with your colleagues that you can build on. In case you face one of the critical situations we described above, try to defer them until you have the chance to meet in person again if that is remotely possible. Having a facilitator who keeps discussions on a factual level might help but it remains a compromise you should consider the last resort.

Conclusion

Before we wrap up this article with the recommendations that can be derived from our learnings there is one thing we want to get back to. In the introduction to this article, we talked about the additional challenge of creating an immersive experience while working in a distributed team. All the tools and principles we found and developed over the years are the necessary foundation in order to achieve this experience. But for us, the true source of immersion for everyone in the team, especially our client, is constantly delivering tangible results. Delivery, of course, is essential for every high-performance team so this may sound like an empty phrase and fairly independent from remote work. The point we want to make here is that when you focus on being highly efficient in delivering the outputs and outcomes you want to achieve and rigorously eliminate any obstacle that is slowing you down, the limits of not being co-located become more and more irrelevant. All the things we shared in this article are just the results of applying this rigor day by day and year by year.

Here are our takeaways in brief:

• Organize Work
  Making the next things to do explicit and signaling who is working on what task is arguably even more important in a distributed team. Make sure you regularly do this exercise. Tools like Trello or the more advanced Businessmap or Jira help you with this.
• Synchronous Communication
  Make the implicit patterns of synchronous communication in the office explicit in your voice-chat tool. People can signal whether they are in the “virtual office”, out for a coffee, cigarette or meeting etc. This implies that you need to always be present in the “virtual office”, wearing your headset or at least watching the channel to put it on if necessary.
  In a group discussion, especially during a workshop or brainstorming session, everyone needs to be remote (using their own computer, headset, and camera). Tools to consider for the different requirements of synchronous communication are e.g. Discord , TeamSpeak , Slack , and Zoom .
• Asynchronous Communication
  Given the ideal conditions, we described for synchronous communication, make sure you deliberately use your chat tool of choice the way you would (or should) use, e.g. WhatsApp, in private situations: every time you don’t require an immediate answer. This helps your peers and colleagues to keep the focus on the things they currently do, given that they handle notifications reasonably. Slack might be a good recommendation for asynchronous communication.
• Generate Ideas
  Great digital whiteboards like Miro are a decisive factor here. They have benefits like unlimited canvas space and immediate digital documentation that make them a considerable alternative even for on-site meetings and thus are by no means a bad compromise for a remote work situation. Just be aware that sketching out templates on the fly during a meeting is not a good idea when working with those tools.
• Limitations
  Emotionally heated discussions and conflicts are the single big boundary we see in a remote setting. In case you can anticipate them and have the chance to do that: postpone them to a moment when you can do them face-to-face