How Linear Combines a Published Method With Continuous Planning and Small Project Teams

Snapshot

Linear was founded in 2019 by Karri Saarinen (CEO, ex-Airbnb design), Tuomas Artman (CTO, ex-Uber), and Jori Lallo (CPO, ex-Coinbase). It builds project management software for software teams. An October 2025 company essay reported 99 people across 15+ countries; a current exact headcount is not established here. (About, October 2025 snapshot)

Linear raised its $82M Series C at a $1.25B valuation in June 2025. On August 26, 2026, it announced a $99M employee tender at a $2.5B valuation, reported passing $100M ARR, and said it was cash-flow positive. The transaction provided liquidity rather than raising new primary capital. (Series C, 2026 update)

The distinctive evidence is the combination of the Linear Method, a public guide to building software, and company essays describing internal practices. The guide’s recommendations and the product’s configurable features should not be mistaken for a complete internal handbook or mandatory company policy.

Core Philosophy

The Linear Method names a small set of published principles that shape how the company operates and how the product is built:

• Build for the creators. Software for software builders should be designed by people who understand the work.
• Purpose-built. Productivity software needs to be designed for purpose, not for everyone.
• Create momentum — don’t sprint. Find a cadence and routine of working. Sustainable rhythm over short bursts.
• Meaningful direction. Understanding long-term goals matters even when daily work involves smaller tasks.
• Aim for clarity. Don’t invent terms when familiar ones exist; use language that doesn’t fragment meaning.
• Say no to busy work. A tool should work for you, not the other way around.
• Simple first, then powerful. Tools should be easy to start with and grow more capable as teams scale.
• Decide and move on. Sometimes the most important thing is to make a decision and move on.

(Source for all)

Inference: published principles can give teams a shared vocabulary for tradeoffs. The Method alone does not establish a mandatory internal decision procedure.

Communication Model

Linear links its product and operating method. Linear documents issues as the fundamental unit of work in its product and says that, while building Linear, it codifies learned software-building practices into both the product and the Linear Method. This supports a tight product-and-method feedback loop; Linear does not publicly document that all internal communication happens inside the product. (Conceptual model, building practices)

Written updates coexist with live gatherings. Linear describes weekly project updates and a monthly one-hour all-hands. (Remote-work practices)

Slack is also used for written updates. The remote-work account describes weekly project updates shared there, so a strict “chat is transient, every durable decision is elsewhere” rule is not established by this evidence. (Source)

The Linear Method makes software-building principles public. It is available to candidates and employees, but the sources reviewed here do not establish required onboarding readership or a complete internal communication handbook. (Method)

Planning and Cadence

Cycles are configurable in the product. Linear supports 1–8-week cycles and optional cooldowns; its Method says two weeks is common in software development. Those sources do not establish a mandatory 1–2-week internal cycle or cooldown for every Linear team. (Cycles documentation, Method)

Projects organize longer initiatives in the product. Linear distinguishes projects from shorter cycle iterations. This is a product model, not proof of a single internal planning schedule. (Conceptual model)

Continuous planning feeds quarterly priorities. Linear’s product team develops candidate projects as requests arrive, then prioritizes them against customer demand, revenue impact and quarterly goals. (How Linear plans)

The planning evidence is more specific than a sprint label. The internal account describes how candidate work is triaged and prioritized; it does not specify a universal release train or mandatory cooldown. (Source)

Decision-Making Model

Linear’s Method recommends named issue and project owners. Its May 27, 2025 founder essay describes small teams using judgment, work trials looking for craft and attention to detail, and internal testing before incomplete experiences reach users. These are stated principles and examples, not a measurement that ICs make most decisions or that every decision is delegated. (Method, founder account)

Linear’s About page names Karri Saarinen as CEO, Tuomas Artman as CTO and Jori Lallo as CPO. The August 2026 update calls for a larger team; it does not prove that founder presence causes consistent product taste. (About, growth update)

Org Structure

• 99 people across 15+ countries in October 2025; this is a historical snapshot, not a current count. (Source)
• Founder-led at Series C scale — three co-founders still in operational leadership.
• Remote-first with optional coworking hubs; hiring geography depends on the role. (Current engineering role)
• Product projects usually use 2–4-person teams, with rotating leads; teams form around projects and disband afterward. (Source)
• A product-management team triages candidate projects. The source does not establish the size of the wider management or operations organization. (Source)

Tools and Stack

The defining choice is a tight product-and-method feedback loop. Linear says it codifies learned software-building practices into the product and the Linear Method. The public evidence supports dogfooding and that feedback loop, but not the claim that every internal decision lives in Linear. (Source)

