Managing a Remote Team: Practices That Scale Down to Five

The remote team management practices that hold up at five people are the plain ones: write things down before you explain them out loud, agree on a short daily overlap window instead of full shared hours, record every decision with who made it and why, keep all the work on one board everyone can read, judge people by what they finish rather than when they are online, hold regular one-on-ones, and onboard new people from a written checklist. None of them needs a people operations team or a new tool. Each is below, with what to do on Monday and what to skip at this size.

The specific rules a team agrees on, such as reply times and core hours, are collected in team norms examples. How channels and response times fit together is in async communication. This page is about the manager’s side: the habits that keep a small team working well when nobody shares an office.

Why small remote teams need a smaller playbook

Large remote companies publish detailed handbooks, and they are worth reading. But much of what they describe, such as meeting rotations across continents, dedicated documentation teams and formal review cycles, assumes scale. A team of five has different problems. Everyone knows everyone, so the risk is not anonymity; it is that everything lives in one person’s head, and that the manager becomes the only route between people. The practices below are chosen for that.

1. Write it down first

When someone asks how something works, answer in a document and send the link, even if a call would be faster today. The second person to ask gets the same link, and so does the next hire. GitLab’s guide to all-remote work↗ (opens in a new tab) lists “Written processes (over on-the-job training)” among the values that make remote work function, and at five people the payoff comes fast: the first time someone is out sick, the team still knows how to ship.

• Start with the three processes people ask about most, often deploys, invoicing and how to hand work to a client.
• Keep each one short enough to read in five minutes. Link, do not paste.
• Whoever changes a process updates its page the same day.

2. A short overlap window, not shared hours

Five people across three US time zones do not need eight shared hours. They need two or three, protected, when anyone can expect a quick answer or a short call. Outside that window, people set their own schedule.

Person    Based in       Works (local)     Works (Eastern)
Ana       Seattle        8 a.m. - 4 p.m.   11 a.m. - 7 p.m.
Marcus    Denver         8 a.m. - 4 p.m.   10 a.m. - 6 p.m.
Priya     Chicago        9 a.m. - 5 p.m.   10 a.m. - 6 p.m.
Sam       Atlanta        9 a.m. - 5 p.m.    9 a.m. - 5 p.m.
Luis      New York       8 a.m. - 4 p.m.    8 a.m. - 4 p.m.

Overlap (Eastern): 11 a.m. - 4 p.m.  ->  core window 1 - 3 p.m. Eastern

Pick a window inside the overlap rather than all of it, so everyone keeps a long stretch for focused work. Put any recurring meeting inside the window, and nothing else in it that could be a message.

3. Decisions in writing, with a window to object

In an office, people overhear decisions. Remotely, anyone not on the call simply does not know. Every decision that affects more than one person gets written down: what was decided, who decided, when, and why, including the option turned down. GitLab’s guidance on all-remote meetings↗ (opens in a new tab) suggests that when a meeting falls outside some participants’ time zones, you consider “confirming decisions and actions for 24-48 hours” so they can weigh in asynchronously.

Keep decisions in one place, not in meeting notes scattered across folders. A simple decision log is enough at this size. The discipline that matters is that a decision is reopened only with new information, not because someone missed the call.

4. One board for all the work

The single most useful thing a remote manager can do is make the work visible without asking for it. One board, with every piece of work on it and a lane that shows its status, replaces most “where are we on this?” messages. The project tracker template covers the columns; the rule here is that if work is not on the board, it is not planned, and a status update is a summary of the board, not a separate report.

• Review the board together once a week: stuck work first, then what comes next.
• Send one written update a week built from the board. The weekly status report template keeps it to five lines.
• Ask about work on the task itself, in its comments, so the answer is still there next month.

5. Results over presence

Green status dots measure nothing useful. Judge work by what was finished and how well, and say so explicitly, because remote employees often assume they are being judged by visibility and start answering messages at 10 p.m. to prove it.

• Agree on outcomes for each person’s next few weeks, written as results someone else could check.
• Model the hours you want. If the manager sends messages at midnight, the team will read that as the expectation. Write late if you like, but delay delivery: Outlook, for example, can hold a message in the Outbox↗ (opens in a new tab) until a time you choose.
• For hourly, non-exempt staff this is also a pay question. The Department of Labor’s fact sheet on hours worked↗ (opens in a new tab) says “Work not requested but suffered or permitted to be performed is work time that must be paid for by the employer.” Answering work messages after hours can count. Check with whoever handles your payroll.
• Skip monitoring software. It measures activity, and a team of five will notice what it says about trust.

6. One-on-ones that are not status updates

The board carries status, which frees one-on-ones for the things a board cannot hold: workload, friction with a teammate, what someone wants to learn next, and feedback in both directions. Remotely they matter more, because there are no hallway conversations to catch problems early. Keep them on the calendar and rarely move them. An agenda and a list of questions are in the one-on-one meeting template.

7. Onboard from a written checklist

A new remote hire cannot learn by sitting near people. Give them a written first two weeks: accounts to set up, documents to read, one small real piece of work in the first few days, and a named person to ask anything. The onboarding checklist template has the full list. Ask them after a month what was missing, and add it.

What to skip at five people

• A second tool for the same job. One chat tool, one board, one place for documents.
• Daily video standups by default. A written update does the job for most small teams; the daily standup post covers the async version.
• Metrics dashboards. At this size you can read the board.
• Formal processes copied from much larger companies. Adopt one practice at a time, when the problem it solves shows up.

Running a small remote team on fenbs

A fenbs team board holds the work for a remote team in one place. Tasks move through To Do, Next Up, In Progress and Completed, each has a note for the problem and a plan for how it will be done, and History records who changed what, with relative times. People join with a role set per company, so a contractor or a client can be given less than the core team.

• Written decisions go on the Decisions and rules page, with the person who decided. The decider is always a person. A rule is a decision that holds from now on, and every connected AI assistant reads the rules first.
• AI assistants such as Claude, ChatGPT, Cursor or Copilot join the board as members with roles, connected over MCP, and their changes are recorded under their own names, which helps when the team is never in one room to ask who did what.
• Copy as Markdown turns the board into text for the weekly update.

Be clear about the gaps. fenbs has no due dates, no assignee field you can set, no sprints and no time tracking. Owners and dates go in the task note, and hours stay wherever your team already records them.