Remote Teams in a Digital World

Distributed teams have been a standard in the digital industry for three years. The question of whether remote works is therefore answered. The interesting questions today are different ones: when does distributed work fit, when does it not, what pays off, and where does it hit limits? In this post I describe how we work at Moselwal and what observations we take from three years of distributed-team setup.

The advantages that actually count in practice

The usual list — access to global talent, lower overhead costs, higher employee satisfaction — is correct but too smooth. In practice three concrete effects make the difference.

Depth instead of meeting tetris. Anyone working in a distributed setup statistically has significantly more block time without meeting interruptions. That is the class of work in which real conceptual thinking, code, copy and design emerge. On a classical day in an open-plan office, that time is often limited to the first two hours before 10 a.m.

Writing as a side effect. Anyone working remotely writes more down. Decisions, rationales, if-then logic. That is initially more strenuous than calling out across a desk, but has a priceless side effect: documentation emerges in the day-to-day. When someone joins the team, the answer is rarely "ask colleague X" but "look at the thread from last Tuesday".

Selection instead of commuting radius. We can hire colleagues based in Cologne, Wuppertal, Leipzig or Vienna without anyone having to move. That has measurably improved our hit rate in hiring — and the quality of life of the people involved along with it.

The challenges rarely on a slide

The standard list of difficulties — time zones, communication barriers, less face-to-face — is known to all. More interesting are the ones not discussed in an interview.

Always-on creeps in. In a distributed team with clear tools and a poor reflex, this happens almost unnoticed: a Slack notification at 9 p.m., a "quick email" on a Sunday afternoon. We address that actively through clear status conventions, shared core working hours, and the right not to respond outside those hours. That only works when leadership models it.

Onboarding is markedly more expensive. Anyone starting in an office learns a lot through observation in the first weeks — who talks how, to whom, in which tone. In a distributed setup this background observation is missing. We compensate with structured pairing weeks, an explicit onboarding plan and a buddy system. That is effort that amortises only after months.

Conflicts surface later. In an open-plan office you notice when someone is in a bad mood, a discussion is escalating, or a team is drifting apart. Remote, much of this stays beneath the surface until an escalation moment in a call. We therefore rely on more frequent 1:1s and honest retros — even though that costs time which does not immediately show in backlog velocity.

What works for us — async-first with deliberate sync islands

We work async-first. That does not mean "we dislike calls", it means: the default assumption is that a question is asked in writing and answered in writing. Calls are the right tool when the question is complex, when a sign is about to flip, or when a conflict is in the room.

In day-to-day operations this looks like this:

• Standups in writing in the morning, three lines: yesterday, today, blocked where.
• A weekly sync island of 60 minutes for the whole team — Thursday, 11:00.
• 1:1s every two weeks, split in half: first half professional, second half personal.
• Retros every four weeks, prepared in writing, discussed in a call.
• A two-day offsite every quarter — in person, together, without laptops.

The offsite is the most important sync island. The relationships that form in two days carry the following twelve weeks of distributed work.

Tools are not the solution, but they are not irrelevant

Anyone thinking that Slack and Notion answer the remote question is mixing two things. Tools are the substrate, not the solution. They can support good practices or cement bad ones.

Our communication runs over Slack, with clearly defined channel conventions: one project channel per client project, one #announcements channel for team-wide updates, no channel spam. Documentation and knowledge live in a combined Notion and GitLab world — Notion for what is read, GitLab for what is versioned. Asynchronous video updates via Loom have replaced calls in roughly a third of cases; some topics are explained more quickly as a two-minute screen recording than in a 30-minute call.

What we do not do: tracking tools that assume mistrust. If trust can only be established through mouse movements, you have a trust problem, not a remote problem.

Onboarding and culture in a distributed team

Culture does not emerge by itself in a distributed team. It emerges in the spaces you deliberately plan for.

Our onboarding runs over four weeks with a clear plan: week 1 is setup, tooling and first small tasks with a buddy. Week 2 is the first independent tickets, with daily feedback. Week 3 is the first own responsibility for a small piece of a project. Week 4 is reflection and adjustment. By the end of the four weeks, the new colleague knows who in the team is the contact for what, how our reviews work, and which cultural ground rules apply.

Culture also emerges in small rituals: a weekly "what surprised me this week" round in the sync, a shared reading circle with one article per month, occasional sport or cooking threads in a dedicated channel. That is not forced feel-good culture but the acknowledgement that people are more than their tickets.

Where remote hits its limits

Honestly: there are constellations in which distributed work does not, or only barely, work.

Early phases of a new business idea. When two or three people are developing something new together and do not yet know what the question even is, they are faster in a room. That is not a technology question, it is a question of insight. In such phases we deliberately mix in more sync days.

Hands-on coaching with younger colleagues. A junior developer learning code reviews benefits more from sitting shoulder to shoulder than from asynchronous comments. With us that means: deliberate pairing days in the office or co-working space, not "do an hour video call".

Sensitive conversations. Difficult feedback, conflict resolution, salary negotiations — belong in a call with video, not in a Slack thread. Written communication amplifies every dissonance in such moments.

Conclusion

Distributed work is no longer an emergency solution for us, and it is not an ideological position. It is the standard form of work because, for the kind of work we do, it delivers the better result in most cases. But it is not without preconditions: it requires writing, clear conventions, deliberate sync islands, and the admission of where it hits its limits. Anyone bringing those preconditions can build a strong team remotely. Anyone without them won't build one in an office either.