All resources

Blueprint library

Communication · Startups

Communication Operating Models

A blueprint library for startup People leaders. Pick the edition that fits how your team actually works.

Most async Most real-time

No single right way

How your team communicates depends on how distributed you are, how much your hours overlap, and how you like to work. This isn't one blueprint, it's a set of editions for different operating models, built on a shared foundation.

A shared spine (the parts that are true on every model) plus per-paradigm editions (which only swap the deltas). Maintain the spine once; the editions inherit it.

The six communication modes

The tools exist regardless of how sync-heavy you are

The "where should this go?" decision flow

The routing logic is universal; only the defaults shift

The scenario playbook

What "good" looks like per scenario is stable

Anti-patterns & the cross-tool workflow

Buried decisions and pointless meetings are bad everywhere

"Write decisions down somewhere findable"

The one rule no model escapes

The spectrum

Four operating models from most async to most real-time. Click to explore an edition.

Pick your model

Answer five questions about your org. Mostly one column → that's your edition. Split down the middle → we recommend the more-async option; it's easier to add sync than to claw it back.

1.How wide is your time-zone spread?

2.Daily real-time overlap between people?

3.Where do people work?

4.Cultural preference?

5.Should a decision ever be made live?

0 of 5 answered

Most async Most real-time

Async-First edition

Where we sit: Async-First

We're remote-first across a handful of time zones with some overlap. Writing is our default operating mode because we're rarely all online at once, and because it's more inclusive. We escalate to live conversation only when the task truly calls for it, and we always leave an async path for anyone who can't be there.

Working across time zones

  • ·Assume the other person is offline. Write self-contained messages: context, the ask, the deadline, and the link.
  • ·No decision is made live without an async window. Share the proposal first, give a fair window for input, then confirm.
  • ·Record meetings and broadcasts by default, someone is usually missing.
  • ·Protect overlap hours for genuinely sync needs; don't burn them on status updates.
  • ·Rotate meeting times fairly so the same region isn't always taking the 6am or 10pm call.
  • ·Schedule messages for the recipient's working hours; never expect replies outside someone's hours.

Live: Google Meet

A meeting earns its place only when it produces a tangible outcome faster or better than async. Live time is scarce across time zones, guard it, and record it.

A meeting is worth it for

  • 1:1s
  • Critical or sensitive feedback
  • Project kick-offs (after the prep doc)
  • Customer-facing sessions
  • Retros and demos
  • Team face time and meeting new people

Skip it: do it async

  • Brainstorms (canvas/doc + talk after)
  • Status updates
  • Repeating documented things
  • Simple decisions
  • Building reports
  • Always have an agenda (a doc) and a clear desired outcome.
  • Pre-read beats presenting, if you'd talk at people for the first 15 minutes, send a doc or Loom instead.
  • End with owned actions (who, by when) and write the outcome into the wiki, linked in chat.

Broadcast

In this model: Live and recorded, with a written recap so nobody who was offline is left out.

Leadership comms cadence

A short, predictable written post from leadership each week does more for alignment than any meeting.

  • · Headline: the one thing that matters most this week
  • · Wins: progress and shout-outs
  • · Priorities / focus: what we're pushing on and why
  • · Metrics: a couple of numbers that show how we're doing
  • · Asks / decisions needed: where leadership needs input or a call
  • · Link to detail: back to the hub / roadmap, comments open
CadenceWhatChannel
WeeklyLeadership update; events reminderWritten post in wiki + chat reminder
Weekly / bi-weeklyProject and team statusWritten update, linked from hub
MonthlyDeep-dive; success storiesLoom or short doc, shared in chat
Bi-weekly / monthlyAll-hands (updates, demos, Q&A)Meet + recorded + written recap
QuarterlyOKR review; AMAAll-hands + wiki recap + AMA form

Response-time expectations

ChannelReasonable expectation
Live Meet / HuddleReal-time, during the call
Chat DM or @mentionWithin the recipient's next working day
Chat channel (no mention)When they get to it, no pressure
Doc comment / LoomWithin the author's stated window
Outside someone's working hoursNo expectation until they're back online

Rule of thumb: Urgency lives in sync tools; everything else is async and patient. If it's truly urgent, say so and use a sync channel during overlap hours.

The toolkit

Tool names change; the modes don't. Match the mode to the job, then use whichever tool you have for that mode.

