Linear

Linear is an issue-tracking and project-management tool for software development teams, covering issues, sprint-style cycles, projects, and roadmaps in a keyboard-driven interface. It integrates natively with GitHub and GitLab so pull requests link to and update issues. It is aimed at engineering and product teams, from individual developers and startups to larger organisations.

This guide gets you from a blank Linear workspace to a system your team actually trusts to run the work. It is written for founders and operators setting up Linear for a software team (or a software-shaped one), the people who care less about pretty boards and more about whether the backlog reflects reality. If you want issue tracking that stays fast, stays honest, and gets out of your way, this is the setup that delivers it.

Getting set up

The first real decision is your team structure, because in Linear a "team" is the container for issues, cycles, and workflow states, and it shapes everything downstream. Resist the urge to create a team per project or per client. Create a team per group of people who plan together. One team for product engineering, perhaps one for design, perhaps one for a separate client pod. If two groups share a backlog and a planning rhythm, they are one Linear team, not two.

Next, settle your workflow states before you import a single issue. Linear groups states into backlog, unstarted, started, completed, and cancelled, and the defaults are sensible, so the temptation to add ten custom statuses is the trap. Keep the set small. Every extra state is a place work goes to hide. A lean flow (backlog, todo, in progress, in review, done) covers most teams, and you can always add a state later when a real gap shows up, never before.

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.

INTERVIEW EWOUD: How is your Linear workspace actually structured, how many teams, do you run cycles, and what does your label and triage setup look like?

INTERVIEW EWOUD: Which single Linear workflow or integration do you rely on most day to day, and why does it matter to how you run the company?

INTERVIEW EWOUD: What is your hard-won tip for keeping Linear honest and fast, the thing you learned the painful way that you would tell a founder setting it up today?

Software engineering and product teams that want a fast, keyboard-driven issue tracker with native Git integration

Linear is an issue tracker and project management tool built for software teams. You file issues, group them into projects and cycles, and move work across a board or list towards done. It is known for being fast, keyboard-driven, and opinionated about how a product team should run, and it has become a default choice for a lot of modern startups.

Where it fits

Linear is genuinely for product and engineering teams that ship continuously and want their tracker to stay out of the way. It suits teams running in cycles or sprints, where the value is a tight loop between planning, building, and shipping. Roadmaps, projects, and cross-team initiatives sit on top, so it scales from a handful of engineers to a larger product org without turning into a configuration project.

It is less of a fit if you need a flexible all-purpose work hub for non-engineering teams (marketing calendars, client work, knowledge bases). Linear is deliberately narrow: it is a software issue tracker first, and it does not try to be a wiki, a doc tool, or a generic database. If your team lives in documents and freeform structure, a more configurable tool will feel more natural.

The honest take

The real strength is speed and restraint. Linear is fast in a way most project tools are not, the keyboard shortcuts mean you barely touch the mouse, and the opinionated model (issues, cycles, projects) saves you from designing your own process from scratch. For a team that wants to just start shipping, that is a meaningful head start, and the interface stays clean as the work grows.

The trade-off is the other side of that opinion. The structure that makes Linear fast also means you work the way Linear wants you to work, and teams that need heavy customisation or unusual workflows can hit its edges. It is built around the software-team model, so stretching it to run a whole company's operations tends to fight the grain. It is also a paid SaaS tracker, so your roadmap and history live inside someone else's tool, which is worth weighing if portability matters to you.

INTERVIEW EWOUD: What is your one-line verdict on Linear, and would you tell a peer to use it?

INTERVIEW EWOUD: What do you rate it out of five, and why that number?

INTERVIEW EWOUD: Is Linear in your own stack today, and what do you actually run on it?