Beyond Issues: 4 Linear Features for Managing Projects More Effectively

Search for a command to run...

No comments yet. Be the first to comment.
The first time I was asked to build a backfill for a production system, I remember thinking: This sounds important... and a little scary. It sounded like one of those engineering terms that everyone

Lessons learned while building a side project on a budget.

The problem it solves Any system that processes a stream of messages—orders, events, uploads, whatever—will eventually hit one it can’t handle. Maybe the message is malformed. Maybe a downstream depen

Two Ways to Control Who Can Deploy to Production in GitHub Actions Say you have a GitHub Actions workflow that someone can manually trigger to deploy something to an environment. It could be productio

Code Like a Woman
46 posts
Making modern software engineering concepts feel approachable through simple mental models and practical lessons learned.
When you first start using Linear, it's easy to think of it primarily as a place to create and track issues.
Create an issue. Assign it. Move it to In Progress. Mark it as Done.
That works well when the scope is small.
But as the work grows, a flat list of issues isn't always enough. Some work belongs to a larger project. Projects have meaningful stages. And sometimes, what looks like a single issue actually requires several steps before it can be considered done.
Linear has a few features that can help you organize all of this without losing sight of the actual work.
A quick note: I'm not affiliated with Linear. I've simply been using it across my last few jobs, including my current one. Along the way, I've been getting more familiar with both Linear and some of the project management concepts behind how work is organized.
Here are four features I've found particularly useful.
Not every issue should live independently.
Sometimes, a collection of issues contributes to a larger outcome: launching a mobile app, redesigning an onboarding experience, or introducing a new authentication system.
That's where Projects come in.
A project gives related work a shared home and lets you track the larger outcome instead of looking at every issue individually.
For example:
Project: Launch Mobile App
Build authentication
Create onboarding experience
Implement navigation
Add user settings
Prepare app for release
Instead of only asking, "Which issues are done?", you can also ask:
"How is the project progressing?"
A project can still contain dozens—or hundreds—of issues.
Milestones give you another level of organization by breaking the project into meaningful stages.
For our Launch Mobile App project, we could have:
Milestone 1: Authentication
Milestone 2: Core Experience
Milestone 3: Beta Testing
Milestone 4: Public Launch
Issues can then be associated with the milestone they contribute to.
This makes it easier to understand not only how much work remains, but where you are in the journey toward completing the project.
Instead of treating the entire project as one large block of work, milestones give the team smaller targets to work toward.
Sometimes an issue isn't really an issue.
It's a small project hiding inside one.
Imagine creating an issue called:
Implement user authentication
At first, that might sound like a reasonable unit of work.
But then you start thinking about what "done" actually requires:
Create the login flow
Implement sign-up
Add password reset
Handle session expiration
Add authentication tests
At that point, keeping everything inside one issue makes it difficult to see what's actually complete and what still needs work.
Instead, you can use the original issue as a parent issue and break the implementation into sub-issues.
The parent captures the larger piece of work.
The sub-issues capture the individual steps required to complete it.
This gives you something similar to an Epic-style structure without needing to turn every multi-step piece of work into its own project.
It's particularly useful when something is too large for one issue but too small to justify creating an entire project around it.
Organizing your work is only part of the problem.
Sometimes you simply need a better way to look at it.
That's where Views become useful.
You can filter your issues and save views based on the information you regularly care about.
For example:
Issues assigned to me
Issues currently blocked
Bugs
Work ready for development
High-priority issues
Issues belonging to a particular project
The underlying issues haven't changed.
You're simply creating different windows into the same work.
This becomes particularly useful as the number of issues grows. Instead of repeatedly searching or applying the same filters, you can create a view for the questions you regularly need to answer.
The useful part isn't any individual feature. It's how they work together.
Projects group work around a larger outcome.
Milestones divide that outcome into meaningful stages.
Parent and sub-issues break complex pieces of work into actionable steps.
Views let you look at all that work from the perspective you need.
You don't need all of these for every project.
But as the work gets more complex, having different levels of organization can make it much easier to understand both the bigger picture and what needs to happen next.
Sometimes an issue is enough.
And sometimes you need to zoom out.