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](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]](https://linear.app/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]](https://linear.app/careers).

## Principles

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

See [references/stack.md](references/stack.md) for the stack and [references/workflow.md](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]](https://linear.app/now/continuous-planning-in-linear). 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]](https://linear.app/now/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]](https://linear.app/now/continuous-planning-in-linear). 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]](https://github.com/linear).
  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](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.