We Set Up Linear on Day One. By Month Three, It Ran Itself.

When Anya and I incorporated the company, we had a four-person founding team: two engineers, one designer, and me. Our issue tracker was a shared Notion page with a table. It worked for six weeks. Then we hired a fifth person and the Notion table stopped scaling. Issues got lost. Priorities were unclear. "Who's working on what?" became a daily question that took five minutes of Slack back-and-forth to answer.

We set up Linear that afternoon. The whole setup took about forty minutes. Within a week, the "who's working on what?" question disappeared. Linear answered it.

What I didn't expect was what happened over the next nine months as we grew from five to twenty. Linear's opinionated structure kept working, but the manual processes around it didn't scale. So we automated them, one at a time, until the system mostly ran without us thinking about it.

Day One: The Setup

Linear doesn't give you many choices during setup, and that's the point. We created one team (Engineering), set up four workflow states (Backlog, Todo, In Progress, Done), and started creating issues. No custom fields. No labels. No integrations. Just issues with titles, descriptions, assignees, and priorities.

The priority system is fixed: Urgent, High, Medium, Low, No Priority. You can't add custom priority levels. At first, Kenji (our first hire) thought this was limiting. "What about Critical?" he asked. I told him that's what Urgent is for. He grumbled but accepted it. Nine months later, he told me the fixed scale was one of his favorite things about Linear. "Every tool I've used before had custom priority schemes that nobody agreed on. Linear's five levels are simple enough that everyone uses them the same way."

