Ways of Working
This document is how the Foxy team decides what to build, plans it, executes it, and ships it. It’s the reference for anyone landing on the team or asking “how do we run things around here?”.
One rule above everything
Linear is the source of truth. Slack is for discussion. If work is real, it exists in Linear — ideas, bugs, product work, maintenance, R&D, urgent fixes, decisions, blockers, sign-offs, release notes. No invisible work, no work tracked only in Slack, no work hidden in DMs.
The shape of work
We operate an issue-first system inside Linear’s Foxy team. Three layers:
| Layer | What it is | Cap |
|---|---|---|
| Project | A container that groups related Issues and gives them context | No hard cap — but it should trend toward Done; one that only accumulates Issues with no outcome is a junk drawer |
| Issue | One meaningful, releasable unit of value | ≤ 8 points of total effort |
| Subissue | One person, one cohesive PR-sized change | ≤ 5 points |
Projects give context, Issues carry priority, Subissues carry execution. Execution decisions happen at the Issue level, never the Project level.
Caps are in points (Linear tracks points; roughly 8 pts ≈ a week, 5 pts ≈ a few days). Split, don’t stretch. An 8-point Subissue should be split; a 13-point one must be split before execution.
Milestones are an optional tool for phasing a large Project (e.g. T-Bone → Core Moderation / Character Workflows / Output QA). They carry no gate or status and are never required.
What fits where
- Project — a coherent area of work that will hold many Issues over time. Billing & Compliance, Content, Characters, Platform, Data, Social, Team Intelligence. Not: a single deliverable (that’s an Issue), or a grab-bag that never reaches Done.
- Issue — one releasable thing with one outcome, one priority, one owner, one QA surface, one release meaning, and clear in/out scope. “Add EmerchantPay as a payment processor”, “[BUG] Fix KYC duplicate handling”, “Ship Co-Stars invite flow v1”. Not: “Small UX fixes”, “Billing improvements”, “misc work for this week”.
- Subissue — one cohesive change, one owner, an estimate, a clear link to the parent. “Add backend endpoint for invite creation”, “Wire frontend button to the API”, “QA checkout success and failure states”. Not: “Fix frontend”, “Backend work”, “Handle edge cases”.
Splitting heuristics
- Can it ship by itself? No → split.
- Doesn’t share one outcome / priority / owner / QA path / release path? → it’s more than one Issue.
- Touches more than two services? Probably 2+ Issues.
- Exceeds 8 points, or more than ~5 Subissues under one Issue? Probably 2 Issues.
- “Figure out X first” → a small R&D Subissue (a spike) whose output feeds the real Issue.
Authority model — the two gates
There are two gates, one default owner each. Gating lives at the Issue level.
| Gate | Transition | Owner | Asks |
|---|---|---|---|
| Gate 1 — Planning | Backlog → Selected for Planning | Sam | Is this worth planning? (protects planning capacity) |
| Gate 2 — Execution | Planned → Selected for Execution | Law | Is this clear, ready, and important enough to execute now? (protects execution capacity) |
Default ownership is stage-based, but the person closest to the risk weighs in when work crosses lanes: Sam on product/UX/customer-facing planning; Law on technical/architecture/infra/execution-risk. Grey areas → Sam and Law ping each other. The goal is one clear owner plus judgment when work crosses lanes — not dual approval for everything.
Roles in plain language
- Sam — owns Gate 1. Decides what’s worth planning, keeps the Selected for Planning and Selected for Execution queues ordered, and sets priority (Linear’s native field). Heavy on product, UX, customer-facing, business-sensitive, strategically-ambiguous judgment.
- Law — owns Gate 2. Decides what planned work is selected for execution. Heavy on technical, architectural, infrastructure, feasibility, sequencing, system-design judgment.
- Issue Lead — end-to-end owner of one Issue: scope, planning quality, Subissue breakdown, estimates, risks, coordination, blockers, readiness for the next gate, and handoff into QA/review. Usually the assignee.
- Subissue assignee — one human per Subissue; owns it through its lifecycle.
- Sourabh / QA — owns Triage and owns Done / On Prod (blesses it). No engineer self-marks Done. If Sourabh is unavailable, Law or Pawel may handle urgent triage/release decisions.
Projects are containers, not gates — they need no separate lead. Ownership lives at the Issue level.
Lifecycle
Project statuses
Projects are containers, not commitments. Three statuses:
| Status | Meaning |
|---|---|
| Active | An area of work that matters now; shows visible movement. Active doesn’t mean every Issue inside is approved — Issues follow their own lifecycle. |
| Done | Purpose achieved; remaining work shipped, moved, or intentionally dropped. Mostly for time-bounded initiatives, not permanent product areas. |
| Canceled | The area was intentionally abandoned; open Issues canceled or moved. The Project remains as historical context. |
Maintenance is not a Project status — it’s an Issue label (see below).
Issue lifecycle
These are the exact Linear status names — use them as written.
Triage → Backlog → Selected for Planning → Planning in Progress → Planned → Selected for Execution → In Progress → In Review / QA → Done / On Prod| Status | Meaning / who |
|---|---|
| Triage | Defects land here; Sourabh routes (urgent bypass invoked here). |
| Backlog | Captured, not approved for planning. |
| Selected for Planning | Gate 1 (Sam) — worth planning. |
| Planning in Progress | Issue Lead turns it into an executable plan (incl. R&D spikes). |
| Planned | Clear enough to execute — satisfies the Planned checklist below. |
| Selected for Execution | Gate 2 (Law) — ready to pick up when capacity opens. |
| In Progress | Work started — only legitimate to enter from Selected for Execution (or an exception). |
| In Review / QA | Ready for review and testing. No engineer self-marks Done. |
| Done / On Prod | Complete, accepted, released. Sourabh / QA blesses. |
Terminal: Canceled (anyone may cancel, with a one-line justification) and Duplicate (set in Triage; link the original).
Blocked work uses the BLOCKED label — there is no Blocked or On Hold status. The weekly report queries on that label. In conversation we sometimes say “greenlit” for an Issue that’s passed Gate 2 — in Linear that’s Selected for Execution.
Subissue lifecycle
Shorter — it inherits planning/gating from its parent and only tracks execution:
Backlog → Planned → In Progress → DoneMoving a Subissue to Planned is just the Issue Lead/assignee marking the chunk ready to pick up — not a gate. Formal QA lives at the Issue level (Sourabh blesses the parent Issue, not each chunk).
The “Planned” checklist
An Issue is Planned only when it has enough clarity to execute: clear outcome · included scope · excluded scope · Issue Lead · Subissues · estimates · dependencies · risks · QA / acceptance criteria · rollout notes (where relevant) · rollback notes · R&D results (where relevant) · design/product notes (where relevant).
Rollback notes are mandatory (not “where relevant”) for any Issue touching payment behavior, KYC, moderation logic, security behavior, or data/analytics semantics — the reversal plan must exist before execution.
Triage, severity, and priority
All new defects land in Triage for Sourabh to route. Severity and priority are different things.
Severity — how bad is the problem? Applies to defects only, set via a dedicated label in Triage.
| Severity | Routing | Response cadence |
|---|---|---|
| P0 — critical (outage / user harm) | straight to Selected for Execution | drop-everything; update every 15–30 min |
| P1 — urgent (major degradation) | straight to Selected for Execution | same-day mitigation; 24-hour fix plan |
| P2 — important (localized defect/debt) | Backlog, normal flow | weekly triage; named owner, due-week |
| P3 — routine | Backlog, normal flow | as capacity allows |
P0 is the only level with a forced update clock; everything else runs on normal Linear hygiene plus the weekly report.
Priority — when should we do it? Set by Sam on Linear’s native priority field (low/medium/high/urgent), always kept current so the team picks the topmost available item. Don’t set priority yourself — Sam owns it.
Exceptions
Most work follows the normal flow. There are exactly two exceptions.
- Tiny work — work under 1 point may skip the gates only if it’s also low-risk, reversible, non-strategic, not sensitive, and doesn’t meaningfully change user behavior. Allowed: typo, copy polish, minor internal admin fix, log cleanup, simple dep bump, small test fix, obvious visual glitch. Never allowed however small: cookie consent, billing, payment flow, KYC, moderation logic, security, data/analytics semantics, major UX behavior, new user-facing feature, redesign.
- Urgent work — production incident, critical payment failure, critical CS blocker, urgent compliance exposure, major user-impacting bug, or provider outage may go straight to Selected for Execution or In Progress. Mark it with the
EXPEDITEDlabel and document: what happened, why it bypassed normal flow, who handled it, what changed, and what follow-up is needed. Urgency is not a loophole for unplanned feature work.
R&D and spikes
R&D exists to unblock planning. Spikes live as Subissues under an Issue in Planning in Progress, never as side work. Every spike defines: research question, why it matters, expected output, owner, estimate, time box. The Issue Lead may spend up to 3 points on R&D/spikes without extra approval; beyond 3 points or past the time box, the Lead stops and flags it for sign-off (Law for technical/architectural/execution-risk research; Sam for product/UX/business/compliance). When a spike ends, the owner reports what was learned, what’s still unknown, a recommendation, and whether the parent Issue should continue, split, pause, or be canceled.
Estimates
All Subissues must be estimated; Issues should be too (summed from Subissues or set as expected total effort). Linear’s native estimate field, Fibonacci scale:
1 · 2 · 3 · 5 · 8 · 13
Estimate during planning; re-estimate if scope changes. 8-point Subissues should usually split; 13-point must split before execution. If work can’t be estimated, create an R&D spike first. Estimates are shared understanding, not promises.
Labels
| Group | Values |
|---|---|
| Severity | P0 · P1 · P2 · P3 (defects only) |
| Service | Brain · Brisket · Sirloin · Fennec · Round · Strip · Chuck · Shank · Flank · Other |
| Type | Bug · Feature · Improvement · Maintenance · R&D |
| Standalone | BLOCKED (in place of a Blocked status) · EXPEDITED (marks an Issue that bypassed gating) |
| Config | chargebee-config · klaviyo-config · primer-config |
Maintenance
Maintenance is upkeep — dependency bumps, small refactors, cleanups, log-noise reduction, flaky-test fixes, doc fixes, minor bug fixes, small performance cleanups. It’s an Issue type/label, tracked under whatever relevant Active Project — there is no Maintenance Project status and no standing “Maintenance Project”. Small maintenance can move fast via the tiny-work exception (same low-risk/reversible/non-strategic test); non-trivial maintenance runs the normal flow. Maintenance is not a hiding place for features — new user-facing features, redesigns, payment-processor integrations, KYC/moderation changes all run the full flow.
Weekly visibility
Cadence comes from Linear hygiene plus a weekly aggregate report — not sprints. We don’t use Linear Cycles; Issues flow continuously as capacity opens.
Queue review cadence:
- Triage — reviewed daily by Sourabh (urgent items same-day).
- Backlog → Selected for Planning — Sam reviews weekly and prioritizes; anything pinged urgent sooner.
- Selected for Planning / Selected for Execution ordering — Sam keeps ordered weekly.
Weekly report — health metrics: story points completed (total + by person) · throughput by area/Project · anyone overloaded or with nothing visible.
Weekly report — exceptions to surface: Issue In Progress without Selected for Execution · Issue missing owner · Issue missing estimate · Subissue missing estimate · planning work with no owner · Maintenance that looks like feature work · urgent work that bypassed normal flow · blocked work (BLOCKED label) · stale work · R&D exceeding 3 points without sign-off.
What should never happen
Work only in Slack/DMs · an Issue starts without being Selected for Execution (outside the two exceptions) · feature work hiding in Maintenance · the urgent path used to avoid planning · the tiny-work exception used for sensitive work · an Issue with no clear owner · a Subissue with no estimate · an engineer self-marks Done · an R&D spike runs past its time box with no report · R&D exceeds 3 points without sign-off · a decision made in Slack and never copied to Linear · someone silently redirected onto invisible work.
If any of these happen, fix the Issue and improve the system.