← Back to Blog | everything I know about Linear

I've been thinking a lot lately about how to do effective work with Linear. I've survived two companies doing a migration from Asana to Linear, and both times required adapting and learning new patterns and ways of working.

Linear is a great tool when it's used well. From experience, though, it's easy to "hold it wrong" and not get many of the benefits Linear can provide for your team.

Here's how I've learned to use Linear, based on my experience from teams that figured out how to make Linear actually useful.

Projects & Updates:

Projects should have clear end dates and be well defined towards a specific goal (like launching a new feature), or be titled like Design System (Ongoing) to denote long-lived areas.

Use ongoing feature-specific projects like AI Chat (Ongoing) if there's lots of ongoing work for a feature, though this isn't usually the case. Example: for an AI chat feature, you might instead have a project like Better Context Management in Chat that lasts for 6-10 weeks, rather than adding tasks to an ongoing AI Chat project.

Projects like AI team should usually be avoided. Issues can be assigned to a team without being attached to a project, so there's no need for "team projects" like this.

Linear enforces that projects have one project lead. Usually, an engineer should be the project lead. The project lead isn't necessarily doing all the work, but is responsible for communicating progress/deadlines/updates (more below). As an IC, this also helped me level up my project leadership skills, by making sure there was a framework around how to lead a project. It's a great tool!

Project updates are incredibly high-value when done correctly. Usually just a few sentences. First, the built-in status: On Track, At Risk, Off Track helps encourage honesty & transparency of what projects aren't progressing and why. No blame culture is important here! Then, the space for a freeform update: what changed? what got done? what was difficult? are we prepared for the deadline? do we need more help? You can convey a lot of info here in just a few sentences.

Project updates post to slack automatically, to both a company wide "updates" channel for all updates, and to any additional channels, eg your team channel. Assume anyone at the company will read this, so individual technical details aren't important here. Also not important: how many tickets you closed, how many lines of code you wrote, etc.

Project updates should be done friday for all active non-ongoing projects. At Replit, our VP of engineering would ping you in a slack thread on monday if your update wasn't in. This could probably be automated, but it also showed that someone in exec staff was reading all the updates, which was important too.

Milestones

Milestones help you separate projects into deliverables. It's tempting to go overboard on these, with milestones like Initial Planning / Design Complete / X feature ready / Y feature ready / Launch.

I found milestones like these to be counterproductive. What I found worked best was not pinning them to features / deliverables, but to flag rollouts:

• Internal Staff Release
• Beta customers
• 50% Rollout
• 100%
• Post-Launch

Small enough projects could usually skip the beta / 50% rollout steps too, and just go from internal release straight to production.

Naming the milestones after flags makes your updates and issue board self-documenting to the rest of the company for what stage of delivery you're at, and what phase future work might fit into.

Cycles

Cycles are Linear's built in "biweekly sprint" feature. Usually, I don't think you should be using these. Project updates have a better default (weekly) cadence, and keep the whole company in the loop of your progress.

If your team is looking at turning on the cycles feature, I'd instead look at how you could shrink your project. Can you decouple blocking dependencies from your project into an initial one? Is there work that can be split out to a future improvement phase? Can you parallelize anything, and assign it to one team member to own?

There's one place I've seen cycles make sense: a really large migration project, where an entire team was working on a very large new change. That project couldn't be decomposed into smaller tasks. It also didn't have clear milestones, just a months-away deadline where it would be finished. Cycles are the best way in that case to group many many issues that need to be organized and planned over time somehow.

Initiatives:

These can usually map to quarterly objectives / top line business goals. That might be something like "X% week 4 conversion to paid", or "Launch Mobile App v1". You might have an initiative for all your company OKRs, but don't do that unless it makes sense.

Each company will be different here, and less noise is better.

Keep internal initiatives, like "fewer than X alerts per week" and "code quality". These help explicitly prioritize the work that often gets left out of planning, like migrations and cleaning up tech debt.

Initiatives have updates, like projects. These might be useful for larger companies with more management levels, but I don't think they're as impactful as project updates. Using them is probably for the benefit of engineering managers & executive staff, rather than for the benefit of ICs.

Issues:

Slack issue -> linear issue is extremely helpful. I'd click this button 5x per day or more on some days. generally, connecting links to linear tickets is much more full featured than asana's. it's good to collect multiple slack threads, PRs, figma links, or anything else you need as a reference on the ticket.

Issues should be actionable and concrete. Usually it works better if they're tied to code changes, too.

Creating tickets like Create designs for v1 and assigning it to a designer isn't usually useful. I & the designers I worked with rarely made tickets like this.

I don't have much experience with "asks", so I can't comment on how helpful they are.

Someone should be responsible for "triage" issues, either the team's EM, the project lead, or a rotation (configurable). Triage issues are really high value, to keep the backlog & todo sections clean and readable.

Linear cancels backlog items after 6 months of inactivity. This is a very good thing.

PR reviews:

Linear lets you do github code reviews in their app. it's faster and nicer looking. it works great. get your act together, github.

end

Linear is all the rage in tech circles these days. Lots of people sing its praise as the best thing to ever happen to project management. Its benefits, though, aren't really obvious at first, and it's very easy to make choices that negate many of its benefits. The learning curve is more than just figuring out the UI: the tool itself wants you to do work a certain way. Usually that's bad, but I've found many of the processes Linear encourages to be quite positive, once you figure them out.