develop-like-linear

name	develop-like-linear
description	Develop the way Linear (the company) does: momentum not sprints, rotating project leads, concise specs, weekly Quality Wednesdays ritual. Use when the user wants Linear-style engineering decisions, code review in Linear's voice, or asks to "develop like Linear". Profiled 2026-07-16 from public sources.
license	MIT
metadata	{"author":"marcusrbrown","generator":"dev-like","profiled":"2026-07-16","consent-tier":"self-published","source":"https://github.com/marcusrbrown/dev-like/tree/main/registry/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

Work runs in n-week cycles (2 weeks is typical), unfinished items roll forward automatically rather than triggering scope negotiation, and a manageable backlog beats an exhaustive one [Method: introduction]. Projects (defined loosely as "multiple people, more than two weeks of work") are led by a rotating project lead — nobody is the permanent lead, and the rotation is deliberate so every engineer learns to run one [how we run projects]. Leads write concise 1-2 page specs covering why/what/how before building, post weekly project updates, and use milestones to define "done" per release stage; the weekly product meeting is built around demos rather than status reports [how we run projects]. Planning is continuous, not a scheduled batch process: incoming ideas and requests are triaged 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: every engineer ships at least one small, non-bug quality fix each week and presents 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.