TL;DR:
Distributed team management is the practice of running a team spread across locations and time zones, where no single office is the place the work happens. At CleanTalk we work from more than ten countries across nine time zones. The single rule that matters most is this: stop trying to simulate an office. Keep a small, fixed amount of live meeting time in a slot chosen deliberately, and design everything else — reports, decisions, task ownership — so it works without everyone being awake at the same moment.
Most advice on distributed teams solves the wrong problem
Search for help managing a distributed team and you will find the same list everywhere: hold more meetings, increase overlap, set up virtual water coolers, check in often. Read it closely and you notice what it is really describing — how to make a distributed team behave like an office team.
That is patching a gap instead of designing for one. And the bill lands on your people: someone takes their tenth call of the day, someone else starts at 6 a.m. every morning so that a fifteen-minute status update can happen live, and a decision that could have been three written sentences waits two days for a slot in a calendar.
We are not against live meetings — we hold them in every team, every week, plus one for the whole company. The point is that live time is the most expensive resource a distributed team has, and it should be spent like one. Below is how we actually run it.
What is distributed team management?
Distributed team management is the practice of coordinating a team whose members work from different geographic locations, usually across multiple time zones, with no single place where the work happens. It covers how work is assigned and tracked, how decisions get recorded, how much synchronous meeting time the team spends, and which systems hold the team’s memory.
“Distributed,” “remote” and “hybrid” get used as if they were three boxes to pick from. They are not. Each answers a different question, and a team can be described by all three at once:
| Term | What it describes | The question it answers |
| Remote | People working away from an office, fully or partly | Where do people sit? |
| Distributed | A team spread across locations and time zones | How far apart is the team? |
| Hybrid | A model splitting work between office and elsewhere | How is office time divided? |
This article is about the distributed part, because that is where the office playbook breaks. If your whole team works from home in one city, most of the old habits still function: you can all be online at ten, a call costs nobody their evening, and a quick question gets answered in minutes. Spread that same team across nine time zones and every one of those assumptions fails.
The principle: design for distribution, don’t simulate an office
Everything below follows from one idea. Your team is not an office team with a distance problem to be closed. It is a different kind of team, and it needs a structure built for what it actually is.
In practice that means flipping the default. In an office, synchronous is free and written communication is the effort. Distributed, it is the other way around: writing costs a few minutes once, while a call costs everyone their attention at the same moment — and for someone in the team, that moment is inconveniently early or inconveniently late.
So: async by default, sync on purpose. Not async-only. A team with zero live contact drifts apart, decisions stall, and misunderstandings compound in text. You need real overlap. You just don’t need it to be the entire working day, and you don’t need a call every time something needs saying.
The 9 rules
These are the practices we use ourselves. Take them as a starting structure, not a prescription — the specifics should match your team’s spread and the kind of work it does.
1. Start from the work, not from the calendar
The first question when setting up a distributed team is not “when can everyone meet?” It is “which work genuinely needs two people awake at the same time?” When you actually write that list out, it is short: unblocking a stuck decision, giving sensitive feedback, working through a design nobody can describe in text yet, and keeping human contact alive.
Everything else — status, progress, handoffs, reviews, FYIs, approvals — has an asynchronous format that works at least as well and often better, because it leaves a record.
A simple test before you put anything in the calendar: can this be a written report, a comment on a task, or a short recorded walkthrough? If yes, it is not a meeting. If no, book it — and see rule 2 for how.
2. Keep sync time limited, regular, and deliberately scheduled
Live meetings should be a fixed, predictable part of the week rather than something that expands to fill the space. A structure that works well in practice: a few short team syncs per week — three is a reasonable default — plus one longer meeting for the whole company. In our case the team syncs are short by design, around fifteen minutes, and the company-wide meeting runs for an hour, once a week.
Two things matter more than the exact numbers.
Pick the slot deliberately. Do not schedule around whoever happens to be loudest or most senior. Map everyone’s working hours, find the window that is least bad for the group as a whole, and fix it. A predictable time that is slightly awkward for four people beats a “convenient” time that is impossible for one.
Share the cost of the awkward hour. Somebody always takes the early morning or the late evening. The failure mode is when it is always the same person — that reads as your time zone matters less, and it costs you people eventually. Rotate the inconvenient slot where you can, and keep track of who took it last. Inconvenience that is visibly shared gets absorbed. Inconvenience that always lands on the same person gets resented.
Two small practices make this much easier: publish meeting times in each participant’s local time, and put local public holidays in the shared calendar. Google Calendar does both, and it removes an entire category of avoidable friction.
3. Give every meeting an agenda — or don’t have the meeting
A recurring call with no agenda turns into a status update read aloud, which is exactly the thing that should have been written down. An agenda does not need to be formal. It needs to exist. Two or three lines posted before the call is enough: what we are deciding, what is blocked, what needs a second opinion.
Two habits that make this work:
- Let anyone add to it. Our weekly company meeting has an open agenda — anybody in the company can put something on it. That is what keeps it a working meeting rather than a broadcast.
- Write down what came out of it. Decisions made on a call and never recorded effectively did not happen, because half the team was asleep and the other half will forget by Thursday. Whatever was decided goes into the task tracker with an owner (see rule 6).
If nobody can name what a recurring meeting is for, cancel it and see whether anyone misses it. Usually nobody does.
4. Make a written report the heartbeat between calls
Short syncs cover the next day or two. They do not give the wider company any picture of what is happening, and they cannot — most people are not on them.
Our answer is a written report. Every person writes to the whole company at least twice a week: what got done, what did not, what broke, any ideas worth sharing, and — the part most teams skip — what they plan to work on over the next few days.
That last part does the heaviest lifting. It is what stops two people quietly building the same thing in parallel, and it lets someone in another time zone flag a conflict before it becomes rework, without waiting for a call.
There is a second benefit that nobody plans for. A written record means someone returning from vacation, joining a project, or picking up an incident can reconstruct two weeks of context in ten minutes. No distributed team gets that from meetings.
5. Put someone on duty, and let everyone see who it is
Each team puts one person on duty for the day — backend duty, for example. That person covers their area: they answer questions about it and take anything urgent that comes up.
We keep the duty schedule as a calendar in doBoard, so anyone in the company can check who is on duty right now without asking around. You tag that person in chat, or assign the urgent task straight to them.
The point is that it is always clear who to ask about a given area. Without that, questions go to everyone at once, and the whole team spends the day answering instead of working. A question with no obvious owner is also the one that sits unanswered — in an office someone would ask whoever is nearby, but across time zones it waits until the next day. With a duty schedule, one person handles that for their shift and the rest of the team is left alone.
6. Put the task tracker at the centre — chat is not memory
A decision that lives only in a chat thread has a half-life of about two days. Threads scroll, search is unreliable, and the person who needed the context was asleep when it happened.
Ownership, deadlines and the reasoning behind decisions belong in the task system, where they are still findable in six months. Chat is for the fast, disposable layer. The tracker is the record. We run all of ours in doBoard — our own project management tool, built in-house after we outgrew Basecamp 2, so treat that as a disclosure rather than a neutral recommendation. The principle holds whichever tool you pick: one place where work lives, and it is not the chat app.
Work also arrives from outside the tracker, and it is worth pulling in. Our GitHub issues used to sit in email among dozens of others, sometimes for weeks, so we connected GitHub to doBoard. A new issue becomes a task, ready to assign and discuss. What that removes is the extra step: nobody has to forward it, copy it across, or ping anyone to get it noticed. In a team spread across time zones each of those steps costs a day, not a minute.
7. Organise around ownership, not around overlap windows
Once a team spans more than about eight hours of difference, the shared working window shrinks to almost nothing. The instinct is to solve that with scheduling heroics. The better fix is organisational: split the work so that most of it never needs a cross-time-zone handoff in the first place. Teams with clear ownership boundaries can move at full speed inside their own window, and only coordinate across zones at the edges.
The related point is one most process advice gets backwards: don’t force every team to run the same way. Most of our teams work in a flexible, adapted version of agile — backlogs, estimates, short cycles, retrospectives — but nobody is following a framework by the book, and the specifics differ per team.
Process uniformity is a co-located instinct. It is easy to enforce when you can see everyone. Distributed, it mostly generates ceremony. What actually has to be consistent across teams is narrower: who owns what, where tasks live, and the reporting rhythm. Inside those constraints, let each team work the way it works best.
8. Watch the per-seat tax and the tool sprawl
A distributed team pays for its infrastructure in software instead of real estate, and that bill behaves differently than an office lease. Per-seat pricing means your costs grow every single time you hire, a structural penalty on exactly the thing distribution is supposed to make easy.
This is not theoretical for us. We started on Google Workspace at around $6–7 per seat per month. It is now $11.97, and it has gone up more than once a year. The product is genuinely good; the pricing model is the problem.
Two ways to push back:
- Self-host what is worth controlling. We run Matrix + Element as our corporate messenger. It gives us end-to-end encrypted chats, voice and video, and threads, and the data stays on our own infrastructure. The trade-off is real — you have to run that infrastructure — so this only makes sense for tools where control genuinely matters to you.
- Prefer flat pricing where you can get it. It is part of why doBoard is priced the way it is: from $5/month with unlimited seats, projects and tasks, with storage as the only thing that scales.
The other half of this rule is where you draw the line on new tools. The usual advice is a specialist app for each job, which is how teams end up with a dozen of them. The better question is not how many apps you have, but how many places someone has to look to find something. A suite that covers email, docs, calendar and calls counts as one place, not four. Ours comes down to three: Google Workspace, our chat, and doBoard. Before adding a fourth, it is worth asking whether it does something genuinely missing, or just something slightly nicer than what you already have.
Consolidating has its own price, and it is the first half of this rule. The more one vendor covers, the more its pricing decisions become yours to absorb. That trade-off is why we self-host the chat rather than take the version bundled with everything else.
9. Spend in-person time on what async genuinely cannot do
None of the above is an argument against seeing each other. It is an argument about what that time is for.
We keep physical offices, but they are for meeting third parties and the occasional face-to-face, not for doing the daily work. Once in a while the team gets together for a few days. That time is not spent on status or coordination; screen sharing already handles those perfectly well. It is spent on the thing screen sharing does not do, which is trust.
Budget for it deliberately. A distributed team that never meets does not fail loudly. It just slowly gets a little more transactional, a little more careful, a little less willing to say the awkward thing early.
Sync or async? A decision table
| Work type | Where it goes | Why |
| Status, progress, FYIs | Written report | Nobody needs to be awake for it |
| Task ownership, deadlines, decisions | Task tracker | Chat is not memory |
| Blocked decision, competing options | Short sync | Written ping-pong is slower here |
| Sensitive feedback, conflict, 1:1s | Call | Tone does not survive text |
| Something is broken right now | Named duty owner | One person, not @everyone |
| Team bonding | In person, occasionally | The one thing tools do not replace |
The stack we actually run
| Purpose | What we use | Why |
| Quick chat, voice, team rooms | Matrix + Element (self-hosted) | Encrypted, threaded, data stays ours |
| Meetings | Google Meet | Screen sharing that works on every device |
| Scheduling across time zones | Google Calendar + doBoard | Local-time conversion, per-country holidays |
| Email, docs, files | Google Workspace | Powerful, and the per-seat cost keeps climbing |
| Projects, tasks, decisions | doBoard (our own tool) | One searchable record of who owns what |
Five rows, but three places to look: the Google suite, the chat, and doBoard.
Five ways teams accidentally rebuild the office
- A stack that grew to too many tools. Every addition looked reasonable on its own. Now nobody knows where anything is, so people ask in chat, and chat becomes your search engine.
- The permanently sacrificed time zone. One person always takes the 11 p.m. call. Nobody ever mentions it. They leave a year later for reasons that sound unrelated.
- The standup that exists to prove people are working. If the meeting produces no decision and no unblocking, it is attendance monitoring with extra steps.
- Decisions made in chat threads. Perfectly reasonable at the time. Unfindable in three weeks, and invisible to whoever was asleep.
- One large team stretched across an impossible overlap window. No amount of scheduling fixes an org chart problem. Split it and give each part real ownership.
The short version
Distributed team management gets hard when you treat distance as a defect to be compensated for. It gets much easier when you accept the shape of the team and build for it: a small amount of live meeting time in a slot chosen on purpose, an agenda for every call, written reports carrying the load in between, one named person on duty, and a single searchable place where tasks and decisions live.
We run doBoard as that last piece — we built it for our own distributed team, and it is priced flat rather than per seat because we got tired of paying a tax for hiring. If you want the longer version of our internal rules, including the full tool stack, it is in our remote work playbook.
FAQ
It is the practice of running a team spread across locations and time zones, where no single office is the place the work happens. It covers how tasks are assigned and tracked, how decisions get recorded, how much live meeting time the team uses, and which systems hold the team’s memory between conversations.
They are not opposites, and a team can be both. Remote describes where people sit: away from an office, fully or partly. Distributed describes how far apart the team is: spread across locations and time zones. A team working from home in one city is remote but not distributed. A company with offices in three countries is distributed even if everyone comes into one of them.
Beyond roughly eight hours of difference the shared working window essentially disappears. That does not mean it cannot be done — we work across nine time zones — but it has to be solved through ownership boundaries rather than scheduling. Split into teams that can operate independently and coordinate at the edges.
It depends on the team and what it is working on. Some teams run a short daily standup and it earns its place; others do fine with a few syncs a week plus one company-wide meeting. What matters more than the frequency is that the call has a purpose beyond reading out status, and that a written report carries progress and plans in between, so nobody has to be online at a particular moment to know what is happening.
Map everyone’s working hours and pick the window that is least bad for the group, rather than the most convenient for the loudest person. Fix that slot so it is predictable, rotate the awkward one where possible, publish times in local time zones, and record anything that people may have to miss.
Fewer than most teams think. You need chat, a project management tool that holds tasks and decisions, and something covering email, docs, calendar and video calls. A single suite handles that last group, so the whole stack can be three places to look. We use Matrix and Element, doBoard, and Google Workspace.
Keep a duty schedule: one named person per team covering a given area at a given time, in a calendar anyone can check. We keep ours in doBoard. Anyone with an urgent question tags that person directly or assigns them the task, instead of paging the whole team or being passed from one person to the next across time zones.
Through consistency rather than proximity: predictable meeting rhythms, visible written reports, dedicated non-work chat rooms, and occasionally getting the team into the same place for a few days. In-person time should go towards trust and relationships, not status updates that email already handles.
For most knowledge work it is faster, because it removes the wait for a calendar slot and lets several people move in parallel. It is slower for genuinely unresolved decisions, where a fifteen-minute conversation can beat two days of comment threads. That is exactly what your limited live meeting time is for.
Leave a Reply