By James Aspinwall
Most project management tools make you work for them. You spend more time updating boards, customizing views, and fighting the interface than doing the actual work. Linear flips that. It’s fast, opinionated, and built around a single idea: the tool should disappear so you can focus on shipping.
What Linear Is (and Isn’t)
Linear is an issue tracker and project management tool for teams that build things. It handles issues, projects, cycles (sprints), and roadmaps. It does not handle CRM, invoicing, documents, or wikis. That’s intentional — it does one thing well.
If you’ve used Jira and felt the weight of it, Linear is the antidote. If you’ve used Trello and outgrown it, Linear is the next step. If you’ve used GitHub Issues and wished it understood projects, Linear is that.
Free plan gets you started. Paid plans add features like time-based cycles and advanced analytics, but the core experience is the same.
The Data Model
Linear organizes work in a clean hierarchy. Understanding this hierarchy is most of what you need to use it well.
Workspace (your company)
└── Team (engineering, design, ops)
├── Issues (the actual work)
│ ├── Sub-issues
│ ├── Comments
│ └── Labels
├── Projects (multi-issue goals)
├── Cycles (time-boxed sprints)
└── Workflow States (status columns)Workspace is your organization. One workspace per company.
Teams are the top-level grouping. Each team has its own issue prefix (ENG-42, DES-15), its own workflow states, its own cycles. Create teams around how people actually work together, not around org chart boxes.
Issues are the unit of work. Every task, bug, feature, and chore is an issue. They have a title, description, state, priority, assignee, labels, and optionally belong to a project and cycle. Issues can have sub-issues for breaking down larger work.
Projects group related issues toward a goal. “Launch v2.0” or “GDPR Compliance” are projects. They span multiple cycles and can involve multiple teams. Projects have a progress bar that fills as issues complete.
Cycles are time-boxed work periods — typically one or two weeks. Think sprints. You assign issues to the current cycle, the team works through them, and at the end you see what got done. Cycles auto-archive when they end.
Workflow States define how issues move through your process. Every team gets these by default:
| State Type | Default Name | Meaning |
|---|---|---|
| Triage | Triage | New, needs review |
| Backlog | Backlog | Accepted, not scheduled |
| Unstarted | Todo | Scheduled, not started |
| Started | In Progress | Actively being worked on |
| Started | In Review | Done, awaiting review |
| Completed | Done | Finished |
| Canceled | Canceled | Not doing this |
You can rename these or add more, but the types are fixed. Linear uses the type (not the name) to calculate progress and analytics.
Day-to-Day Usage
Creating Issues
C creates a new issue. That’s it. Type the title, tab to description, set priority, assign someone, hit Cmd+Enter. Under two seconds for a well-practiced user.
Keyboard-driven is Linear’s core philosophy. Everything has a shortcut. You’ll rarely touch the mouse once you learn the basics.
What makes a good issue:
- Title describes the outcome, not the activity: “Users can export data as CSV” not “Add export button”
- Description has enough context for someone else to pick it up: what, why, and acceptance criteria
- Priority is honest: Urgent means drop everything, High means this cycle, Medium means soon, Low means eventually
Priority levels:
| Priority | Label | When to Use |
|---|---|---|
| 0 | No priority | Unscored, needs triage |
| 1 | Urgent | Production is broken, fix now |
| 2 | High | Must ship this cycle |
| 3 | Medium | Should ship soon, next cycle if not this one |
| 4 | Low | Nice to have, gets to it when there’s room |
Be ruthless with Urgent. If everything is urgent, nothing is. Reserve it for genuine emergencies that stop users from working.
Working Through Issues
When you start working on something, drag it to In Progress (or press 2 for the shortcut). When you open a PR, move it to In Review. When it’s merged and deployed, move it to Done.
Linear tracks these transitions. Over time, you get data on how long issues spend in each state — your cycle time. This is the single most useful metric for understanding team velocity.
Sub-issues break large issues into steps. “Implement user export” might have sub-issues for “Add CSV generation,” “Build download endpoint,” and “Add export button to UI.” The parent issue tracks progress as sub-issues complete. Use sub-issues when one issue has three or more distinct deliverables.
Comments are for discussion, not status updates. Don’t comment “started working on this” — that’s what the state transition does. Comment when you need to discuss an approach, flag a blocker, or share a finding that affects the work.
Managing Cycles
Cycles bring rhythm to the team. A typical two-week cycle:
Day 1 (Planning): Review the backlog, pull issues into the new cycle. Look at capacity — how many issues did the team complete last cycle? Don’t plan more than that. Linear shows you the previous cycle’s velocity as a guide.
Days 2–9 (Execution): The team works through issues. The cycle view shows progress in real time — a burn chart of completed vs total scope. If scope creeps (new issues added mid-cycle), you see it immediately.
Day 10 (Review): What got done? What carried over? Linear auto-generates a summary. Issues that didn’t complete can roll into the next cycle automatically.
The key insight: cycles are a feedback loop, not a commitment device. If the team consistently completes 80% of planned work, plan for that. If a cycle is light, pull from the backlog. The goal is sustainable pace, not heroics.
Using Projects
Projects are for work that spans multiple cycles and needs a visible finish line.
Good projects:
- “Launch billing v2” — clear scope, clear end state
- “SOC 2 Compliance” — defined deliverables, external deadline
- “Reduce API latency below 200ms” — measurable goal
Bad projects:
- “Bugs” — that’s a label, not a project
- “Q1 Work” — that’s a cycle, not a project
- “Ongoing maintenance” — no end state means no progress to track
A project has a start date, target date, and a progress percentage calculated from its issues. When a project falls behind (issues aren’t completing at the rate needed to hit the target), Linear shows you early — not the week before the deadline.
Project updates let leads post periodic status notes visible to the whole team. Use them weekly: what’s on track, what’s at risk, what needs attention. These create a written record that’s searchable later.
Labels
Labels categorize issues across teams and projects. They’re the cross-cutting concerns that don’t fit neatly into the hierarchy.
Useful labels:
-
Type:
Bug,Feature,Improvement,Chore -
Area:
Frontend,Backend,Infrastructure,Design -
Impact:
Customer-facing,Internal,Tech debt
Keep labels flat and few. If you have more than fifteen labels, most of them aren’t being used consistently. Audit quarterly and prune.
What Linear Gets Right
Speed
Every interaction is instant. Filter a list, switch views, search across everything — no loading spinners. This matters more than any feature because it determines whether people actually use the tool. A project tracker that’s slow to update becomes a project tracker that’s always out of date.
Opinions
Linear doesn’t let you customize everything. Workflow state types are fixed. Priority levels are 0–4, not configurable. Cycles have a set cadence. This sounds limiting but it eliminates a category of bikeshedding. You don’t spend a sprint deciding how to configure the tool. You use the defaults and they work.
Keyboard Navigation
C to create. S to set status. P to set priority. A to assign. L to label. Cmd+K to search anything. Once muscle memory kicks in, using Linear feels closer to typing than to clicking through a UI.
Filtering and Views
Linear’s filter system is genuinely powerful. Filter by assignee, state, priority, label, project, cycle, or any combination. Save filters as custom views. “My high-priority issues in the current cycle” is one saved filter you’ll use daily.
Teams can create shared views too. “All bugs reported this week” or “Issues blocked for more than 3 days” — these become your team’s operational dashboard without any configuration ceremony.
Common Patterns That Work
The Triage Workflow
New issues start in Triage. Once a day (or once per standup), someone reviews Triage. Each issue gets one of three outcomes:
- Accept — set priority, move to Backlog or directly into the current cycle
- Clarify — comment asking for more info, leave in Triage
- Close — duplicate, not a real issue, or out of scope
This prevents the backlog from becoming a dumping ground. Everything that enters the system gets a human decision within 24 hours.
The Weekly Sync
A 15-minute weekly meeting per team:
- Open the current cycle view (2 minutes) — what’s done, what’s in progress, what’s blocked?
- Review blocked issues (5 minutes) — can we unblock anything right now?
- Check project progress (3 minutes) — any projects at risk?
- Quick triage (5 minutes) — anything in Triage that needs immediate attention?
Linear is the shared screen for this meeting. No slides, no status report documents. The tool is the status report.
Linking to Everything
Linear issues can link to:
- Other issues — “blocks” and “is blocked by” relationships
- Pull requests — GitHub/GitLab integration auto-links PRs to issues
- Documents — attach specs, designs, or external links
- External URLs — link to client conversations, contracts, or design files
Use blocking relationships honestly. If ENG-42 truly cannot start until ENG-38 is done, mark it. This makes bottlenecks visible during planning.
What Linear Doesn’t Do
Linear is not a wiki. Don’t write long documents in issue descriptions — use a dedicated tool (Obsidian, Notion, Confluence) and link to it.
Linear is not a CRM. Don’t track client relationships in projects. Use Pipedrive or similar for that and link Linear issues to client context when needed.
Linear is not a time tracker. It measures throughput (issues completed) and cycle time (time from start to done), but it doesn’t track hours. If you need time tracking for billing, use a separate tool and reference the Linear issue ID.
The integrations are where this comes together. Linear connects to GitHub, Slack, Figma, and dozens of other tools. Let each tool own its domain and use Linear as the coordination point for the work itself.
Getting Started
- Create a workspace. Name it after your company.
- Create one team. Name it after your primary working group. Don’t create five teams on day one.
- Add your first ten issues. Real work, not test data. Move three of them to In Progress.
- Start a cycle. Two weeks. Pull in the issues you plan to complete.
- Work for two weeks. Move issues through states as you go. Don’t overthink it.
- Review the cycle. What got done? What didn’t? Adjust next cycle’s scope accordingly.
After two or three cycles, you’ll have real data on team velocity, and the tool will feel like a natural extension of how you work rather than an obligation you maintain.
That’s the whole point. The best project management tool is the one that captures what’s happening without demanding you stop and update it. Linear gets close to that ideal.