How to Build a Remote Work Policy
That Actually Works
Most startup remote work policies are either non-existent (“we’re flexible”) or copied from a large company template that doesn’t fit a 12-person team. The result is ambiguity that costs you in hiring, culture, and productivity. Here’s how to build one that’s honest, specific, and actually followed.
- Choosing your model — the four options and what each requires
- The systems that must match your model
- Async-first communication — what it means in practice
- The documentation standard that makes remote work functional
- Timezone management without burning out your team
- In-person moments — when to bring the team together
- Writing the policy itself
Choosing Your Model
There are four coherent remote work models. The problems come not from choosing any of them, but from claiming one and operating like another.
Fully in-office: everyone in the same building most days. Decisions happen in hallways and whiteboards. Fast coordination, limited talent pool, high real estate cost. Only works if your whole team is in one city and you can afford to pay city-level salaries for city-level talent.
Hybrid with anchor days: everyone remote most days, 2–3 mandatory in-office days per week. Works when you have a meaningful concentration of team in one geography and the in-person time is genuinely used for the work that benefits from it — not just meetings that could be async.
Remote-first with hubs: primary hiring in a handful of cities, occasional in-person. Most communication is async. Works well for early-stage companies hiring across 2–3 cities without committing to a lease.
Fully distributed: no primary office, async-first, hires anywhere. Access to global talent, lowest overhead, hardest to build culture and coordination systems. Works when the team has strong writing discipline and you invest in regular in-person offsites.
The most expensive remote work mistake: claiming “we’re remote-first” while defaulting to synchronous communication, in-person decision-making, and promotion patterns that favour people who happen to be in the same timezone as leadership. Distributed employees notice within weeks. The attrition that follows costs far more than the clarity of committing to a model would have.
The Systems That Must Match Your Model
Every remote work model requires four downstream systems to match. If they don’t, the policy is fiction.
Hiring geography: in-office means hiring in one metro. Distributed means hiring anywhere. Hybrid requires being explicit about which roles are location-flexible and which aren’t — ambiguity here creates resentment when someone moves and finds out their career options changed.
Meeting culture: in-office teams default to synchronous meetings. Distributed teams must default to async, with synchronous meetings as the escalation path for decisions that genuinely need real-time discussion — not just easier. If your distributed team has the same meeting load as an in-office team, you’re paying the coordination cost without the culture benefit.
Documentation standards: distributed teams live and die by written communication. Decisions made verbally on a call without a written record don’t exist for anyone who wasn’t on the call. This isn’t optional — it’s the infrastructure of a distributed team. See our team update playbook for the written cadence that keeps everyone aligned.
Compensation: fully distributed teams face a choice on location adjustment — do you pay San Francisco rates everywhere, adjust by cost of living, or pay local market rates? Each is defensible; what’s not defensible is being inconsistent about it. Publish the policy clearly and apply it consistently from the first hire.
Async-First Communication in Practice
Async-first doesn’t mean slow or unresponsive. It means the default is to communicate in a way that doesn’t require the recipient to be available at the moment you send it. The practical rules that make async work:
Write decisions down, not just meeting notes. “We decided to do X because Y, and the owner is Z with a deadline of [date]” — in a shared channel or doc, immediately after the decision is made. The meeting note that summarises discussion without capturing the decision is not useful to anyone who wasn’t there.
Set response time expectations explicitly. “We aim to respond to Slack messages within 4 hours during working hours” removes the anxiety that comes from not knowing whether silence means busy or missed. Different channels can have different SLAs — urgent, normal, and FYI.
Default to over-communication on context. Async communication strips the body language, tone, and real-time clarification that in-person communication relies on. The remote team member who writes short, context-free messages creates ambiguity that costs more time to resolve than the message saved. Train for verbosity on context, brevity on conclusions.
The Documentation Standard
Every remote team needs three categories of documented information: how we work (the remote policy itself, meeting norms, communication tools and their purposes), what we’ve decided (a lightweight decision log — what was decided, why, who owns it), and what we know (product documentation, onboarding guides, process SOPs). Without these, every new hire starts from zero and every team member is one resignation away from irreplaceable tribal knowledge walking out the door.
The documentation system that actually gets used: Notion or Confluence for structured docs, a consistent naming convention, and a “documentation is everyone’s job” norm enforced from the top. If the founder doesn’t write things down, nobody will. Use our AI Prompt Pack for Ops to generate SOPs and documentation templates fast.
Timezone Management
For teams spanning more than 4 hours of timezone difference: define a “core overlap window” — 2–4 hours per day when everyone is expected to be available for synchronous communication if needed. Protect it. Don’t schedule optional meetings outside it. Use it for the weekly team sync and the decisions that genuinely need real-time discussion.
The principle that prevents timezone resentment: no single timezone should bear the full cost of overlap. If your US team always meets at 9am their time and your Asia-based team always joins at 10pm, that’s not a distributed team — that’s a US team with remote contractors. Rotate meeting times, or split the team into timezone-coherent squads with async handoffs between them.
In-Person Moments
Even fully distributed teams need in-person time. The research is consistent: the relationships, trust, and cultural alignment that in-person time builds are harder — not impossible, but harder — to build purely remotely. Two to three company-wide offsites per year (3–4 days each) is the minimum for a distributed team that wants to maintain genuine cohesion. Budget for it from the start — it’s cheaper than the turnover that comes from a disconnected team.
What to use in-person time for: relationship building, strategic alignment, and the creative and collaborative work that genuinely benefits from being in a room together. Not status updates, not individual heads-down work, not meetings that could have been async. The offsite that’s just a series of presentations is an expensive waste of travel time. See our team offsite playbook for the agenda design that makes it worth it.
Writing the Policy
A remote work policy that works is under 2 pages and covers: the model (which of the four, clearly stated), hiring geography expectations, core hours or overlap windows, response time expectations by channel, documentation standards, equipment and home office support, and how in-person time is handled. It’s a living document — review it when the team grows significantly or when the model changes.
“Write a remote work policy for my startup. Model: [describe — fully remote, hybrid, etc.]. Team size: [number]. Geographies represented: [list timezones or cities]. What’s currently ambiguous or causing friction: [describe — e.g. unclear response time expectations, inconsistent meeting load, uncertainty about hiring geography]. Write a clear, concise policy (under 2 pages) covering: (1) Our model and what it means in practice, (2) Core hours or overlap expectations, (3) Communication norms — which tools for what, response time expectations, async vs sync defaults, (4) Documentation expectations, (5) Equipment and home office support, (6) How in-person time works. Write it in plain language — direct and specific, not corporate. It should read like something our team would actually use.”
Get 50 more prompts for ops, team management, and company building — free.