ModeTypical toolsWhat it's forLifespan
Docs / WikiSlite, Notion, ConfluenceKnowledge, decisions, processes, memos, anything that should outlive the conversationForever / for future hires
ChatSlackCoordination, quick questions, announcements, day-to-day chatDays to a few weeks
Async videoLoomWalkthroughs, demos, nuanced or personal messages where tone and visuals matterAs long as it's linked
Visual canvasMiro, FigJam, FigmaBrainstorms, workshops, mapping, retros (Miro/FigJam); design and UI review (Figma)Project to forever
LiveGoogle Meet, HuddlesHigh-bandwidth discussion that reaches an outcome faster than writingThe length of the call
BroadcastTown hall / all-hands, AMACompany-wide updates, vision, morale, sensitive news, open Q&ARecorded + written recap

Where should this go?

The decision flow: routing logic that works on every model.

  1. 1

    Does this need an immediate answer? Yes → Chat (or a Huddle / Meet). No → keep going.

  2. 2

    Can I explain it clearly in writing or a short recording? Chat for quick things; a doc for anything substantial; a Loom if tone or a screen-walkthrough helps.

  3. 3

    Do people need time to reflect? Async gives everyone space to contribute thoughtfully.

  4. 4

    Is this divergent / spatial thinking? (ideas, mapping, journeys) → a visual canvas.

  5. 5

    Am I just sharing info or a status update? That's async. No meeting required.

  6. 6

    Does the whole company need to hear it, with room for questions? → Broadcast (town hall / AMA), backed by a written recap.

  7. 7

    Does it need to be found later? It lives in the wiki, wherever the conversation happened.

Scenario playbook

The toolkit tells you where; this tells you what good looks like in the moments people actually hesitate.

Written memo (wiki) + comment window

Propose a significant decision or change

A memo forces clear thinking and lets everyone engage on their own time. State the problem, options, your recommendation, and the decision needed. Share in chat, set a 48 to 72h comment window, then confirm the decision in the same doc.

Comments in the doc

Get structured feedback on a draft

Inline comments beat a meeting, quieter and offline voices weigh in equally. Be explicit: "Feedback by Thursday; I'll assimilate and share v2."

Loom (async video)

Explain something nuanced, visual, or where tone matters

A 3 to 5 min recording carries warmth and can walk through a screen in a way text can't. Pair it with a one-line TL;DR and the doc link.

Visual canvas (Miro / FigJam)

Brainstorm, workshop, map a journey or run a retro

Spatial, divergent thinking that a linear doc kills. Seed the board with structure first; use silent-write time so it's not just the loudest voices.

Figma

Review designs or give feedback on the actual UI

Comment directly on the frames so feedback is anchored to what it refers to. Keep decisions and rationale in the doc.

Town hall / all-hands

Share a company-wide update, vision, or sensitive news

High-trust moments deserve face time and live Q&A. Keep it tight, leave room for questions, record it, and post a written recap.

AMA

Open the floor to questions for leadership

Collect questions in writing beforehand, answer, and publish written answers so the whole team can refer back.

Written update

Give a routine status / progress update

Never a meeting. A short post every 1 to 2 weeks: what's done, blockers, next steps. Link it from the relevant hub.

Multi-channel sequence

Roll out a big change well

Town hall announcement → wiki doc + Loom walkthrough → Slack TL;DR + links → manager 1:1s → AMA. Repetition across mediums is what makes a message land.

Mode deep-dives

Shared guidance on each communication mode.

Docs / Wiki: the knowledge layer+Slite, Notion, Confluence…
  • · Use for: decisions and reasoning, memos, processes and how-tos, project briefs, meeting notes and outcomes, team/role docs, anything a future hire would benefit from.
  • · Write the decision, not just the discussion, what was decided, why, and who owns the next step.
  • · One source of truth. If it's in the wiki, link to it rather than re-explaining. All comms link back to a central hub.
  • · Make it findable with clear titles, structure, and tags. A doc nobody can find doesn't exist.
  • · Keep it live. A stale doc is worse than no doc, update or archive.
  • · Pre-read, then meet. Pre-reading plus shared questions can cut a 60-minute meeting to 20.
Chat: the coordination layer+Slack
  • · Public by default. Channels over DMs, so knowledge stays shared and searchable. DMs hide information and create silos.
  • · Right audience, right room. Before posting company-wide, ask: does everyone need this?
  • · Reply in threads, always. Threads keep channels readable and let people catch up later.
  • · Give context and state the ask: an answer by when, a decision, an FYI, or nothing. Say which, and link the doc.
  • · Assume good intent, written text loses tone. Use reactions (✅ seen, 👀 on it) to close loops without noise.
  • · Huddles are the lightweight sync option for quick "let's just talk for two minutes" moments.
Async video: Loom+Loom
  • · Reach for it when: you're walking through a screen or demo, explaining the thinking behind a doc, delivering a message where warmth and tone matter, or onboarding someone to a process.
  • · Keep it short (aim 2 to 5 min) and lead with the "so what" so people stay engaged.
  • · Always pair with text: a one-line TL;DR plus the relevant doc link, so people can skim or skip.
  • · Don't use it for simple things text handles, or anything needing live two-way discussion.
