Leading remote teams mostly means deliberately organizing things that simply happen on their own in an office. The quick chat at the coffee machine, the “got a minute?” across the desk, the glance at a face that doesn’t look happy right now. None of this happens by itself when everyone sits in a different place. That is exactly why the topic keeps me busy: remote work rarely fails because of technology. It fails when nobody builds the frame in which people feel connected despite the distance.
This last part of the “Leadership in brief” series is about that frame. I’ll show you which rituals really carry a distributed team, how to set up a weekly rhythm, when asynchronous beats a call, and how to create a team agreement in 60 minutes that won’t disappear into a drawer.
In short
Remote teams need a few reliable rituals instead of many meetings: a short daily check-in, regular one-on-ones, a written weekly update, time without an agenda and a retro. More important than any single ritual is a shared agreement on when you work asynchronously and when you meet live. The biggest pitfall is rituals that turn into mandatory events nobody gets anything out of.
What you will learn in this article
- Which five rituals carry a remote team through the week
- What an asynchronous weekly update looks like that people enjoy reading
- When a call is better than a message, and vice versa
- How to create a team agreement for working together in 60 minutes
- Which typical mistakes hollow out remote rituals
Why leading remote teams is different
In an office, a lot happens on the side. You overhear two colleagues cursing about the same bug and bring them together. You notice from someone’s tone that they are overloaded. New team members pick up over lunch how the team ticks. This chance information is invisible, yet it holds a team together.
In a distributed team, it disappears. What remains are calendar entries, chat messages and tickets. That has two consequences. First, information evaporates: whatever was discussed in a spontaneous call is known only to the three people who were in it. Second, closeness becomes a matter of planning. If you don’t actively take care of contact, at some point you only see your colleagues as avatars in a video tile.
Anyone leading remote teams has to fill this gap on purpose. To me, a ritual is nothing esoteric. I mean a recurring meeting or routine with a clear purpose that everyone knows. The daily is a ritual, and so is the Friday update. Compared with an arbitrary meeting, a ritual gives people something to hold on to, because it happens reliably and everyone knows what to expect.
Five rituals for leading remote teams
For leading remote teams, you don’t need ten new meetings. Five rituals are enough for most teams, as long as each one serves its own purpose. The diagram shows a possible weekly rhythm; below it, I describe each ritual in detail.
A possible weekly rhythm: a few fixed live meetings, complemented by a written update on Friday.
1. The daily check-in: 15 minutes, no more
If your team works with Scrum, this meeting is called the Daily Scrum. The Scrum Guide sets it at 15 minutes, every working day at the same time, with a clear purpose: inspecting progress toward the Sprint Goal and adapting the plan for the next day. How the developers run the daily is explicitly left up to them.
Remotely, it pays to use that freedom. One proven variant: instead of going round the room person by person, walk the board from right to left, from “almost done” to “just started”. That way you talk about the work instead of about people. A minute at the start for a personal question helps too, for example “How is your energy today, on a scale from 1 to 5?”. This small round partly replaces the glance across the desk.
2. Regular 1:1s: the place for what doesn’t belong in chat
In distributed teams, one-on-ones matter even more than in the office, because there are no hallway conversations to complement them. Schedule them firmly, move them rarely and, if at all possible, never cancel them. I described in detail how to keep them from turning into status meetings in Recurring 1:1 meetings that aren’t status meetings. Remotely, there is one more point: ask specifically about the workspace. A bad chair, constant interruptions or a feeling of isolation would otherwise go unnoticed.
3. The asynchronous weekly update
A written update on Friday replaces many status rounds. Everyone writes in a shared channel or the wiki what happened during the week. The format has to be short, otherwise nobody will still be writing it after three weeks. This template has worked well:
- Done: one to three things I’m proud of this week
- Next: what I’ll work on next week
- Stuck: where I need help or a decision, with names
- Personal (optional): one sentence on how I’m doing or what I’m up to at the weekend
The third point is the most valuable. A blocker written down with a name gets solved faster than one briefly mentioned in a call. As a lead, you should not only read the updates but also react to the “Stuck” items the same day. Otherwise, the team quickly notices that they go nowhere.
4. Time without an agenda: the virtual coffee chat
GitLab, one of the largest fully remote companies, describes a whole range of such formats in its public handbook: coffee chats usually lasting 25 minutes, random pairings via a chat bot, social calls without an agenda within a team. What I find remarkable is the attitude behind it. GitLab deliberately separates work meetings from social formats instead of squeezing the social part into work meetings on the side.
For a single team, one fixed coffee chat per week is often enough: 25 minutes, voluntary, no topic. Voluntary is meant seriously here. Anyone who doesn’t come owes nobody an explanation. So that the slot doesn’t stay empty, you can bring an opening question for the first few weeks, such as “What did you learn recently that has nothing to do with work?”.
5. The retro as maintenance for collaboration
The retrospective is the ritual that keeps all the others alive. Here you ask not only what went well in the sprint but also whether your rituals still fit. For remote retros, I recommend a shared online whiteboard and a silent writing phase of five minutes before anyone speaks. That way, the voices that tend to get lost in video calls are heard as well. How to complement a retro with a forward-looking view is covered in the article on the pre-mortem method, which is easy to prepare asynchronously.
Asynchronous or live: which is better when?
If you are leading remote teams, this may be the most important question of all. Most distributed teams don’t suffer from too little communication; they suffer from the wrong form. A call for information that would take three sentences costs five people half an hour. A chat thread about a contested architecture decision, on the other hand, drags on for days, even though a 20-minute call would have settled it.
GitLab states a clear default: “GitLab has a bias towards asynchronous communication”. Asynchronous is the normal case there, but not a dogma. The handbook explicitly names situations in which a live conversation works better. From that, I built a small decision aid:
| Situation | Better asynchronous | Better live |
|---|---|---|
| Status information, result of a task | Yes, in the weekly update or ticket | No |
| Code review, detailed technical discussion | Yes, people can reread and think | Only when it goes in circles |
| Production incident, tight deadline | No | Yes, right away |
| Brainstorming, first ideas for a design | Preparation, yes | Yes, for the joint session |
| Thread full of misunderstandings or contradictions | No, it only gets longer | Yes, and write down the result afterwards |
| Getting to know new team members | A short profile, yes | Yes, personally and without an agenda |
| Critical feedback to one person | No | Yes, in a one-on-one |
One rule applies in both directions: whatever was discussed live gets written down afterwards. GitLab documents the results of such conversations in the related issue. For you, that can be a ticket, a wiki page or a reply in the original thread. What matters is that the people who weren’t there know about it too.
Making remote meetings better
For the meetings that remain, a few simple rules help, which GitLab describes as well. Every work meeting has a written agenda in the invite that is shared beforehand. Anyone who isn’t strictly needed is invited as optional. In addition, you start with shorter default lengths, such as 25 or 50 minutes, so there is room to breathe between two calls. Notes go straight into the agenda, so nobody has to send minutes afterwards.
Creating a remote team agreement step by step
Rituals only work when everyone has the same expectations. Especially when you lead a remote team, this is no side issue. When can people reach me? How quickly do I have to answer a message? Which channel is meant for what? A team agreement, often called a working agreement, captures exactly that. Atlassian’s Team Playbook describes a workshop of about 60 minutes for two to ten people. My process is based on it.
Prerequisites
- 60 minutes with the whole team, plus ten minutes of preparation per person
- A shared document or whiteboard everyone can edit
- A list of friction points from the past few weeks, for example from the last retro
The process in six steps
- Preparation (in advance, 10 minutes per person): Everyone adds their core working hours, their time zone, their preferred way of communicating and how they like to receive feedback to the document.
- Opening (10 minutes): Explain the purpose. You are not writing rules for eternity but a first version that you adjust regularly. Read out the friction points you collected.
- Clarify channels (15 minutes): Decide which channel is meant for what and which response time you expect. An example: chat for questions answered the same day, tickets for tasks, phone calls only for urgent matters.
- Set the meeting plan (15 minutes): Go through your rituals. What happens live, what asynchronously? Which meetings do you drop?
- Escalation and decisions (5 minutes): Agree on how you proceed when something is on fire or a decision is stuck. The delegation board from the previous part helps here.
- Plan the review (5 minutes): Put a date in the calendar when you will look at the agreement again. Atlassian recommends a quarterly review, plus whenever new people join or the way you work changes.
What a team agreement can look like
A fictional example: a team of six builds the app for a city library. Two people work in Hamburg, one in Lisbon, three from home somewhere in Germany. After the first workshop, the wiki contains this agreement:
| Topic | Agreement |
|---|---|
| Core hours | Everyone is reachable from 10 am to 3 pm German time; outside of that, replying is optional |
| Chat | Reply on the same working day, questions in the team channel instead of direct messages |
| Urgent matters | Call instead of message, only for incidents and hard deadlines |
| Check-in | Daily at 9:45 am, 15 minutes, camera optional |
| Weekly update | Friday by 2 pm in the #library-week channel |
| Decisions | The result of a call is in the ticket by the next day at the latest |
| Focus time | No meetings on Tuesday and Thursday mornings |
| Review | In every sixth retro, after three months at the latest |
Notice how concrete the entries are. “We communicate respectfully” isn’t in there, because it doesn’t help anyone when a question pops up in chat at 4:30 pm. Good agreements answer exactly these everyday questions.
Typical mistakes when leading remote teams
More meetings as a substitute for trust
If you can’t see people working, you are tempted to schedule more meetings. The result is a calendar full of status rounds in which nobody gets any work done. Pay attention to outcomes rather than presence. A good weekly update tells you more than five calls.
Making cameras mandatory
Cameras make conversations more personal, that’s true. A rigid rule creates pressure, though, especially for people who work in their living room or are having a bad day. I prefer an invitation to a rule, for example “camera on when it suits you”. For one-on-ones, feel free to ask for the camera and say so.
Half in the office, half remote
Hybrid meetings are particularly tricky. Four people sit around one microphone in the meeting room, two join remotely and miss half of it. GitLab advises avoiding hybrid calls where possible, or having everyone join on their own device. I consider the second option the most practical: as soon as one person is remote, everyone dials in individually.
Rituals nobody wants any more
A ritual that no longer helps anyone is a burden. If only two people still show up to the coffee chat, that’s a signal, not a failure. Ask in the retro whether you want to change the format, stretch the rhythm or drop it entirely. Just as important: sometimes remove something before you introduce something new.
New team members without a connection
Anyone starting a new remote job has no chance to bump into people by accident. That’s why GitLab has new hires schedule at least five coffee chats during onboarding. A similar approach works in any team: a list of people you should get to know in your first two weeks, plus one fixed buddy. How to run the first conversation with new team members is covered in the first part of the series.
My take
I consider remote work one of the best developments of recent years, especially for developer teams. Focused work without open-plan noise, talent regardless of where people live, more self-determination in everyday life. For that, though, you need leadership that builds structures rather than exercising control. Leading remote teams means saying goodbye to the image of the manager who sees whether everything is running just by being present.
At the same time, I disagree with the idea that asynchronous is automatically better. Some teams overdo it and write each other novels for weeks instead of talking briefly once. Relationships don’t grow in tickets. That’s why I like the stance in the GitLab handbook so much: asynchronous as the default, but with clear exceptions where a real conversation simply achieves more.
And then there is a parallel that I, as a serverless fan, notice again and again. Good event-driven architectures work because services are loosely coupled and still communicate reliably: clear events, clear contracts, traceable logs. A good remote team works in a similar way. Everyone works at their own pace, but everybody knows where information lands and how to reach each other. People first, here, means building this frame for people and not for the calendar.
FAQ
How do I lead a remote team successfully?
With a few reliable rituals, clear agreements on communication and a focus on outcomes rather than presence. Regular one-on-ones and a written flow of information are the most important building blocks.
How often should a remote team meet live?
There is no fixed number. A short daily check-in, a retro every one to two weeks and regular one-on-ones are a good start for many teams. Everything else you decide by asking whether a topic really gets solved faster live.
What belongs in a team agreement for remote work?
Core working hours, expected response times per channel, how to handle urgent matters, your meeting plan, the escalation path and a date for the next review. The more concrete the entries, the more helpful they are in everyday work.
Should cameras be mandatory in remote meetings?
I don’t recommend making them mandatory. Invite people instead and explain why cameras matter to you in certain meetings, for example in one-on-ones. That leaves room for people who don’t want to be seen right now.
Your next step
Leading remote teams starts with an honest look at what is already there. Today, go through last week’s calendar and mark every team meeting with one of three letters: H for “helps us move forward”, A for “would be better asynchronous” and D for “we can drop it”. Bring the result to your next retro and suggest trying a weekly update. Four weeks are enough to see whether it helps your team.
I’m curious how this looks for you: which ritual holds your distributed team together, and which one did you deliberately abolish? Feel free to share it in the comments.
More in the series: Back to the “Leadership in brief” overview · Previous part: Delegating with the levels of delegation. Next part: Remote onboarding: planning the first 30 days.
Sources
- Ken Schwaber, Jeff Sutherland: The Scrum Guide (2020), section Daily Scrum
- GitLab Handbook: Asynchronous communication for remote work
- GitLab Handbook: All-Remote Meetings
- GitLab Handbook: Informal Communication in an all-remote environment
- Atlassian Team Playbook: Working Agreements
This post was created with AI assistance.
👉 Next step: Preparing a first one-on-one? My question cheat sheet puts the best questions on one printable page.
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en
Top comments (0)