---
summary: "Orbit operating model: remote-first, written-first, weekly rhythm, decision process, escalation policy, and standing operating norms."
usage_mode: auto
sort_order: 0
tags:
  - policy
  - orbit
refs:
  - orbit-company-overview
  - customer-communication-policy
---

## How We Work

**Source:** Notion - Orbit Demo Home / How We Work, last edited 2026-05-07

---

## Operating Model

- Orbit is a **mostly remote, mostly written** company.
- Meetings must serve a specific purpose: making a decision, unblocking a handoff, or building shared context that writing alone would be slower to achieve.
- If a meeting does not meet one of those three purposes, default to async written communication.

---

## Weekly Rhythm

| Day(s) | Focus |
|---|---|
| **Monday** | Commitments and dependency checks |
| **Tuesday – Thursday** | Customer calls, product work, implementation, and building |
| **Friday** | Closing loops - review what shipped, what slipped, and write down any decisions |

Use this rhythm when scheduling work, meetings, or reviews. Do not schedule decision-making meetings on Fridays; use Friday to record decisions already made.

---

## Decision-Making Process

1. **The person closest to the work writes the recommendation.**
2. **Stakeholders who will live with the decision get to push back.**
3. **The accountable lead makes the call** when a real tradeoff exists.
4. **The result is written where the work is happening.** Decisions that exist only in Slack or a meeting are not considered durable.

> A decision that isn't written down didn't happen.

---

## Standing Operating Norms

These are explicitly codified rules Orbit has identified as recurring failure modes:

- **Name the accountable person before work begins.** If no one is named, no one is accountable.
- **Never let a quick sync be the only source of truth.** Write it down after.
- **Bring a customer example when proposing product changes.** Abstract proposals without customer grounding are harder to evaluate.
- **Involve affected teams before a plan is finalized.** Surprises in execution are more expensive than slower planning.
- **Prefer a rough written decision today over a perfect recap that never gets written.** Done and documented beats polished and lost.

---

## Escalation Policy

- **Escalations are coordination tools, not indicators of individual failure.** Escalating is the correct behavior when a problem exceeds the current team's ability to resolve it alone.
- When escalating, the person escalating must:
  1. Bring in the right people (those with authority or context to unblock).
  2. Summarize current state clearly - what has been tried, what is blocked, and why.
  3. Name the customer impact explicitly.
  4. Keep updates moving until the risk is resolved or a workaround is established.
- Escalations that stall because no one owns the next update are a process failure, not a customer failure.
- An escalation is closed when the risk is resolved or a documented workaround is in place - not when the immediate noise stops.

---

See also: [[orbit-company-overview]], [[orbit-team-lanes-detail]], [[customer-communication-policy]]