Visual collaboration: Miro, FigJam and Figma+Miro, FigJam, Figma
  • · Use a canvas when thinking is spatial or divergent and a linear doc would flatten it.
  • · Miro / FigJam: brainstorms, workshops, journey and system mapping, affinity clustering, retros, offsites.
  • · Figma: product/UI design, design reviews, visual feedback on real screens.
  • · Seed structure first. A blank canvas intimidates; pre-build frames, buckets, or a template.
  • · Use silent-write time so it's not just the loudest voices.
  • · Canvas is for thinking, the wiki is for deciding. Always capture the outcome and decision back in a doc.
  • · Don't use a canvas for linear text, a simple decision, or a quick question.
Broadcast: town halls, all-hands and AMAs+Town hall / all-hands, AMA
  • · The company-wide layer for alignment, trust, and morale. Structure beats sprawl.
  • · Announcements: revenue/metrics and major news
  • · People: hiring, new joiners, leavers, promotions, birthdays and anniversaries
  • · Acknowledgements: kudos and shout-outs
  • · Topic of the day: a short exec deep-dive on one theme
  • · Q&A / AMA: ask leadership anything (collect questions in advance)
  • · Demos: short, "so what"-first show-and-tell of recent work

Deltas matrix

Everything not listed here comes from the shared spine. This is the maintainer's map of what changes across editions.

DimensionFully AsyncAsync-FirstHybridSync-First
Default stanceWrite / record everythingAsync unless sync clearly winsSync in core hours, async otherwiseReal-time first; docs record it
Real-time ever mandatory?No: always optionalMinimal (a few rituals)Yes, in core hoursYes: the primary mode
MeetingsRare, optional, always recorded; never where decisions happenMust pass "outcome faster than async"; recordedNormal & expected, but need agenda + outcome; default-recordFrequent & expected; record only when someone's out
Response timesWorking-hours / next-day; zero immediacy pressureNext working day for DMs; patient otherwiseSame-day in core hours; async outsideFast during work hours; chat near-real-time
Time zonesBuilt for zero overlapSome overlap helpful; rotate meeting timesAssumes meaningful overlap / core hoursSingle zone assumed
Decision-making100% async with comment windowsAsync window before any live confirmCan decide live, but document + short async window for absent voicesDecide live, then write up for the record
Broadcast cadenceRecorded + written; live attendance optionalLive + recorded + recapLive (in-person + streamed) + recordedIn-person all-hands; recorded for the few who miss
Centre of gravityThe wikiWiki decides, chat coordinatesSplit: meetings + chat for momentum, wiki for recordPeople + meetings; wiki is system of record
Visual collabAsync boards over a windowAsync or live, both fineOften live workshops + async bridgesLive whiteboarding (physical/digital)

Cross-tool workflow

1.Wiki: Write the brief / memo / proposal.
2.Chat: Share the link, set a feedback window, gather input in-thread.
3.Canvas or Loom (if it helps): Map it out visually or record a walkthrough.
4.Meet: Talk through the genuinely contentious bits.
5.Wiki: Record the decision, reasoning, and owners.
6.Chat / Broadcast: Announce the outcome and link back to the doc.

Anti-patterns to watch for

  • Decisions that only exist in a chat thread or on a canvas, they vanish. Move them to the wiki.
  • Meetings that could have been a doc or a Loom, especially status updates and one-way broadcasts.
  • Important info buried in DMs, if others need it, it belongs in public or the wiki.
  • A blank-canvas brainstorm with no structure, seed it first, or you get silence.
  • Re-explaining documented things, link, don't retype.
  • A town hall with no recap, someone always misses it.
  • Decisions made live with no async window, they exclude everyone offline.
  • Expecting instant chat replies, that's what sync channels are for.

Async-First

Quick reference

Forever? → Wiki · This week? → Chat · Show / explain? → Loom · Think it out together? → Canvas · Talk it out now? → Meet · Whole company? → Broadcast.

  • · Before a meeting: could this be a doc, a Loom, or a canvas + comments?
  • · Before posting company-wide: does everyone need this, or is it a thread / DM / link?
  • · Before deciding live: has everyone offline had an async window to weigh in?
  • · After every decision: is it written down somewhere findable?

More open resources

Other free templates and diagnostics from Open Org.

Principles adapted from established distributed-team handbooks: Open Org, PostHog, GitLab, HelloBetter, Airalo, Mostly AI, Cal.com and Sourcegraph.

Want help applying this in your org?

Join Open Org Workspace