Linear

Then decide whether you run cycles. Cycles are Linear's time-boxed sprints, and they are where the tool earns its reputation, because the velocity and scope tracking are automatic once you commit to them. If your team plans in weekly or fortnightly batches, turn cycles on from the start and pick the cadence you can actually hold. If your work is genuinely continuous and unplanned, you can skip cycles and lean on projects instead, but most teams benefit from the rhythm cycles impose.

Finally, set up labels and a triage habit, not a labyrinth. A short, shared label set (bug, feature, chore, plus one or two area labels) is enough to filter usefully. Turn on triage so incoming issues from integrations and forms land in one queue a human reviews, rather than scattering raw into your backlog.

How to actually use it

The core loop is simple, and the order matters. Capture first: every idea, bug, and request becomes an issue, fast, with a clear title and just enough description to act on later. Linear's speed is the point here, so use the keyboard. Creating an issue, assigning it, and setting a priority should take seconds, and once that becomes muscle memory the backlog stops leaking into your head and Slack threads.

Once issues exist, group them into projects. A project is a body of work with an outcome and usually a target date, so a feature launch is a project and the dozen issues that build it live inside it. Projects give you the single view leadership actually wants, which is "is this thing on track", without anyone assembling a status report by hand.

Then, if you run cycles, plan each one by pulling a realistic set of issues into it and nothing more. The discipline is in what you leave out. Linear will show you scope changes mid-cycle, and that visibility only helps if you treat the planned scope as a commitment rather than a wish list. Through the cycle, move issues across states as the work actually moves, because the value of the whole system collapses the moment the board stops matching reality.

Close the loop with the views you live in. Build a saved view for "my work in progress", one for your team's current cycle, and one for triage. Most days you should be working from two or three filtered views, not scrolling the full backlog.

Power moves

The keyboard is the real Linear. Learn the command menu and the single-key shortcuts, and you stop clicking entirely. Assigning, prioritising, moving states, linking issues, all of it happens without your hands leaving the keys, and this is the difference between people who tolerate Linear and people who fly in it.

Sub-issues and issue relations let you model real dependencies instead of flattening everything into one list. Break a large issue into sub-issues so progress rolls up automatically, and mark blocking relations so the team can see what is waiting on what rather than discovering it in standup.

Projects gain a roadmap once you set target dates and initiatives, which is where Linear stops being a task tracker and starts answering the quarterly planning question. Use project updates, the short written status a project owner posts, so the narrative of why something slipped lives next to the work, not in a separate doc nobody reads.

Automation is the quiet power move. Linear can auto-close stale issues, move an issue to "in review" when a pull request opens, and auto-assign on certain triggers, so the board updates itself from the work your team is already doing in Git. Wire those up and the system maintains its own honesty.

Where it fits your stack

Linear's centre of gravity is the Git integration. Connect GitHub or GitLab and issue states follow branch and pull-request activity, so an engineer never has to remember to update Linear, the act of shipping does it. This is the integration to set up first and the one that makes everything else stick.

Slack is the second pillar. Two-way Slack sync means issues can be created from a message and updates flow back into the channel, which keeps the conversation and the work joined instead of drifting apart. For a growth or ops team, this is how a request from sales or support becomes a tracked issue without anyone copying and pasting.

Beyond those, Linear connects to design tools like Figma, to Sentry and similar for turning errors into issues, and to your docs layer for linking specs. The pattern to follow is the same everywhere: let the tool where work actually happens push state into Linear, and let Linear be the single place anyone checks to ask "what is the state of things".

Pitfalls to avoid

The first and biggest pitfall is over-configuring. Custom states, label sprawl, and elaborate workflows feel like rigour and are actually friction, and they slow the one thing Linear is best at, which is speed. Start minimal and add only when a real gap proves itself.

The second is letting the board drift from reality. A backlog full of stale issues nobody will ever do is worse than no backlog, because it trains the team to distrust the tool. Run a regular triage and prune ruthlessly, and use automation to close what has gone cold.

The third is treating cycles as a wish list. If you routinely pull in more than you finish, the velocity data becomes noise and planning stops meaning anything. Commit to less, finish it, and let the honest numbers build over a few cycles.

The fourth is scattering work across too many teams. Every team is a planning boundary, and the more you create the harder it is to see across them, so collapse teams that plan together into one.