How to Manage a Development Team in Linear in 6 Steps

Most engineering teams that look disorganized are not lacking effort. They lack one place where the work lives. The roadmap is in a spreadsheet, decisions get made in chat, tickets stack up in a queue nobody opens unless something is on fire, and the founder is the only person holding the three together. Linear starts from the reverse arrangement: a single workspace for the company, with three levels of work inside it that answer the three questions a manager keeps asking: what is this person doing today, what ships this quarter, and what is the company actually trying to get done?

This guide sets up Linear for a development team in six steps, starting at the workspace, going down to a single issue, and coming back up to company goals. It is written for founders and CTOs who manage engineers rather than for the engineers themselves, so each step says what the structure is for and what you have to decide to put it in place. A short quiz before the conclusion checks that the three levels stuck.

Step 1: put the company in one workspace, then cut it into teams

Linear gives a company a single workspace. Not one per department, not one per product line. The workspace is the company, and everything else is nested inside it.

The first real decision is how to cut that workspace into teams. Two approaches both work, and Linear is deliberately neutral between them:

1. Mirror the org chart. Each reporting line gets one team. That is simple to explain to a new hire and simple to keep in sync with payroll and permissions.
2. Group people who work together regularly. You get one team per surface or product area, whoever reports to whom. In a small company where one manager covers several areas, this usually matches how the work really flows.

Whichever you pick, issues and projects live inside a team. That is what makes the choice worth five minutes of thought rather than five seconds: a team is the container everything else inherits.

You can see the split in the sidebar. The upper block (Initiatives, Projects, Views, Teams) applies to the whole workspace, while anything under a team name belongs to that team alone. Standard processes set at workspace level keep reporting consistent from team to team, yet each team can still configure its own workflow without asking anyone. For someone you bring in from outside, this structure is also the quickest explanation of how the company works; keep that in mind when you onboard a remote developer.

Step 2: give each team a workflow it will follow

Most of the custom setup, and most of what goes wrong with it, happens in a team's issue statuses. Linear sorts statuses into four buckets, and triage sits in front of them:

• Triage holds incoming issues that nobody has sorted yet. The screenshot below shows a queue of nine, marked as needing to be triaged.
• Backlog covers everything accepted but not yet scheduled, and it is usually the biggest bucket by a wide margin.
• Unstarted holds work that has been committed to but not picked up, usually as a single Todo status.
• Started means work in flight. It is the bucket teams extend: here that means In Progress and In Review, with a new Planning status being created.
• Completed holds the end states, and there can be more than one. In this team, Done and Commit show up as separate statuses.

The bucket is what keeps the freedom safe. A team can invent the statuses that match how it works, and because every status still belongs to one of the four groups, a project read at company level stays comparable across teams. Add statuses when a real handoff exists and someone is waiting. Skip them when the status only records a feeling about the work.

The sidebar of each team also lists its cycles, current and upcoming, where sprint-style commitments land if you run them. Structure alone will not run the meeting for you, so it still pays to be deliberate about how you run sprint planning.

Step 3: make the issue the unit of work

In Linear, the most basic unit of work is the issue: a concrete task that one individual owns and that takes hours or days to finish. That definition works as a filter. Work that needs three people, or three weeks, is not an issue. It is a project with issues inside it, and squeezing it into a single ticket is how a board ends up with one item that has sat at 60% for a month.

Creating an issue is meant to cost nothing. Press C anywhere to open a new one; most other actions sit behind a keyboard shortcut or the command menu. When your team keeps writing the same kind of ticket (bug reports, incident follow-ups, customer requests), make it a template so the fields arrive pre-filled.

For a manager, what counts is what the issue contains once it exists. Everything needed to do the work, and to judge whether it is done, is meant to sit on the issue itself:

• Attached files and sub-issues for anything that splits.
• Linked pull requests, their state visible on the issue (the one below appears as merged).
• Synced Slack threads, so you can read the conversation that led to the change without leaving the ticket.
• Comments for updates, so the latest state stays up front instead of buried in chat.

The properties panel on the right holds status, priority, assignee, estimate, labels, the cycle the issue belongs to, and the project and milestone it rolls up into. That final pair links this step to the next. From the level where you make decisions, an issue with no project is invisible. Writing the description is a skill of its own, and the same rules apply as when you write user stories.

Step 4: group issues into a project with a written overview