We created our first cycle (Linear's term for a sprint) on day three. Two-week cycles. Linear defaults to this and we never changed it. The cycle view shows what's planned, what's in progress, and what's done. At five people, the board fit on one screen.

Month One: Still Simple

Five engineers, one cycle at a time, maybe 30 issues per cycle. Triage was me spending ten minutes each morning in Linear's inbox. New issues from the team, bugs from testing, feature requests I'd written up. I'd set priority, assign them, and drag them into the current cycle or leave them in the backlog.

We added our first labels: "bug," "feature," "chore." Three labels. The temptation to add more was real. Elena suggested "tech-debt," "customer-reported," "quick-win," and "design-needed." I said no to all of them. At five people, you don't need a taxonomy. You need to know what type of work it is and who's doing it.

The daily standup was in person. Everyone said what they were working on, what was blocked, and what they'd ship that day. It took seven minutes. We didn't need any tooling around standup because five people in a room is already efficient.

Month Two: Growing Pains Start

We hired three engineers in month two, bringing us to eight. The standup got longer. Not because each person talked more, but because eight people meant more cross-dependencies, more "wait, I thought you were working on that," and more coordination overhead. Standups crept from seven minutes to fifteen.

The triage load doubled. Instead of 30 issues per cycle, we had 50. My ten-minute morning triage became twenty minutes. Some mornings I'd skip it because I had back-to-back meetings, and the untriaged issues would stack up.

We split into two teams: Platform (Kenji's team) and Product (Elena's team). Linear's team concept maps perfectly to this. Each team has its own board, its own cycles, and its own backlog. Cross-team issues go into a shared "Triage" team, and I'd route them during my morning session.

The first real scaling problem was the backlog. At five people, the backlog had maybe 40 items. At eight people, it had 120 items after two months. Nobody groomed it. Nobody knew what was stale, what was duplicate, what had been solved by other work but never closed. The backlog became a guilt-inducing list of things we'd probably never do, mixed in with things we genuinely needed to do soon. It would take us until month eight to solve this properly with a backlog grooming agent, and I wish we'd done it sooner.

Month Four: The Automation Starts

Priya joined as our first engineering manager. She took over triage from me, which freed up my mornings. But she also inherited the backlog problem and the standup problem.

Her first change was adding automated standup generation. Instead of the daily in-person standup (which was now fifteen minutes with twelve people), she set up a standup generator that pulled each person's Linear activity from the previous day and posted a summary to Slack. What each person closed, what they moved to In Progress, what's blocked. The summary hit Slack at 9:15 AM, before the standup. The standup itself became a discussion of blockers and questions, not a status recitation. It dropped from fifteen minutes back to seven.

The team pushed back at first. Tomás said it felt like surveillance. But after a week, he changed his mind. "I like that I don't have to remember what I did yesterday. The agent already knows. And the standup is actually useful now because we talk about real problems instead of listing tasks."

The time savings were modest per person (maybe five minutes per day), but across twelve people, that's an hour of engineering time recovered every day. Over a month, that's roughly 20 hours. Not transformational, but a nice win for zero ongoing maintenance.

Month Six: Triage Gets Automated

At sixteen engineers across three teams (Platform, Product, and Infrastructure), Priya's morning triage was taking thirty-five minutes. New issues arrived from engineers, from our customer support Slack channel, from product managers, and from QA. Each one needed to be read, assigned a team, given a priority, labeled, and either added to the current cycle or left in the backlog.

We added an issue triage agent that handled the obvious cases. It read new issues, assigned them to the right team based on the content, set an initial priority, and applied labels. Priya reviewed the agent's assignments each morning instead of triaging from scratch. Her triage time dropped from thirty-five minutes to about ten.

Over the first month, the agent correctly assigned the team for 83% of issues and set appropriate priority for about 78%. The misses were edge cases: cross-team issues, vague descriptions, and priority calls that depended on business context the agent didn't have.

Month Eight: The Backlog Problem

By month eight, we had twenty engineers and a backlog of over 300 issues. Priya's quarterly attempt to groom the backlog took an entire afternoon. She'd go through each issue, check if it was still relevant, check for duplicates, and make keep-or-close decisions. Four hours of tedious work that she dreaded and often postponed.

The stale issue problem was the worst part. Issues filed three months ago that referenced code that had been refactored. Feature requests from customers who had since churned. Bugs that had been fixed by other work but never explicitly closed. Duplicate issues filed by different people who described the same problem differently.

We added a backlog grooming agent that runs every Friday. It scans the backlog, identifies issues with no activity in the last 30 days, checks for duplicates by comparing titles and descriptions, flags issues that reference code or features that have changed since the issue was filed, and generates a report with recommendations: close, merge, or keep.

Priya reviews the report on Friday afternoon. It takes her about twenty minutes. The agent typically recommends closing 15 to 25 issues per week. Priya agrees with the recommendation about 85% of the time. The other 15% she keeps open because she has context the agent doesn't, like knowing that a low-activity issue is actually part of a planned initiative for next quarter.

After eight weeks of automated grooming, the backlog went from 300+ issues to about 140. More importantly, the 140 that remained were all genuinely relevant. When engineers looked at the backlog, they could trust that everything in it was real work that needed doing. That trust changed how people interacted with the backlog. Engineers started pulling from it during cycle planning instead of ignoring it.

Month Nine: The Current State

At twenty engineers across three teams, Priya spends about 45 minutes per day on Linear process management, down from roughly two hours at the same team size with manual processes. Morning triage takes 10 minutes (reviewing the agent's assignments instead of triaging from scratch). Standups take seven minutes of discussing blockers (the status recitation is handled by the Slack summary). Cycle planning happens every two weeks and takes about 30 minutes per team because the backlog is clean. Friday reports take five minutes to review before forwarding to leadership.

That's not because Linear does more. It's because agents handle the repetitive reading, categorizing, and summarizing that doesn't require human judgment.

What I'd Tell Day-One Founders

Start with the minimum. One team, default workflow states, no custom fields, no labels beyond the basics. You can add complexity later. You can't easily remove it.

Use cycles from the start. Even at five people, the discipline of planning two weeks of work and reviewing what got done builds a rhythm that scales. We've used two-week cycles since day one and never changed.

Don't automate until it hurts. Our standup generator would have been pointless at five people. Our triage agent would have been overkill at eight. Each automation solved a problem that had become painful at a specific team size. If you automate too early, you're maintaining automation for a problem you don't have yet.

Keep the backlog honest. The biggest operational debt we accumulated was a backlog full of stale issues. If I could change one thing, I'd have started weekly backlog grooming at month three instead of waiting until month eight when the problem was much larger.

Linear's opinionated setup is the right foundation for a startup engineering team. It makes the right choices about workflow, hierarchy, and simplicity so you don't have to. The work of scaling comes not from configuring the tool but from automating the human processes around it.

Try These Agents

• Linear Backlog Grooming Agent -- Weekly backlog review that identifies stale, duplicate, and obsolete issues
• Linear Issue Triage Agent -- Automatically categorize, prioritize, and route incoming issues
• Linear Slack Standup Generator -- Daily activity summaries from Linear posted to Slack