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