A project groups issues that add up to a timebound deliverable, and teams can work on it jointly. The standard example is a feature that takes several weeks and needs more than one team to ship. It is exactly the unit a founder cares about, and exactly the unit that normally has no home in a ticket queue.

The project overview serves as the source of truth. Read that as a statement about where the writing goes, and take it literally:

1. In the ideation phase, write the spec in the overview. Do not put it in a separate doc that gets linked once and then drifts.
2. Finalize the details in comments and threads on the overview itself, which keeps the reasoning beside the decision.
3. As the project grows, add related documents, or link to external files like designs and spreadsheets. In the screenshot below, the Resources row contains an interaction flow and a mockup file.
4. When you are ready to build, convert the list items in the spec into issues and then sort those issues into milestones.
5. Then revisit the project properties to set status, priority, members and timeline. People skip this one all the time, yet it is the row every roll-up view reads from.

A project overview's header shows all of it at a glance: status, priority, the teams involved, the lead, the members, and the date range the project is meant to span. Below it is the update box, with the current health. Scoping the deliverable before any of this remains the hard part, and it is the same exercise as when you scope an MVP.

Step 5: save the views you check often, and write project updates

As work builds up, the default lists stop helping, since they show everything. Linear answers this with saved views: you build the filter once, save it and return to it rather than rebuilding the same filter every Monday. For a manager, the useful views are narrow ones: everything at risk, everything targeted at this quarter, everything assigned to the person you are meeting in ten minutes.

The view below is sorted into quarters and carries the columns a manager reads first: health, priority, lead, target date and percentage complete. Health is the column worth watching, because On track, At risk and Off track are set by the people doing the work rather than derived from a progress bar.

The write-up is the other half of this step. Project leads send project updates so the wider organization stays informed about progress and health, and those updates can be cross-posted straight into the team's Slack channel. That is what replaces the status meeting. More of the company reads a written update landing in the channel where they already are than a meeting half of them cannot attend, and the update leaves a record you can scroll back through when a project slips.

Step 6: roll projects up into initiatives

Above the project sits the initiative. It tracks a larger stream of work spanning multiple projects, is normally tied to a top-level goal or objective at the company, and can run for a quarter or for several quarters.

This is the view a founder or CTO lives in. Each initiative carries a one-line description of the outcome, an owner, a target period, a health indicator and a count of how many of its projects are complete. Seeing every initiative on one screen is the fastest answer to the question of what the company's top-level priorities are right now, and it is the only level where that question has a short answer.

It helps to restate the three levels as a test for any piece of work that comes in:

• One person, hours or days, a single clear outcome: that makes it an issue.
• Several people, several weeks, a dated deliverable: that is a project.
• Several projects, a quarter or longer, tied to a company goal: that makes it an initiative.

If work cannot be placed on one of those three lines, it usually has not been defined yet, and the gap shows up in Linear long before it shows up in a deadline.

Habits worth setting up in the first week

Setting up the structure above is the slow part. Whether the team keeps using it comes down to these small things:

• Teach the keyboard shortcuts on day one. C opens a new issue, and the command menu handles everything else. People write less to a tracker that is slow to write to.
• Create templates for the ticket types you see weekly. That means bugs, customer requests and incident follow-ups. Pre-filled fields are the cheapest route to consistent issues, with no policing required.
• Link the pull request to the issue every time. The issue then becomes a record of what actually shipped instead of what was planned.
• Sync the Slack thread instead of summarizing it. The decision keeps its context, and nobody has to search chat six weeks later.
• Write the spec in the project overview, and link designs and spreadsheets as resources instead of pasting in their contents.
• Convert spec list items into issues once the project moves to implementation, then group them under milestones to give a long project internal checkpoints.
• Cross-post project updates to Slack. An update nobody sees does not inform anyone, and this is a setting rather than a habit anyone has to remember.

One workspace, three levels

Six decisions make up the setup: one workspace for the company; teams that match either the org chart or how people actually work; a status workflow per team, inside the four standard buckets; issues sized for one person and a few days; projects whose overview is the source of truth; and initiatives that tie projects to company goals. Once the structure fills up, saved views and written project updates keep it readable.

The hardest part of running a development team is rarely the tool. It is having enough engineers to put against the work you just made visible, and knowing that each of them can take an issue and finish it without supervision. If that is the constraint, we can place vetted developers on your team and handle the sourcing while you keep the roadmap moving.