Best practices for large workspaces to structure teams in Linear
As an organization grows, teams need the flexibility to work in ways that suit them without making it difficult to collaborate across the company. Here’s how to structure teams in Linear and establish shared standards and workflows that balance autonomy with alignment.
Create teams around meaningful boundaries
Teams are the main way to organize people in Linear, often representing groups of people who work together frequently. A team can stand on its own or be organized into a hierarchy, with a parent team nesting sub-teams beneath it. Sub-teams inherit certain workflows from their parent while configuring others independently, allowing different parts of the organization to establish their own processes while remaining connected within a shared structure.
When using a hierarchy, treat parent teams as the broadest groups of people you want to represent in Linear, and then create sub-teams for the specific groups within them.
When an entire org is using Linear, parent teams are usually major functional groups like Product, Engineering, Marketing, Ops, Finance, and so on. For companies where Linear is primarily used by Product and Engineering, parent teams might instead represent product groups like Core Product, Platform, and Growth.
A good rule of thumb is to start with the smallest possible number of parent teams that reflect how the organization is structured. It’s easier to add structure over time than to unwind unnecessary complexity later.
Add sub-teams to mirror operating structure
Sub-teams might follow reporting lines, product areas, business units, or any other grouping that people are already familiar with. They give leaders centralized visibility across the teams beneath them. For example, an engineering manager overseeing Infrastructure, Platform, and Mobile can use the parent team to track work across the three sub-teams from one shared space.
A useful way to decide whether you need a sub-team is to consider whether that group of people is likely to have unique ways of working. If you’re mainly trying to categorize an area of work, you’re better off doing that within a single team. For example, Mobile might need its own sub-team if it plans work separately or reviews incoming requests differently. By contrast, bugs, technical debt, and feature work handled by the same engineering team can stay together, with labels such as “Bug,” “Technical debt,” and “Feature” distinguishing the issues.
Use team types intentionally
We recommend keeping teams public by default to support collaboration but private teams are an important exception, commonly used for sensitive work where access needs to be tightly controlled, like HR matters, customer data, or executive planning. A private team’s issues can only be viewed by the members added to it.
When a private parent team has sub-teams, you can control visibility more precisely. A restricted sub-team is visible to members of the parent team, who can choose to join it; a private sub-team is visible only to people explicitly added to it.
These sub-teams are useful for modeling internal business groups that need to manage their own team access. For example, if you have a skunkworks group operating within your company, its members can join the relevant sub-teams themselves, without relying on IT to manage individual team access.
Standardize operating conventions across a team
Beyond organizing people, teams in Linear also help groups of people establish shared ways of working. When everyone follows different processes, coordinating work can quickly become chaotic, especially as AI takes on more of it. Common conventions make it easier to track progress across teams and give agents a consistent structure to follow as they move work forward.
Take an engineering org with Engineering as the parent team and Infrastructure, Platform, and Mobile beneath it. If those teams plan work on the same two-week cadence, Engineering can define the cycle schedule once and every sub-team will follow it automatically. They might also choose to share the same statuses and estimates, so issues move through the same stages (like “backlog,” “in-progress,” and “done”) and the same scale is used to estimate the size or complexity of work.If they categorize bugs, technical debt, and customer requests in the same way, those labels can be defined once at the team level and be made available to every sub-team. The sub-teams may share templates for recurring types of work like incident reviews, or saved views that surface the issues everyone needs to keep an eye on.
As a general rule, make labels and issue templates available only to the teams that need them. Otherwise, they can accumulate over time, leaving people to sift through a sea of irrelevant options in their day-to-day.
Define how work enters and moves through teams
Once your team is set up, the following principles offer guidance on building good work habits in Linear.
Connect your team to the work
You want to make submitting work to your team as easy as possible, but there’s a balance to strike between keeping the process simple and ensuring each request arrives with enough context for your team to act on it. Since work often comes up in Slack conversations, connecting Linear to your Slack workspace is a natural starting point. This makes it possible for people to tag Linear Agent to create an issue from a long thread that resulted in useful product feedback.
And when people outside the team need to request something, Asks provides a structured way to gather relevant information upfront. A product team, for example, might use a feature request template that asks what the desired outcome is and how users are working around the problem today.
Turn requests into the right next steps
If anyone can file anything straight to your team, your backlog is likely to fill up quickly, with no efficient way to move work forward. Our recommendation is to have Loops take on much of that. An engineering team, for example, could have a loop review each day’s requests, identify and label bug reports, and assign a coding agent when there’s a clear fix. When there isn’t, the loop can share its findings with the relevant code owner so they have the context to take it further.
Linear comes with some automations built in, like updating issues when pull requests move through review and merge states in GitHub. That way, your team isn’t spending their days retroactively tracking their agents’ work.
Use what you learn to improve workflows
We recommend regularly zooming out to understand where a team could work more effectively. Are important issues getting stuck? Are requests piling up? Are the same bottlenecks appearing again and again?
A good starting point is asking Linear Agent these questions. The agent can set up views, dashboards, and loops to help you understand which parts of the workflow need attention. A Platform team, for example, might ask the agent to identify high-priority bugs that haven’t moved forward and look for common blockers, such as fixes waiting on the same reviewer or work held up by another team’s API changes. Those patterns can help the team decide whether to share review responsibilities more broadly or coordinate dependencies earlier, rather than simply pushing people to close more issues.