Rituals

The meeting and gathering cadences come from Linear’s October 2025 account. (Source)

AI

These accounts describe how Linear uses its own agent. They are separate from the customer study at linear.app/data, which covers other companies’ workspaces and cannot see AI use outside Linear.

Work stays attached to the issue. An April 10, 2026 account says Customer Experience turns Intercom email into scoped issues, triage routes feature requests, and a product manager uses the agent to cluster overlapping requests and draft specs. Engineers delegate a first pass to a coding agent while the issue stays assigned to them. For the prior couple of months, a coding agent reviewed every pull request — the team was leaning on Codex — and a human engineer made the final approval. One product manager used the agent to open a pull request for a small filter; a human engineer reviewed it within the hour. The account says teams put a workflow on autopilot only after it has proved reliable, and that engineers get better results by splitting work into small steps. (Source)

Review moved toward judgment as volume rose. On June 10, 2026, an engineer reported that, on his team, issues created and pull requests merged both rose 50% between January and March 2026. He describes agents as covering most line-by-line correctness checks, with human review moving toward whether the change fits the system and solves the problem. Review is also one of the remaining moments when people look at each other’s work directly. That is one team’s before-and-after count, not a company productivity result. (Source)

Narrow automations work; a first pass on every bug did not. On June 12, 2026, an engineer wrote that asking the agent to attempt every incoming bug failed because there was not enough context to one-shot the fix. Two narrow cases remain. Dead feature flags, filed once a flag returns the same result all the time, are one-shot nearly every time. Failing background tasks, filed when a task’s failure rate climbs above 0.2%, land the correct fix about a third of the time. Gates require the agent to show it understands the problem before it attempts a fix. A person still reviews and merges. (Source)

Migration work combined deterministic tools, agents and human checking. An August 26, 2026 engineering account describes migrating React styling through more than 1,000 pull requests. The team gave agents narrow scopes, a codemod, examples, validation scripts and checklists, starting with less-connected components. Agents struggled with some visual differences, so manual testing remained necessary. Visible progress tools encouraged the migration. This is one project’s account, not an AI-adoption percentage or a measured productivity gain. (Source)

Validation needed maintenance as code volume grew. In a September 21, 2026 account, Mufeez Amjad says the CTO assigned him responsibility for CI cost and speed. He reports that, while test suites nearly quadrupled from the start of the year, pull-request wait time fell from more than six minutes to just over five and runner time per test roughly halved. The work changed infrastructure, scheduling, repeated setup and test execution. These are CI measurements reported by Linear, not a company productivity estimate. (Source)

Recurring work has shared context and human owners. In an October 13, 2026 account, engineer Andrew Moedinger describes security loops that prepare vulnerability and bug-bounty triage for people. His deprecated-code workflow expanded from finding candidates to creating at most five issues per run, then assigning and delegating work; the assigned engineer reviews and submits the pull request. Internal loops use a bug-investigation skill and product-ownership documents. He also describes iterating a weekly meeting-agenda loop and a customer-success loop that redirects off-hours requests to the person on call. These are reported workflows, not a measured adoption rate or productivity result. (Source)

What They Do Well

• Quality has a documented practice. In an August 13, 2025 account, Tuomas Artman describes Quality Wednesdays: engineers show small polish fixes in a weekly team meeting, with more than 1,000 fixes reported over two years. The practice began after early-2023 offsite exercises. This is a team ritual and reported activity count, not a company-wide productivity result or a binary quality rule. (Account)
• Planning has an intake mechanism. Candidate projects feed prioritization against customer needs and quarterly goals. [Inference — this makes the account more operationally useful than a generic sprint label.] (Planning)
• Published principles make priorities inspectable. [Inference — the Method and founder essay can help candidates and colleagues understand tradeoffs; no recruiting conversion or retention effect is established.] (Method, founder essay)

Tradeoffs and Weaknesses

[Inference — questions raised by the documented model; not observed failure rates.]

Quality requires continuing calibration. Quality Wednesdays illustrates a recurring practice for noticing and fixing small problems. The sources do not establish that the Method fails at 500 people or that quality depends on a fixed hiring substrate. (Account)

Investment has an opportunity cost. Teams should decide which quality improvements matter to users and what to defer. The evidence does not establish that companies without strong product-market fit cannot follow these principles.

Founder involvement and delegation need distinct evidence. The current leadership roster does not document a complete succession or founder-step-back model. That is a limit of this profile, not proof the company has no plan.

