Linear

Consent tier: self-published · Kind: org · Sources: 6 · Updated: 2026-07-16

Install: npx dev-like linear

Prebuilt skill: SKILL.md

Identity

Makers of the Linear project-management tool; small, remote-first team that runs its own product development on the same principles it sells — “we build better with fewer people” careers. Their process is published as “the Linear Method”, a hub of principles and practices explicitly aimed at other product teams, not just an internal handbook Method: introduction.

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.

Workflow shape

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.

Stack

Linear does not publish its internal engineering stack the way 37signals or Every do; its public technical surface is its own API/SDK ecosystem (TypeScript SDK, CLI tooling, Zapier and webhook integrations) under the linear GitHub org, a verified owner of linear.app GitHub org. Treat “the stack” here as the product surface, not a verified internal toolchain — don’t invent implementation details beyond what’s published.

Principles (cited)

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

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.