All companies

Company Profile

·Handbook-first·Primary sources

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

Linear publishes its software-building principles and describes continuous planning, small project teams and remote-work rituals. Its August 2026 update reports $100M ARR passed and an employee tender at a $2.5B valuation.

Remote model

Remote-first since 2019, with optional coworking hubs and company/team gatherings

Size

99 people across 15+ countries in October 2025; current total not disclosed in the latest dated announcement

Industry

B2B SaaS — issue tracking and project management for software teams

Headquarters

San Francisco, CA (registered) — globally distributed

Founded

2019

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

Decisions are made by the people closest to the work. Founders and team leads provide direction; ICs make most product and engineering decisions inside the framing the leadership has set.

Founder team retains operational involvement at Series C scale. Karri Saarinen (CEO), Tuomas Artman (CTO), and Jori Lallo are all hands-on. Product taste is consistent because the people responsible for it are still in the room.

Hiring remains selective while the company expands. The August 2026 update says maintaining quality at its expanded scope requires a larger team, with more than 30 open roles. (Source)

The Method offers decision principles. Inference: a shared written guide can clarify tradeoffs. The public guide does not establish that it is the mandatory tiebreaker for internal decisions. (Method)

“Taste” is the explicit hiring filter — defined as the judgment to make non-obvious choices that improve the product over time. Stated outright across founder interviews and the Linear Method. Most companies hire for skill, fit, or self-direction; Linear hires for judgment.


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

Tool Purpose
Linear Issues, projects, cycles, roadmap — full dogfooding
Slack Chat and written project updates
GitHub Code collaboration
Figma Design collaboration
Internal docs Long-form writing and decision records
Zoom / video Sync calls when async is genuinely worse

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

Ritual Cadence Who Purpose
Project updates Weekly Project teams Share progress
All-hands Monthly, one hour Full team Shared company context
Company offsite Annual Full team Shared context and relationships
Smaller team gatherings Cadence not specified here Teams Work together in person
The Linear Method Public reference Open to employees and candidates Software-building principles

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)


What They Do Well

  • Public principles make product judgment inspectable. Inference: the Method can help readers understand Linear’s approach without treating it as a complete employee handbook.
  • Planning has a documented intake mechanism. Candidate projects feed prioritization against customer needs and quarterly goals. Inference: this makes the planning account more useful than a generic claim that the company runs sprints. (Source)
  • Quality bar as operating constraint. Quality is binary. It ships or it doesn’t. This is the most recognizable export from Linear’s culture and is the structural reason the product feels unusually focused.
  • Founder involvement continues through expansion. Inference: continued founder participation can preserve product judgment as the team grows; the evidence does not establish a fixed headcount ceiling for that approach.
  • The Method as recruiting filter. Candidates who do not resonate with the Method self-select out before applying. The hiring funnel benefits from the public document the same way Tom Preston-Werner’s “Optimize for Happiness” essay benefited early GitHub or DHH’s writing benefits 37signals.

Tradeoffs and Weaknesses

The handbook works because the team is small and taste-aligned. Replicating the Linear Method at 500+ people without continuing to maintain the same hiring substrate produces ceremony, not quality. The handbook is downstream of the hire pool; not the other way around. [Inference — editorial synthesis from cross-company observation, not a published Linear claim.]

“Build for the long term” is easier with strong product-market fit and venture funding. Cash-constrained or pre-PMF companies face a different tradeoff between speed and craft. The Method is harder to maintain when shipping speed is existential. [Inference — editorial synthesis, not a published Linear claim.]

Small project teams still need coordination. Inference: as the organization grows, dependencies between projects can require more explicit ownership. The sources do not establish either a universal Linear cycle duration or a numerical threshold where its model fails.

Founder-led depth has a ceiling. The current model relies heavily on the three co-founders being in the work. The transition to a model that survives founder-step-back is not yet documented (and may not have happened).

No public compensation transparency. Unlike Buffer’s published salaries, Linear does not disclose its compensation philosophy at the formula level. Compensation is mentioned in careers material but not at the level a Buffer-style transparency commitment would imply.


What Founders Can Copy

  1. Write down the principles you use. Inference: a public software-building guide can make product standards easier to discuss. Linear’s Method is an example, not proof that every company needs a complete handbook at a particular headcount.
  2. Document how work enters the plan. Inference: a clear path from customer requests to candidate projects and priorities is worth copying. Choose cycle duration and cooldowns for your own team rather than attributing a universal setting to Linear.
  3. Connect hiring to scope. Inference: a quality bar and a growing team are compatible. Linear’s latest update makes the case for expansion rather than a permanent headcount constraint.
  4. Make the product the operating model when the product is a workflow tool. Linear runs Linear; GitHub ran on PRs; Basecamp runs on Basecamp. The dogfooding tightens both surfaces simultaneously. (Applies when the product is a workflow / collaboration tool; not all companies have this option.)
  5. Quality as binary, not tunable. Treat the quality bar as a ship-or-don’t-ship criterion rather than a slider. This is the Linear-distinctive choice and is the most operationally consequential one for product orgs. (Applies most cleanly at <100; harder above 500 because of role specialization and review chains.)

Where This Model Breaks

  • When shared product judgment stops scaling. Inference: growth can require more explicit calibration of standards. No verified current headcount or fixed failure threshold is established here.
  • In commodity / fast-following markets. “Build for the long term” assumes the market rewards craft. In commodity markets where speed-to-feature dominates, the Linear approach is a competitive disadvantage.
  • Without strong product-market fit. The Method is partly a luxury of resources and time. Pre-PMF companies usually need to ship faster and rougher than the Method allows. (Trying to operate Linear-style pre-PMF often produces beautifully crafted unused features.)
  • Below 5 people. At very small scale, the handbook is overkill. A 3-person team should just talk.


Sources

  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

Inferences

  • A public Method is most useful when it describes principles the team actually applies. Its value does not depend on Linear remaining at its historical 99-person size, and the current evidence does not establish a headcount threshold for success.
  • “Build for the long term” is easier with strong product-market fit and venture funding. Linear has both. Cash-constrained or pre-PMF companies face a different tradeoff between speed and craft. The Method is harder to maintain in that setting and reads as a luxury, not a discipline.
  • The Linear Method is functioning as a recruiting filter and a marketing asset simultaneously, in the same way that Tom Preston-Werner’s “Optimize for Happiness” or DHH’s writing did for prior companies. Candidates who don’t resonate with the Method self-select out before applying — the hiring funnel benefits from the public document.
  • Coordination costs can grow as projects acquire dependencies. Linear’s continuous-planning account offers an intake and prioritization example; its product settings do not establish a universal internal cycle length or a scale ceiling.
  • The product and documented building practices can reinforce one another through dogfooding. This feedback loop does not make every configurable product setting a confirmed internal company policy.
  • Linear’s 2026 agent accounts describe a shift from writing the first pass to reviewing a narrower change. The 50% volume figure and the one-third fix rate are one team’s reports. They do not establish company-wide productivity or a reason to remove human 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.