Working Together

Goal: Reduce the time anyone spends guessing how to work, who decides what, or whether they’re doing well. This page covers the human layer; Workflow covers how code moves and Principles covers how we make technical trade-offs.

Decision Ownership

We optimize for speed by pushing decisions to whoever is closest to the work. Use this ladder:

• You decide and proceed — anything reversible and inside your feature’s stack: UX details, implementation approach within paved paths, library choices already in the stack.
• Decide, then post a heads-up — schema changes, new dependencies, anything touching another person’s surface. Post in #[xxxx Engineering] channel (such as ‘Frontend Engineering’) in our collaboration platform before merge, not after.
• Loop in your lead before committing — auth/permissions, data model changes, anything cross-cutting, anything that affects the roadmap or a customer commitment.

Default rule: if it’s reversible, make the call and tell us; if it’s one-way, ask first. (See “Point 6 - Small, Reviewable Changes” in Principles.)

Communication

• Async-first. Decisions live in writing — ADRs for architecture, the PR description or decision log for everything else. If it wasn’t written down, it didn’t happen.
• Response expectation: acknowledge within 1 hour during working hours. You don’t owe an instant answer — you owe a “seen, will reply in 15 minutes.” However, for urgent issues such as app downtime, an immediate response will be expected.
• Flag blockers within 2 hours. A blocked engineer staying quiet is the one failure mode that actually costs us.

What a Good Teammate Looks Like

The human complement to our engineering principles:

• Ask early over struggling silently. Asking after ~30 minutes stuck is the norm, not a weakness.
• Own your commitments. If a date slips, say so as soon as you know, with a new estimate. Surprises are the problem, not slips.
• Disagree and commit. Disagree reasonably before the decision; support it fully after.

Cadence

• Daily async standup — answered in the daily Basecamp check-in each morning before heads-down work. Three lines, no prose:

  • Yesterday: what I moved forward
  • Today: what I’m working on
  • Blocked: anything in my way (or “nothing”)

  We run this async on purpose — it keeps us coordinated without fragmenting maker time. The one rule: blockers get a response. If you post one, your lead either unblocks it, routes it, or resolves it.

• Weekly 1:1 (30 min), your agenda first — career, blockers, feedback in both directions. This is your time, not a status meeting.

• Weekly Engineering team planning (Monday) — what shipped, what’s next, what’s at risk.

• Weekly CTO Chat (Friday) — product direction, feature demo, product roadmap.

• Retro every 2 weeks (30–45 min). Order: (1) review last retro’s actions — did they land?; (2) everyone adds Keep / Drop / Try notes silently for 5 min; (3) cluster and discuss; (4) pick 1–2 actions, each with an owner and a date. Feedback on how the team is run — including the lead — is in scope and expected.

Feedback Norms

• Feedback is frequent, direct, and small — and is given close to the moment, not saved up. A “this missed the mark, here’s how” is a normal Tuesday, not a crisis.
• It runs both ways. Tell your lead when something they’re doing isn’t working.