Compensation evidence is limited. The reviewed careers page does not provide a Buffer-style public salary formula. That does not establish the absence of an internal compensation framework. (Careers)

What Founders Can Copy

[Inference — application guidance from the documented practices.]

1. Publish principles with examples. Use the Method to discuss product standards without assuming every company needs a complete handbook at a particular size.
2. Document intake and prioritization. Explain how customer requests become candidates and which tradeoffs determine the plan.
3. Make quality review recurring. Quality Wednesdays offers a concrete small-fix practice to evaluate; its activity count does not predict another team’s return.
4. Use your own product where it fits. Dogfooding can expose friction, but should not substitute for evidence about customer needs.
5. Assess judgment in realistic work. The founder’s essay describes craft and attention to detail in work trials. This is more specific than treating taste as the only hiring criterion.

(Method, planning, quality ritual, hiring account)

Where This Model Breaks

[Inference — conditions to assess, not verified Linear failure cases.]

• Unclear product standards: growth may require explicit calibration and ownership across projects.
• Misallocated quality work: the team still needs to decide what customers value and what to defer.
• Insufficient feedback: principles need contact with actual user problems, not only internal taste.
• Documentation with no use: evaluate whether a guide helps real decisions; the evidence establishes no minimum headcount for writing useful principles.

Related Practices

• Planning Cycles — distinguish configurable product cycles from verified internal planning
• Async Communication — async-first inside the product the company sells
• Documentation Systems — the Linear Method as a published software-building guide
• Decision Ownership — project leads and explicit responsibility

Related Frameworks

• 20-30 Person Fracture Point — publishing operating principles is one way to make shared expectations explicit
• Sync vs Async Decision Matrix — written project updates alongside recurring live gatherings

Sources

Linear — Why is quality so rare? (May 27, 2025): https://linear.app/now/why-is-quality-so-rare

Linear — Quality Wednesdays (August 13, 2025; older missed practice account): https://linear.app/now/quality-wednesdays

1. The Linear Method (Introduction): https://linear.app/method/introduction
2. Linear Docs — Cycles: https://linear.app/docs/use-cycles
3. About Linear: https://linear.app/about
4. Linear Blog: https://linear.app/blog
5. Linear Conceptual Model: https://linear.app/docs/conceptual-model
6. Practices for Building Linear Is Now Open for All: https://linear.app/blog/practices-for-building-linear-is-now-open-for-all
7. Linear Series C announcement (Building Our Way): https://linear.app/now/building-our-way
8. Linear Series B announcement: https://linear.app/now/series-b
9. Linear Careers: https://linear.app/careers
10. Sharing Linear’s growth with the people building it (August 26, 2026): https://linear.app/now/sharing-growth-with-the-people-building-linear
11. Designing remote work at Linear (October 29, 2025): https://linear.app/now/designing-remote-work-at-linear
12. Continuous planning in Linear (October 30, 2025): https://linear.app/now/continuous-planning-in-linear
13. Senior / Staff Fullstack Engineer (live role, checked September 12, 2026): https://linear.app/careers/cd5ae036-0223-427a-b038-ba16ef9dcb32
14. How we use Linear Agent at Linear (April 10, 2026): https://linear.app/now/how-we-use-linear-agent-at-linear
15. Reviewing code in the agent era (June 10, 2026): https://linear.app/now/reviewing-code-in-the-agent-era
16. Teaching an agent to auto-fix bugs (June 12, 2026): https://linear.app/now/linear-agent-bug-fix
17. Styling Linear for the future with StyleX (August 26, 2026): https://linear.app/now/styling-linear-for-the-future-stylex
18. AI coding has made CI a bottleneck, so we reworked ours to keep up (September 21, 2026): https://linear.app/now/ci-bottleneck-reworked
19. Five principles for working with Loops (October 13, 2026): https://linear.app/now/five-principles-working-with-loops

Inferences

• Published principles are useful when people can connect them to actual choices. Linear’s planning and quality accounts provide examples, without establishing a numerical size limit for the Method.
• Recurring small quality fixes may help teams calibrate attention, but the reported count is an activity measure rather than an independently measured productivity gain.
• Dogfooding can connect product friction and operating practice. It does not make every configurable product setting a confirmed internal policy.
• The 2026 agent accounts describe narrow delegation and human review. One team’s output volume and fix rate do not establish company-wide productivity or justify removing approval.

Work with Alex

If you are running a small team and want the operating-system clarity that handbook-first companies have, Alex helps founders and leadership teams write the operating handbook that compresses recruiting, onboarding, and decision-making at the same time.