Develop like linear

Develop like Linear

Profiled as of 2026-07-16 · consent tier: self-published · full bibliography in references/sources.md. Cultures drift — if this is more than ~6 months old, re-run /dev-like linear to refresh.

Core principle

Create momentum, don't sprint — find a cadence and stick to it; the goal is healthy, sustained momentum across cycles, not a rush to a deadline [Method: introduction]. Paired with a bias for small scope: "ship early... simplify and ship smaller" is principle #1 of how the company says it thinks and works [careers].

Principles

1. Momentum, not sprints — pick a cadence and hold it [Method: introduction]
2. Ship early, ship smaller — simplify scope before building [careers]
3. Rotating project leads — ownership is real but not permanent; everyone learns the role [how we run projects]
4. Write concise specs (1-2 pages) before building, not after [how we run projects]
5. Candidate projects as the continuous unit of planning — triage as ideas arrive, don't wait for a planning ritual [continuous planning]
6. Quality is a weekly habit, not a milestone gate — one small fix per engineer per week, every week [Quality Wednesdays]
7. Avoid side quests — don't fix every problem, don't add process or documents you don't need [careers]
8. Think in principles, not playbooks [careers]
9. Keep the team small, do more with less; wear multiple hats [careers]

Workflow

Execute these checkpoints before and during the task. Treat them as required actions, not background description:

Run work in n-week cycles (2 weeks is typical). Roll unfinished items forward automatically rather than triggering scope negotiation, and keep a manageable backlog instead of an exhaustive one [Method: introduction]. For projects (defined loosely as "multiple people, more than two weeks of work"), rotate the project lead; do not make anyone permanent, and use the rotation to teach every engineer to run one [how we run projects]. Before building, write a concise 1-2 page spec covering why/what/how. Post weekly project updates and use milestones to define "done" per release stage; build the weekly product meeting around demos, not status reports [how we run projects]. Planning is continuous, not a scheduled batch process: triage incoming ideas and requests directly into "candidate projects" as they arrive, so a quarter's planning session starts from an already-vetted list instead of a blank page [continuous planning]. Quality is a weekly team habit, not a phase: have every engineer ship at least one small, non-bug quality fix each week and present it at a dedicated Wednesday standup ("Quality Wednesdays") — over 1,000 such fixes shipped in two years [Quality Wednesdays].

See references/stack.md for the stack and references/workflow.md for workflow detail.

Tensions

• The Linear Method is, transparently, product marketing for Linear the tool — nearly every practice page frames itself in terms of how "the Linear app easily facilitates" it [continuous planning]. The principles (momentum, small scope, rotating ownership, concise specs) are genuinely extractable and tool-agnostic, but read the workflow docs as advocacy, not neutral reporting.
• "How we run projects" is a 2023 interview and "Quality Wednesdays" describes a practice that started in 2023 and was written up in 2025 [Quality Wednesdays] — solid provenance, but older than the AI-driven "continuous planning" post from October 2025, which now folds AI triage suggestions directly into the workflow [continuous planning]. Linear's AI posture reads as a recent, still-evolving product direction (AI-assisted triage, an advertised "AI" product page) layered onto an older, more stable process — not a deep, long-held engineering philosophy the way Rails-vanilla or Shape Up are for 37signals.
• No published internal engineering stack (languages, frameworks, deploy tooling) — only the public SDK/integration surface is verifiable [GitHub org]. Don't extrapolate an internal stack from the open-source repos; they're developer-facing tooling, not necessarily what Linear's own product is built with.

Want a reviewer/pair persona in Linear's voice? See personas/linear-developer.md — it's reference material. Claude Code users can copy it to .claude/agents/ to run it as a first-class subagent; other harnesses may need their own harness-specific metadata.