Before we launched Linear agent, our teams were already using it across Slack, Linear, and our codebase. It’s become a core part of how we build. Here are three workflows that have proven most effective:

• A customer email turns into a shipped feature
• A Slack thread becomes a pull request
• A PM files an issue, and ships the fix

As you’d expect, some of what we use internally has not been released yet, and we’ve called that out where relevant.

From customer email to shipped feature

Stage 1: Pull the context into Linear

Customer feedback submitted by email, or in-app within Linear, accrues to an Intercom inbox managed by Customer Experience. That creates a large volume of high-signal feedback which needs to find its way through the org to the right team. Through Linear agent, CX turns emails into scoped issues directly from Intercom, without ever needing to leave the inbox.

The agent picks up the full context, including any back-and-forth with the customer, metadata, and attachments. While you can add extra details in Intercom to help define the issue, Alexandra Lapinsky Wilson, who leads Product Operations and CX, says she rarely finds it necessary. The agent typically gets it right.

Stage 2: Route it to the right team automatically

Once the agent has scoped the context into an actionable issue in Linear, the CX team doesn’t have to hesitate over who to assign it to because Triage Intelligence handles that step. It sends feature requests to the product management team’s triage queue, and in doing so, flags duplicates, suggests the right labels, and links relevant customer context, including their Datadog and Sentry.

Stage 3: Make sense of overlapping feature requests

Often projects can fill up with feature requests related to the same part of the product without quite asking for the same thing. Untangling this is time consuming and easy to put off, which can turn it into a bottleneck.

When Sid Bhargava, a PM, runs into a catch-all project like this, he opens a chat with Linear agent and asks it to identify the main themes across the requests; an example of a repeatable workflow that Sid could save as a Skill.

After reviewing the output, he instructs the agent to reorganize the issues around the themes, shaping the work into a clearer starting point for Engineering. Sid also might use the agent to add usage scenario context to an existing PRD, draft implementation issues based on a spec, or write a PRD from scratch for a new project.

Stage 4: Code alongside the agents

Once an engineer picks up the issue, how they work with the agent depends on the nature of the task at hand. For more complex requests, Mingjie Jiang, one of our product engineers, starts by chatting with Linear agent about the history of decisions around that part of the product: Why did we build the feature this way? When was it most recently touched? Which engineers should I talk to if I have further questions? The agent uses Code Intelligence to provide answers grounded in its knowledge of our codebase. (We’re currently testing Code Intelligence and custom MCP servers internally, with plans to launch soon.)

Mingjie then usually delegates the issue to a coding agent directly within Linear. While the issue reflects the delegation, it remains assigned to him. The agent takes a first pass to save Mingjie the friction of starting from scratch, then, if necessary, he continues the work locally. He sees even AI’s mistakes as useful because it shows him potential failure modes as he works through the problem.

At Linear, a coding agent takes a crack at reviewing every PR (for the past couple of months, we’ve been leaning on Codex for this), and then a human engineer makes the final approval. When the pull request is merged, our Github integration marks the related issue in Linear as ‘Done’.

Stage 5: Close the loop with a happy customer

When an issue is marked ‘Done,’ every related feature request reopens in Intercom with a note for the CX team to know that the customer’s request is fulfilled. The team then follows up with each one, which Alexandra calls a joy because customers are delighted that their request made it into the product and that Linear took the time to tell them about it.

How a complaint in Slack ends up as a pull request

Stage 1: Turn a Slack thread into a scoped issue

In shared Slack channels with our high-priority customers, ambiguous user feedback used to mean a scramble for context. Now, Simone Jacobs, who works in Customer Support, starts with Linear’s Slack agent.

Simone questions the agent in an internal product channel, with the intention of drawing Engineering and Product into a discussion about its response. She sees the agent’s role as providing context about the current state of the product, allowing the team to focus on the roadmap ahead.

Product engineers like Mingjie keep an eye on these discussions, often using the agent to create an issue routed to the engineering triage queue directly from Slack. And if the discussion continues, he tags Linear again to update the issue instead of reading through dozens of new messages.

Stage 2: Code alongside the agents

When engineer Matthijs Wolting is assigned a customer-specific issue like this, he uses Linear agent, along with Code Intelligence and custom MCP servers, to investigate. This saves him from the tedium of looking up the right customer ID, logs, and metadata, and correlating information fragmented across various tools.

Matthijs gets the best results from coding agents by breaking the work into small, targeted steps, which keeps the agent on track and creates a much narrower path to success.

Stage 3: Close the loop with a happy customer

Once Matthijs has resolved the bug, he marks the issue as ‘Done’ in Linear. This automatically sends a notification to the Slack thread where the issue originated, which is Simone’s signal to follow up with the customer.

When the person who noticed it can also ship it

Stage 1: Find a problem (and fix it)

Product managers like Sid are restless beings. He sometimes fiddles with features in Linear without a precise objective, just to re-experience them the way a new user would. Recently, he noticed there was no way to filter for issues that had been created from a specific external source, a gap that made it harder to track and triage that work

He used Linear agent to create an issue to add that filter and take a first pass at actually adding it. The agent opened a pull request, which was reviewed by a human engineer within the hour (thanks, Paco Coursey), and the change was live.

…and there’s no Stage 2

The same prompt that Sid would’ve once used to report an issue can now be used to solve it. Deciding when to work this way, he says, is still a judgment call. UI polish like copy edits is an obvious candidate, but what made this especially interesting was that it was a functional, albeit small, change in the product.

How you can get the most out of Linear

We’ve noticed a few recurring patterns in the way teams at Linear use the agent. The most effective workflows seem to share the same principles, and we’re keeping a running list of them, with an eye to consolidate in the near future.

The best workflows keep the agent close to the source

Teams get the most value when they use it inside the systems where work is already happening, like Intercom, Slack, and Linear.

Autonomy works best when it is introduced gradually

Teams start by asking the agent for suggestions, observe its performance, and add guidance, only putting it on autopilot once it’s proven reliable. Engineers too, get better results by breaking work into small, focused steps instead of delegating a broad task.

The agent is most useful at points of friction

People use it where work would otherwise stall, whether that means making sense of overlapping requests, debugging a gnarly customer-specific issue, or clarifying ambiguous feedback.

We notified the owners/admins of affected workspaces by email on Thursday, March 26.

We’re sorry this happened. Private teams and guest roles exist so that sensitive work stays visible only to authorized members, and we failed to uphold that boundary.

Below is a timeline of the incident, more detail around its cause, and the steps we’ve taken and intend to take.

Incident timeline

All times are in Coordinated Universal Time (UTC)

March 24

• 00:07: Code change deployed to production.
• 01:10: Initial subset of exposure identified, code change reverted, and rollback deployed.
• 01:30: Server side cache reset and database version incremented, forcing client cache reset.
• 01:40: Customer report of notification email with excessive content.
• 01:45: Incident channel opened.
• 03:13: Mobile clients active during the window logged out, forcing cache reset.
• 03:23: Web and desktop clients forced to clear cache with reload.
• 04:02: Status page incident published.
• 05:04: Auto-generated Pulse feed posts created during the window deleted as a precaution.

March 25

Data gathering and analysis efforts to understand per-workspace exposure continued.

• 23:45: Email notification sent to all affected workspace contacts.
• 23:47: Status page incident marked as resolved.

March 27

Analysis efforts to understand per-workspace exposure continued.

• 21:30: Began sending per-workspace exposure summaries to customers who requested additional detail.

What happened

Linear’s access control layer uses an internal “sync group” mechanism to determine which data each workspace member can access. When a query is executed—whether via the web client, mobile app, or API—sync group resolvers add permission filters to ensure users only see data from teams they belong to.

A performance optimization attempted to skip sync group resolvers that could never match a given user’s permissions. The optimization was gated to run only for a single internal workspace in production, with the intent to validate before broader rollout. However, the code that disabled the optimization for all other workspaces contained a variable shadowing bug: instead of falling back to the original unfiltered resolvers, it omitted all user specific resolvers.

This caused the downstream permission check to be skipped entirely; rather than raising an error, queries silently returned results without team-level filtering.

The change was tested and peer-reviewed. Our existing test coverage validated that the optimization worked correctly when active, but did not cover the codepath where it was disabled for non-target workspaces. This is the gap that allowed the regression to reach production.

This change was written and reviewed by engineers without AI assistance. While we use AI extensively in our development workflow, the root cause here was a variable shadowing bug in a code path that was peer-reviewed and tested. The gap was in test coverage, not in the authoring process.

What was affected

No data was exposed to anyone outside each workspace. No credentials, API keys, or authentication tokens were exposed.

During the window, data from private teams may have been exposed to other workspace members, including:

• Issues, comments, and attachments
• Projects, documents, and related entities

Private teams did not appear in the Linear web or desktop app interface directly.

The exposure was primarily through:

Notification emails: Digest emails sent to workspace members during the window may have contained inflated unread counts and details of activity from private teams. The notification system, operating under the broken permissions, generated notifications spanning team boundaries. In some workspaces, a single member received a digest containing notifications for the entire workspace.

Web and desktop client data sync: Approximately 7,000 full client bootstraps occurred during the window. Users who synced may have temporarily had data from private teams in their local client database, though this data was not surfaced in the app interface. All clients were force-reloaded during remediation to clear cached data.

Mobile app: Mobile sessions active during the window may have had access to data from private teams via in-app functionality. All mobile sessions active during the window were logged out. Pulse feed content that may have contained cross-boundary data was deleted.

API and third-party integrations: OAuth apps and API keys made requests during the window that may have received responses containing data from private teams, depending on the scope of each integration’s queries. Integrations that query specific issues or teams they already have access to would not have been affected, while those making broader queries may have received data beyond their normal permissions. API access was restored to normal permissions when the code change was reverted.

Background tasks: Several server-side tasks that operate with user context were affected. The notification pruning task incorrectly archived notifications at the workspace level instead of per-user, and the feed summary generator produced posts with cross-boundary data. Incorrectly archived notifications were restored, and affected feed posts were deleted.

Our post-incident audit of sensitive mutations—team membership changes, role changes, and workspace invitations—across all affected workspaces found no evidence of malicious abuse.

Our response

Following identification of the issue, we completed an initial set of remediation activities:

• Reverted the code change within one hour of deployment
• Force-reloaded all desktop and web clients to clear cached data
• Logged out all mobile sessions active during the window
• Conducted an audit of access and modification logs for affected workspaces

We notified affected workspace contacts within 48 hours of the incident. For customers who requested additional detail, we provided per-workspace exposure summaries covering activity associated with each exposure vector during the window.

Next steps and improvements

This incident revealed gaps in how we validate and deploy changes to our access control layer. We’ve already made the following changes:

• Expanded integration test coverage that validates permission boundaries across deployment environments, team types, user roles, guest access, and authentication methods.
• Implemented limits to cap the number of notification items rendered in a single digest email.

Additional followup tasks we will prioritize are:

• Tighten enforcement of pre-deployment security review, by human and agent, for any changes to authorization-related code paths.
• Improve operational monitoring for anomalous authorization layer behavior and permission boundary violations.
• Extend internal logging system to provide a higher level of visibility into workspace related events.
• Allow workspace admins / owners to configure specific security contacts for future notifications.
• Document incident data collection process to enable faster analysis in future incidents.

We take the trust our customers place in us seriously, and we’re committed to the actions above and continued transparency in our incident response.

Software rarely gets worse all at once. More often, it contorts out of shape one useful feature at a time: a new control here, another state there, an exception for one workflow followed by yet another. Even when each decision makes sense in isolation, over time, the product begins to feel crowded, inconsistent, and hard to use.

A big part of building good software is carefully pruning the product’s edges, returning it to what is helpful and intuitive to users. Since the last major redesign in 2024, Linear has evolved considerably, and that growth created opportunities to make the interface more consistent—for example, the layout of the header bars, where actions like sharing a page, copying a link, and opening a PR no longer appeared in predictable places.

We believe that the experience of using the product should feel familiar and fluid; and that spirit guided the improvements we’re introducing to Linear’s visual interface today.

What changed in the interface

Linear is designed to surface exactly what you need, when you need it. The challenge was preserving that rich density of information without letting the interface feel overwhelming. To that end, the refresh was guided by a couple of design principles.

Don’t compete for attention you haven’t earned

In a product as information-dense as Linear, not every element of the interface should carry equal visual weight. While the parts central to the user’s task should stay in focus, ones that support orientation and navigation should recede.

The navigation sidebar used to appear bright enough that it remained visually prominent even after a user had reached their destination. In the updated interface, it’s a few notches dimmer, allowing the main content area—where users work—to take precedence.

We treated the tabs at the top of the desktop app similarly, making them more compact rather than spanning the full width of the screen, with rounded corners and smaller icon and text sizing.

We applied the same thinking to icons. Linear relies on them to make projects, issues, initiatives, and statuses recognizable at a glance, but in some views their presence had grown excessive. The refresh reduces icon usage, scales their sizes down, and removes unnecessary visual treatments like colored team icon backgrounds.

Structure should be felt not seen

Borders and separators help clarify the relationship between elements in the interface. While these dividing lines are intended to help users orient themselves, they had quietly proliferated across the platform, sometimes appearing without clear reason. By rounding out their edges and softening the contrast, the polished interface gives users structure on the page without cluttering their view.

How we approached the refresh

A refresh of this scope has an obvious organizational challenge baked into it. The design system and component library were both changing at the same time that other teams were actively building features on top of them. When the foundation shifts beneath you, even slightly, the natural instinct is to pause and wait for solid ground. That hesitation compounds quickly, so we had to find a way to move fast without creating uncertainty for the rest of the team.

The tools that helped us move faster

Moving this quickly was made possible by a few bespoke internal tools we built along the way—and by leaning on coding agents where they were most useful.

A handy dev tool bar — The dev toolbar exists directly inside the app and allows us to easily toggle feature flags on and off. When something didn’t look right in the refreshed UI, it took us just one click to compare it with the previous version. That made it easier to determine whether the refresh had broken something or whether it had behaved that way before. Having the updates live behind feature flags also meant that instead of developing the redesign in isolation and shipping all the changes at once, we could integrate incremental changes to the platform.

An integrated color picker — Linear already allows users to create custom themes by selecting base UI and accent colors and adjusting contrast. While that capability remains, the refresh changed the default ‘light’ and ‘dark’ modes that ship with the product. The old palette was a cool, blue-ish hue, and the aim was to inch toward a warmer gray that still feels crisp, but less saturated. Go too warm, though, and the interface risks looking muddy, so getting it right involved a fair bit of iteration.

But experimenting with these changes was painfully slow: mocking it up in Figma, implementing the update in a PR, spinning up a preview build, reviewing it, and repeating the process. To speed things up, we used Claude Code to build a color tool inside Linear’s dev toolbar. The tool allows us to do everything the user-facing theme builder can do, while also exposing controls for tweaking the hue, chroma, and lightness of individual design tokens. Anyone at Linear could experiment with different combinations and share their preferred “recipe” with us.

Once we landed on a palette we liked, we copied the token values as JSON and imported them directly into Figma using a plugin built by one of our designers, Yann-Edern Gillet. This created an alignment between what we were experimenting with in the interface and what lived in the design system.

A team of coding agents — As a team of two that had started working on the codebase just two months ago, we used coding agents to bring us up to speed. The Linear agent, Cursor, Codex, and Claude Code helped us answer practical questions that would’ve otherwise been a time suck: where a component was defined, the places it was used across the product, and which designers and engineers had historically worked on this area.

We also used coding agents to move faster in execution. They helped us build internal tools like the color picker in a couple of hours, and made it more efficient to prototype larger ideas. When we were choosing between two directions, we could explore both quickly, and then invest more time in implementing the right one well.

Approximating the future, by design

This refresh was aimed at improving the human experience of the product: making the interface better for the people using it every day, with an eye toward how it might evolve further over time. While Linear was originally designed to help humans coordinate with one another, it has since matured to support other kinds of interactions, including agentic workflows through integrations with leading AI providers, as well as the launch of an API for agents.

Much of this project came down to tweaking a series of small details, reviewing the changes, and tweaking some more until things felt right. If most people don’t immediately notice what changed, that’s probably a good sign. Just as Linear’s users rarely think about the bugs they never hit, the paper cuts that were smoothed away, or the performance issues that never slow them down; most of what makes software feel good is what you aren’t likely to see.

The recent discourse has focused on whether designers should code, whether code is the right medium for design, how code “presents the truth” of a design, and so on. But I think centering this debate on code and tools is reductive.

The bigger question to me is what happens to how we see designers contributing in the future, especially now with AI and these new tools. How do roles evolve, and what do we start expecting from each of them?

Are designers now engineers, with the same expectations? Do engineers start having the same expectations of designers? Will we still have a “head of engineering” and “head of design”, or does it turn into something like “head of craft”? Titles don’t matter that much, but these questions are useful because they reveal what we value and how we think the job gets done.

And then the practical question. If designers get funneled toward engineering, designing with code directly, is that a good direction? What do we lose or gain?

Part of why this discussion gets messy is that design means different things to different people. Your view on it depends on what kind of design you do, and how you understand design as a practice.

I believe design comes in many flavors. It’s influenced by the person, the domain, the market, the customers. In consumer products, you might need to test ideas quickly because motivations are hard to predict. In B2B or enterprise, you often have more context and can design from that. Some industries require extreme reliability and clarity. The environment matters too. Stakeholders, clients, company culture, and your skills as a designer. If you’re more visual, you lead with visuals. If you’re strong in code, you might use it earlier.

And for some, design simply is getting the button on the screen and moving on.

So there’s a broad domain of software design, with different tools and methods inside it. The code vs no-code argument often misses the point and becomes a polarizing force.

What I’m trying to say is that I want to elevate this discussion above tools, and make sure tools don’t take over the future of design. I don’t want us to needlessly devalue conceptual and divergent thinking just because new tools make execution easier.

Even engineers who work with code all day step away from it. They draw architectures, plan systems, and reason about tradeoffs. While code is where software lives, it’s not always where all decisions should be made.

To explain what I mean, I have to start with how I understand design and how I’ve practiced it.

Designing the problem

First of all, I’m not a formally trained designer. It’s been self-taught through hundreds of design projects over the last two decades. So I’m not advocating gatekeeping, or any one “right” way to design. But I do think design is rarely linear. You work at different levels of abstraction, move between them. And while the outcome is the goal, spending time on the journey can make the outcome better.

Through that work, I learned to question the problem first, not treat it as an assumption. If asked to work on something, I start with: is this a real problem? What if we don’t do this? Who defined the problem?

It sounds philosophical, but what I’ve found is that the most common reason design projects drag or fail is that the problem wasn’t clear. People won’t agree on solutions, because they have different problems in mind. The solution becomes a compromise of many different problems, instead of a clean solution to one major problem. This compounds when you have too many stakeholders.

To tackle this, I’d do two things. Write the problem the way I understood it, and ask who the stakeholders are. Then when presenting solutions to those stakeholders, I’d repeat the problem to see if it caused reactions. If it did, I’d stop and get the room to align on the problem. So what does this have to do with design? This sounds kind of corporate.

You’re always going to have stakeholders, if not colleagues, then customers. You have to understand whether feedback is true because the solution isn’t good, or because people don’t agree on what the problem is. Sometimes you’re designing against the wrong problem. The problem is the first part of the equation. It’s the foundation of what you’re trying to design and build.

At Linear, we knew quickly that companies needed projects. So what goes on the roadmap is “build projects.” Everyone agrees it’s needed. But if you think about it more, why do companies organize work into projects? Why not just work on the next task? What happens if they don’t have projects?

You can go deep on project management. There’s a whole discipline behind it, and many ways of doing it. But if your vision is to build a purpose-built tool for software companies, you start narrowing. What do they actually care about?

Simply put, projects are a natural abstraction for companies to manage streams of work. They help with accountability, ownership, cross-team collaboration, predictability, and visibility.

Now you might ask why research something so basic or well understood. Sometimes you don’t need to. But learning the landscape and history gives you orientation. You find assumptions you can challenge, or you decide which traditions to follow.

Most importantly, learning the problem first helps you decide what you want to do about it. What direction the product vision is pulling you toward. What you want to optimize and influence.

At Linear, we saw that projects might be the most important unit of work. Products are made of them, organizations orient around them, and you celebrate when one ships. That understanding gave us a direction for what problem we were trying to solve.

Designing the solution

I think of designing the solution in two stages: The conceptual stage and the execution stage. The conceptual stage is finding the overall form the design will take. While the execution stage is building it out and getting it onto the screen.

Take projects in an issue tracking tool, you could treat them as one large issue with sub-issues, a folder or label of issues, or its own entity connected to issues. Those are conceptual ideas you can consider without putting anything on the screen. The decision comes down to your understanding of users, the company, and the vision you want. All of these concepts can work, and you can find them in real products.

Because we saw projects as important, and different to issues, they needed to be their own entity, with their own shape. A project should have a recognizable form and functionality that communicates status, reasoning, user feedback, prioritization, timing, and connection to larger initiatives. Demoting projects to a label or a loose collection of issues didn’t feel right.

This conceptual stage might happen in words, on paper, in a design tool, or in code. It’s just about giving those ideas a shape, trying different directions and eventually choosing the direction that serves the problem and the product vision the best.

Once I have a direction I believe in, it’s ready for broader feedback. You test the concept by building it.

It’s the part closest to the final output. You make the design concept actually work, shaping it into something real. Code, or working with the material, is essential for this. And there are times when you gain new insights and have to go back and revisit the problem or concept.

There are different ways to use code in this stage. You can build tools, or “sketch” with throwaway code. This removes some of the constraints of production code and makes the process more exploratory. My point is that while you might see the execution stage as the real part of design, you’ve already built a foundation of context and confidence. When the material fights back, you’re pushing with that confidence.

Think of it in LLM terms. The design work you do before is the goal, context, and prompt you’re building for the agent to address the problem. The execution work is where you guide the agent through specific decisions.

After reading all this, you might think, who has time for this? We need to ship. Why not build right away and figure it out as we go? I don’t think it comes down to time. My explanation might have been long, but the process itself can be fast. You just spend the time needed.

My feeling is that without that context and goal built in, you might be iterating toward a direction, but not one that was chosen intentionally.

This brings me back to where I started. Our industry is not very patient, and once you start building designs directly to production as the default, the culture and organizational reasons to consider problems, concepts, and intentions start evaporating. We start devaluing the why behind our designs in favor of output.

My worry isn’t the code or the tools themselves. It’s a decline in consideration, and with that, a decline in unique, well-designed products. The question is how we keep that alive even as new tools and technologies emerge.

To me, design was never about what the button is or does, or which medium you work in. It was and is about finding the right problem, the right intent, the right vision. The feature you design and build today should be a considered step toward that vision.

Thank you Charlie Aufmann, Tuhin Kumar, Ramon Marc, Conor Muirhead, Gavin Nelson, Raphael Schaad, Jeff Smith, and Soleio for their comments and discussion on this topic.

One of our main goals in Customer Experience (CX) at Linear is to make the support process feel like an extension of the product itself.

That starts with meeting customers where they are—places like Intercom, Slack, Slack Community, X, or Reddit—and turning those conversations into part of our product development process. This creates a tight feedback loop between customers and our EPD teams, leading to a better product and moments of delight when users see their feedback realized in the app.

At a high level, this is our process:

Stage 1: CX routes customer feedback through designated waypoints (namely Intercom and Slack) into triage queues in Linear monitored by our engineering and product teams.

Stage 2: When an issue lands in triage, it triggers a notification to a Linear team member whose priority that week is to take on the work themselves or assign it to the right engineer (in the case of bugs) or attach it to the right candidate projects (in the case of feature requests).

Stage 3: The assigned engineer builds the solution and merges the PR.

Stage 4: Once the PR is merged, Linear’s GitHub integration marks the issue as Done in the Linear issue, which prompts CX to close the loop with the customer.

The key is building systems that collect and funnel information in a consistent way, and wiring them together so that handoffs between stages happen efficiently. Here’s more detail on how it all works.

Stage 1: Intake

We initiate the CX process in two main places: Intercom and Slack. There we begin the process of translating a customer’s words into a Linear issue.

Intercom

We use Intercom to collect all support tickets that come in via email or from within the Linear app. We use the Linear-Intercom integration to create Linear issues directly from inside Intercom.

(Linear also supports integrations with Zendesk, Salesforce Service Cloud, and Front. Plain and HelpScout have built their own Linear integrations.)

We have two templates in Intercom for turning customer feedback into Linear issues—one for bugs, another for feature requests. The templates automatically apply the right issue type and take a first pass at duplicate detection. They also route issues to the right team: bugs go into the engineering triage queue, feature requests go into the product triage queue.

Slack

Each week, as part of our CX on-call rotation, one team member is responsible for keeping an eye on feedback from external channels like social media, community spaces, and app store reviews.

Notifications from those sources flow into dedicated Slack channels such as #notifs-twitter and #notifs-reddit, which make it easier to catch relevant comments. The CX on-call person also keeps an eye on channels in our own Slack community, like #help and #product-feedback.

When they spot a comment that needs engineering or product attention, they use Linear Asks templates to turn the message directly into an issue.

Just as in Intercom, we maintain two Asks templates—one for bugs, one for feature requests. We keep the required fields to a minimum so CX can file issues quickly while still including enough detail for engineering and product teams to act on. These issues automatically include the customer’s exact words and a link back to the original conversation, which makes it easy to close the loop once the issue is resolved.

Stage 2: Triage

Triage—the dedicated “inboxes” monitored by our engineering and product teams—is where we decide who should take the work and how it should be categorized. Triage Intelligence helps a lot here. Above and beyond the automation built into our intake templates, it:

• Detects duplicates (particularly useful for aggregating feature requests)
• Applies labels (such as the area of the product the issue is about)
• Suggests the right team or assignee

After that automated pass, the person overseeing triage makes the final decision about where each issue should go (internally we refer to this person as the “goalie”). Engineers and product team members rotate through the role each week, as configured in our triage responsibility settings.

For bugs, the goalie either takes the issue themselves or assigns it to the right expert on the team. We address bugs according to clear SLAs consistent with our zero-bugs policy.

Feature requests follow a different flow. By utilizing Customer Requests, the user’s direct feedback, company information, and a record of the original discussion are all linked to a Linear issue or project. The product team goalie for the week reviews this feedback and adds notes or context that CX can share back with customers. (For more about how we aggregate feature requests into projects, see our blog “Continuous planning in Linear.”)

You can automate much of the process of sorting incoming work with triage rules which let you define actions that run the moment after Triage Intelligence completes its work. For example, you might route all urgent enterprise bugs directly to a specific team or assignee and automatically apply the right SLA.

Stage 3: Engineering

When an engineer takes on an issue, it becomes part of their active work. They make the changes, test the solution, and merge the pull request. At that point, our GitHub integration marks the associated Linear issue as “Done.”

Stage 4: Closing the loop

Once an issue is marked Done, it triggers an update back to wherever it originated. In Intercom, the linked conversation reopens with a note letting the CX team know the issue was resolved.

In Slack, the linked message is updated with the current status. From that point, we reach out to the customer directly to share the update and confirm the fix.

CX as UX

Treating customer experience as part of the Linear product experience means two things. First, at a tangible level, it means CX is connected directly to product and engineering. Second, it means we want the experience customers have when they reach out for help to feel as seamless as the experience they have using Linear itself.

To build a similar workflow in your own workspace:

• Integrate Linear with your support tools such as Intercom, Zendesk, Salesforce Service Cloud, and Front.
• Install the Slack and GitHub integrations to connect CX with product, design, and engineering workflows.
• Turn on Triage to organize new issues and route them automatically.
• Enable Triage Intelligence to automate labeling, deduplication, and assignment.
• Set up Triage Rules (Enterprise) to handle recurring actions automatically.

Or, if the Linear way of product building appeals to you, consider joining our team.

Product planning is a fresh start for your product team. It should feel energizing and full of possibility. After all, it’s a rare opportunity to step back from the churn of daily activity and recalibrate your efforts in the most meaningful directions.

But in practice, it often creates a kind of whiplash when you shift abruptly from deep execution to high-level strategizing. Gathered in a room, staring at a blank page, it’s natural to wonder: Now what do we do?

An obvious place to turn is all the customer notes you’ve collected over the past quarter. But typically those are scattered across different surfaces and recorded at wildly different levels of abstraction: some customer requests are extremely specific—a small feature tweak—while others are sweeping statements about product direction. It’s hard to assemble mismatched building blocks into a coherent plan.

Our answer to these pitfalls is a process called continuous planning. It’s how the product team at Linear plans, and it’s a workflow we’ve designed the Linear application to easily facilitate.

Instead of organizing through a disordered pile of customer notes every few months, continuous planners organize ideas into candidate projects as they arrive (and as of 2025, use AI to maintain them and keep them up to date). These projects form the center of gravity for both planning and execution. They are the most granular level an organization’s leadership can be expected to reason about, and they are the highest level concept that contributors are expected to think about on a day-to-day basis.

It’s an approach that alleviates the pressure of a blank page and the recency bias that can compromise planning. Under continuous planning, you’ve been accumulating and organizing ideas all along, so that by the time you actually sit down to map your team’s work for the next quarter, a well-vetted list of possibilities is already waiting for you.

Organize your backlog around candidate projects

Project ideas can originate from all sorts of places within your company and from customers. They can arrive via Slack, support tools, sales calls, hallway chats, or even public exchanges on social media.

Wherever the ideas originate, the key is to funnel them into a central location for processing in a structured, predictable way. At Linear, we send all feature requests to the triage queue of the product management team.

As a quick aside: It’s important to have separate workflows for feature requests and bugs. Bugs describe how your product doesn’t work as intended and are prioritized by severity. Feature requests describe how your product might work in the future, and are prioritized through your continuous planning process.

As ideas come in, patterns will start to emerge. They could be overlapping requests for specific features, or feedback around common problems users are facing.

Once a pattern takes shape, we’ll create a candidate project against it. The project serves as a gathering place for user interview notes, related feedback, and additional requirements that we discover as we continuously develop a more refined understanding of what we’d need to build.

AI increasingly assists with this work. In particular, we use our intelligent triage suggestions to reliably identify when a new idea or request is related to, duplicates, or just broadly belongs in the same project as existing issues.

In this way, little by little, piece by piece, discovery happens all across the org. The result is an emergent map of the product landscape, with candidate projects as its main landmarks.

Promote candidates into priorities

When entering into a planning cycle, a well-organized list of candidate projects might be all it takes to form a roadmap—just select the top few and go.

However, companies will also often have a structured goal-setting process to set strategy and ensure alignment. This could be a set of specific product themes or formalized systems like OKRs. Within the Linear app, those company goals are represented as initiatives, which can be nested into each other to closely model whichever system you employ.

When it’s time for the product team at Linear to plan, the first thing we do is order our candidate projects by the number of associated customer requests and their revenue impact. From there, we’ll pick and choose based on the highest impact candidates, our goals for the quarter, and any calculated bets we want to make.

We promote the projects that we want to take on by assigning them a priority:

• High (must do)
• Medium (should do)
• Low (nice to have)
• No priority (won’t do this quarter)

By starting from a prepopulated set of well-developed candidate projects, we’re never panicked to fill a blank page. This ensures that we’re not just examining the first things that come to mind or being overly affected by recency bias.

The output of the planning process is an extremely legible list of projects to undertake that have each been vetted, thoroughly considered, and prioritized.

Continue to use projects to track progress and manage work

Once you’ve decided which candidate projects to act on, the transition into execution is smooth. Projects seamlessly become the interface for executing on what’s been planned.

For leadership, projects are a clean handoff point to individual teams. They answer the question: What do I want the teams to be working on?

For individual teams and contributors, projects answer the inverse question: What should I focus my attention on? They create issues and sub-issues within the project to define their daily work.

Then, as the work proceeds, project updates from team leads keep planners and leaders closely in touch with how things are going.

The key to continuous planning is there’s never a need to translate between discovery, planning, and execution: projects are the universal vocabulary. You develop them organically as you triage ideas and requests; you prioritize them in your planning cycle; you use them to guide daily execution and management.

And then, when it’s time to plan again, you return to your evolving list of candidate projects and the wheels continue to turn. No sharp breaks. No staring at a blank page wondering what to build next.

Instead, just the steady, uninterrupted process of finding and realizing your best ideas.

That vision still shapes how Linear works. Today, our 99-person team spans more than 15 countries and 10 time zones. Because we are distributed, each year we bring our whole team together in one place. This year it was Copenhagen, where we spent a week working side by side, sharing ideas, and aligning on what’s next for us as a company.

We wanted to capture what working at Linear feels like, so we brought a film crew along with us. They joined us for team sessions and other activities, filming the moments that make Linear what it is. Along the way, they interviewed members of our team who talked about what being remote-first means for us, how we stay connected across time zones, and the ways we come together in person throughout the year.

We wrapped that footage into this video, which shares what it’s like to work at Linear, told through the people who build it every day.

How we work

We maximize for trust in our builders. Teams set their own rhythms, communicate directly, and keep meetings to a minimum. There are few distractions, and a shared respect for uninterrupted focus. Deep thinking time is treated as something worth protecting. We believe that quality compounds when work has time to develop.

At Linear that means:

• Small teams, clear ownership. Two to four people is typical. Teams assemble around a project and disband when done. Project leads rotate. Often engineers or designers lead.
• One product team, one roadmap. We do not use OKRs or run A/B tests. We align on a north star and make decisions with judgment, customer insight, and taste.
• Short specs, fast feedback. Specs focus on context and intent. We ship behind feature flags to internal users first, then invite select customers through Origins when it helps. Weekly written updates auto-post to Slack so everyone can follow progress without a meeting.
• Protect quality. We keep a zero-bugs policy with SLAs. Bugs get fixed now, not later. We review a weekly bug dashboard to rebalance load and spot patterns.
• Practice the craft. Quality Wednesdays train the team to see what is off. More than 1,000 small fixes over two years have raised the bar and changed how we build in the first place. Feature roasts help us ship with better judgment.
• Use constraints. Constraints create clarity. We ask why a feature matters, why now, and for whom. We keep the bar high by saying no.
• Stay close to customers. We build what customers need, not just what they ask for. Customer Requests pulls signals from support and Slack into Linear so product and engineering can see patterns next to the work.
• Plan for unplanned work. Triage and a “goalie” rotation handle inbound so projects keep momentum. SLAs make expectations explicit.

This rhythm allows people to plan their days around their lives. What matters is doing great work and getting things done.

Profitability and ownership

Profitability is freedom. It lets you control your destiny and keep standards high. We’ve hired slowly, stayed focused, and built a business that funds itself. Having bigger teams does not guarantee better work. Usually it means the opposite. We hire the next person who raises the bar.

We want people to be able to choose Linear for the long term. Alongside our Series C, we ran a tender offer so current and former teammates could sell a portion of vested options at the same $1.25B price as investors. Our equity program includes a 10-year exercise window, early exercise in the US, refreshers over time, and Linear Infinity, which provides paths to liquidity along with recharge sabbaticals so people choose to keep working here.

Connection

We make space for connection too. We meet monthly for a one-hour all-hands to share metrics, demo upcoming releases, and reflect on what’s working and what we can do better. Once or twice a year, the team runs Hack Week to step away from regular work and build for the fun of it. Smaller rituals, like the Great Linear Bake-Off or regular coffee chats, bring people together outside of project work and help maintain a sense of closeness across distance.

Once a year, we bring the entire company together for an offsite as we did in Copenhagen in 2025. Past offsites have been in Mexico City, Helsinki, and Lisbon.

We use these offsites to prioritize building a shared understanding of how we’ve grown, what we’ve learned, and what we’ll do to preserve the essential elements of Linear’s culture as we scale. But we also keep the agenda intentionally light to make room for unstructured time together, coworking, or discussions while exploring the city around us.

At other times during the year teams meet in smaller groups for planning sessions, project kickoffs, or to welcome new teammates. Most teams plan at least one meetup a year, usually in the opposite season from the company offsite, and anyone on the team can suggest or host one.

Coworking hubs

While we’re a remote-first culture, in 2025 we introduced coworking hubs in Berlin, New York, and San Francisco. These are places for anyone who wants to work alongside teammates in person. There’s no expectation to show up, but many people build it into their week in a way that works for them.

In San Francisco, for example, someone usually starts a Slack thread at the beginning of the week to see who’s around. People share their plans, line up a few overlapping days, and end up working together, grabbing coffee, or going for lunch.

Why it matters

We’ve built Linear with a deliberate balance of work styles that achieves the best of both worlds: the freedom to do your best work anywhere and the shared rhythm that keeps us aligned and cohesive as one team.

Our remote-first approach is part of how we live our mission to inspire and accelerate builders. By giving people autonomy, focus, and clarity of purpose, we create the conditions for world-class builders to do their most meaningful work. The systems, rituals, and offsites all exist to support that creative momentum and preserve the craftsmanship that defines Linear.

If this sounds like a place you’d want to help build, we’re hiring.

Project management software is a good example. It establishes channels for a well-defined set of human actions: users create and triage issues, merge duplicate bug reports, and write updates as projects advance. The software provides all sorts of supports, reminders, and guardrails, but human users still do the work.

Enter the Chatbot Era

The first instinct that many incumbents have had with AI has been to layer a helper chatbot on top of existing systems. You can prompt the chatbot to draft a document, tell it to create a research report, ask it to group or categorize items, or otherwise enlist it to operate your app.

These chatbot workflows can look magical in a demo, but they’re really just the old ways of working dressed in a new interface. Human users are engaged in all the same tasks they’ve always been. They’re still nudging the system along every step of the way, only now using prompts instead of button presses.

Self-driving software

Real change comes when AI stops requiring constant input and instead proactively moves work forward. Rather than constantly requiring user attention and input, the systems of the future will be self-driving.

In our project management example:

• Customer requests are automatically extracted from inbound support tickets, customer research, and sales calls. Any communication the organization has with its current or potential customer base is used as context by the system for generating new issues and requirements.
• Newly created issues are analyzed, researched, and automatically assigned to the correct team, project, and person. The system uses the past completion history, existing backlog, and future roadmap as context to understand what to do.
• Simple changes are dispatched to a coding agent and completed without additional intervention. More complex requirements are automatically collated into project specifications and as new requirements roll in, the system keeps documentation up to date with the latest information.

In this new world you, the user, are still in control—you decide which projects to pursue and where to allocate your resources—but the system moves everything forward on its own.

Our vision for Linear

In case it wasn’t obvious, this is our vision for Linear: a system of planning and building that operates autonomously on your behalf.

We’ve already started to build and release features to make this a reality. Like with self-driving cars, they can be adopted and operated at different levels of autonomy.

At the most basic level, the system suggests actions the way a lane-departure warning beeps when you drift. In Linear that looks like recommendations for which teams to assign an issue to or which labels to apply. You can use these assistive hints or not.

At moderate autonomy, the system takes the first pass and you correct what doesn’t fit, similar to the lightly interactive way drivers use adaptive cruise control. The car does most of the driving, but you can still nudge the steering wheel or tap the brake. In Linear, you can set up rules that direct the system to auto-apply suggestions selectively, under the conditions of your choosing. We also clearly identify these AI actions after they’ve been taken, so you can easily reverse or modify them.

At full autonomy, you can take your hands off the controls entirely and the system drives the work from start to finish. You merely step out of the car at the end of the trip and confirm you arrived at the right destination. In Linear, this means identifying classes of issues that can be completely handled by coding agents and guiding the system to automatically dispatch them. Human users only become involved when evaluating the final result.

To get there, capabilities and culture both need to progress. The adoption path there isn’t just flipping on a switch. It’s learning how to adjust your workflows to take advantage of the system’s ever-improving abilities.

Transforming the nature of work

Whenever a new technology arrives, our first instincts are usually naive. There’s a tendency to graft the new thing onto what already exists, often awkwardly.

But we know the real leap comes when people adjust their mental models and start to imagine what the technology makes possible on its own terms.

We can already anticipate that the self-driving cars of the future won’t just be sedans where no one’s sitting in the driver’s seat. They’ll be living rooms or offices on wheels that free your time and attention to focus on what you value.

How will the job of building software look when your attention doesn’t need to be spent on routing issues, merging duplicates, writing status updates, debriefing call notes, maintaining documentation, or fixing minor issues? You’ll be entirely focused and present when engaging with your users, discovering their problems, and imagining what’s possible.

Read more here about how we’re building AI workflows for modern product teams.

Earlier this year, we were ready to redesign our mobile app. The original version had served us well, but it was built with a narrow use case foremost in mind: individual contributors engaging with issues.

A year later, Linear is the product development platform of choice for larger, more complex organizations, and the app wasn’t serving everyone equally well. In particular, executives and managers want an overview of what’s happening across their teams and the existing structure, optimized for a single workflow, couldn’t easily support that.

We knew we needed a more customizable foundation that would allow us to make the navigation more flexible, adaptable, and expandable depending on a user’s role.

Then in June, something fortuitous happened: Apple announced Liquid Glass at WWDC. We watched the keynote and right away it was clear Apple had landed on a design language that felt modern and expressive. It also matched the aesthetic shift we were already imagining.

But as we explored it more closely, we realized adopting Apple’s new APIs wouldn’t give us the control we needed to build the customizable navigation that was the real purpose for our redesign. Instead, we decided to recreate our own version of Liquid Glass. We wanted to capture what we loved about it while retaining the flexibility to design a navigation experience that fits the way people use Linear.

It was without question the harder path.

We have a small iOS team—just two engineers—and fully adopting Apple’s APIs would have been much simpler. But rebuilding it ourselves would allow us to bring our new navigation to all of our users, including those on iOS 18, while freeing us from the compromises and uncertainty that come with depending on someone else’s design system. We knew that Liquid Glass had remained a moving target throughout the beta period of iOS 26, and Apple is still making changes to it today (like the recently introduced Tinted Glass option).

It was a go-big-or-go-home moment, which made the choice easy. We weren’t deciding against Liquid Glass, and our goal wasn’t simply to rebuild it as it was. We wanted to push the design to a new level that felt true to the Linear brand and better suited the way our users work.

Aqua versus ProKit

We knew that building our own design system might seem like an unusual choice. But it also followed a tradition that runs through Apple’s own design history.

Nearly two decades ago, the company drew a similar line between consumer and professional software, with Aqua on one side and ProKit on the other.

Aqua defined the look of consumer Mac software for nearly a decade. Similar to Liquid Glass, it was exuberant, with pinstripes, bright highlights, glassy buttons, and drop shadows everywhere. The goal was to make the interface feel tactile and approachable.

What fewer people remember is that during that time Apple also used another design language called ProKit. It traded away Aqua’s reflections and translucency for flatter gradients and sharper edges. ProKit was built for professional tools like Final Cut or Logic with complex, information-dense workflows where clarity and control are more important than visual flourish.

Liquid Glass is a beautiful successor to Aqua. Its primary purpose is to feel fluid and friendly for a broad consumer audience. Apple has to design for every kind of app—education, entertainment, banking, fitness—and build systems that adapt to all of them.

We have a different set of constraints. Our users come to Linear to do a specific kind of work in a focused environment. That gives us freedom to push the design in specific ways Apple can’t.

In that sense, we saw an opportunity to take Liquid Glass’s aesthetic qualities—its translucency, depth, and physicality—and apply them with a ProKit philosophy: purpose-built, disciplined, and designed for sustained focus.

Owning our materials

To rebuild the glass effect from first principles, we started with a single SwiftUI view modifier that applies multiple effects at once. Behind the content, a Gaussian blur sets the base layer using a UIVisualEffectView. Above it, we layer a subtle gradient for structure, then a specular highlight calculated in a SwiftUI shader.

Making the highlight behave convincingly required describing the shape mathematically. We generate a signed distance field (SDF)—a way of representing a shape mathematically—for the continuous rounded rectangle surrounding the content. Then we use its gradient to build a normal map, and from that determine how much light each point catches.

Because we can’t apply the shader directly to the UIVisualEffectView, we layer it on top using a Plus Lighter blend mode. Finally, we mask the whole thing with the same SDF and add a subtle shadow for added contrast.

After we’d defined the surface, we focused on how the light itself should behave. Instead of faking highlights with static gradients, we modeled a physical light source that moves through space as you interact with the app. Because the lighting is calculated in real time on the GPU, the surfaces respond naturally to movement—soft highlights shift as you scroll, tap, or move through the app.

Implementing a customizable tab bar

Once we had control over the material, we could extend it to the part of the interface that mattered most for this redesign: the tab bar. Apple’s stock tab bar in iOS 26 looks similar on the surface to the one we ended up with, but you can’t meaningfully change its shape or behavior. We wanted a bar that could expand to fit different navigation patterns, so we built it ourselves. Owning the material made that possible.

This also gives us the flexibility to customize the bar in the future. Five items is a sensible limit for apps for a general audience, but Linear users often need more. Our tab bar can expand to accommodate additional entries, similar to how the tab bar can turn into a sidebar on iPad.

Sweating the details

Once the core system was in place, we focused on the tactile and visual details that make the interface modern.

When you touch an element, it lifts up slightly, providing a quick pulse of feedback. Dragging beyond the edge of the view distorts it slightly, resolving the physical tension and making the UI feel responsive.

We also replicated some of the smaller effects Liquid Glass uses, to make our custom material feel at home on iOS. At the top and bottom edges of scroll views, we apply a variable blur that intensifies as content approaches the edge of the screen. This is a detail Apple relies on internally but doesn’t expose through public APIs, so we had to get creative. We layered a subtle color mask over it to match the soft edge Apple uses systemwide.

We spent a lot of time on accessibility details. Apple’s system glass automatically adapts to settings like Increase Contrast mode. When a user enables that setting, iOS draws solid outlines around glass elements. Our material now mirrors that behavior exactly, preserving legibility for users with accessibility settings turned on.

The one effect we chose not to reproduce was Liquid Glass’s refraction. Technically, it requires access to pixel-level data that isn’t available to third-party developers. Aesthetically, it also wasn’t the right choice because refraction can make dense professional interfaces harder to read. By relying on precise blurs, masking, and lighting, we maintained a sense of depth without losing clarity.

None of these details were individually complex to implement. But like so much of what we do when building Linear, it’s the sum total that creates an enjoyable and productive user experience.

Customization for a growing user base

This new visual language is just the start of a broader architectural redesign of our mobile app. As Linear’s user base grows, people in different roles are using the app in more varied ways. This new foundation, which we built and own ourselves, lays the groundwork for more adaptable navigation and customizable toolbars in the future.

We’ll have more to share about that soon. In the meantime, read more about the redesign in our changelog or download the update in the App Store and Play Store.

Dashboards let you combine data from different Linear sources into a single view, whether that’s monitoring operational health, keeping tabs on team workflows, or reporting on how resources are being spent across initiatives.

Teams have created thousands of dashboards since we launched them in July, with especially strong uptake among enterprise customers: more than half of enterprise workspaces now use at least one.

Dashboards are modular and customizable, with insights shown as charts, tables, or single-number metrics, and they are flexible enough to support both short-term operational needs and longer-term strategic planning. Three months after launch, we’ve found that one-third of viewers check dashboards weekly, while two-thirds return monthly.

In that time, we’ve also noticed clear patterns in what makes some dashboards more useful than others. Here are some of the practices that stand out, illustrated with real dashboards from our own use.

Practice 1: Fewer dashboards is generally better

We’ve observed that the median workspace creates just two dashboards, and adoption drops off quickly beyond that. When every team spins up dozens, most go stale and stop being trusted. The solution is to make each dashboard intentional, with a clear purpose and an owner. Build regular review cycles into your process so dashboards stay accurate and relevant.

This chart looks at workspaces bucketed by size, showing the average number of dashboards created versus those actively used. As companies get larger, the number of dashboards grows fast, but usage doesn’t keep pace and many dashboards go stale. Be realistic about how often a dashboard will actually be used, and keep the set as tight as possible.

Practice 2: Match the design to the dashboard’s purpose

Dashboards built without a specific purpose tend to collect random charts and quickly lose their value. The best dashboards are built for a clear use case with a design that reflects that purpose. Strategy dashboards work best when they focus on a handful of long-term trends that rarely change but help with alignment. Operations dashboards, by contrast, should surface a wider range of metrics, highlight unexpected changes and help teams react quickly. Decide which type you’re building before you start.

This dashboard is my personal tool for keeping data requests up to date so the underlying data stays clean. Each status has a burn-up chart so I can quickly tell if the current number looks normal. The bottom panels flag issues that need attention—items that are stale or waiting for review. I check this dashboard at least weekly, often more, to make sure my backlog is in good shape. It’s deliberately short, focused, and glanceable.

Practice 3: Design for the right audience

The right level of detail for a manager, an IC, or an executive will look very different. We’ve found that dashboards are most effective when their detail and update frequency are tuned to the audience. If a dashboard is reviewed only occasionally, it should include more guidance and annotations so it’s easy to reorient after time away. If it’s checked daily or weekly, it should be denser, more glanceable, and optimized for speed.

This dashboard is built for weekly internal team meetings. The metrics are broken down by individual, the charts align with recurring meeting topics, and the design avoids extra annotation. It wouldn’t work for execs or cross-functional stakeholders, but for this audience, it’s the right level of granularity to inform discussions.

Practice 4: Provide context, not just numbers

One of the most effective dashboards I’ve seen pairs every key metric—revenue, conversions, refunds—with a simple chart showing this week, last week, and trailing highs and lows. Anyone, even without additional context, could instantly see if something was good, bad, or in line with expectations. Using consistent, minimal visuals reduces cognitive load and makes the dashboard work with the company’s operating rhythm.

This dashboard tracks inbound requests from different teams. Each column represents an org (Sales, GTM, Data, Product), and each row shows burn-up, new issues, and completed issues. Laying them out this way makes it easy to compare volumes across teams and spot trends over time. It also helps with capacity planning, both for myself and in conversations with other leaders at Linear. Having the context side by side means I can see at a glance which teams are driving the most requests and whether their pace is changing.

Dashboards are available to workspaces on our Enterprise plans. See the docs to learn more.

When we tell people that Linear maintains a zero-bug policy a common response is disbelief. It may sound like a ridiculous approach, but we do it because no other way makes sense.

The zero-bug stance means that we address bugs immediately, with the exact number of days depending on the severity: low-priority bugs need to be addressed within 7 days, high-priority bugs within 2. We formalized this approach two years ago. The impetus was actually a bug in a popular consumer app that I had reported to their team. Finally two years ago—and five years after I first reported the bug—I saw that it got fixed. I thought to myself, “wow, millions of users suffered through this bug for years for no reason.” If the company was going to fix the bug eventually, it would have been so much better to fix it right away.

That’s the big idea behind our zero-bug policy. We want Linear to be a solid, high-quality product, which means we’re going to address any bug that comes in. Fixing a bug takes the same amount of work whether we do it right away or put it off. But it’s not a zero-sum game: fixing it immediately gives us a higher-quality product and spares users unnecessary pain for the same overall effort.

Plus the approach allows us to deliver a kind of magical experience for customers who report bugs and the next day (or sooner) find it’s fixed. For example, this user last October who reported a problem with paragraph breaks in the Linear editor that we fixed the same day:

Zero-bugs starts by clearing the backlog

Once we agreed that a zero-bug policy was the only right way to go, the first step was to clean out the backlog. We had about 175 open bugs at that point and set aside three weeks to fix them all. For that period we paused all other projects. No one did anything but fix bugs. By the end we had given ourselves a clean slate.

Next we had to put in place practices to maintain it.

We already had rotating triage duties. Each week it would be someone’s job to assign incoming bugs to the right team members. Now with our new zero-bug policy we gave everyone a choice: When a bug is assigned to you, you can either mark it as “won’t fix” if it’s too marginal to address, or you can commit to fixing it. Importantly, we eliminated the option of sending bugs to the backlog.

(Related to this, I’ve heard stories of companies whose backlogs grow to thousands of bugs. Eventually, instead of fixing the bugs, they just delete the whole thing and start over. It’s a reflection of how when you put bugs in a backlog, in most cases what you’re really saying is you’re never going to get to them.)

We also set SLAs to focus our work: 48 hours for high-priority bugs and 7 days for the rest. Those were the official guidelines. In practice, it soon became the team norm that the first thing you do in the morning is open your inbox and see if you have been assigned a bug. If you have, you spend a few hours fixing it right away. By taking bugs on immediately, we make sure we stay within our SLAs. We also avoid the drag of context switching all the time. Bugs first, the rest of your work after that.

The zero-bug dashboard

Each week we review a dashboard of open bugs. If one person has too many, we reassign some so the load is even. Those reviews show us more than just who’s carrying what. Often they highlight patterns in the product and make it obvious when a team doesn’t have enough capacity. It’s one thing to know that in the abstract, but seeing bugs accumulate in particular areas of the product really drives it home and helps us allocate resources.

The same idea holds for conversations with individual team members. When an engineer’s bug count creeps above four or five, we notice it when reviewing the dashboard, and provide them with the resources they need to bring it down. The solution might be to reassign a few bugs, or to have the engineer step away from project work for a couple of days and focus on clearing their queue.

Zero-bugs is not just a practice, it’s a value

The zero-bug policy has a few major effects at Linear. One is obvious: We end up fixing a lot of bugs. Last year we fixed more than 2,000. In the last three months we’ve addressed more than 700.

Another effect is less obvious but just as important: The zero-bugs policy changes our relationship with our customers.

It’s not uncommon for Customer Support to file a bug in the morning—often through our Intercom integration—and have it fixed by lunch. That kind of turnaround allows us to turn a bad experience—an encounter with a bug—into an excellent one that changes their whole perspective on what it’s like to reach out to a company when something is broken.

Over time these experiences have molded the way our user base reacts to imperfections in the product. Instead of coming to us angry or frustrated, we find many users write to us in a spirit of collaboration—working hand in hand with us to make Linear a better product because they trust we’ll respond quickly. It also often turns them into Linear advocates:

Then there’s how the zero-bugs policy shapes the culture of our engineering team. One way is that it preempts bugs: because the team understands they’re going to have to fix all these bugs eventually, they work harder to avoid introducing them in the first place.

It’s also a way of establishing our values as an engineering team and sets the tone right away during the hiring process. Engineers who join Linear know we care deeply about quality and that part of their job will always be fixing bugs. It’s a clear signal that helps us attract the right people.

There’s no doubt that the zero-bugs policy requires us to reprioritize our effort. Our team shipped a lot of new features this summer and keeping up with bugs alongside that was a lot of work. But when we recently discussed, purely as a thought experiment, whether anyone would want to discontinue the practice, the answer was unanimous: Nobody could imagine going back, because to do so would mean accepting a lower-quality product.

And for us, that’s simply not an option.

If building in a zero-bugs environment appeals to you, check out our open roles.

As teams grow, the surface area of their work expands. This makes it harder for leaders at every level of an organization to plan on both short- and long-term timescales. It’s easy to lose track of what’s happening day to day, and just as easy to miss slow-growing trends until they’ve already caused problems.

We built Dashboards in Linear to help with that. They let you bring together multiple insights in a single place so you can see where things stand and step in early when something’s off. Dashboards are fully customizable, allowing you to filter by team, dig into specific issues, and take actions directly from the page.

Commure, a healthcare technology company that supports over 400,000 clinicians, uses Dashboards to guide both short-term action and longer-term planning. They check some dashboards daily to stay on top of triage, SLA performance, and postmortem follow-through. Others they refer to at longer intervals to understand how engineering time is being spent and whether it matches the company’s priorities. One of the biggest impacts for Commure has been tracking whether different workstreams are moving in the right direction. Burnup charts, for example, give their teams a way to see if issue volume is increasing or decreasing over time.

The dashboards below are real examples from their workspace, shared by Myles Baumann, a senior product manager at Commure.

1. High-Priority Issues Over Time

Intended user: Everyone

Purpose: Track how the backlog is doing and how it’s spread across teams

Scope: One product, many teams

Usage: This shows how the backlog has changed over time and how it’s distributed across teams. Not all teams get the same number of high-priority issues, so this helps Commure see who’s carrying more load and how that’s shifting. It’s useful for just keeping an eye on whether things are trending in the right direction.

2. Feature SLA Tracking

Intended user: Everyone

Purpose: Track SLA performance based on severity

Scope: One product, many teams

Usage: We have SLAs depending on how critical a feature is—P0, P1, or P2—and this dashboard helps Commure see how we’re doing. It shows how often we’re hitting or missing those SLAs, what our lead times are by severity, and how that breaks down by team.

3. Project Estimate Burndown and Investment View

Intended user: Product Manager, Engineering Manager

Purpose: Understand where engineering time is going and whether project scoping matches reality

Scope: One product, several teams

Usage: The top chart shows cumulative effort across all active projects. It helps teams explain delivery timelines and surface cases where a project is taking more time than expected. The bottom chart splits out time spent outside of projects on feature requests, operational work, and more. It’s used to spot how much unplanned work is drawing attention away from roadmap commitments.

4. Insights Dashboard: Cycle Time by Assignee

Intended user: Product Manager, Engineering Manager, Team Lead

Purpose: Provide context for performance-related questions

Scope: Product-wide. Multiple engineering teams

Usage: This dashboard visualizes cycle time by assignee, giving managers a way to spot patterns in how long individuals take to complete issues. It’s not used as a performance metric on its own, but it’s helpful in two ways: as a starting point to ask questions—like whether someone is getting poorly scoped tickets or not surfacing blockers—and as a way to validate anecdotal concerns. When it feels like someone isn’t keeping up, unusually long cycle times can help reinforce the case for follow-up.

5. Engineering Hygiene Review

Intended user: Product Manager, Engineering Manager, Team Lead

Purpose: Support regular board cleanup and planning

Scope: Engineering team

Usage: This dashboard is used to prepare for weekly or bi-weekly reviews. It shows high-priority issues that need to be addressed in an upcoming cycle, outstanding bugs, tickets missing estimates, and tickets that haven’t been assigned. Other views highlight metadata gaps—such as missing feature labels, ticket types, or notability flags—so that teams can keep pace with labeling standards. The goal is to make sure nothing slips through the cracks and that every issue is accounted for in the current or upcoming cycle.

Dashboards are available to workspaces on our Enterprise plans. See the docs to learn more.

To provide genuinely helpful signals for product decisions, a backlog needs to be well-organized, with similar issues grouped together and labels applied consistently. But organizing a backlog has historically been manual work that doesn’t scale. It tends to depend on the institutional knowledge of a few people who aggregate and classify incoming issues.

Last month we launched Triage Intelligence to help product teams handle incoming issues and put them in the right place in the backlog. It uses a combination of search, ranking, and LLM-based reasoning to make suggestions as new issues come in—drawing on your existing backlog as a data set to understand how similar work has been organized in the past. It can flag duplicates, link related issues, and recommend properties like labels or assignees, all with a brief explanation so teams can triage quickly and consistently.

We built Triage Intelligence around a few core principles. First, trust—if you are going to act on AI-generated suggestions, you need to see where they came from and believe in their accuracy. Second, transparency—making the model’s reasoning visible so that teams can validate its output and improve it over time. And third, making the feature feel like a natural extension of Linear, not an add-on. Here’s how we did it.

Better search + bigger models

The process started earlier this year when we were rebuilding our search engine. We were moving from a basic keyword-based system to a more general-purpose semantic backend. At the time, we were already surfacing similar issues using vector search and semantic similarity. As we rebuilt our search infrastructure, we wanted to unify on a single search approach across Linear while also improving how we detect and surface related issues.

The new search system surfaced better candidate issues from the backlog to match against incoming issues. That candidate set became the input to our LLMs, which would evaluate each incoming issue and decide whether it was a duplicate, loosely related, or unrelated.

Our first version used small models like GPT-4o mini and Gemini 2.0 Flash. We gave them tightly scoped prompts and rigid workflows to flag duplicates, and they did fine in straightforward cases. But they faltered when context-sensitive, nuanced decision-making was required because they could only work with the information we provided up front. If something important was missing, they had no way to go find it.

That limitation led us to an agentic approach, where the model could pull in whatever additional context it needed from Linear’s data. To make that work, we switched to larger models like GPT-5 and Gemini 2.5 Pro, which could handle more complexity in both inputs and reasoning. That shift unlocked better suggestion quality—especially for fuzzier or more complex issues—and made it possible to support custom, user-defined guidance to steer the data sourcing and decision-making process for each workspace.

Beyond detecting duplicates, Triage Intelligence could now reliably suggest related issues, recommend properties like labels or assignees, and explain their reasoning. But these new capabilities brought a new challenge: how to present this richer, more deliberate decision-making in a way that still felt fast and trustworthy.

That became a design question as much as a modeling one and led to the UI patterns we built for Triage Intelligence.

Design for reasoning models

Speed has always been a core principle in Linear. If something takes more than a few hundred milliseconds, we try to make it faster. Smaller models can get close to that bar, but the larger, frontier models behind Triage Intelligence run multi-step reasoning and matching processes that are fast compared to a human, but slower than Linear’s usual deterministic systems. Designing for that meant balancing two goals: making the feature feel responsive, even when it’s still working, and making its reasoning visible so people can trust the results.

In the triage view, Triage Intelligence lives inside its own dedicated module. We wanted it to be visible enough to be useful, without adding extra noise to an already dense screen. The suggestions it makes—assignee, labels, projects, related issue links—use the same visual language as the rest of Linear, so they blend naturally into the workflow. And we’re careful not to blur the line between issue metadata set by humans or rules and suggestions from Triage Intelligence. The UI makes that distinction clear, so you always know what came from the system and what came from your team.

From there, each piece of the UI reinforces trust and transparency. Hovering over a suggestion reveals the model’s reasoning in plain language along with alternative suggestions when applicable. At the bottom of the module we display the model’s “thinking state” along with a timer. Our goal was to give you a sense of progress and to let you keep tabs on its activity, so Triage Intelligence feels active rather than idle throughout the reasoning process.

Then, for deeper visibility, we incorporated a thinking panel—using the same approach we employ with Linear for Agents—that lets you see the full trace of the model’s research: the context it pulled in, the decisions it made, and how additional guidance shaped the outcome.

In addition, you can use the Additional Guidance setting to fine-tune Triage Intelligence at the workspace or team level with natural language prompts. It’s a quick way to steer suggestions toward your priorities, which is especially valuable for larger teams with multiple products or brands, where the ecosystem—and the triaging process—is more complex.

Each of these design choices ties back to the principles we started with: building trust, keeping the reasoning transparent, and making Triage Intelligence feel like it’s always been part of Linear. (These are also general principles we codified in our recently released Agent Interaction Guidelines.)

The future of Triage Intelligence

From here we intend to move in the direction of more automation and decisions based on richer context. Triage Intelligence will improve as it draws on a deeper understanding of your workspace and as we adopt newer models and techniques. With that expanded context, it will be able to deliver more accurate suggestions and handle a wider range of scenarios. We’re adding new capabilities outside of just triage support, including using LLMs to draft project and initiative updates.

Automation will come gradually and with control. If you trust certain types of suggestions, you’ll be able to opt in to having them applied automatically—whether that’s assigning an issue, adding a label, or routing work to the right team—while still keeping full visibility into what’s happening.

Every step in that direction makes your backlog more valuable. Each time Triage Intelligence takes an action, it’s quietly improving your team’s shared memory—making it more complete, accurate, and actionable.

Triage Intelligence is available on our Business and Enterprise plans as a technology preview. To learn more read the docs.

From the beginning, we’ve tried to design Linear’s equity program to be as employee-friendly as possible. That comes from my firsthand experience at previous startups, where I had to exercise options within 90 days and then hold shares indefinitely with almost no flexibility. Often there was little transparency around early exercise, and in some cases the option wasn’t even offered.

At Linear, we wanted to do better. Since the early days, we’ve offered a 10-year extended exercise window, early exercise in the US, and as much transparency as possible on the performance of the business, starting from when we present a job offer. This tender offer builds on that approach. By creating a path to liquidity, we’ve given our people the option to realize some of the value of their ownership today, while still holding the majority for the future.

We’ve tried to think more broadly about what helps people stay at companies they care about. Too often, people leave not because they lose motivation but because their needs change. They may need cash for a life event, time away to reset, or a chance to refresh their equity to continue having skin in the game.

At Linear, we call our approach to addressing these realities Linear Infinity. The idea is to make it easy for people to keep choosing Linear, as long as the work remains fulfilling. Infinity includes paths to liquidity, such as this tender offer. It also gives teammates the ability to take real time away: a fully paid month off after four years, and an additional paid month every two years after that, with options for longer breaks through flexible unpaid leave. This allows people to recharge without having to step away from the company. We also offer equity refreshers, so ownership continues to grow without forcing a job change every few years.

We have built Linear differently than most startups. We have grown profitably, sustainably, and predictably, while keeping the team small and focused. Our hope is that people choose to stay and contribute far beyond the typical two- or four-year tenure, and Infinity is designed to make that possible.

I’m proud we were able to do this at such an exciting moment in Linear’s journey. But more than anything, I feel grateful. None of this would exist without the people who chose to put their time, talent, and care into building Linear. Whether you’re part of the team today or part of our alumni community, thank you.

If you’re excited about building the future of software with us, we’re hiring. Check out our careers page.

Over the last few years, powerful new tools have emerged for software development. They’ve delivered big gains on their own, and one of the most important productivity levers now is making them work closely together.

That’s why today we’re announcing a new Cursor integration for Linear, letting you assign issues directly to Cursor agents the same way you already assign issues to teammates. Many teams already use both Linear and Cursor, and this integration ties them together at the point of maximum leverage: inside Linear, where teams already manage their work and where the full context lives to spin up and manage high-quality agents.

Today, Cursor agents can take on coding tasks, open pull requests, and update progress back in Linear. The benefits of this tight integration will only grow as agents continue to improve, teams get used to writing issues with the context needs of agents in mind, and it becomes possible to have agents work with increasing automation—drafting PRs before you even open the issue, or tackling multiple issues at once in the background.

To share more about the integration—what it took to build and where it’s going next—Kevin Hartnett from Linear spoke with Rohan Varma, the product manager from Cursor who led the project. We talked about the workflows this supports, the technical decisions behind the integration, how Rohan sees agents evolving inside Linear, and advice he has for other teams building agent integrations with Linear.

This interview has been edited for clarity.

For people who haven’t seen it yet, what does the Cursor–Linear integration do?

Rohan: Basically, you can assign work to Cursor, you can mention Cursor, and you can also follow up in the same session to Cursor. We’ll show you the thoughts and tools, to-dos, as it progresses.

For a lot of users, working with coding agents is still new. The reliability of these coding agents is improving a ton week over week, but it’s not perfect. So the assumption here is: how does a new user understand and use these agents? How do they build trust in them?

How does this kind of workflow build that trust?

Rohan: We think it’s important that you can go to Cursor, open it up with the code, see what the agent’s done, and clean it up yourself if you want, or give the agent feedback on its approach. A lot of that is best done in an IDE where you can explore the code and build confidence—or lose it—or understand where the agent went wrong.

How do you see Linear and Cursor complementing each other?

Rohan: Linear is the expert on product, customer, and project context. Cursor is the expert on the codebase, development history, and engineering practices. When you put those together, agents start with a much more complete picture. That makes their output better and lets teams move faster—because the agent isn’t starting from scratch.

What kinds of issues does the agent do well with?

Rohan: For a while they’ve been very effective for smaller changes, where they can pattern match or easily verify correctness, and for larger tasks where power users provide rich prompts with clear context, file pointers, and an outline of the approach. There’s also a category of more difficult changes where the agent can ramp on codebase context a lot faster than I can, like making a fix in a really old, tricky part of the codebase.

I think the bigger point, though, is that agent capabilities are expanding rapidly as models get better. The things they’re great at have already progressed from small issues to now medium ones, and soon to really large, complex tasks without much user iteration.

How does this integration change the kind of work teams can realistically take on?

Rohan: It lowers the activation energy for getting work done. A lot of teams have P2s or P3s that linger in the backlog because they’re not urgent enough to justify the context switch. With this integration, those tickets can get scoped, have a PR drafted, and be ready for review without much extra effort from an engineer. It’s a way to make progress on the polish and quality work that otherwise gets deprioritized.

What was it like to build on the Linear platform?

Rohan: It was overall very easy. I think I got the new API up and working in a day. Working with Tom [Linear’s head of engineering] and Mingjie [a Linear engineer] over Slack was very easy. Having that high-fidelity touchpoint with the Linear team helped a lot. Having the Linear SDK and the auto-generated GraphQL types also helped a lot. It just reduces how much you have to look things up in the documentation.

Can you tell me about a moment where you and the Linear team troubleshot something together?

Rohan: One was understanding the agent API data model and whether it was safe to always assume an issue ID exists. Tom explained that in the future there might be agents acting outside issues, so we made our code handle missing IDs. That kind of long-term context was valuable. I also gave feedback on surfacing the “open in Cursor” link more prominently. Our workflow often starts in Linear but continues in Cursor, so it should be easier to get back there.

Were there any tricky parts of the integration?

Rohan: The main one was working with webhooks. You have to set up and run your own instance, so it’s a little hard to collaborate with other people on the team. If multiple people are working on webhooks, you create a Linear test app, but then it has to talk to my local server on my laptop and sometimes someone else’s laptop. If we both set up things to forward events to our laptops, it gets confusing.

Another thing that could be better is having an even deeper developer experience for running locally and testing everything end-to-end.

We’ve developed Agent Interaction Guidelines for agents in Linear. Did any of those ideas come up in your work?

Rohan: One thing we talked about was how often the agent should leave comments in Linear. It’s tempting to have it comment whenever it does something, but that can get noisy and fatigue users.

Another principle I noticed was “an agent cannot be held accountable.” That’s important for us—it solves the problem of communicating to our users that ultimately it’s the human engaging with the agent who’s responsible. Linear encoding that as a design really helps set the default. I was also pleasantly surprised by the support for “thoughts” and “tools” in the API. That maps well to our agent model, and I was able to quickly show that internal state to the user through Linear.

The API now has a “sessions” abstraction, which represents the interaction between an agent and the Linear workspace. How did that affect the way you built the integration?

Rohan: It was pretty simple to work with overall. It complicates things a little bit because you can’t just key things off an issue. If there’s no issue, we just say we don’t know how to work with this. But it simplifies the idea of how the agent gets back to the user. Rather than trying to figure out which comment to edit or starting a thread, it’s a much simpler API for what we need.

What would you like to see from Linear in the future?

Rohan: I wonder if you guys would have a taxonomy of some sort at some point. Things like bug, typo, feature, documentation, testing, tech debt, or refactoring. I think it’d be interesting if the platform itself understood that and could give agents a cleaner decision-making process on what to do. It would help with refusals—if it’s too hard or underspecified, we shouldn’t try to solve it. You could also use different models or budgets depending on the work.

What would that allow Cursor to do?

Rohan: Mostly it’s just moving up the automation hierarchy. Imagine label-based or rule-based triggers that automatically assign issues to agents—“in this project, with this label, and t-shirt size small or less, let the agent handle it.” That’s a stepping stone toward richer collaboration with coding agents.

What else is part of your vision for Cursor in Linear?

Rohan: I think it’d be really interesting to see how agents can help do planning in Linear. Potentially take a lot of the context from a large ticket and create smaller Linear issues out of it. Or take something that an agent isn’t comfortable working on and turn it into smaller pieces that it can work on.

Finally, what advice do you have for someone building an agent integration with Linear?

Rohan: I’d recommend thinking about how your agent will handle longer-running tasks. The Linear API is designed so you accept the work, queue up the task, and then update back when it’s done. This works fine for quick jobs, but for something that takes hours you need a way to check in periodically or stream updates back. That way the user knows it’s still making progress. And think about how your agent communicates in those updates—like a new hire explaining what they did so the reviewer can quickly decide if it’s ready.

To learn more, read about the Cursor integration and check out our agent developer docs.

In early 2023 at an offsite in Tenerife, our European engineering team did a series of exercises that ended up changing the way we work.

The first was a test of sorts. I showed the team a short screen recording of a small part of the Linear app: a series of three buttons, each illuminating when the mouse hovered over them and going dark when the mouse moved away. I asked the team if they could tell what was wrong with the interactions. Even after watching it a few times, no one could see it. That’s when I realized we probably weren’t looking at the right things.

That same afternoon we did a more open-ended survey. One by one we scrutinized specific parts of the application like display options and issue lists. I gave the team the prompt to write down everything they noticed that wasn’t quite as good as it could have been. I didn’t know whether we’d turn up a long list or barely notice anything at all. Even so, I was surprised by the outcome: Each person noticed something different—small quality flaws that had been invisible to everyone else, including me.

From these offsite experiences, two things became clear. The first was that the pursuit of quality is not an individual sport. It’s hard to perceive subtle problems with a UI you yourself have built. Other people need to point out problems, and if you do it as a group, you’ll come closer to gaining a comprehensive view of everything that’s wrong with a product.

The second thing I realized is that I wanted a way to make sure we kept quality top-of-mind in everything we did. At the same time, I knew the team was too busy to drastically reallocate how we were spending our time. We needed quality to be a habit, like brushing your teeth. Something you just do without thinking too much about it. No one ever says they don’t have time to brush their teeth. I wanted our team to begin thinking about quality in the same way.

A new practice came out of that offsite, which we formalized a few weeks later. In my announcement I asked that each engineer find and fix some defect that’s decreasing the overall quality of the app. I added that these fixes shouldn’t address “bugs per se,” but rather, small imperfections that “degrade the overall experience you have with Linear.” I asked the team that we henceforth devote our Wednesday team meeting (one of three standups we have each week) to presenting our quality fixes. That was the start of a ritual we now call Quality Wednesdays. It’s been going ever since.

Making quality a habit

Everyone on the team approaches Quality Wednesdays in their own way. One engineer maintains a note file where he records everything he encounters during the week that seems off to him. Then as Quality Wednesday approaches, he’ll fix one or two. Others make quality fixes in the natural course of their work.

There is no shortage of places to look. Some people make quality fixes on a theme. They’ll spend a month or two scouring the menus in “Preferences,” or looking at keyboard navigations or accessibility features. The way the product appeared on mobile was a popular hunting ground before we had a native mobile app. Not all controls were optimized for small spaces, so often you could find a quality fix just by narrowing your browser and seeing what didn’t look right.

Here is a fix from this June that standardized the sizes of adjacent buttons:

And here’s a recent UX fix to stop the height of the issue composer from changing when the user adds a line:

Many of these quality fixes take 30 minutes or less. None should take more than an hour or so. Keeping the time commitment low helps to make it a sustainable practice. Consistency matters a lot too. It’s not strictly speaking a requirement that each engineer make a quality fix each week. But if someone misses a week, I’ve been known to joke, “That’s OK, just bring two next week.” The point is that attention to quality only works when it’s a habit, and as with any habit, it’s easy to lose momentum if you miss a rep.

Catching mistakes before they happen

Over the last two years we’ve completed more than 1,000 small acts of polish as part of Quality Wednesdays; we track them inside Linear with a “quality” label.

Most of these fixes are small on their own, but together they completely change how the product feels. They allow us to push Linear’s extremely high quality bar even higher.

These 1,000+ improvements are also just one part of the impact Quality Wednesdays has had on our team and on the product. The bigger change is in how we build new things in the first place. This is how one engineer on the team put it recently: “Since you train this muscle over time, you start noticing patterns and common pitfalls while building stuff, so fewer of these papercuts ship.”

On that point, I think about that screen recording I showed the team more than two years ago, of the mouse hovering over three buttons. The problem with it—the one that the team couldn’t see at the time—was that the animations were inconsistent: one of the buttons darkened instantly when the mouse moved away, rather than fading out over 150 milliseconds as it should have.

I think everyone on the team would catch that now. But more importantly, because of Quality Wednesdays, it’s also far less likely to arise.

By late last year it was clear that agents were improving rapidly. People were tweeting about them, prototyping with them, and sharing demos of newly derived, end-to-end agentic workflows. It seemed obvious that they were going to fundamentally change the way products are built. Instead of spending most of their time writing code, product teams were poised to reorient themselves around managing context and reviewing outputs.

We recognized that Linear was a good fit to become the orchestration layer where humans and agents interacted. Many teams did most of their product work in Linear already; agents just needed to meet them where they were. And, as a platform, Linear already had a strong foundation for third-party interaction: OAuth apps, scoped permissions, user roles, a rich API. The building blocks were there.

The work was figuring out how to bring agents into the system in a way that felt natural, adding only what was necessary. At the same time, we wanted to stay flexible. Developers were just starting to explore what agents could be, and we didn’t want to box them in.

We started thinking in terms of flexible guardrails—clear platform primitives and opt-in constraints that could guide behavior without limiting what agents were capable of now and in the future. Later we codified this thinking into our Agent Interaction Guidelines. Here’s how we got there.

Agents as first-class users

Before agents could participate in work, they needed to exist in the workspace. We already had a model for third-party apps—they could authenticate via OAuth and use the API to create issues, leave comments, and sync data—but these apps weren’t proper users. You couldn’t assign them work, mention them in a thread, or see what they were doing.

To enable that, we added a new actor mode to the OAuth flow: actor=app. When this actor mode is used, the app installation process creates a dedicated user to represent the agent inside the workspace. This dedicated user has their own OAuth token that is tied to specific scopes and teams that the agent can access. The scopes are requested by the agent’s developer, but the team access is determined by the user installing the agent into their workspace. The agent now has its own identity, token, and permissions within the workspace, all of which can be managed by workspace admins. Treating agents as first-class users follows a principle in our Agent Interaction Guidelines: an agent should inhabit the platform natively.

Once installed, they can show up in the assignee dropdown. They can be tagged in comments. You can click on their name and see what they’re working on. And because they’re clearly marked as agents—not people—the human-agent distinction is always visible. This aligns with another principle in our Agent Interaction Guidelines: agents should always disclose that they are agents.

Scoping agents’ work

Once we had a clean way to create agent identities, the next question was: What should they be able to do?

We wanted developers to be in control of whether their agent should appear in the assignment menu, or if their agent should be invokable through mentions. So we added two new scopes to the OAuth model: app:assignable and app:mentionable.

These scopes are opt-in. If you’re building an agent that should take on work—like getting assigned issues or tasks—you include app:assignable. If your agent needs to respond when mentioned in a comment or a document, you add app:mentionable. If you don’t include them, your agent won’t show up in those places. That made it easy to keep existing apps unchanged, and gave developers a clear way to opt into more interactive behaviors.

The nice thing about this model is that it sets you up to iterate. You might start with a low-touch app—one that listens for events or operates in the background—and later decide to make it more interactive. With these scopes, you don’t have to rebuild your app from scratch or worry about breaking anything for existing users. You just opt into the ones you need.

How agents listen

Once agents had identities and scopes, the next step was figuring out how they should listen. What should happen when an agent is assigned to an issue or mentioned in a thread? How does an agent know that it needs to do something?

Our first approach was straightforward. We already had a webhook delivery system and an inbox notification system, so we combined them. Since agents were now users in Linear, we mirrored a regular user’s inbox, just delivered via webhooks rather than inbox notifications or emails. If an agent was assignable or mentionable, we’d send a webhook any time it was tagged or assigned.

But that model pushed a lot of complexity onto the developer. You’d receive a notification webhook and have to figure out all the context around it: what the comment was about, whether the comment was in a thread, what issue it belonged to, and how to format your reply correctly. There were no patterns and no good defaults—some apps responded with an emoji, others with a new comment, and some didn’t respond at all. Even just replying to a comment took more code than it should have.

This lack of structure was intentional. We wanted to see what agents actually needed in the wild before codifying any abstractions. And now we have with “agent sessions.”

An agent session is an abstraction that represents the interaction between an agent and the Linear workspace, whether that’s an assignment, a mention, or some other trigger. When an agent session is created, we send a webhook with structured context: what happened, where it happened, who triggered it. Then the agent responds to the session directly, and we route that response to the right place in the product.

Agent sessions also track state. An agent can be waiting for input, actively working, completed, or errored. This gives us a way to manage the lifecycle of the interaction, and it gives users more visibility into what the agent is doing and why. We capture these ideas in two principles in our Agent Interaction Guidelines: an agent should provide instant feedback and an agent should be clear and transparent about its internal state.

The agent session model is part of how we’ve tried to strike a balance between structure and flexibility. We don’t tell you what kind of agent to build, or how it should respond, but we do give you a consistent surface for handling core interactions.

Delegating responsibility

One of the early questions we wrestled with was how to divide responsibility between agents and humans. You might assign an issue to an agent to see how far it can get. But unlike when you assign an issue to a human teammate, the responsibility doesn’t transfer. You’ll review the output, tweak it, maybe go back and forth with the agent, but you’re still the one accountable for the result.

We considered using sub-issues to model that relationship, but it didn’t quite fit. Sub-issues are intentionally independent, each with its own status and owner. We wanted tighter control over this human-agent responsibility loop.

That’s where the idea of “delegation” came in. Instead of assigning issues to agents as you would to human teammates, you delegate to them. This changes the shape of the assignment: the issue still has a human assignee—someone accountable for the result—but it also has a delegated agent responsible for taking action. It creates a clean taxonomy: issues can only be assigned to humans, and only delegated to agents. That reflects a core tenet of our Agent Interaction Guidelines: an agent cannot be held accountable.

The feature also helps with visibility. Before delegation, you’d sometimes see an agent with dozens of issues assigned, but no clear sense of who was behind them. If you disagreed with what the agent was doing, it wasn’t obvious who to talk to. Now, any issue involving an agent has both a human assignee and an agent it’s been delegated to.

The future of agents in Linear

The current version of the Agent Interaction SDK provides a solid foundation but there’s still more to do, especially around helping agents share more of their thinking. Right now, most agents respond with a single comment or update. But as they take on more complex tasks, we want them to be able to explain what they’re doing and why. We’re already adding structured activity types—tool calls, thoughts, elicitations—that let agents surface their reasoning and make their behavior easier to follow.

We’ll keep evolving the platform, but with the same core ideas in mind. First, give developers the right set of primitives and guardrails to build agents that feel at home inside Linear. And second, stay flexible enough that our Agent Interaction SDK will work not just for the agents people are building today, but also for the ones no one has thought to build just yet.

Learn more about Linear for Agents.

This past March, Mercury held an internal hackathon and Matt Russell knew exactly what he wanted to work on.

Russell, a staff engineer at the seven-year-old financial technology company, was aware that coding agents were advancing rapidly and he wanted to see what they could do for Mercury. He and his hackathon team created a tool that allowed them to assign issues in Linear to third-party agents, which would return a pull request for engineers to review like any other PR. Almost immediately they saw the potential. The project showed how agents could reliably tackle simple, well-scoped tasks—like straightforward refactors or UI changes—under close human guidance.

Around the same time as the hackathon, Mercury joined the beta of Linear for Agents, which gave Matt and his team a foundation for building more complex agentic workflows. In the months since, they’ve refined their ability to have agents one-shot routine tasks while learning how to guide agents step-by-step to accomplish more sophisticated projects. While many engineers at Mercury today use AI for code suggestions and, recently, in-editor agentic chat, a smaller group has started experimenting with other agentic workflows.

In the following conversation with Kevin Hartnett on the Linear team, Matt shares how Mercury is using agents today to move faster, reduce tech debt, and give internal teams more autonomy. He also talks through the company’s approach to shipping high-quality AI features, his strategy for keeping current on AI developments, and how he thinks engineering roles will change over the next five years.

This interview has been edited for clarity.

What kinds of tasks have turned out to be a good fit for agents?

Matt Russell: It comes back to how much you’re in the loop—nudging the agent along—and how far you go. If you’re really trying to one-shot, it’s hard to add much complexity. The task needs to be repeatable or follow some common pattern. It’s just too easy for the agent to go the wrong way.

We’ve found that getting agents to create a plan, start with step one, and then move to step two works great, especially in-editor for larger tasks. Not trying to do too big of a project in one go is key. Otherwise, they lose context and go off the rails.

So you stay involved and review each step?

Matt: Yeah, we’ve found a lot of success saying, “I’m trying to work on X feature, I’m gonna go back and forth with you for a while until we agree on the plan. Then, let’s execute step one,” which might be writing test cases first. That helps center the AI and keep it on track. That’s worked quite well.

Tell us about one of your early experiments around providing agentic support for your ops team.

Matt: One of the best use cases we saw, and one we still use today, was with some configuration UIs that our operators use to review activities in Mercury.

Where does the workflow originate?

Matt: We created a Linear Asks template around it. It would start from Slack where someone fills out five required fields, and it generates a ticket. The top part describes the task, and then there’s a “notes for AI” section at the bottom, with stuff like “Copy this approach” or “Refer to this PR as an example.” It was super repeatable and worked with almost no errors.

So you were able to empower your ops team to resolve technical issues almost completely on their own, without engineering support?

Matt: Yeah, we were able to make it so that some of these UIs could be built in a more self-serve way. An ops person could submit a ticket, it would get automatically assigned to an agent using a Linear template, and the agent would just pick it up, start working, and put up a PR. Then an engineer could review it—same as any other PR.

Are these agent experiments usually initiated by individual engineers?

Matt: There’s broad support from the top for using AI, but a lot of the experimentation definitely comes from ICs. People will try something out, see that it works well for their use case, and then that bubbles up.

We also have a lot of venues for sharing—engineering all-hands, team showcase events—where people show off things that are working. So there’s been a steady stream of demos and examples lately. There are just so many interesting ways to weave these tools into workflows.

How do agent reviews coexist with human reviews? Where do you see that balance going?

Matt: The way we work today is: engineers put up PRs, and you own whatever code you push. Yes, AI may be a part of the process, but it’s still your code. You’re expected to have understood it, and you do a self-review first.

We’re piloting CodeRabbit for AI-generated reviews. Those usually come faster than human ones, and I’ve seen some great feedback. It catches logic errors and other issues. But we still need human approval. I don’t think that’ll change soon. We’ll keep evaluating, but I expect a human-in-the-loop signoff for a long time.

We’ve talked about internal workflows so far. How are you thinking about incorporating AI into the user experience at Mercury?

Matt: We’re trying to use AI in ways that enable not just our operations team, but also make the experience smoother for users. We started beta testing new search capabilities—kind of like what Linear has—where you can go from natural language into actual filters. So instead of figuring out how to select the necessary filter combinations a user can just say, “Show me how much I spent at Chipotle in the last two years,” and it’ll generate the right filter.

When building AI features—where the underlying technology is so new—how do you make sure you’re hitting your quality bar?

Matt: We hold ourselves to a very high bar in terms of quality. That’s one of our core principles, and something we think differentiates us from more traditional banking software.

So it is a challenge. We want to be really comfortable with anything we put out there—especially because of the non-deterministic nature of LLMs. Whether that means using a reinforcement system on the backend to make sure it’s doing the right thing, or falling back to an alternative if it doesn’t seem quite right.

Or it could just mean putting it through really good testing or doing a slower rollout. We’re still figuring out exactly how this changes our approach. But we’re definitely conscious that we don’t want to sacrifice quality just to ship an AI feature. We want to make sure it’s actually improving things for our customers.

You’ve mentioned agents helping you get to more of the backlog. How do you think that changes the product?

Matt: I think it’s great. There are enablements all across teams. Things that didn’t meet the threshold before can now get done: file a ticket, assign it to an agent, review the PR, and move on.

That lets us polish the product more and meet our standards. It also helps with tech debt—things that affect performance or help prevent bugs. I think that’s been really nice. One other thing I find interesting is how good agents are at larger refactors.

How does that change the way your team works?

Matt: Upgrading to a new platform version or switching testing frameworks used to take months. Now you can say, “Switch from this library to that one—here’s an example,” and it can churn through it. That’s really freeing and you get productivity wins just by being on better systems.

What do you think engineering work at Mercury will look like in the future?

Matt: It’s still early and things are evolving quickly, but maybe there’s a world in a few years where senior engineers act more like project leads over a bunch of agents. You’d scope the project, align with product, and then delegate the plan. From there, you’d check in and give feedback. It starts to feel more like a lead engineer working with junior engineers.

Once we can trust agents to run overnight, the pace of building is going to skyrocket. You’ll wake up, check in, and most of the feature will be done. That’s really exciting.

If someone in a role like yours were just starting out with agents, say six months behind where you are now, what advice would you give them?

Matt: I mean, it’s a little cliché, but I think it’s really: experiment, experiment, experiment. Take the time to try different things, try new techniques, see what’s going to work for you. I would also highly recommend looking at AI code review. One of my favorite features is being able to teach these systems about patterns or styles at Mercury and automatically get those learnings applied across all reviews at scale.

One of the hardest things I find is keeping up with it. If I stop experimenting with the newest thing for a week or two, suddenly I feel like I’ve fallen quite far behind. So setting some kind of time budget—like maybe an hour a week, maybe more—to play with some new tools you’ve seen come out in the last week or so, I think is really key.

I do want to take this opportunity to say that I’m proud of how far Linear has come. And how we’ve gotten here. For the last six years we’ve been able to build our way, with quality and purpose. We haven’t sacrificed what we care about.

I believe that building companies is a kind of craft. You’re creating something one of a kind. It’s shaped by a very specific group of people, in a very specific moment in time. You can never really replicate that or manufacture it again. And for most founders, it will be the only company you’ll ever build. That makes how you build just as important as what you build. Therefore, the way you craft should be important to you, and not just a means to an end.

Across the industry, there’s a tendency to pattern-match successful companies and rely on templates, playbooks and benchmarks. While it’s not completely wrong, trying to fit a mold often means missing out on truly unique opportunities.

I’m glad we’ve been able to resist fitting the mold. I’m glad we’ve resisted “best practices.”

We’ve built Linear without running a single A/B test and without chasing metrics or looking to data for answers. We didn’t do SEO and growth hacks. We’ve grown the team slowly and intentionally. Linear operates profitably and remotely. We built strong technical foundations before finding product-market fit.

We did this because our goal was to create quality experiences and the best product — not follow conventional practices. As a founder, your craft is to figure out how to make the most of your team, your strengths, the vision you have and the ways to get there. That doesn’t mean being stubborn. In the six years of building Linear, I’ve learned a lot and my thinking evolves constantly.

I’ve come to appreciate over time that saying no and setting constraints can help bring clarity. Whether in product, hiring or company operations, the constraints often reveal what’s really needed and bring out the right arguments and feedback. When you ask leaders to make a case for their hires, or when you ask deeper questions about why a customer needs a feature, you end up with something sharper.

And I’ve seen the response from teams using Linear every day and switching to it from other tools. Over 15,000 companies — including OpenAI, CashApp, Ramp, Scale AI, and Boom — choose Linear over legacy tools to move faster.

With this round, we’re marking our position as a company that is high growth, profitable and a standard for modern companies. But more importantly, we’re making a promise to our employees and every current and future customer:

We’re not going anywhere.

We’re going to keep building, and keep fighting for the way we believe software should be built.

The next shift

So why raise this round now? I want to take a moment to talk about a generational change that is happening in how software is made. It’s a change in how teams work, how code gets written, how products get built.

Linear was built to be a generational company. It’s exciting to see this shift taking place. AI is changing the industry. We want to be the company that supplies the industry with the best possible workflows and tools for the new era.

It‘s hard to imagine a future where AI doesn’t play a major role, but like me, you are probably already tired of hearing about AI and its potential. The message is as widespread as it is thin.

Many AI launches today are announcing very broad tools that aim to address a large range of problems and use cases. While that shows the potential impact of AI, many teams still don’t know where to start or how to apply these tools to their workflows. There’s a gap between what these tools promise, and how teams actually use them. My gauge for what is hype and what is real is often measured by how close the person is to actually using the technology productively and realizing its value.

I’ve started to see a shift toward real AI productivity from our customers. They have been building AI features and agents that work with Linear. When you start to see this from your customer base, it means that people are truly motivated and adoption is happening. It’s no longer just a marketing message, actual use cases are taking shape.

Over the past few years, we’ve expanded Linear to support end-to-end workflows for building products, from customer discovery to planning to execution. Linear is unique because it actually manages all these workflows in a structured way and in a single product, bringing teams together.

We see this end-to-end workflow as the natural place to integrate AI and agents as purpose-built capabilities that serve teams, not just individuals. We’re focused on solving real, contextual problems within the workflow.

So this is all to say that AI is coming to Linear, but we are approaching it from the ground up, starting with real problems first. We are roughly aiming to do two things:

Linear for Agents

We’re making Linear the place where agents can be deployed and managed to act across product workflows. Whether it’s a third-party agent, an internal agent you’ve built, or something we’ve made ourselves, the goal is for agents to live and work inside the same system as your team.

As teams start to run more agents across more workflows, coordination becomes important. It shouldn’t matter which agent you’re working with. Interacting with an agent should feel purpose-built, efficient, and integrated.

This will allow teams and individuals to utilize agents day to day and in parallel with their own work. Agents can solve annoying problems or maintenance tasks, low priority items or even hard broad problems, asynchronously. As Linear is a place to coordinate work across many builders, it will also be the place to coordinate work for agents.

Linear AI

Because Linear already covers a wide range of product-building workflows, we are designing AI features that make those workflows more effective or automated. Helping teams create issues smarter, triage, categorize and route issues automatically, or summarize feedback and surface patterns that might have gone unseen.

These are not separate AI features. They’re built into the workflows themselves. Just like every other feature in Linear, they’re crafted with care, made to integrate seamlessly and designed to make you faster.

We’re continuing our mission to inspire and accelerate builders.

Thanks to all our employees, customers and investors.

The modern world has made huge advances in knowledge, technology, and skill. We can build faster than ever. We know more than ever. Yet quality still feels so rare. So many things feel unfinished, broken, or forgettable – why?

That’s the question I’ve been trying to answer, almost my whole life. I remember as a kid, seeing bikes at the store, some of them just felt wrong. I couldn’t understand why someone would go through the effort of making something and not make it beautiful.

Later in my life, I realized it’s because many don’t care, many opt for cost, and many just do what’s easy. What I was noticing, even as a child, was the presence or absence of craft.

Craft happens in cycles

Before machines, everything was made by hand. A tool, a chair, a door. They reflected the skill and care that was put into them. Some things were rough. But when someone puts their full attention into the work, the result could be truly great.

This is what craft is about — the deliberate attention put into making something excellent, not because someone is checking, but because it matters to the maker.

Then came the industrial revolution and mass production. We started losing the connection to craft. We began to optimize for costs, speed, and quantity.

We’ve been living our own version of this in the software industry. In the beginning, small teams crafted software with care. They took pride in what they built.

But over time, the teams grew and the process started to look more like a manufacturing line. As we learned to ship to the cloud multiple times a day, we started to change how we work and think.

“Just ship it.”

“Move fast and break things.”

We replaced purpose with metrics. If it didn’t move a metric, it didn’t matter. Even we, as designers, stopped asking; “Does this feel right?.” Instead, we started asking: “Does it convert?”

Experiments and A/B testing replaced judgment. Optimizing for a process replaced craft.

The interesting thing is that this cycle keeps happening in the same way with each technological advancement, it’s nothing new. In 1927, Earnest Elmo Calkins wrote in The Atlantic:

“The directing minds, absorbed in the new wonder of so many things made so easily [...] aggravated that fact by producing the bad design in incredible quantities.”

“We passed from the hand to the machine, we enjoyed our era of the triumph of the machine [...] and then we began to miss something in our cheap but ugly products.”

You see this common cycle play out. Craft exists naturally at the beginning. Then technology comes along and makes it easier or quicker to create things, and so we’re pulled away from craftsmanship. But then we start to miss it (in our work and the products we buy) and in response we seek quality, which causes a revival of craft.

AI is making craft more rare

Today, we’re at a familiar moment in the craft cycle. Maybe even bigger than before.

AI feels more like a change in substrate, rather than just another tool. Like electricity, the internet, or the mobile phone, it changes the material conditions of how we make things by putting near-instant creation in everyone’s hands.

While mass production separated the maker’s hand from the object, AI attempts to separate the maker’s judgment and taste from creation itself.

With each prompt, we’re trying to outsource not just labor, but the craft itself — the thinking, the intuition, the care. Yet craft, by its nature, can never be fully outsourced. The qualities that make something truly excellent come from being deeply involved in the entire process.

Technology makes it faster to build, but harder to care.

Craft is the pursuit of quality

The craft we’ve been discussing is essentially the input that creates quality. When something is crafted with care and attention, it possesses a certain feeling — a quality that’s difficult to define but impossible to miss.

Christopher Alexander called it “quality without a name.” He wrote: “There is a central quality which is the root criterion of life and spirit… It is objective and precise, but it cannot be named.”

It’s when something feels alive. When something feels right, even if you can’t exactly describe why. You know when it’s there. And you know when it’s not. Like a door opening and closing perfectly, it’s satisfying.

At Linear, we recently did an interview series on quality. My takeaway from those interviews with different makers was that everyone approaches it differently. There isn’t a single right way to operate or create quality.

But one thing was common with everyone: The belief and need to seek that quality. Seeking the feeling of rightness, even when it was hard.

Quality is a business strategy

While some seek quality, it’s still not that common. Time after time, working in companies and teams, I heard: “Quality doesn’t matter, we have other priorities.”

The conventional wisdom in tech is that quality doesn’t scale. That pursuing craft is too slow, too expensive, too precious for business realities. That at a certain point, you have to choose between growth and craft.

This belief is so pervasive that it’s rarely questioned. Companies optimize for immediate metrics and quick wins, assuming quality will somehow take care of itself (it never does).

While I understood the reasons, I never fully believed in them. In the back of my mind, I always believed that if you actually try to do it, it can work. So when I started Linear, quality became a central part of the business. Not just because it was important to me personally, but also because I saw it as a way to win.

In a crowded market of issue tracking tools, Linear stood out through quality. Quality creates gravity — it pulls people in rather than requiring us to push. One team would experience Linear, tell others, and adoption would spread organically throughout organizations. This natural flywheel of experience to advocacy to adoption to loyalty has powered our growth far more effectively than traditional tactics ever could.

Linear became profitable by year two. And by year four, we had more than 10,000 paying customers with effectively zero marketing spend. Turns out when you build something that feels just right, your customers will do your marketing for you.

Quality at Linear

When I talk about quality, I don’t just mean product quality. I mean the whole customer experience. So, how do we build for quality at Linear?

• Quality as the north star for every team
  We evaluate decisions by asking “does this improve quality?” not just “will this ship faster?”
• Intuition & customers over data
  We trust our sense of what feels right and listen closely to users, not just metrics
• Hire only people who show craft and care
  We look for evidence of taste and attention to detail in our work trials
• Small teams using their judgment
  We believe 3-5 people with good taste make better decisions than large committees
• No handoffs, whole team iterates towards “right”
  Rather than assembly-line development, we keep teams engaged from concept to completion
• MVPs for internal use only
  We don’t ship half-baked experiences; we test incomplete products internally first
• Zero bugs policy
  Issues are fixed within 7 days 

I’ve learned that building quality requires three elements working together: The belief that quality matters fundamentally, the skill and taste to recognize it, and the willingness to care deeply about the user’s experience.

Quality is a choice

The cycles of technology always drive us toward prioritizing speed and cheapness. We forget the craft. We stop paying attention to quality. And while we can’t stop these shifts, we also don’t have to surrender to them.

Quality is a choice we can make every day.

We can choose to care and put it in our work.

We can seek that feeling of rightness.

It starts with an individual. It can scale through teams and companies, but it always starts with an individual — you. Individuals who seek the quality without a name. Even when it’s not measurable or when the world tells them no.

I genuinely believe it’s the right thing to do, and I know it’s good for business. So If there is one trend I’d like to start, it’s this one. Regardless of what the world around us might tell us, let’s make this choice – let’s keep making things we’re proud to put our names on.

For decades, interfaces have guided users along predefined roads. Think files and folders, buttons and menus, screens and flows. These familiar structures organize information and provide the comfort of knowing where you are and what’s possible.

This understanding of interfaces has shaped my perspective on design throughout my career, leading me to see design as largely deterministic. I could visualize how interactions would work. The sequence when a user clicks a button, how information appears, how it adapts to different screens. It’s dynamic, but predictable. I could visualize the user’s journey and think about how to improve it.

That changes with AI and LLMs.

After ChatGPT’s release, the chat interface quickly became the “AI native” standard. This makes sense on the surface – LLMs output text, and chat interfaces are familiar. Language itself is a powerful interface that removes traditional UI barriers. You simply have a conversation. But although useful for some tasks, they aren’t optimal for specific use cases.

Prompting is essentially like writing a spec, sometimes it’s hard to articulate exactly what you want and ultimately control the outcome. Two people looking for the same thing might get wildly different results just based on how they asked for it, which creates an unprecedented level of dynamism within the product.

This shift from deterministic traditional UI to something more unbridled raises a challenge for designers: with no predictable journeys to optimize, how do you create consistent, high-quality experiences?

Form follows function

The role of design is to bring form around the function. Form acts as a way to set the context – like the way an axe looks and feels in your hand, you get an immediate sense of its purpose.

The design itself establishes this context for both the user and the system. By managing inputs and outputs along structured forms, you minimize the cognitive load required to successfully engage with the product, and minimize the variance in outcomes from that usage.

Without form, function gets lost. Unbounded AI, much like a river without banks, becomes powerful but directionless. Designers need to build the banks and bring shape to the direction of AI’s potential. But we face a fundamental tension in that AI sort of breaks our usual way of designing things, working back from function, and shaping the form.

Because we don’t yet fully understand what AI can do, trying to shape the form with unknown function feels a bit like trying to build a bridge over a foggy chasm, without a clear view of the other side. We’re likely going to have to reinvent our design processes – working forward to understand capabilities, rather than backwards from user needs.

Our attempts so far

A chat interface is a very weak and generic form. It’s a simple container for conversations back and forth, which is a start, but it isn’t precise, and it doesn’t effectively integrate with the rest of the tools and systems a team is using.

Some try to solve this by relying on ‘artifacts’, which are structured outputs from the AI (such as CSV files, JSON documents, or model binaries) which can be ported back into core workflows. These feel a bit like a band-aid. I believe a better option is to build a functional application with a more traditional UI and then complement it with AI functions.

Bringing function to form

One way I visualize this relationship between the form of traditional UI and the function of AI is through the metaphor of a ‘workbench’. Just as a carpenter’s workbench is familiar and purpose-built, providing an organized environment for tools and materials, a well-designed interface can create productive context for AI interactions. Rather than being a singular tool, the workbench serves as an environment that enhances the utility of other tools – including the ‘magic’ AI tools.

Software like Linear serves as this workbench. It provides structure, context, and a specialized environment for specific workflows. AI doesn’t replace the workbench, it’s a powerful new tool to place on top of it.

As we move forward to more agentic workflows, the workbench becomes even more important. It will be the place where AI agents live and operate. The place where agents are deployed and managed. Where agents operate with clear guidelines and output is reviewed and approved. Humans stay in the loop, and design still has a massive role to visualize how to make this new world more approachable and understandable.

We need to move beyond the generic chat format and reconsider what users truly require for their specific workflows. Without a workbench, we risk wielding powerful tools in empty space.

Steve Jobs famously said customers don’t know what they want until you show it to them. Henry Ford quipped that people would have asked for faster horses, not automobiles. Yet at Linear, we just built a feature specifically designed to collect customer requests. Seems contradictory, right?

It’s not. Here’s why.

The feedback paradox

Product teams face a fundamental tension. Build only what customers ask for and risk mediocrity. Ignore feedback entirely and risk irrelevance. Every product decision exists within this practical challenge.

The most innovative products emerged without explicit customer requests. Nobody asked for the first iPhone, Airbnb, or Figma. These products came from vision and intuition.

Meanwhile, the graveyard of failed startups contains countless visionary products nobody wanted.

Feedback sharpens intuition

At Linear, we believe the best products come from strong opinions informed by customer reality. Customer feedback serves as the whetstone that sharpens intuition, rather than the source of product vision.

Users rarely articulate their core problems directly. They describe symptoms, request features they’ve seen elsewhere, or suggest solutions that address their specific need but wouldn’t serve the broader user base effectively.

When a user asks for “custom fields,” they’re expressing a deeper need that requires interpretation. Just as a doctor doesn’t make accurate diagnoses by collecting more patient self-diagnoses, product teams don’t create successful products by simply amassing feature requests.

The magic happens in the interpretation. The most valuable skill in product development lies in understanding what remains unsaid, beyond the explicit feedback.

Why we built Customer Requests

So, why build Customer Requests if raw feedback alone misses the mark?

Customer feedback, when collected thoughtfully, organized intelligently, and interpreted skillfully, becomes a powerful intuition amplifier.

Feedback becomes fragmented at scale

We observed a consistent pattern across growing companies. When teams are small, customer understanding happens naturally. Engineers chat directly with users, support teams recognize repeat requests, and everyone develops an intuitive feel for customer priorities through proximity.

But scale changes everything. Customer conversations multiply and fragment across email threads, support tickets, Slack messages, app store reviews, and research calls. What was once a clear signal becomes buried in noise. The small-company systems that worked at the start begin to fail under this volume.

Capturing feedback isn’t the problem. Sales teams use Gong, support uses Intercom, and product teams maintain separate research repositories. The challenge appears when product teams need to use this feedback. They spend hours navigating multiple systems, many of which they lack access to, trying to piece together fragmented context.

I love seeing customer feedback — it brings our work to life. While we get great insights from UX interviews and our customer-facing teams, sometimes valuable feedback gets stuck in tools I can’t access.

Maja Waite, Engineering Manager, Multiverse

When product teams lack deep customer understanding, they explore paths that don’t address core customer problems. For larger companies especially, this creates significant waste — engineering resources go toward features that customers don’t need while crucial problems remain unsolved.

Reading between our own lines

We experienced this pattern firsthand. When users requested “custom fields,” we dug deeper to understand the underlying need rather than implementing the feature at face value. Conversations with users revealed that approximately 40% wanted these fields specifically to track customer needs. Adding a simple custom field felt like a bandaid to a bigger problem — instead, we created something purpose-built that solves this specific problem exceptionally well — a dedicated workflow connecting customer context directly to product decisions.

We created a dedicated space in Linear, displaying customer context alongside engineering work. Customer needs weren’t just abstract requests anymore, and they didn’t get buried. These were real companies with real people, positioned alongside actionable engineering work.

Support tools often have the highest density of customer feedback. When product and support teams get closer together, and the systems between them are smooth, magical things happen.

Marty Kausas, Co-founder, Pylon

Our Customer Requests feature brings feedback from support tickets, Slack messages, and calls directly into Linear – where product and engineering teams can spot patterns, interpret needs, and build context that informs decisions.

We designed it to move beyond tallying votes for features — providing teams with concrete data to recognize patterns and build products users actually need.

Customer Requests enables teams to:

• Bring the voice of customer directly into product development
• Prioritize high-impact needs by filtering customers by revenue, tier, and other business metrics
• Replace scattered tracking methods and eliminate manual syncing between tools

Where we’re heading

When we started building Customer Requests, we set out to solve a clear problem — help growing companies stay as close to their customers as they were when small.

We’re working on integrating with Salesforce and HubSpot so teams can capture customer context where they already work. We’ll use AI to help teams find the signal through the noise and make sense of all this feedback.

The best products emerge when strong vision meets deep customer understanding. Pure customer-led development and isolated visionary thinking both fall short of consistently producing breakthrough products. Develop your product intuition by immersing yourself in customer feedback while trusting your ability to see patterns and needs they cannot articulate. Treat customer requests as input, not instructions.

But that thinking was always flawed.

Profitability isn’t unambitious; it’s controlling your own destiny. It means you don’t have to rely on investors for survival. It means you can focus on your unaltered vision and mission. And it means you as a founder decide the pace of growth. And once you experience it, it’s hard to imagine doing things any other way.

Paul Graham famously wrote about “ramen profitability” – the point where a founding team could survive without external funding. He argued this made startups more attractive to investors, showing they could get customers to pay, were serious about building valuable products, and were disciplined with expenses.

Graham wrote his essay in 2009. I’d argue that we now live in a world where it’s not just easier to get ramen profitable, but traditionally profitable – while also growing fast.

At Linear we didn’t set out to be profitable but kind of stumbled into it. We believed that to win this market we really needed to build a superior tool. The best way we knew how to do that was to keep the team small and focused. And when we launched after a year in private beta, almost all of our 100 beta users converted to paid customers. To our surprise, we realized it wouldn’t take that long to become profitable if we kept the costs in check. Twelve months after launch, we hit profitability, and we’ve stayed profitable ever since.

I don’t know why hiring massive teams ever became the norm. In my own experience, small teams always delivered better quality, and faster. Maybe it’s fear of missing out if you don’t grow the team fast. Maybe it’s investors whispering that your team is “understaffed compared to benchmarks.” Being understaffed compared to benchmarks almost always should be a source of pride, not a problem. People should be surprised how small your team is, not how big it is.

What holds you back is rarely team size – it’s the clarity of your focus, skill and ability to execute. Larger teams mean slower progress, more management overhead, more meetings, more opinions, and usually dilution of vision and standards. Yet growing the team has somehow become a symbol of success.

At Linear, we hired our first employee after six months and roughly doubled the team each year. With each hire, we make sure they truly elevate the team. We don’t set out to hire ten engineers – we hire the next great engineer. This intentional approach has allowed us to maintain both quality and culture.

The most underrated thing about profitability is how much peace of mind it gives you. Once you’re profitable, you stop worrying about survival and focus on what really matters: building something great. Building the way you want. Instead of optimizing for the next fundraising round, you optimize for value creation.

While profitability might not come quickly for every startup, I believe it’s achievable sooner than most think. If you’re creating a new market, or truly require massive scale like a social network, or significant upfront investment like a hardware company, it might take longer. But if you’re in a category where there isn’t hard upfront investment, and you get some level of product-market fit with customers willing to pay, you can probably be profitable. You can decide to become profitable. And usually, it’s a decision about how much and how fast you hire.

Measure What Matters

Revenue per employee is one of the clearest ways to see you’re hiring appropriately. While some of the best public companies benchmark at $1-2M per employee, for startups it’s not unreasonable to target the range of $500k-$1M per employee.

Understand Your Risk Profile

Are you building something highly speculative where you’re not sure if there’s a market for it, or are you building something that already has a market but with a different take on it? In the former case profitability takes longer, but in the latter it could happen right away. Most software today, especially in the B2B space, is about building a modern version of something existing.

Hire Intentionally and Slower

For most software startups, ten people before product-market fit should be your ceiling, not your target. After PMF, every hire should address a specific, pressing need – not just fill out an org chart. At Linear, our deliberately slow headcount growth forced us to be selective, which meant making better hires. It also protected our culture, since rapid hiring often dilutes the very things that made your startup special in the first place. When you hire less, you naturally hire better.

Raise on Your Own Terms

Being profitable doesn’t mean you have to be anti-investors. It means you have that choice, and investors are quite interested in profitable companies that also grow fast. You can raise more, less, or nothing. You can wait for the right timing, the right partner, or fund. For most ambitious startups, it can still be a good idea to raise something even if you could get by bootstrapping. Investors can still be helpful, and the additional cash balance can help you to make larger investments, or acquisitions.

The point is that you can be and are allowed to be profitable as a startup. It’s not a bad thing, it’s not an oxymoron or as hard as people make it out to be. The secret is that a lot of successful companies actually were quite profitable early on, they just didn’t talk about it. When you’re profitable, you make decisions based on what’s best for your customers and your product, not what’s best for impressing investors.

I didn’t set out to build a profitable startup. But once I got there, I realized I wouldn’t want to build a company any other way.

In the rapidly changing space of AI, Scale has evolved and grown to lead the space. As the company expanded, adding hundreds of new employees, their existing project management tools were unable to keep up with their needs.

The need for new tooling became apparent and leaders across different teams independently sought better solutions. A grassroots movement within the company, guided by leaders from different teams, converged on the same solution: Linear.

What drove Scale to Linear

Before migrating employees to Linear, Scale was using a combination of other tooling across their teams. Pitching and coordinating a tooling switch of this scale can be difficult, but Sam Sipe, Head of Engineering for Public Sector at Scale, knew he wanted to switch to Linear.

Before, they had difficulty reassigning issues, sharing context, and seeing progress. To get clarity, members of each team bookmarked different views and periodically audited other teams’ boards for issues that weren’t appropriately tagged to their team.

Theoretically, we were agile, but it was difficult to find tickets. We had a backlog that wasn’t in service of our products or the engineers working on them. Things got lost if end users didn’t use workflows properly.

Sam Sipe, Head of Engineering, Public Sector

Having used Linear at a previous company, Sam was confident it was the right tool to organize and engage his teams.

Having used Linear previously, I realized how much better it would be to have purpose-built tools that do the right thing. Linear’s easy-to-follow workflows would be incredibly useful to our engineers.

Sam Sipe, Head of Engineering, Public Sector

Over the past year, Scale’s business product offerings expanded rapidly, and so did its team. The expanding team looked to Linear to support its growth.

Engineers hate issue tracking in general, so you need to make the barrier as low as possible and set incentives for them to use it. One way to do that is to have a tool that people enjoy using.

Clemens Viernickel, Staff Product Manager

Over time, engineers did what they could to avoid logging tickets, like resolving issues outside of the tracking tools already in place. The broken issue tracking process caused complications downstream.

Though Clemens Viernickel, a Staff Product Manager at Scale, had never used Linear before, he knew of it from peers and made an independent decision to pilot it on his team. Conversations outside their previous tool unearthed new tickets that needed to be created. They needed a bridge for a disconnected workflow. There was no initiative to roll Linear out to Joshua’s team. But when he caught wind of it, he thought his team should convert, too.

When other teams caught wind of a potential shift to Linear, they also wanted licenses.

We planned for 50 seats initially, but suddenly, 200 more people signed up. It was a classic grassroots story – other teams heard we were using Linear and wanted to use it, too. Now, we’ve switched all teams over.

Clemens Viernickel, Staff Product Manager

My advice for anyone curious about Linear is to do a pilot. The product sells itself. My team instantly thought Linear was great. There were no grumblings. The only conversations we had were about getting enough seats to give people access.

Joshua Hall, Head of Customer Engineering

Deploying Linear

The first team that used Linear chose their optimal workspace and team settings. That foundation made it easy to onboard remaining teams. Eager to get moving in Linear, the group decided to leave their old tool behind and go into the transition with a clean slate.

Joshua’s smaller team imported all of their issues to Linear, archived the ones they weren’t working on, and adjusted Linear settings to their way of working. By the time Linear was approved across the org, they were fully up to speed.

The larger teams took a similar approach but extended rollout to ensure smooth change management. They established a cutover date where all issues would be imported to Linear, and all work would take place in Linear moving forward.

Moving at high velocity

Quick adoption of Linear led to impressive outcomes for Scale. Scale improved bug resolution time by 52%, resolving problems for customers and building data products faster than ever before.

In Linear, Scale found the infrastructure it needed to continue fueling the most exciting advancements in AI.

I often get asked, ‘Why Linear?’ While I could talk about all of its incredible features, the switch to Linear was really fueled by one thing: velocity.

Clemens Viernickel, Staff Product Manager

The switch to Linear Asks

Why did you switch to Linear Asks from your previous internal request tool?

Zeo Csoltai

Our existing tool HALP was shutting down and we were looking for another tool to manage internal requests. HALP had worked well for us when we started using it; we had around 300 employees at the time. Unfortunately, HALP was acquired by Atlassian. We could tell almost immediately that their product was slowing down–there were no new features coming and we heard silence from their team. Eventually, we got an email saying that HALP’s product would be sunset and our only option would be to move to Jira Service Management’s ITSM tool. We decided to explore other options.

Stefan Christensen

We were hoping to move to something similar and not have to use a bloated or more complicated tool. We started looking for another solution around the same time that Linear reached out to us about joining the beta for Linear Asks, so it was a perfect match.
‎‎ ‎

What mattered to you in making this decision?

Zeo Csoltai

We wanted a tool that would be effortless for anyone at our company to use. If people dislike your internal support tool, they won’t use it. They’ll be slow to report issues and work around the tool, messaging their manager or pinging the internal support team individually. This adds more time to each request and more work for internal teams.

We definitely didn’t want a tool that required users to login separately. Everyone at the company has access to Slack and is comfortable using it, so it was crucial to have a tool that integrated seamlessly with it.

Stefan Christensen

We also needed a tool that was flexible enough to support different workflows. Our internal teams all work very differently from each other. Some teams get a few requests a day while others get hundreds per week. Teams vary in size and the requests can differ a lot, from getting someone at Pleo access to an internal system, to debugging a development platform error, to investigating a billing discrepancy. We wanted each internal team to choose how they worked: how they set up staffing rotations, how requests would be sent to them, and what information would be included in each request.

While it wasn’t a specific requirement, we also didn’t want to spend much more than we were paying for our existing tool. In the end, we’ve actually saved close to $30,000 a year since moving to Linear Asks, since Asks is part of our existing plan and not a paid add-on like Jira Service Management.

A natural fit with Pleo’s workflow

Zeo Csoltai

Primarily, we liked Asks because it is so simple to use. My teammate can open Slack, post a question, and it instantly gets routed to the person and team who can help. They don’t have to think about filling out complicated forms, tagging specific people, or following a specific process. Getting help is as easy as posting a question in Slack.

It’s also a huge benefit that through Asks, these requests are linked bidirectionally with Linear. Requests are sent directly to a team’s Triage inbox, where they can be reviewed and processed just like any other Linear issue. Comments and status updates post across to the linked Slack message, too, so you are kept up to date no matter which tool you are in.

Many teams at Pleo were already using Linear for product and engineering work, and even creating issues from requests posted in Slack manually. Adding internal support requests to their Triage queue didn’t change the day-to-day workflow for most teams.

Building a best-in-class Technical Operations team

You have a strong opinion on how you run your Tech Operations team. Can you share more?

Zeo Csoltai

Our vision for Tech Operations (TechOps) is rooted in modern DevOps principles. We want to be proactive, to anticipate problems and prevent them before teams even realize that an issue is brewing. If we can resolve issues earlier when they are small, we can prevent large bottlenecks that affect delivery or have other serious ramifications.

We’ve tried to avoid running TechOps like a traditional IT operation, where work is primarily reactive, going ticket by ticket, and solving problems only as they are reported.

We also use a more casual style in our interactions, getting to know our teammates as people and building relationships with them beyond just fixing the issue at hand. Most of us have had dreadful experiences with IT, where you fill out a billion forms on a website and have no clue if you’ll hear back in five days or five years. That’s an experience we don’t want our teammates to have when they need our help.
‎

What does this vision look like in practice?

Zeo Csoltai

A lot of my job involves discovery: talking to my stakeholders on a regular basis, checking in and figuring out where we can make small improvements to their existing workflows without breaking things in the process.

Using Slack as the interface for ticketing helps us reinforce this human-focused approach to internal support and helps us be more approachable, so that when a problem or question does come up, people feel comfortable reaching out to us. It’s so easy to send a Slack message, it doesn’t feel like a chore. And it doesn’t feel as onerous as a form.
‎

How do you know if you’re succeeding at building that vision?

Zeo Csoltai

There are a few things we look at. First, the whole company is my stakeholder and our ability to help them is directly tied to how comfortable they feel reaching out to us. We don’t track a metric for this, but we pay attention to how things feel and actively work to curate this sentiment in every interaction.

We also look at how many asks are coming into Triage. Are we seeing more or fewer requests than usual? The more issues we can discover proactively, the fewer asks we should see overtime. Honestly, I think if people don’t really know what I do or that I exist, that means they’re not having problems and I’m doing my job well.

How have you structured Asks in your TechOps team?

Zeo Csoltai

We run a weekly rotation, where someone from our team is in charge of fielding requests that come into Triage. We’re a team of four and everyone does frontline support, even our team lead. It’s really important to us that everyone is close to the problems our teammates are having. We don’t want anyone to forget what it’s like to field questions or get boxed into a specific niche, where they become known as the person that only fixes certain types of issues.

It is easy to support a regular rotation in Linear. We just created a schedule in incident.io and linked it to our Linear Triage inbox. From incident.io or Linear, you can see who is on frontline and who is scheduled next. We also always have a backup person on call in case we get an influx of requests and the main person on frontline needs help.

We also built our own helpbot using Linear’s GraphQL API, so that whenever someone sends us a request through Asks, the helpbot comments on the Linear issue with contextual information that helps us process the request, e.g. the user’s location, device, device state, etc. This helps us process requests much faster and with less back and forth.

Scaling internal support workflows

How did you manage the transition of moving 800 employees to send and manage requests with Linear Asks?

Stefan Christensen

For people already using Linear there was very little change to their daily workflow. We moved our team (TechOps) as well as Developer Experience and Site Reliability Engineering to Asks first. Quickly, other teams followed suit.

The magic of Asks for us is in how flexible it is in how teams can use it. Every single team that has requests coming into them internally uses it but can configure it slightly differently. Once we onboard a team to use Asks, they go ahead and set up the templates and automations that their team wants to use. The Asks configuration lives in a single settings page, so they can see how other teams use it and just copy the settings.

For example, some teams configure a #help-team channel in Slack with auto-creation, so that any message posted in the channel creates an Ask automatically. Other teams prefer to review questions in a Slack channel first and create asks manually, only when significant follow up is required. You can also enable it so that reacting with a ticket emoji (🎫) turns a Slack message into an ask.

Zeo Csoltai

Across the company, we didn’t hear about many issues either, since everyone is familiar with Slack and people picked up on how to make requests without much hand-holding. When there were questions that I couldn’t answer, the Linear team would respond quickly, often within a few hours.

From a change management perspective, the transition was extremely smooth and dare I say enjoyable.The actual switch was simple: you just need to configure a few things in settings and then type /invite @asks into a Slack channel.
‎

How do you see Asks helping you as you scale your teams?

Zeo Csoltai

It’s so helpful that we can keep everything in Linear. Every ask is recorded in Linear with a backlink to the Slack conversation and synced comment threads. We can more easily keep track of our work in Linear than in Slack, set reminders, and snooze issues to follow up on them in the future.

We now also have a history of issues in Linear that we can look at and use to improve how we work. We can track how often requests are coming in and how long they take to resolve, so we have concrete data to justify investing in better solutions for these types of issues. We can easily link issues together and just get a better sense of trends in requests. This will be even more important as we continue to grow and support more people.

Pleo’s experience centralizing internal requests transformed their organization’s workflows while keeping things human. Their TechOps team found that simple tools often work best: a single place to track work, seamless Slack integration, and the flexibility to let each team work their own way.  Learn more and sign up for a free trial on the Business plan to try Asks.

Why support multiple regions?

Initially, Linear’s infrastructure was concentrated in a single location - Google Cloud’s us-east1. While this configuration served most users well, it presented long-term challenges. We identified two primary reasons to diversify our data hosting locations.

First, having a separate region with a full instance of the Linear application makes future scaling simpler. If we can host some workspaces in a particular infrastructure deployment (application servers, databases, etc.), then we can add other regions behind the scenes in the future to avoid hitting scaling limits on, for instance, the size of our primary Postgres server.

From the early beginnings of Linear, we’ve sought to invest in our foundation preemptively, always having an eye on potential future bottlenecks we might encounter. This enables us to build out the best possible infrastructure and application framework, without being forced to urgently implement sub-par solutions to scaling issues when we’re hitting those bottlenecks. This is also why we decided to tackle multi-region infrastructure earlier than other companies would typically do.

Second, many larger European companies prefer to have their data hosted in Europe as it makes their compliance with GDPR easier. Specifically, some companies were worried about potentially entering their customer’s information into Linear and having that data be stored in the US.

Instead of sharding the database, we chose to replicate the entire Linear production deployment. This simplifies development as we can continue executing operations against a single database instance within one deployment, and any ancillary data stores are also regional by default with no additional logic needed. Further, we gain full segregation of regions we operate in. Problems in one region won’t affect others and we are able to improve the reliability and availability of the Linear app.

Multi-region architecture

From the start, the biggest requirement was that the region selection be invisible to users except when creating a workspace. In practice, this means we didn’t want to have a separate domain for our Europe region–you should be able to use our client (linear.app) and API (api.linear.app) via these primary domains, regardless of where your workspace is hosted. We also extended this requirement for integrations and internal tooling, to make the migration to multi-region seamless and require no code changes outside of our application. Every single feature in Linear should work, regardless of which region you are using.

We wanted to isolate all multi-region complexity to a few sub-systems and APIs. Engineers should never have to think about multi-region when developing functionality for the Linear backend or clients. They should be able to work in their local development environments and multi-region should simply work without any additions when their code is deployed into production.

We identified a simple architecture that would achieve this. Add a proxy in front of all traffic that would be able to authenticate requests, associate them with a user and their workspace, and route the request to the correct region:

We worked on this in three distinct phases: Terraforming our infrastructure, extracting authentication to a global service, and creating the proxy to route requests to the correct regions.

Terraforming our infrastructure

Before going multi-region, all of Linear’s infrastructure was manually managed in Google Cloud Platform. While we could have continued doing this, moving to infrastructure as code (in our case, Terraform) made spinning up a second region a lot easier.

We used Google Cloud’s Terraform export tooling to create an initial set of Terraform resources for our existing infrastructure. We removed everything that we knew we didn’t need for our main application to be deployed through Terraform: this was typically either resources that we hadn’t created manually in the first place, or global resources that wouldn’t be affected by the move to multi-region Linear.

Once we had the exported resources in place, we refactored the Terraform code into modules to support passing in the target region as a variable, as well as managing region-specific credentials and secrets that the application needs. We used this to build a staging environment too, which we used for testing infrastructure changes, as well as the proxy’s routing logic.

Extracting the authentication service

The proxy needed a way of routing network requests to the correct region based on the information contained within these requests. For this, we created a global authentication service, which would know about all user accounts, workspaces, and their associations. The auth service would be able to authenticate user accounts and work out the region of the workspace that the request was sent to.

To keep things as simple as possible, we chose to have a one-way data flow between the regional backend services and the authentication service. A regional service can call the authentication service directly, but if the authentication service wants a regional service to take an action, it schedules a background task using the Google Pub/Sub one-to-many pattern to run that task on all regions. This also means that the authentication service only responds to HTTP requests–it has no background task runner of its own–making deployment more straightforward. Even so, this was by far the largest step in the project, touching large parts of our codebase.

After prototyping a few different options for the internal API between the API service and the authentication service, we settled on GraphQL. It isn’t ideal for service to service communication, but we already had strong tooling for GraphQL in our codebase (our public API is GraphQL), and we used Zeus to generate a type-safe client for the API service to call the authentication service.

As we wanted to extract this gradually, the authentication service shares a database with the main backend service in our US region - which was the only region while we were working on this. When the logic was fully extracted, we split the tables from the authentication service and the other backend services into their own schemas, and set database permissions to guarantee that the authentication service cannot read or write regional data in the database, and vice versa: they must go via the calling conventions described above.

Most existing tables had a single owner. For instance, documents are only on the regional databases, as they are not needed for authentication. Some, however, needed to be split between the two services as they contained both application information as well as authentication information. For example, most workspace information and configuration is in the regional service, but some workspace settings relate to authentication, so the authentication service needs to store its own copy of that data. This means that we have pairs of tables in the authentication service and the regional services that have a 1:1 relationship: their data should always be in sync for shared fields, and we should never have a case where one system has a record but the other doesn’t.

To handle the data sync between the two systems, we settled on a mix of patterns that fit neatly into our existing codebase and conventions. There were three cases we needed to cover: creating, deleting, and updating records.

• When creating a shared record, we always create it in the authentication service first, and use the returned ID to create a corresponding record in the regional database. This is to ensure that any uniqueness constraints (such as on a workspace’s URL key) are applied globally first.
• Deleting works in the same way as creating records, with an additional fallback using Postgres triggers to create an audit log of deleted records, which accounts for records that are deleted due to a foreign key cascade from another table.
• For updating records, we already have a lot of logic around creating efficient updates for clients using our sync engine. We were able to reuse this to also schedule an asynchronous update to the authentication service with the new data, so that updates are easiest for developers: they just update the record in the regional service as normal.

To extract this in a gradual way, we first created the new tables with database triggers to copy over the columns we needed on create and update. This worked because we had a single region at the time, so we could allow the database users for each service to see each other’s tables, while using linting rules to ensure that our application code did not reach across service boundaries. Once we confirmed the syncing logic was working, we deleted the triggers and relied solely on the methods described above, even while still running in a single region.

Finally, we created a set of background tasks that would periodically walk through all tables that are synced with the authentication service. These tasks fetch a batch of records in the regional service, and use an internal API call to check that the authentication service has the corresponding batch of records, with no missing records on either side or differences in column values.

Routing requests and putting it all together

Since we already use Cloudflare Workers extensively, it was an easy decision to also use Cloudflare Workers for the proxy that routes requests. The worker extracts the relevant authentication information from a request, calls the authentication service to obtain a signed JWT and the target region, and then forwards the request to that region with the pre-signed header.

The Cloudflare Worker securely caches authentication signatures so that frequent requests from the same client don’t need to spend time on the round-trip between the Cloudflare worker and the authentication service, and instead the request can be directly routed to the correct region.

That is, our request flow went from users connecting directly to our API servers…

…to having this proxy in between:

Using Cloudflare Workers as a proxy like this is effective, even for long-running requests, because Cloudflare Workers that return a fetch request without modifying the response hand off to a more efficient code path. Linear uses WebSockets for our realtime sync, and so this is an important factor for us.

While we were building the authentication service, we were still using a single region, so we kept fallback code in our API service to authenticate the request directly if it was not pre-signed by the authentication service. Once we had the initial proxy in place, the rest of the work here was largely straightforward: logging and fixing requests that used this fallback, working through our existing library of integrations and adding code to handle each one in the API router, and ensuring internal tools could read from or write to both regions as necessary.

We rolled out a region selector that lets you choose what region to host new workspaces in, gated by a feature flag. This flag was initially available only to Linear engineers. Once we confirmed that the new region functioned without any problems, we gradually allowed everyone to create workspaces in the new region.

Wrapping up

This was a lot of work behind the scenes, and it touched authentication logic, which is always a sensitive part of any codebase. We built it in such a way that while there were of course bugs along the way, most of those were invisible to our users because we left the hard cut-overs as late as possible, making sure we had a fallback in place until we were confident that we had covered every corner case.

Linear now supports creating new workspaces in our European region. We set the default region in the workspace creation form based on your system timezone, to give the best experience for most people, while still allowing you to choose the region yourself. Workspaces in Europe have access to all Linear features, and always will.

We intend on adding support for existing workspaces that want to move to a different region later this year.

–

If you like how we build, apply to join our team. We’re hiring for backend and fullstack engineering roles.

Introducing a more cohesive, timeless UI

Karri Saarinen

Our environment plays an important role in the success of our projects. Among all the variables that compose our environment, the tooling we choose has a profound impact on the work we do, and, in the best case scenario, becomes a standard for how we build products. This is why we put so much care into even the tiniest details in Linear.

Today, we are revealing the result of many weeks of work redesigning Linear’s interface. We’ve adjusted the sidebar, tabs, headers, and panels to reduce visual noise, maintain visual alignment, and increase the hierarchy and density of navigation elements. These changes make space for Linear to evolve from a simple issue tracker into a purpose-built system for product development.

Read on to learn how we went from concept to redesign in a few weeks.

Concept exploration

Karri Saarinen

As I outlined in part one, there is never a good time to do a redesign. Normally these projects require a team of 5-7 people, but when I started seeing the need, our product and design team were busy with ongoing projects. We only had three product designers for the web and desktop platforms at the time, and even pulling just one of them into this project would have stalled several other workstreams. That wasn’t something I wanted to do.

An opportunity presented itself when I returned from my parental leave last summer. The company was functioning mostly without my direct involvement. This created a window of time where I could get started on the concept design myself. So, I opened Figma and began to explore.

The most pressing problems seemed to be:

1. Accommodating the product evolution
2. Enhancing the clarity of the application chrome and views
3. Improving the navigation

While I initially delved into all three areas, I eventually set aside navigation as it became clear the problems were complex and no longer solely a design issue. Any updates would require significant engineering work and change how users interacted with the product. This felt like an unnecessary risk and would expand the scope, so I made the call to focus purely on a redesign.

Even when doing concept work, you often need to focus your efforts. The design concept should feel like an exciting evolution of the product. A redesign should not completely disassemble the product to its atomic parts. While you might have ambitious goals, you also have to be realistic and manage risks.

I started to focus on this inverted L-shape. It’s the global chrome of the application that controls the content in the main view.

I didn’t adhere to a specific method during the exploration phase, but typically, each day I designed a complete set of screens and flows. One day might be dedicated to designing the Inbox view, while the next day I could focus on the roadmap and projects. Other days, I explored upcoming product features. During this process, I experimented with different iterations of the sidebar, visual styles, and colors, and then linked the screens together as a prototype to assess their functionality.

Through this process, I generated hundreds of screens and was able to narrow down a few major directions that resonated most. Around this time, I began sharing the screens with other designers and people within the company to gather feedback and additional insights.

Ultimately, we settled on the main design direction, and I created a few views to showcase it.

The concept had taken shape. Now, it was time to bring it to life.

From a concept to prototype

Yann-Edern Gillet

We started with the concept design Karri had originally imagined, but it wasn’t fully figured out and needed some additional design work. We didn’t know how we would bridge the previous UI design with the new style or if the new design could support all of our application states and options. We were able to make some changes off the bat, such as updating the color system, while other changes had to be punted to later on, such as the different headers you come across while navigating the app.

To help spark conversation and speed up decisions, we had two people tackle two different design parts of the project simultaneously. While I was building out the prototypes, I referenced example screens that showed the new visual language so I stayed true to the north star. I kept asking myself, “How real could this concept car be?” and then pushed during the tests to get as close to it as possible.

What tests did we run before getting into implementation?

Yann-Edern Gillet

It’s easy for the scope of UI redesign projects to blow up. Before we got too far down any one path, we needed to get some confidence on the right option to keep everyone focused. So we ran some stress tests (or crash tests if you want to be dramatic) before going into implementation and iterating with engineers. We tested three main focus areas: the environment, the appearance, and the hierarchy.

1. Environment

Yann-Edern Gillet

Our app runs on Electron, so our navigation needed to work not just on macOS and Windows as a native app but also in any browser. That meant that previous/next navigation buttons, history, and tabs needed to be easily removable to work with browsers. We tested a lot of options, from very condensed to more spacious configurations. I often relied on Apple standards, which also helped get close to the feeling of a native app.

I also spent time aligning labels, icons, and buttons, both vertically and horizontally in the sidebar and tabs. It was definitely a challenge given the amount of UI elements we have on this tiny surface. This part of the redesign isn’t something you’ll immediately see but rather something that you’ll feel after a few minutes of using the app.

2. Appearance

Yann-Edern Gillet

Linear is compatible with both light and dark modes, and we also provide a custom theme generator for users who want a unique look for their tools.

Karri mostly worked with opacities of black and white during his explorations, which really helped him get results quickly and helped me understand the relationship he had in mind between the elements and their respective elevation and hierarchy. As our system relied on a set of variables, I worked with Andreas on our software engineering team to polish and iterate on both the core variables and the operations we apply to them to generate our aliases for surfaces, texts, icons, and controls.

Andreas Eldh

A while back, we rebuilt the system for generating custom themes in Linear, using the LCH color space instead of HSL. LCH has the benefit that it’s perpetually uniform, meaning a red and a yellow color with lightness 50 will appear roughly equally light to the human eye. This makes it possible to generate more consistently good-looking themes, regardless of which base colors are used.

We never fully rolled out this system, though. Custom themes in Linear kept using an HSL-based system to generate theme colors and the new system was only used for surfaces like elevated and translucent parts of Linear.

With this UI refresh, we started using the new theme generation system not only for custom themes but also for the main light and dark themes. So, instead of having to define 98 specific variables for each theme, we defined three: base color, accent color, and contrast.

Yes, the theme generation system also supports a contrast variable which defines how contrasty a theme should be. This allows us to automatically include super high-contrast themes for users who need it for accessibility reasons.

We kept using LCH for our theme generation, as it is one of the closest color spaces to the human eye and allowed us to deal with different elevations for our surfaces (e.g. background, foreground, panels, dialogs, and modals).

We migrated the light and dark themes to adopt the same theme generation, so it was easier for Yann and me to share the same language and iterate.

3. Hierarchy

Yann-Edern Gillet

Linear relies on a set of structured layouts that support the navigation elements and content. It integrates additional headers to store filters and display options, side panels to display meta properties, as well as the actual display: list, board, timeline, split, and fullscreen.

When I joined the project, Karri had already gathered most of the app’s views and their respective states, so I was able to run all of my tests quite effectively. I mostly worked by type of view (list, board, split, etc.) as I found it easier to focus and ensure that every decision worked in all cases.

What milestones did we use?

Yann-Edern Gillet

We divided the project into five milestones:

1. Stress tests: Following the series of explorations made in November 2023, we tested if the direction felt right in the main views of Linear: Inbox, Triage, My Issues, Issues List, Project, Cycles, Roadmap, Search.
2. Behavior definitions: As the direction was refined, we documented and defined the behaviors of the main components of the app: sidebar, tabs, app headers, and view headers.
3. Sidebar and chrome refresh: We implemented the first bits of the refresh on the sidebar, tabs, and view headers. We also improved the appearance and contrast of our theme for light and dark modes. We used a feature flag to allow for internal testing at this stage.
4. Private beta: We started rolling out the new design in Private beta to get initial feedback. Once we felt comfortable, we began rolling out the changes to a percentage of workspaces each day.
5. GA: We released the new UI to all workspaces.

We also have to give a shoutout to all the friends of Linear for their feedback throughout the entire process.

How did we prioritize the refresh work with other projects?

Karri Saarinen

It’s always better to do a redesign quickly. Otherwise, you will block almost every project and create design debt as newly added features and screens need to be redesigned very soon after they are created. Once we had the initial direction in place, we focused a small team on the redesign: Romain and Yann led the efforts with contributions from Andreas, Adrien, and the full Linear design team.

Romain Cascino

We knew that in order to move quickly and ship our work successfully, we needed to dedicate time and team resources to it. We couldn’t treat it as a side project. All in all, the redesign project took about six weeks to complete.

We kicked off the project at an offsite in Athens earlier this year, where we tackled a big chunk of the initial work, most notably on the sidebar, tabs, and different levels of headers.

Each afternoon, we divided the coding portions into groups of two engineers while designers iterated on other parts of the project, building a pipeline for us to work from. This daily back-and-forth between designers and engineers helped us get the first working version of the new UI by the end of the week. The result of that week’s work was added to a feature flag that allowed everyone else at Linear to start testing the new UI.

Yann-Edern Gillet

Next, we worked on the Inbox. We redesigned notifications to be more centered around the notification type and emphasized the faces of your teammates. We simplified headers and filters to improve the overall navigation. We also reviewed comments alignments and harmonized the look of our buttons with the new themes.

We continued polishing the new color theme with Andreas to increase the overall contrast and return to a more neutral and timeless appearance. The latter was achieved by limiting how much chrome (blue in our case) was used in the calculations applied to our color system. The contrast of the content has also been improved by making our text and neutral icons darker in light mode and lighter in dark mode.

We started using Inter Display to add more expression to our headings while maintaining their readability and kept using regular Inter for the rest of the text elements.

How did the wider Linear team help test the new UI?

Romain Cascino

We dogfood all our new features before releasing them publicly to ensure everything works and feels as it should. After refining the design for about a week after the offsite, we turned on the feature internally and invited anyone at the company to try it out and give us feedback.

It was crucial to get the maximum amount of feedback from the different teams (Product, Customer Success, Sales, Brand, etc.) as they’re more inclined to use specific parts of the app to get their job done. For example, Product and Sales teams are often looking at a roadmap view, project leads frequently use documents, while the Customer Experience team is often filing issues to Triage and working out of issue views in select teams.

We also added a toggle to our internal developer toolbar, as a shortcut to quickly switch the new UI feature flag on or off, which helped the team to compare different parts of the app more easily.

How did we manage feedback and questions across the company during final testing?

Yann-Edern Gillet

We wanted to make sure all the updates could easily be found in one place as we moved along, so we created a dedicated Slack channel linked to the project in Linear. Discussions and questions on our weekly project updates in Slack automatically synced to Linear, so we didn’t lose any context between the tools or teams.

Welcome to the new Linear

You can explore the new UI in your Linear workspace today. Let us know what you think on Twitter, LinkedIn, or in our Slack community.

If you like how we build, apply to join our team. We’re hiring for product, design, and brand roles.

The challenges start from the fact that it’s never a good time to do a redesign. It’s hard to make it a priority. It’s difficult to calculate the ROI on it. And if you run your product with A/B testing, every global redesign will tank the metrics in the short term. Teams get furious and try to push back as they don’t want to see their product surfaces changed outside of their control.

However painful it might be, there is a real need for redesigns, and your product experience suffers if you never do it.

Design debt is real

The real need for redesigns often comes when you have created a successful product and it has evolved with the market and users over time. This is also the case with Linear.

We ship small changes daily, and something major almost every week. Every year, it’s almost like a new product. This incremental way of building the product is hugely beneficial, and often necessary — though it unbalances the overall design, and leads to design debt. Each new capability adds stress on the product’s existing surfaces for which it was initially designed. Functionality no longer fits in a coherent way. It needs to be rebalanced and rethought.

I believe this debt has to be paid if you aim to keep your product experience excellent. If your product evolves fast, you should be paying this debt every 2-3 years. The longer you wait and the more successful your product becomes, the more you will have to untangle.

Slowly the user sentiment and perception might start turning negative and you might start looking like a dinosaur incumbent. This leaves an opportunity for some nimbler player to come along and compete in your market. Companies often try to address this with brand refreshes, but if you don’t refresh the product, nothing truly changes about the experience.

While the design debt often happens in small increments, it’s best to be paid in larger sweeps. This goes against the common wisdom in engineering where complete code rewrites are avoided. The difference is that on the engineering side, a modular or incremental way of working can work as the technical implementation is not really visible. Whereas the product experience is holistic and visual. You cannot predict which path the user takes. If you update just one module or view at a time, the overall experience becomes more disjointed. Secondly, if your goal is to reset and rebalance the whole product UI and experience, you have to consider all the needs simultaneously. An incremental approach doesn’t let you do that.

There needs to be a major reset on which you can leap forward.

CEOs & leadership need to be behind the change

A real redesign can only happen when there is a reset on the design across the whole product. That’s why I’ve never seen redesigns successfully executed without the CEO behind it. While design might have a seat at the table generally, they are usually not able to convince everyone around that table. Only the CEO can push through all the excuses and give the latitude to a project touching all of the surfaces the product needs.

The CEO’s interest is not only critical because it gives the project the air cover it needs, it also gets them and many other execs involved and makes sure they take it seriously. While leadership might not have direct input on the design itself, they have a perspective on where the company is headed, so you can proverbially skate to where the puck is going.

The way to get the CEO involved is to tie a design reset into a larger company shift or directional change. For example, if a company is looking at a new product, or major new feature, a redesign project can be a way to imagine how it might look or feel. This can be the justification for why you need to spin up the team (and at the same time, you can make a case for updating the rest of the product experience).

For the leadership team, this design project can be the initial momentum they need to galvanize the company and steer it into a new direction. Organizations are often quite stuck in their views and ways of doing things, making them less enthusiastic about something new. When I was at Airbnb, the mobile redesign project was a way to shift the company to become mobile-first. It set the tone and got the message across to the whole company that mobile was happening and that it was happening now. While it looks like an obvious change in hindsight, there were many arguments against it at the time and it took a lot of convincing. Switching to think about mobile meant the design and features had to be rethought to work in that platform.

While Linear is a smaller and younger company, we’re also undergoing a shift. The product vision has widened from a simple issue tracker to a purpose-built system for product development. We are now moving into planning workflows that naturally come before the building or execution phase of building products. This product evolution creates new future needs from the product design, and we have to make space for it.

From concept to yes

When you realize that a design reset is needed for your product, how do you actually get started with the project? You start with a standalone team to explore the new concept design and create something the company can rally around.

The auto industry has a practice of building “concept cars”, where they explore the next version of the car freely and boldly without considering practicality. A concept car sets the direction, but usually is not expected to land in production because it’s too impractical or costly to manufacture.

Calling it a concept is important, especially at the start. A secret I’ve learned is that when you tell people a design is a “concept” or “conceptual” it makes it less likely that the idea is attacked from whatever perspective they hold or problems they see with it. The concept is not perceived as real, but something that can be entertained. By bringing leaders or even teams along with the concept iterations, it starts to solidify the new direction in their mind, eventually becoming more and more familiar. That’s the power of visual design.

It becomes something easier and easier to say yes to, not something to say no to.

But eventually the concept has to become real in some way. How did we do this for Linear? We cover that in Part II.

The minimum viable product, as many founders know it, doesn’t reflect the reality of how products get built today.

Building something valuable is no longer about validating a novel idea as fast as possible. Instead, the modern MVP exercise is about building a version of an idea that is different from and better than what exists today. Most of us aren’t building for a net-new market. Rather, we’re finding opportunities to improve existing categories. We need an MVP concept that helps founders and product leaders iterate on their early ideas to compete in an existing market.

When we started to build our MVP for Linear, we spent a lot of time talking to users, narrowed our audience, and tested what we were building. And it taught us some important lessons about our product (and building great products in general).

Below, I’ll discuss why building in today’s market requires an updated concept of the MVP, the importance of narrowing who you’re building for, the power of strategically using your waitlist, and some indicators you’ll see when you’ve found early product market fit.

The MVP is a journey, not one moment in time

The MVP as a practice of building a hacky product as quickly and cheaply as possible to validate the product does no longer work. Many product categories are already saturated with a variety of alternatives, and to truly test the viability of any new idea you need to build something that is substantially better.

The MVP as we knew it before

In 2011, Eric Reis described the MVP in his book The Lean Startup as “the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

He conveyed that if you have an idea and you don’t know if it will succeed at market, you need to quickly build something to validate it. This validation could take many forms, such as a prototype, pamphlets describing your idea, or a commitment form. This worked years ago when you needed quick validation for a novel idea or service concept and there weren’t as many existing variations of that idea.

For example, Airbnb wanted to build a service that relied on people being comfortable spending the night at a stranger’s house. When they started in 2009, it wasn’t obvious if people were ready for this. Today, it’s obvious that it works, so they wouldn’t need to validate the idea. A similar analogy works for Lyft when they started exploring ridesharing as a concept.

The MVP as it exists today

Today, the MVP is no longer about validating a novel idea as quickly as possible. Rather, its aim is to create a compelling product that draws in the early users in order to gather feedback that you then use to sharpen the product into the best version of many.

If you look at successful companies that have IPO’d in the recent years–Zoom, Slack, TikTok, Snowflake, Robinhood–you see examples not of novel ideas, but of these highly-refined ideas.

Since many of us are building in a crowded market, the bar for a competitive, public-ready MVP is much higher than the MVP for a novel idea, since users have options. To get to this high bar, we have to spend more time refining the initial version.

Founders and product leaders must refine their visions and audiences and relentlessly iterate based on user feedback to build great products. The MVP process then becomes a journey to figure out if there’s something in an existing category the market wants improved.

Let’s jump over the regular startup journey that you might take today when building a new product:

• You start with the idea on how you want to improve on existing products in a category.
• You build your first prototype.
• You iterate with your vision and based on feedback from early users.
• You get an inkling of product market fit and traction.
• Optional: You start fundraising (with demonstrable traction).
• Optional: You scale your team, improve the product, and go to market.

The role of the MVP journey is to demonstrate your idea has potential in the market, and – if you’re not bootstrapping the journey yourself – get your startup ready to raise funds. And you have to do this with limited resources.

The importance of narrowing your users

The first key lesson we learned during our MVP process was to scope down who we were building for as much as possible.

In today’s landscape, you’re likely competing against many other products. To win, you have to build a product that provides more value to your users than your competition does.

To be able to do this with limited resources, you must scope down your audience (and thus your ambitions) as much as possible to make competing easier, and aim to solve the problems of specific people.

When we started Linear, our vision was to become the standard of how software is built. This is not really something you can expect to do during your early startup journey, let alone in an MVP. But you should demonstrate you have the ability to achieve your bigger vision via your early bets. We chose to do this by focusing on IC’s at small startups. We started with the smallest atomic unit of work they actually needed help with: issue tracking.

Something that helped immensely was that we were our own ideal customer profile. We could build a product for ourselves. We knew we wanted our product to demonstrate three values:

1. It should be as fast as possible (local data storage, no page reloads, available offline).
2. It should be modern (keyboard shortcuts, command menu, contextual menus).
3. It should be multiplayer (real-time sync and teammates presence).

Once we had built something for ourselves that we thought was valuable, we needed real user feedback. This is an extremely important step of the MVP journey—don’t underestimate it. Engage with users, have conversations with real people, gather their insights and evolve from it.

The power of the waitlist

After the prototyping stage and getting some small group feedback from early users, you need to build awareness around your product to get a bigger pool of people interested in your product and ready to try it out. One way to achieve this is to build a waitlist of target users, invite them in small groups, learn from what they do with the product, interview them, and get feedback and insight into shortcomings.

The second lesson we learned: The waitlist is a great tool to maintain the narrow focus and bring in the right kind of early adopters.

How to build your waitlist

To build your pool of beta users to learn from, you need some mechanism for amassing a waitlist with a large variety of users or a smaller, targeted list with just the right people.

There are a few ways to go about this, but the quickest (if you’re able) is to leverage your social following. If you don’t already have a social platform to build from, partnering with leaders in your personal network, investors, and community influencers can help you reach the right people. The goal is to create a list of people who are interested in what you’re building, and who you can pressure test your product against to refine it into something great.

Remember, you’re likely not building a revolutionary or novel product. You’re unlikely to go viral with your announcement, so you need a network of people who understand the “why” behind your product to help spread the word to drive people to sign up. Any product category has many people who are frustrated with the existing tools or ways of working. Ideally you find and are able to reach out to those people.

How to use your waitlist to build a high-impact product

Once you have a bunch of people on your waitlist, you need to invite the right users at each stage of your iteration. You want to invite people who are likely to be happy with the limited set of features you’ve built so far. Otherwise, they’ll churn straight away and you’ll learn nothing.

To do this, we asked people a few basic questions when they signed up onto our waitlist:

• What’s the size of your company?
• What’s your role?
• What project management solution are you currently using?
• What version control system are you using?
• Why do you want to try Linear?
• What’s your pet peeve with current solutions?

We only had a GitHub integration to start, so we filtered the responses to make sure we were only inviting people who could actually use the product. We then handpicked founders of small companies with pet peeves we were already addressing. Founders are usually happy to chat and are also more forgiving if functionality is missing (if they believe in the direction of the product). This gave us a good initial user set that didn’t churn, and that we could have frequent conversations with to understand the shortcomings of our prototype.

Then, you start addressing the feedback of your early users and prioritize functionality accordingly. When your users stop asking for new features, this is a good indication it’s time to pull in more people from the waitlist and expand your target segment a bit as well.

From here, you repeat the cycle, inviting more users from new target audiences, learning from how they use the product, and incorporating their feedback. You effectively turn your waitlist into a more refined product that caters to an ever growing audience.

Indicators you’re ready for public launch

Knowing you’re ready to launch your product publicly comes down to testing user sentiment and trusting your gut.

Here are three ways to go about testing user sentiment:

1. Meet with users via Slack, Zoom, or in person and figure out how happy they are
2. Use a product-market fit questionnaire (and ask how they would feel if they suddenly couldn’t use your product tomorrow)
3. Ask users to pay (the ultimate test)

To test willingness to pay, we started with a pay-if-you-want model. Users didn’t have to pay to use Linear during beta, but if they went into their settings, they found a “Friends of Linear” plan offering nothing more than our gratitude.

After using these methods for a year, we gained the confidence we needed to launch publicly (and then asked users to subscribe to a real paid plan).

Public launch and beyond

Once you’ve demonstrated value to and incorporated the feedback from your early users, you’re probably ready to open up access and launch publicly. You can continue to use this MVP journey model as your product grows to test new features and offering out with existing customers or new user segments.

To recap:

• Narrow down your initial audience and build for them: Figure out who you’re building the product for and make the target audience as small as possible before expanding.
• Build and leverage your waitlist: The waitlist is the grinding stone with which you can sharpen your idea into something truly valuable that will succeed at market, so use it effectively.
• Trust your gut and validate demand with your users: Talk, talk, talk to your users and find out how invested in the product they are (and if they’d be willing to pay)

And, of course, I’m available on X @artman for questions and thoughts.

Today, your tooling is the place most of your team’s collaboration and work happens. What tools you choose–and how well your team truly embraces the functionality and potential of them–determines how well your organization operates.

Thankfully, leaders like Andrew Mason, CEO at Descript, are out there creating comprehensive resources for their teams, including a great breakdown of how to use Linear as your work operating system.

For the unfamiliar, Descript is an all-in-one video editing platform that’s been building on Linear since December 2020. Over the years, we’ve helped them uplevel their engineering workflows, and drive deeper collaboration between different functional teams.

As Andrew expands on in the re-printed guide below, the superpower of a great collaboration tool isn’t really about the tool at all. Rather, it’s about the ways you can free up your time to focus on more satisfying work (in turn making your team more successful and happier to work together).

Thanks again to Andrew for creating such a great resource for the teams at Descript, and for letting us republish it here for the wider Linear community.

Descript’s Linear best practices

At Descript, Linear is core to the way we work internally, and if you use it effectively, should be your central work operating system.

But, like all tooling changes, getting up to speed with it and helping our engineering, product, design, and business teams learn how to best leverage it has taken some time and standardization. This is less a comment on Linear and more just the reality of folks learning a new way to do project and task management.

It’s worth putting in the time to learn though, because, as a company, these are the benefits we get from using Linear effectively as a collaboration tool:

• Less time looking for things (Did someone file a ticket for X already? Where is that bug?)
• Less fielding questions from a zillion people like ”What’s the status of X?” - just look it up in Linear
• Less interruptive use of Slack for things that should really be handled as tickets (distinction touched on below)
• A framework for you to prioritize your work and decide what you can/can’t commit to, so you don’t get overwhelmed. And you automatically communicate those prioritization decisions to everyone and automatically set expectations

Below are the Linear best practices encouraged across all the teams at Descript.

How to get more efficient with Linear

Linear has a range of features that help you work faster and smarter across all your workflows, including keyboard shortcuts, quick screen capture with Raycast, and their Slack integration.

If you spend a few minutes at the beginning of your Linear journey understanding how to navigate these shortcuts, it’ll save you a ton of time down the road.

Learn the keyboard shortcuts

You’re going to spend a lot of time in Linear, but you’ll spend a lot less if you invest in learning the built-in keyboard shortcuts. Linear is probably the most tricked-out with keyboard shortcuts app I’ve ever used. Here are some of my favorites:

• command + k to open a list of commands specific to the item you’re on (e.g. moving an issue to another project, changing the assignee or followers, changing status, etc.).
• g and then various keys to quickly navigate to My Issues, Projects, etc.
• o and then p to search projects, or t to switch teams, or d to open project documents
• j and k to navigate up and down list items

There are also a bunch of single-key keyboard shortcuts (c to create issue, a to assign to user, l to add label, p to assign priority, and f to filter are particularly helpful). You can access them for whatever the active item is you have selected. If it takes some time to remember them all it’s ok (I’m still getting them into my muscle memory).

Send saved Slack messages to Linear

Managing two inboxes is hard. Here are two ways to use Zapier to stop flipping between multiple inboxes and merge your Slack and Linear to-dos into your Linear inbox.

The quick improvement

The end result of this flow is to have your saved messages in Slack automatically added to your Linear inbox with the original message context. This way, you can easily follow up on tasks and messages at a future date.

Here are the steps:

• Go to your Zapier account and create a new Zap
• For trigger event, select Slack and set the event to “save message” (make sure you’ve connected your work Slack account)
• For the action, find Linear and set the event to create an issue (sign into your Linear account before continuing)
• Tell Zapier what team to create the issue in and what info you want to populate the issue title and description with
  • For title, I use username:(the description text)
  • For description, I repeat the message text and include a markdown link to the original message for reference later

The powered-up version

If you want to take it to the next level, you can also have chatGPT summarize the description of the message. This is the workflow I use every day:

• Building on the zap above, add chatGPT to the flow before the Linear issue creation step
• For the action, have chatGPT summarize the Slack message into 12 words or less
• Now, in the Linear action step, populate your issue description with the summarized version. Include the markdown link back to Slack (I use the same title formatting as before).
• Set the issue status as triaged to yourself

Use Raycast for quick capture

Another key requirement of any task management system is a way to quickly capture an emergent issue. That way, you’re never left trying to store this stuff in your brain.

Unlike many native task management apps, Linear doesn’t have a quick-entry global system hotkey type of thing. Instead, you can use Raycast, a free system-wide command bar “Spotlight on Steroids”.

Install the Linear extension, and then bind the create issue for myself action to the hotkey command + space + shift.

How to customize Linear to your work and focus areas

Linear doesn’t just offer features to help you customize your shortcuts. It also gives you ways to customize your inbox and views to stay focused on your highest-priority work.

Configure My Issues to only contain what’s actionable

A task management system should give you a view of all your issues. It should reduce the chaos to something orderly and actionable. My Issues (g and then m) is how Linear does this.

To make My Issues more manageable, I recommend adding a few filters (which Linear remembers until you change them):

• Don’t show Project Status = Done or Backlog
• Don’t show issues that are blocked.
• Try to keep In progress issues to only 1-2 issues at a time*

*I’m sure this will vary depending on your role, but the point is, it should only be the stuff that you’re actively working on, and everything else should be in Todo.

My Issues in a more focused state w/ Status and blocking filters.

Use a saved View to promote tasks from Backlog to Todo

The My Issues view is intended to be the spot where you’ll spend most of your time (think of it as your home view). Since you should have backlog issues filtered out of your My Issues view (and you want to avoid changing view filters back and forth), I recommend saving/favoriting a separate view for this to see all open issues sitting in your backlog so you can promote them to Todo as needed.

You can use the view I use, which is called Open by Project. This view groups issues by the project.

At the beginning of the week, I’ll open this view and do a pass-through on every issue, deleting stuff that’s no longer relevant or needed.

How to handle issues effectively

As we do more and more work in Linear, the number of issues we create and interact with can become unwieldy. To avoid creating a bunch of noise for yourself and your teammates, there are a few hygiene best practices to keep on top of.

Use the Todo/Backlog statuses to organize active work

Marking an issue status as Todo means you plan to start it in the next week or so. Everything else should be in the Backlog.

The first thing you do each week should be to go through all the issues assigned to you in your backlog and promote a manageable number to Todo.

This will help you prioritize. It will also set expectations with your collaborators on when you plan to actively work on an issue. For example, the Backlog status communicates it’s not coming soon. Meanwhile, Todo shows it’s imminent.

Use Issue Blocking and Reminders to focus My Issues

Sometimes you’ll have a task that’s In Progress or you otherwise want to keep it in My Issues, but you can’t actually act on it. This is just creating cognitive noise. To narrow my focus, there are two things I do:

1. If I’m blocked by another issue, I mark the issue as Is blocked by (command K → Blocked) and filter blocked issues from the list.
2. If I’m not yet ready to work on it, I move the issue to my Backlog with a reminder to follow up at a future time (H shortcut).

Set a Priority instead of a Due Date to rank issues

Sometimes due dates are real (like when there’s an external dependency), but often we’re just using them to stack rank work. If this is the case, try using priorities instead.

When you’re going through your backlog, promote the highest-priority items — it’s that simple. This will save you from the common and demotivating state of having a zillion overdue tasks. Try to only use due dates when they’re real.

How to collaborate in Linear

The main goal of using Linear as our work operating system is to break down silos across teams and make it easier to do great work together. Here are a few of the best practices to follow to make it easier (and joyful) to build with your teammates.

When you assign issues, put them in Triage

When you assign new issues to someone, putting them directly into Todo is tantamount to declaring that they’ll be working on it this week. So use your judgment, but generally it’s better to mark issues as Triage, which is a status that tells the assignee that they need to process/assign a status.

Use “Verify” when done with issues

Oftentimes, we need to have someone review and sign off on work before it’s truly done. To reflect this review stage, we created a custom workflow status in Linear called verify before the Done status. Rather than marking a task as done, use verify to flag that it’s ready to review and then assign it to your teammate.

Stay on top of your Inbox

For this all to work, it’s paramount others can rely on you to read new comments and see new issues as they come in. Treat your Linear Inbox the way you treat Slack (and the way, once upon a time, we all treated email): Keep it open and process it at the same rate you would process things with those tools.

When people feel the need to ping you on Slack to get feedback on a comment left in Linear, it’s a pretty good signal that you’ve got work to do here!

To tame your Linear Inbox, use general Inbox Zero processing principles (i.e. clear out your notifications as you’re reading them.) Use the E keyboard shortcut to quickly archive an Inbox notification, Shift + H to snooze an issue, and use J and K to navigate up and down the list.

Be intentional about when you start a Slack thread vs assign an issue in Linear

As we streamline how we work and communicate as a team, we need to be more intentional about what kinds of communication goes in which channel.

• Use Linear if it’s a task that someone needs to complete (distinct outcome)
• Use Slack if it’s a discussion without a “completion” state (fuzzy outcome) or if it involves a lot of context sharing between teams.

Take what works and leave the rest

The principles throughout are good hygiene for any team using Linear that wants to improve their day-to-day workflows.

Learning a new way of working always takes some intentional effort, but Linear helps us spend less time answering tons of questions and searching our systems for information, and more time working on our actual product.

As part of the disaster recovery process, we took Linear offline for one hour, impacting all users. We restored over 99% of lost data within 36h of the start of the incident. But, in some cases we couldn’t restore data due to conflicts.

A database migration caused the incident, which accidentally deleted data from production servers. We put Linear into maintenance mode and reverted the database to a backup taken a few hours prior. We immediately began restoring missing data, which took two days to complete.

We’re deeply sorry for the inconvenience and frustration this incident caused for our customers. Reliability and security are top priorities for us at Linear and last week we fell short from our promise to our users and ourselves. In learning from this incident, we’ll improve our tools and processes to prevent such mistakes and recover more quickly.

Below is a timeline of the incident, and more details around its cause and the ultimate fix.

Incident timeline

All times are in Coordinated Universal Time (UTC)

January 24

• 04:47: Full database backup completed (pre-incident).
• 07:01: Merge of migration that caused data loss.
• 07:20: Migration completed.
• 07:52: Strange notifications noticed in the app, engineering and support notified to check other reports.
• 08:10: Critical incident initiated with Zoom call to investigate, additional engineers paged.
• 08:36: Update posted to Linear status page and shared on X: “Investigating data access issues“
• 09:20: Additional update posted on Linear status site.
• 09:56: Linear put in maintenance mode to prevent further changes and recover from backup.
• 10:48: Linear access restored with the database backup from 04:47.
• 11:09: Status site updated to monitoring.
• 11:30: Restoration started for all data entered between 04:47 and 09:56.
• 13:50: Emails sent to customers who had created workspaces between 04:47 and 09:56 asking them to recreate their workspace as we could not rebuild it.
• 15:35: Emails sent to affected users and workspace administrators with information about the incident and restoration process.

January 25

• 14:00: Data recovery page published to application settings and shared with admins via email.
• 14:25: Bug fixed with the data recovery page by forcing clients to refresh (which then overloaded our API and caused application loading issues).
• 16:40: Dry-runs of the restoration process started.
• 17:49: Workspace data restoration started.
• 19:48: 98% of affected workspaces restored.
• 23:20: 99% of affected workspaces restored.

January 26

• 07:37: Restoration for all workspaces except one completed.
• 08:39: Restoration of final workspace completed.

What happened

Linear uses trunk-based development and changes land in production on an ongoing basis as part of new feature development. We gate execution using feature flags.

While developing new features, we created two new tables in the production database. We also filled these tables with data from existing tables in preparation for rolling out the new functionality. We considered the data faulty and planned a new migration to update it. We had to drop the existing data in the new tables as part of that migration.

A pull request was created, reviewed and accepted that added a database migration that first dropped data in the new tables. Then, it copied data from existing tables to the new ones. The new tables were only used by engineers developing the feature and not used by actual users yet, so we deemed deletion safe. We used the following SQL statement for data deletion:

TRUNCATE TABLE <new_table> CASCADE;

The intention here was to delete any data in the new table as well as any rows of test data with foreign keys pointing to the new table. However, CASCADE simply truncates the entire contents of any tables that have foreign keys to the table.

This caused the full deletion of production data for issue and document descriptions, comments, notifications, favorites, and reactions.

When pull requests include migration, we do include CI warnings for dangerous migrations, like large indexing operations. The pull request was tested locally and reviewed by multiple engineers but the cascade operation was missed by both author and peer reviewers.

Outage and investigation

With the data deleted, symptoms weren’t immediately visible to end-users, including our own team. Linear stores most workspace data in a local client cache, and there’s also a database cache which sits in front of the Postgres database. Our sync engine updates this database cache programmatically to add and remove “sync” packets describing database mutations.

As this is part of the application logic, deleting rows directly from the database won’t create sync packets and thus won’t update the cache or clients. This meant users would continue to see and receive data for the deleted tables in the Postgres database until they reloaded their local data and the backend cache was invalidated, which usually takes 24 hours. Data caching was also one of the primary reasons the problem was missed in local development.

The data loss went unnoticed for 30 minutes due to the multiple layers of cache involved. It was possible to reload the Linear client and not see any visible problems at all. Only mutations caused errors due to underlying database entities no longer existing.

The outage first became apparent with notifications, as it is one of our most frequently updated tables, with notifications created and deleted based on many events. There is always a small lag in synchronization state between the backend and its clients. We often see the client trying to update deleted entities and see these as a synchronization lag warning. As an expected part of the system these did not count towards error metrics or trigger alert monitors.

An engineer started an internal incident to investigate when they saw problems while using their own notification inbox. User reports confirmed the synchronization issues that the problems pointed to. This happened around 30 minutes after the migration. This caused a critical incident to start and personnel to be paged.

The cause wasn’t clear at first due to the caching. But, a spike in warnings from clients to the notificationUpdate GraphQL endpoint offered a clue about when the problem started. The faulty commit was quickly correlated. Our engineers verified that the commit did cause similar symptoms when run locally. Shortly thereafter, an engineer found all notifications had been deleted in their local database. At this point, production data was checked and we found multiple tables had been entirely deleted.

Linear was promptly taken into maintenance mode, which blocks any updates and presents a maintenance screen for all users. We created a new backup to capture all the sync packets created up until that point. Then the database was restored from the latest backup from before the faulty migration ran.

Linear takes daily full backups in addition to having point-in-time recovery. The last backup was taken at 04:47 UTC and the bad commit landed at 07:01 UTC. With point-in-time recovery engineering could have restored services to the state they were in at 07:01. However, the engineering team had never tested point-in-time recovery, nor had engineering developed tooling to quickly restore the database using point-in-time recovery, so that option wasn’t considered. Restoring from a full backup was a frequently tested procedure and thus executed to get the application up and running as quickly as possible, while initially losing more data than point-in-time recovery.

After backup restoration was completed, Linear was brought back online again with data as of the 04:47 UTC backup.

The service recovered somewhat quickly, with intermittent problems affecting synchronization. The sync service uses a cursor to get changes not yet sent to clients and caches this cursor in Redis. However, the code did not account for the ID moving backwards, as was the case with a full database restore. Resetting the cache and restarting the sync service resolved these issues.

Data restoration

After Linear was back online, our engineering team started restoring data that was affected by the rollback.

As mentioned earlier, Linear’s realtime sync engine keeps a log of every change that affects entities and properties in a form of sync packet (“action”) that is sent to clients. This includes the type of action taken (insert, update, archive, delete), a snapshot of the entire entity after the change, and a delta of properties changed in case of an update action. Each change also contains an actor, usually the user that made the change.

We used these actions to find all users affected by changes in the outage. We then contacted them to tell them about the problem and when data would be restored. We also sent an email to all administrators of the affected workspaces in the interest of transparency and awareness.

Part of our team implemented a new settings page to show administrators the progress of the restoration procedure.This page also listed any lost data and errors during restoration so they could then fix their data, if needed.

At the same time, we added a restoration script to run through the lost actions for each workspace. It reapplied the actions by users, integrations, API calls, and Linear automations. The script was first executed as a dry-run to expose and fix any edge cases in the replaying of these changes. When a workspace didn’t have any errors in the dry-run, recovery was run for it. We investigated workspaces that had errors to see if we could fix them.

Due to the large number of affected workspaces, this investigation took the majority of the recovery time. Some actions were unrecoverable because of unresolvable conflicts and were listed in the individual workspace’s recovery page. Most of the errors revolved around:

• Document content already existed: This meant the description for an issue or document had been recently created. We did not want to override changes made by users.
• User created: Users created during the outage were not recovered as we had no way to tie them back to an authentication. Ultimately, all the actions involving a new user (e.g. being assigned to an issue) and issues created by these new users were skipped as well.
• Modifications to entities no longer existed: If an update for an entity was archived or deleted, those updates were skipped.

We also excluded some objects from recovery entirely, such as integrations allowed to act in Linear on behalf of a workspace. We did not want to bring these back automatically after this delay. Instead, we chose to let users reconnect any missing integrations themselves. Similarly, we did not recover newly-created workspaces. Instead, we sent the workspace administrators an email telling them about the situation.

Impact

All users experienced one hour of platform downtime while the backup restored data.

In all, 12% of workspaces had data that was unavailable until the restoration finished. Another 7% had automated changes (like generated Cycles) that were also unavailable.

We restored over 99% of data within 36 hours. The remaining 4,136 sync packets for unresolvable conflicts represent an average of 0.44 per workspace.

Next steps and improvements

This incident was the largest in Linear’s five-year history. We strive to build the fastest and most reliable product for our users. This incident revealed many areas where we can do better to find, stop, and recover from similar outages. We learned important lessons from the outage, which we’ll be making actionable in the coming weeks and months. We’ve listed some of the changes we’ll implement below, with more to come as we continue assessing our response:

• No user on the production databases should have TRUNCATE privileges.
• Improve how migrations are created and applied to the database. This includes better review practices from database admins—separate from code reviews—and linting of dangerous operations.
• Make testing of database migrations in a staging environment easier and automated to reduce friction.
• Create and test tooling to quickly re-create the database from point-in-time backups.
• Various changes to internal tooling, addressing weaknesses or friction uncovered by the incident response.
• Improved monitors for data integrity.
• Implement the ability to turn on a read-only mode for Linear, so that clients have read access even when no changes are allowed to reduce the effects of downtime.

Again, we’re extremely sorry that this outage happened and it has involved most of our engineering team over the past week to resolve. We’ll keep working to improve as a team and to commit to a high level of transparency around our incident response, both during and after.

In order to build the best product, we need the best team

We believe the only way to build a quality product and business is to hire people we can trust to make good judgments, across all functions and levels. Finding people who have the skills, taste, and understanding to shape the product and execute the work itself is how we keep a small and effective team.

At Linear, we expect all team members to take ownership of projects — shaping the direction, making decisions, talking to users when needed, and communicating progress. It’s very much a full-stack role, being part of the product-building, instead of one small cog in a larger machine.

The problem is that these types of people, unfortunately, are few and far between. The majority of companies don’t work in the way we do, which leads to fewer people with these kinds of skills. We found that standard interview processes didn’t work well for us. It’s challenging to assess in interviews if someone is truly a builder, has good taste and judgment, can take initiative, and approaches problems productively.

Additionally, one of the most common reasons people fail to succeed in startups is that they lack the ability to adjust to the ways startups need to operate. Startups need to move quickly while many things are in flux, and roles and problems are often less defined than in mature companies. A conventional interview process, often modeled by large companies, doesn’t account for this.

To evaluate if a person is a fit for Linear with the skills to be successful, we bring candidates in for a work trial as the final step in the interview process. A work trial is a paid 2-5 day period where a candidate works with our team on a real project that we plan to implement (or as close as possible to that) with access to relevant internal tools and resources.

Over the last four years, work trials have helped us scale to over 50 people with a 96% retention rate. Everyone — from engineers to C-level candidates — has gone through one. We think that this has been one the best ways to make sure both us and the candidate feel there is a great fit.

Before the work trial

As work trials are a large time commitment from the candidate and from us, candidates only move to a work trial when we really want to work with them. Work trials aren’t for weeding candidates out.

Before the work trial, we follow a fairly standard interview process:

• Defining the role: With all roles, we start with the problem to be solved, not the title or levels. The recruiter, hiring managers, and the interview panel of 3–5 people align on what we’re looking for in a candidate. Along the way, there might be additional calibration.
• Interviews: The early stages of our hiring process contain standard elements — an intro call with a recruiter, a hiring manager interview, and role-relevant skills assessments with team members.
• Panel voting: The interview panelists provide strong no to strong yes scores and share their feedback. During a debrief, they also do a thumbs up/down vote. Ideally, we see a majority of “strong yes” before going forward.

The work trial

Work trials are designed to help both sides make the right decision:

For Linear: The work trial lets us observe how candidates work in our remote startup environment and make decisions in situations that might have more than one solution. We experience how they collaborate with our team day-to-day. While previous interview stages can surface how candidates have worked in the past, the work trial enables us to see firsthand how they think about problems, drive a project forward, and demonstrate their product sense.

For the candidate: We believe candidates benefit equally from the trial. Taking a job at a company can be a risk and candidates usually don’t get much insight into the company they’re interviewing with. Companies don’t like to share information, and usually the process is focused around what they need. With the work trial, candidates have more access and time to evaluate the company and decide whether this is the right place for them.

The role and the availability of the candidate determine the length of the work trial. Senior roles typically take the full five days, while other positions can be shorter. We understand that candidates are juggling other work and personal commitments, and are flexible in scheduling trials. We sometimes use weekends to help candidates who need to minimize time off from work. And we encourage candidates to maintain a normal, balanced schedule during the week — block off time to spend with family, take appointments, etc.

All work trials are paid. We pay the candidate a daily rate during the work trial, and we communicate that to the candidate in advance.

Preparing for the trial

The goal with the work trial is to simulate a normal working environment as much as possible. To that purpose, we assemble a supporting project team. Members typically include the recruiter, hiring manager, and 3–5 teammates that would closely intersect with this role.

The team first defines what a successful output for the work trial would be based on current and upcoming team priorities, and then works backward to design the prompt. We want to limit the scope of the work trial while getting as close to a real project as possible. Work trial projects sometimes end up being the first project for the new hire when they get started.

Some examples of past prompts:

• For an engineer, building a feature allowing teams to effectively triage incoming feature requests
• For a content marketer, writing a blog post based on a feature release
• For a designer, designing a way to resolve comments

Our recruiter and people operations coordinator handle necessary logistics pre-trial — securing a non-disclosure agreement (NDA), granting temporary tool access, scheduling meetings, and prepping docs conveying context on goals and expectations. We use a templated issue list in Linear to make sure we cover each step.

We give each candidate access to the tools they need to be successful — typically Slack, Notion, Linear, and Pitch but also GitHub and Figma.

As a last step before the trial, our recruiter covers the logistics of the work trial and the project prompt with the candidate.

During the work trial

The work trial itself has a few standard meetings:

• Kick-off: Candidate meets with the team to go over prompt, get additional context, ask clarifying questions, and discuss an initial approach
• Check-in: Candidate leads status update to share progress, ask questions, and get feedback. Check-ins are candidate-led because we want to see their ownership and readiness to course-correct.
• Final presentation: Candidate presents final deliverable to the work trial team and answers questions. These presentations tend to be discussion-based.

Apart from these meetings, the candidate focuses on carrying out the project, and can reach out to the team through a dedicated Slack channel or ad-hoc calls if they have questions or need information.

The recruiter also schedules 1:1 coffee chats with a couple other Linear employees for additional perspective, and invites the candidate to other team events happening that week, such as company all-hands or bake-offs. Some go-to-market candidates will shadow or even run an actual customer-facing call.

Debriefing and deciding

After the work trial, each member of the project team submits feedback separately — and without reviewing comments from other evaluators — before debriefing together live. In evaluations, anything other than a strong yes is a no. At Linear, all debriefs begin with a blind thumbs up/down vote and proceed with an open discussion on feedback anchored in specific examples and anecdotes. The hiring manager makes a final decision on whether to extend an offer to the candidate, though we strongly prefer unanimous decisions.

The recruiter documents highlights and key takeaways to later share back with the candidate, offering detailed transparency regardless of outcome as closing the feedback loop can provide significant value to the candidate.

When we decide not to move forward with a candidate, we stick to our transparent approach and let them know why, despite the hard situation.

How we’re continuing to evolve

We’re still improving the work trial process based on feedback from candidates and our team. We’ve clarified expectations for both the candidate and our work trial teams to make sure everyone actively participates and understands each person’s role.

Our company has grown, and we’ve removed the expectation that candidates participate in our regular product meetings or All Hands. Instead, we encourage them to shadow these meetings so they can see our culture and workflows without putting them on the spot to participate actively. We also narrowed the presentation audience to the work trial team, so that we can have deeper interaction in a more comfortable environment.

While we’ve modified parts of the work trial as the company has scaled to provide better experiences, we know that work trials may not scale with us forever. They require a significant commitment from candidates, and a great deal of time from our team. For now, they’re very much worth our efforts.

Building work trials into your own team

Work trials may not work at every company. We have a few suggestions if you’re considering implementing work trials at your own company:

• Identify prompts that will surface the signals you’re looking for. Work closely with the hiring manager and project team to define projects that map to real work in your own environment.
• Evaluate candidates based on how they work with your team — while output matters, work trials reveal so much more around communication, self-direction, responsiveness to feedback, etc.
  

To help you get started, we use to create the work trial plan we share with each candidate. It’ll give you a sense of how we schedule meetings, but also how we communicate Linear’s work style and culture to candidates. Feel free to remix it, and adapt it to your own company.

If you have questions about how we do work trials at Linear, or what it takes to make them successful, please reach out. We’re happy to help.

If you’re interested in a career at Linear, take a look at our open roles.

A few months ago, we rolled out our Similar Issues matching feature to all Linear workspaces. This feature was the latest to graduate from our internal AI “skunkworks” team, which we spun up over the summer to experiment with new machine learning technologies. Instead of flashy AI features, we focused on areas where automation can reduce repetitive work and organize your data.

Why we built it: Duplicate issues and backlog management

Anyone who has worked with a large team and a long issue backlog knows that dealing with duplicate issues is something of a forever-problem. Sometimes you have a hunch the issue you’re creating is already in the backlog somewhere, and other times you have no idea at all. In the best-case scenario, your issue backlog is a bit bigger than it needs to be; in the worst case scenario, you have multiple engineers fixing the same bug, completely unaware of the overlap.

We wanted to address this common problem by interjecting during the issue creation process and suggesting issues that could be related to or duplicates of the one you’re creating. It seemed as though this would be a great application of large language models (LLMs), which would offer a level of accuracy that wouldn’t be possible by simply computing similarity based on properties or keywords alone.

As we worked on the design of the feature, we quickly realized it could extend to our functionality to help with issues from external sources. When working through the Triage inbox, we’d be able to show existing similar issues front and center and make it easy to mark them as duplicates.

While having the feature in Triage is useful, it could still be too late in the process since the issue is already created. So, we decided to push the detection even closer to the edge and ‌surface similar issues in as well, directly next to incoming customer emails.

Now, when a customer emails in about a bug or problem, the support team can clearly see if a related issue already exists and what its status is. Without having to jump between different tools, they can respond accordingly.

How we chose our tooling: Vector embeddings and search

With a solid idea in place, the next task was deciding which technologies to use. As with any new technology, there are many startups vying to form the foundation of your stack, and so we evaluated multiple approaches and platforms. Fundamentally, we needed two things: a way to generate accurate embeddings and a place to store and search them.

Vector embeddings

At the core of our approach are vector embeddings. Embeddings encode the semantic meaning or concept of a piece of data as a matrix of floating point numbers so you can search and group items with similar meaning using simple mathematical operations. For example, “bug”, “problem”, “broken” are all different keywords but within the context of a Linear issue mean very similar things. Using cosine similarity queries, issues that are conceptually similar would have a score closer to 1, whereas opposing ideas would be closer to -1.

While this method of calculating similarity is not particularly new (Google in particular has been innovating in this area for years), it has seen a resurgence in popularity with the new LLMs that can generate more semantically accurate vector embeddings at a very low cost, and with a single API call.

Storing vectors

During the first proof of concept with our own data, we actually stored the vector embeddings as blobs in our primary data store. This let the team iterate quickly on ideas while we evaluated other long-term options for storage. It turned out to be a pretty good trade-off, but it’s important to ensure the giant blob column is not being selected in queries unnecessarily — vectors can be quite large compared to most other data we store.

We experimented with several vector-specific databases, but each came with drawbacks such as downtime to scale, high cost, or increased ops complexity.

After much consternation and after moving the development embeddings between providers on more than one occasion, we ended up choosing PostgreSQL with the pgvector hosted on Google Cloud. Thankfully, GCP launched support for the extension just in time for us to take advantage of it. Postgres is a known quantity that our small engineering team can maintain with confidence, and it still provides very reasonable response times for cosine similarity queries.

Backfilling and indexing vectors

Next, we needed to generate embeddings for all issues in all workspaces, based on their textual content, and fill out the database with the vector embeddings and metadata such as status, workspace, and team identifiers. Thankfully, we have an existing internal framework for running data backfills using our task runners to process jobs in parallel on a kubernetes cluster, so this was a breeze and involved writing a small “task” to iterate through issues, concatenating the content, and converting the resulting text to a vector through a single API request.

Without indexing, searching across this database was (unsurprisingly) very slow and initial naive testing saw cosine similarity queries regularly timing out or taking multiple seconds to complete.

Because we’re adding this feature to an existing product, we have tens of millions of issues from the get-go. Generating indexes for embeddings at this scale took some iteration and failure, even with providing the database server with hundreds of GB of memory. We found success in partitioning the embeddings table by workspace ID across several hundred partitions and creating indexes on each partition separately. While we tested different parameters, such as list size, we largely followed pgvector’s recommendations to maintain sufficient search accuracy.

What’s next: Improving similar issue detection

Surfacing similar issues has already helped our customer experience team consolidate support issues in Intercom with less time spent manually aggregating messages. We’ve also received some early feedback from the community that the feature is helping folks better manage their backlogs across engineering and support teams.

We have a few improvements to explore already, focused on making it easier to identify similar and duplicate issues across sources and improving the quality of our vector search. Additionally, we would like to:

• Make the feature available in more integrations
• Consider other properties, such as labels in the embedding
• Ensure issues created with templates do not unduly influence the similarity score
• Use this index as a signal for our main search functionality, which is currently powered by ElasticSearch.

Similar Issues was one of the first fully-fledged features to come out of our AI experimentation, and we’re excited about its potential to make Linear even more powerful. We believe this feature can create those “magical” moments that make Linear feel special.

You can learn more about Similar Issues in our recent changelog here.

Intro

There are two types of work.

Planned work and unplanned work.

Planned work are tasks and activities that have been organized and scheduled in advance. This type of work typically happens in projects that tie into roadmaps and larger company goals. Because the work has been planned before, you know what you’re trying to do, who’s going to work on it, and when they will get started.

Unplanned work, on the other hand, are issues and emergencies that appear suddenly and seemingly randomly in the form of a bug report, an important feature request, or an outage.

Unplanned work happens unexpectedly, but it’s not unexpected. You know that there will be bug reports, you just don’t know when, where, and in what shape they will come up. The only thing that is certain is that they will appear.

There is no way to escape these ad hoc forces of the product building process. But there are strategies to plan for unplanned work and tools to systematically manage it. What these are and how they work is what we’ll cover in the next few chapters.

Let’s begin.

The challenges of unplanned work

Before we jump into the specifics, we should take a step back and think about what makes unplanned work so difficult to manage in the first place.

Unplanned work has two broad phases: There’s an intake phase where unplanned work gets reported. And there’s an execution phase in which the reported problems are actually resolved. Both of these phases have their own unique challenges.

Intake is challenging because unplanned work appears in so many different and disconnected places. Take bugs as an example. They will turn up across many different channels, both internally and externally: social media, email, Slack, a meeting, your customer support tool, and half a dozen other places you didn’t even think about. Is every recipient across these various touch points able to quickly file a bug report? Do they know where to file it, how to write it, and who to send it to?

Execution is challenging due to uncertain responsibilities and priorities. Because unplanned work is unplanned, it’s not always clear who should work on it. In fact, it might not even be clear if anyone should work on it at all. Some issues are emergencies, but others can be ignored. Some requests seem irrelevant, but what if they come from your most important customer? How do you ensure the most important work actually gets done quickly?

Let’s take a closer look at each of these phases, starting with intake.

Phase 1: Zero-friction intake

The intake phase is all about turning reported bugs and other requests into explicit, actionable company knowledge by feeding them into your issue tracking system. Because every piece of friction increases the likelihood that something doesn’t get reported, it is critical that this process is as simple and smooth as possible.

Why is this point so important?

Think of your issue tracking system as a hive mind or a collective brain that contains important knowledge about the state of your product building process. It’s the source of truth upon which you and your company make decisions and coordinate work.

If the data in your hive mind is incomplete or incorrect, however, it stops being a source of truth. It becomes a source of half-truths. You can’t know what people are thinking if it’s too hard for them to communicate with you, and you can’t act on what they say if you don’t keep track of it.

The focus of the intake process on the left side of the Venn diagram: We want to minimize the amount of unreported issues so that the knowledge in your issue tracking system accurately reflects the reality you are in.

So how do we get there?

The first step is to allow intake directly at the source where unplanned work first appears. It’s like instrumenting your organization to get full situational awareness of everything that’s happening. The complexity here is that there are many different sources and you want to cover as many of them as possible.

This is why at Linear we put such a strong emphasis on . From the start, we developed integrations for the most common sources of unplanned work. They include customer support tools like Intercom, performance monitoring platforms such as Sentry, and popular communication services like Slack.

Slack plays a particularly important role in this stack because it’s the place where most unplanned work surfaces. It acts as a sort of catch-all for the long-tail of unplanned reports and requests. As others have described it, Slack is like “911 for whatever isn’t possible natively in a company’s productivity apps”.

The 911 analogy is interesting but not entirely accurate. When you call 911, someone will respond and take action. When you post on Slack, someone might respond and take action. You don’t know if anyone has seen your call for help or if you have just been shouting into the void.

To improve this area of unplanned work, we recently introduced a new feature called . With Asks, anyone in a Slack workspace can quickly turn a conversation into a request that automatically gets routed to the relevant team in Linear.

The core idea behind Asks is to make unplanned work explicit and actionable — but in the most frictionless way possible (remember, we want to maximize the probability that intake actually happens):

Most importantly, the person making the request has complete peace of mind that their request will be seen and taken care of. While we don’t like the comparison too much, there are a lot of conceptual similarities between Asks and an emergency hotline. It’s the missing piece that actually turns Slack into 911 for unplanned work.

Now that we have the intake process covered, let’s move on to the execution phase.

Phase 2: Efficient execution with Triage

Most issue tracking systems have frameworks for planned work, but no native conceptual containers for unplanned work. While planned work is neatly organized in projects and roadmaps, there is no clear, predefined path for what should happen with unplanned work. It either constantly disrupts the team’s existing work or ends up being dumped onto an endless backlog never to be looked at again (or both).

To manage unplanned work systematically rather than just locally, Linear has an important concept called .

Triage is a shared inbox for your team that centralizes all incoming unplanned work. All the bug reports, feature ideas, alerts, and other requests that get reported and filed in the various different channels we talked about in the previous chapter are added to this queue.

Triage provides a chance to review, update, and prioritize each issue before it gets assigned and added to the team’s workflow. This helps to filter out irrelevant requests and duplicates.

Let’s go back to our Venn diagram from earlier to understand why this is important.

While the intake process is designed to reduce the number of unreported issues on the left side of the Venn diagram, the first part of execution phase is there to verify that whatever we are feeding into the issue tracking system is actually accurate.

By reviewing all issues, we can filter out invalid requests, ask for more information if necessary, and merge duplicates that have been reported before. This way we ensures that the knowledge in your “company hive mind” is not just a complete but also an accurate reflection of reality.

The review process also helps to clarify what part of the unplanned workload is most important and who should work on it. This avoids scope creep and distractions that usually happen when unplanned work doesn’t get managed systematically.

The review process boils down to four primary actions:

This leaves us with the challenge of accountability (or the lack thereof). To plan for unplanned work we need to define roles and priorities, so that tasks are actually taken care of in a timely manner. We solve the accountability problem with Triage responsibilities. This is in the Triage queue.

who will get notified (or auto-assigned) for each new issue, or use an existing PagerDuty schedule to automate the process.

Lastly, we can use to communicate urgency and set guidance on completion deadlines. SLAs are applied automatically depending on pre-defined variables. For example, you can set specific timelines for urgent bugs or for requests from your most important customers.

SLAs help you to establish and maintain internal standards for how quickly unplanned work gets resolved. But they also give your team a framework for prioritization, so that the most important issues and requests get resolved first.

Outro

Wrapping up, let’s summarize the most important points and provide you with some useful links so you can set up your own plan for unplanned work.

• Unplanned work are bugs, alerts, and other requests and emergencies that appear suddenly. You can’t escape this type of work, but you can manage it.
• Unplanned work has two broad phases: An intake phase and an execution phase.
• The intake phase is about turning reported bugs and requests into explicit, actionable issues. To make this process as frictionless as possible, you enable intake right where unplanned work first appears — with integrations to your most important tools. Linear has integrations with customer support platforms (Intercom, Zendesk, Front, Plain), engineering tools (Sentry, Incident.io), and many other products.
• Slack is a particularly important intake channel where a lot of unplanned work surfaces. We built a tool called Linear Asks that allows your team to quickly turn these requests into actionable issues.
• In the execution phase, we first centralize all incoming unplanned work in a shared team inbox called Triage, where each issue gets reviewed, prioritized, and assigned. You can learn more about Triage and how to enable it for your team here.
• To get the most out of Triage, we recommend having a clearly defined person who reviews incoming work. For larger teams, enabling SLAs can help with the prioritization of time-sensitive requests.

Let’s start with the basics: What even is a project?

Nan Yu

If I had to name a heuristic for what we would consider a project, it would be multiple people working on it. If multiple people work on it, and it takes over two weeks, that’s a project. If a single person works on something for two weeks, that’s probably not quite a project yet. We try to make it very obvious what the definition of being done with a project means because we believe that projects need to be completed at some point. There are exceptions, but the majority of projects should have end dates.

Sabin Roman

It’s difficult to give a single definition of a project — it really depends on context. During the planning phase, we define a high-level roadmap with themes that we want to address in the next six months or so. And we break those themes further into concrete features that we can build. Those features often become the projects themselves. The project descriptions are quite open-ended to start with. For example, about a year ago, we knew we wanted to build an for Linear. But then it was up to the project team to define what that actually meant. Which metrics do we want to surface? What’s the user experience? And so on. What might have looked like a single project at the beginning turned into four or five different projects in the end.

How do you go from the exploratory phase to writing project specs?

Nan Yu

In the beginning, we’ll collect everything we have heard about whatever we are about to work on in a doc or a tracking issue. That includes feedback, backlogs, user interviews, and random tickets. We synthesize the common themes and open questions. We involve everyone across engineering, design, and support.

With specs, we write about in what context this was a good idea. We help everyone understand the intent of why we’re undertaking a project, what are the problems we’re trying to solve, and what are the related problems or downstream issues. Giving people situational awareness is the main goal of project specs.

Sabin Roman

Most of our discussions and debates are around product decisions rather than technical implementation. Engineering discussions are very efficient as the team has a lot of trust, and folks are quite senior and have a good sense of the technical direction.

As we decide on the product and technical direction, we run multiple customer interviews, summarize the findings, and discuss them as a team. Once we have a rough direction, we document it, ask for a review, and iterate. We aim to write concise specs (1-2 pages) outlining our key product and technical decisions. Having crisp and focused specs makes for an easier read and better quality feedback.

Who leads projects at Linear?

Raissa Largman

We’re still fairly small and only have one PM (Nan, our Head of Product), so we have always had engineers leading projects. Compared to my experiences in the past at bigger companies, where it was always the PMs leading everything, I really like it. There’s a lot of independence and autonomy; we get to influence the product roadmap quite a bit and run projects the way we want, which is more efficient than someone with less knowledge coming in micromanaging. Fewer dedicated PMs are required when you are still small, structure your teams properly, and have a fairly senior team.

How do people get assigned as project leads, and what do the leads do?

Sabin Roman

The project leads are rotational. Nobody is the de facto project lead. We make sure that everybody on the team will be a project lead at some point. The project lead drives the communication around the project, shares updates, and ensures things are running on time. This allows the other engineers to focus on coding. It also helps every engineer to understand what it takes to be a project lead, especially when the projects are more complicated. It allows every person to learn that skill set and build empathy within the team for others.

Raissa Largman

While project leads are rotational, we do consider relevant expertise from the past that would make an engineer more qualified to take on a particular project. It also depends on how much bandwidth people have. If you want to work on something, you can say I really want to work on that, and you probably will be able to work on that. There are things people don’t want to work on, and everybody has to take a turn and do what nobody wants.

How do you keep others updated on the progress of your projects?

Nan Yu

We use extensively. Each project lead writes a weekly update with a summary of the current state of the project and what’s top of mind.

The format of these updates varies from project to project: Some are short and more high-level, others are longer and more technical. We often write updates right after project meetings and include the most important take-aways.

Here’s an example of a typical project update (from the project that led to our recently released ):

To ensure that projects get updated on a regular basis, we have reminders set up that notify the project lead to post an update.

Raissa Largman

Everybody in our Linear workspace can read these updates and see where each project stands. To increase the visibility of project updates, .

We have a #product-updates channel which receives all Linear project updates, and individual channels for each Linear project (#p-[projectname]) where project-specific discussions happen.

How do you use milestones?

Nan Yu

Let’s take a step back and return to the idea of being done with something. Issues want to be done. Projects want to be done. But projects have a lot of issues. We designed to be able to let people define the concept of being done.

If any open issues remain in a milestone bucket, it still needs to be done. On a project level, it’s a little more difficult because you have everything from issues we are working on to ideas we might want to explore.

Milestones let people decide different definitions of being done for different stages of the project. For example, a project might be done for a closed beta release — but there is still a lot of work that has to be completed for it to be done for a public release.

Raissa Largman

We don’t have a set structure for how we use milestones in our projects, but it’s usually tied to different release stages of the project. This is a typical example:

How do you know when something is good enough to ship?

Sabin Roman

There’s no strict process or a document with checkmarks to tell you when the project is ready for release. It comes down to the engineers working on the project feeling that the project is ready. And once they do, they share it with the team. Our weekly product meeting is focused on demos. We recently started experimenting with what we call “feature roasts”. If you are working on a feature and think it’s ready to be shipped, you can ask the team to try it out during the weekly meeting and provide instant feedback. So far, this has proved to be a productive and fun exercise. That’s how quality corrections happen at the team level. Once the team is ready, we submit it as a release candidate for company-wide feedback. For some projects, we release them to our private beta program (Origins) for feedback before we do the public release.

Raissa Largman

You have to be on the same page about what level of polish you are trying to achieve to put something in front of a customer. There’s some risk management work — some users are okay with trying out half-baked stuff, some are not. We have escalating release channels and segmented users to balance this out.

When we release features to our beta customers, it’s still not at the polish level we aim for. If you release something and iterate too much, it can be difficult for your customers because they might have to relearn what they just figured out. The judgment around when to release boils down to the level of polish we look for and the size of the changes we expect to happen for that feature in the future.

What’s next?

Nan Yu

We are actively working on a variety of projects to improve Linear’s planning and roadmapping functionalities. An upcoming change we think folks will get excited about is the ability to comment on project updates. We have more coming and would love your feedback: Join our Slack community and tell us what we can do better for you when running your own projects on Linear.

Some of the best product builders and operators are partnering with us and joining the round: Stewart Butterfield (CEO, Slack), Cal Henderson (CTO, Slack), Claire Hughes Johnson (Corporate Advisor and former COO, Stripe), Koen Bok & Jorn van Dijk (Co-Founders, Framer), Christina Cacioppo (CEO, Vanta), Kyle Parrish (VP Sales, Figma), Praveen Neppalli Naga (VPE, Uber), and Ganesh Srinivasan (former CPO, Confluent).

Additionally, several of our current customers became our investors as well, including Guillermo Rauch (CEO, Vercel), Ilkka Paananen (CEO, Supercell), Josh Miller (CEO, Browser Company), Andrew Mason (CEO, Descript), and Immad Akhund (CEO, Mercury).

We’re extremely grateful to work with these industry leaders. Together, we’re excited to continue shaping Linear into the best-in-class project and issue tracking system that teams actually love to use.

Our progress over the past three years

We’ve had quite the momentum since launching and raising our Sequoia-led Series A in 2020.

Linear has evolved to cover more product development workflows, helping companies drive their roadmaps, share project updates, triage incoming bug reports, and get actionable insights from our data tools.

The business has grown significantly and we’ve been able to do it profitably. Linear has been growing & operating profitably since 2021, a year after launching the product. We also have a negative lifetime burn rate (we have more cash in the bank than we have raised from investors). This is a strong sign of long term sustainability.

It’s been amazing to see Linear becoming trusted and used by thousands of companies of all sizes – from public companies to early stage startups. It’s very likely that Linear is powering the companies behind products that you use and love today. Companies such as Cash App, Supercell, The Browser Company, Raycast, Retool, Vercel, Cohere, Substack, Mercury, Runway, Loom and Ramp all build with Linear.

Linear is the tool of choice for modern teams. While some find Linear and start using it from day one, more commonly we see companies switching over from legacy tools. Remote, Replit, Modern Treasury, and Verkada are just a few of the companies that have recently migrated their teams over. The reason these companies are choosing Linear isn’t just the speed, optimized design, or powerful features. It’s the collective result of all of these elements coming together into a better way to build products, where the team can focus on doing the work, not configuring the system.

As we grew from a startup to a 1,000 person company, the tool we were using to manage our work just got more complicated. Every single project management tool we tried fell short—until we tried Linear. Everyone loves using it. It’s fast. It’s so much easier to communicate about issues and projects. We trust Linear as our single source of truth. Our team can focus on what’s actually important: building our product.

Marcelo Lebre, Cofounder & President, Remote

Linear has been a lever. It gives our teams everything they need to improve coordination and inspires us to build better products.

Anil Varanasi, Cofounder & CEO, Meter

With Linear, we finally get a sense for the state of our work and our velocity. The speed with which you can navigate, review and update work is huge. Linear actually helps us to ship on time.

Matt Marcus, Cofounder & CPO, Modern Treasury

What’s next

While this is an exciting milestone, there is still a long journey ahead of us. We are staying focused on our commitment to building magical, high quality software and helping our customers around the world do the same.

Today, we are a team of 50 people and we plan to continue expanding the team very intentionally. One of our core beliefs is that smaller and focused teams achieve better quality results if given the right environment. If you want to be part of the journey, we are hiring.

Lastly, we are incredibly grateful for our customers and the community. We know that so much of where we are today is because of your support and trust. Thank you and we’re looking forward to continue building for you.

Thank you to our investors of this round: Kenneth Auchenberg, Koen Bok, Christina Cacioppo, Miles Clements, Dick Costolo, Jorn van Dijk, Claire Hughes Johnson, Akash Garg, Robert Gentz, Gavin Weigh, Cal Henderson, Immad Akhund, Marianne Vikkula, Krithika Muthukumar, Riku Mäkelä, Josh Miller, Andrew Mason, Henrietta Moon, Kristo Ovaska, Ilkka Paananen, Kyle Parrish, Praveen Neppalli Naga, Anssi Rusi, Guillermo Rauch, Oskari Saarenmaa, Rudi Skogman, Lee Robinson, Ganesh Srinivasan, and Stephanie Zhan.

Update (2025)

We have come a long way since then, so we recorded a sequel to that talk at our company offsite a few weeks ago. In this video we cover the challenges we’ve had scaling the sync engine, how the API around it has formed because of those challenges, and how the sync engine works in the Linear application today.

Watch video on YouTube

If you want to experience the sync engine in action, you can sign up for a Linear account (it’s free!) and test it yourself.

Interested in helping us scale the sync engine (and Linear) to the next level? We are hiring for a variety of roles across Europe and North America.

Cristina joins us at a pivotal moment in our journey to create a new standard for building software. Beyond the thousands of startups using Linear, there is an increasingly large number of established companies that are pushing back against the stagnation of their tools and looking for a better way to build their products.

Remote, Watershed, and Cohere are just a few of the companies that have migrated their teams over to Linear since the start of this year.

To ensure that Linear provides the same level of performance, effectiveness and delight to teams of any size, our focus has been to make Linear even more scalable and reliable. This involves not only leveling up Linear the product, but also leveling up Linear the company. And this is where Cristina comes in.

Cristina brings a wealth of experience to Linear having previously scaled products and teams at Stripe and Notion. At Notion, Cristina served as the Head of Platform & Partnerships managing the launch of the company’s API and building various business development and product growth teams. She previously spent more than seven years at Stripe, where she led a business unit and built the partnerships team from the ground up. She joined Stripe as one of the first employees and helped to grow the company to nearly 3000 people.

Most recently, Cristina was a Partner at First Round and an investor and advisor to companies such as Canva, AtoB and Meter (most of which are building with Linear).

Our approach to company building is similar to our approach to product building: We want to ship better, not just faster. We value craftsmanship and getting even the smallest details right. This means being considerate in who we bring on board to drive Linear forward. The reason I believe Cristina is such a great fit for Linear’s next phase of growth is not just her track record of scaling industry-defining companies, but the fact that she shares our values and our way of thinking.

Cristina has worked on developer products for the majority of her career and cares deeply about customer experience. She shares our commitment to quality and will bring the same attention to detail to our go-to-market efforts. In short, Cristina will help us expand Linear’s magic and bring it to the entire customer journey.

Last week we introduced a new concept to Linear called Project Updates. Project Updates are short status reports that keep everyone in your company informed about the progress and health of your projects.

“Projects” was one of the core themes of our 2022 roadmap planning session and we spent a lot of time discussing what features we should work on to meaningfully improve this part of the Linear experience.

Project Updates wasn’t part of our initial list of things to build. It slowly emerged as a problem space that we should tackle as we were building other things.

Here’s what happened.

As we started working on our 2022 initiatives, we realized that some of our coordination and reporting processes needed upgrading. Linear is still a fairly small company, but even with just 22 employees it felt like we needed a more formal process to keep everyone up-to-date on the progress of all the projects that people were working on.

Our first solution was a setup of different Slack channels:

• Each project received a dedicated Slack channel
• Once a week, the project owner would write a short progress update and post it in the respective Slack channel
• Every update would then be cross-posted to a global #project-updates channel so that everyone outside the project was also notified of the update

It worked. But not well.

The writing process felt very manual and required a lot of back and forth. The reading process was even worse with updates getting lost in an endless stream of Slack messages. Most importantly, the updates were completely siloed from where the actual project work was happening.

So we asked other companies how they managed project updates.

Turns out that their solutions weren’t much better.

The exact process differs from company to company, but the first step typically involves a tool to collect updates. Sometimes that tool is a spreadsheet, sometimes it’s a slide deck, sometimes it’s a Notion doc. But in every case the process is manual and requires switching between several different applications.

In a second step, a dedicated person has to collect and format all the updates that have been submitted, and finally send them via email to all relevant stakeholders in the company.

The process is tedious. People waste a lot of time. Everyone dreads doing it.

It felt like we could build something better.

On a high level, project updates solve a pretty basic problem. Every company wants to know how their projects are progressing. Is everything still on track? Or is the projected outcome at risk? Nobody wants to be surprised that the project that was supposed to be ready tomorrow is suddenly six months delayed.

A large part of the problem with “traditional” project updates is that the writing process is decoupled from where the rest of the work is happening. Productivity and collaboration are treated as two distinct activities. By moving the writing process into Linear, the whole activity becomes a more fluid experience. There is no need for context and application switching.

In some of our earliest explorations we tried to build data-based project updates by aggregating issues statistics and calculating velocity. But we quickly realized that project progress is not something that can be predicted based on quantitative data alone. It needs qualitative input from the project team.

The best way to answer “How is this project going?” always comes down to a short, plain text update. It is partly a quick summary of the past (“here’s what happened in the last 7 days”) and partly an educated guess about the future (“based on the knowledge I have today, I think this project will finish on time”).

A good project update should be brief and to the point. Almost like a tweet. And it should be easy to consume for a reader who might not be familiar with all of the project details. We felt that a visual representation of the current project status would complement the written update nicely.

Based on this approach, we built a project updates feature that consists of two simple components:

➀ A health indicator that provides a high-level signal of the current state of the project
➁ A rich text description to provide more in-depth information

To get into the habit of posting regularly and on time, we built a reminder feature that notifies project leads when it’s time to write an update. (At Linear, we write project updates every week on Friday.)

While the writing and broadcasting experience is critical, it is just one side of the process. Making sure the right people actually read the updates is equally important.

Similar to the writing process, we felt that we could deliver a more focused and uncluttered reading experience by showing project updates directly in the spatial context that matters most. That’s why project updates in Linear can not only be read directly on each project page, but also as an aggregated update feed on the project roadmap ➂.

For those in the organisation working outside of Linear, project updates can automatically be broadcasted to a select Slack channel. This way we can serve everyone in their native medium instead of forcing people to modify the way they work.

Linear is meant to be a tool that streamlines the entire product building process. Its role is to create focus and routine by removing unnecessary barriers. Project updates felt like one of those friction points that we could turn into a more fluid and enjoyable experience.

This release is just a very first version of our take on Project Updates. Think of this blog post as a very long and public project update on Project Updates. Everything is on track, but we have a lot more planned for the future.

Stay tuned.

I was on a flight from Lisbon to Paris recently.

Sitting on an airplane is one of those moments where I eventually get bored enough to start exploring my iPhone settings.

While I was reorganizing my phone, I had a sudden realization: Settings are typically seen as the result of design failure. The thinking goes that as designers, our goal is to create product experiences that don’t require any adjustments by the user. Consequently, offering customization options is interpreted as a failure to make firm product decisions.

I think there is a misunderstanding about what settings really are.

Users love settings

There certainly are moments where I find myself on the settings page of a product because it failed to deliver the experience I really wanted. But not all settings are created equal.

There’s a difference between product settings that a product needs to get right by default and preferences that designers deliberately shouldn’t have a strong opinion on.

First of all, remind yourself that users love settings.

Despite initially being born out of the absence of airplane WiFi, I actually enjoy discovering new settings on my iPhone that will make my life easier or improve my productivity.

Just look at your own user behaviour:
What do you do when you set up your new computer?

You change your background image.
You adjust your mouse speed.
You set a default browser.

You make all of those rearrangements not because the operating system is badly designed. You make them to create a more comfortable environment. To feel more at home.

In the end, this is the feeling we all try to re-create as designers.

Making settings sexy again

As a designer at Linear, I recently spent a lot of time redesigning our settings view. We understand that our users will spend a lot of time with us and so we really want to make sure that they can feel that we care about them.

During our team discussions, I realized that adding a customization layer to Linear had an additional benefit: It’s an excellent way to showcase our product and educate users about all its functionalities.

Some users immediately explore Linear’s settings to tailor their workspace to their unique team processes. So it made perfect sense for us to add tutorials and tips directly to our settings page. Once users have grown more experienced with Linear, they want to go deeper on the customization options of their workspace — and again, the settings page is the most natural way to learn what they can adjust.

With these realizations in mind, we approached our settings redesign like an onboarding experience. We created a settings “homepage” to show users what they can do with Linear and experiment with different functionalities.

When our users come across a feature or integration that isn’t working the way they want, they typically send us screenshots of their settings page. So we decided to use this space to display tutorials and tooltips. This way, users can learn more about the product and its features by simply navigating the settings.

Come for the vision, stay for the details

In addition to workspace settings, we also provide user-level settings. You can add custom emojis or import the ones you already have in Slack. We also allow you to completely customize your theme colors and other aspects of the app.

From a business perspective, focusing on small design details like this can be seen as a distraction. But if your users don’t feel comfortable using your product, even if it’s due to small details, they quickly leave you for a more cozy place. A place that feels more like home.

Some details become annoying because they are so repetitive. Some details are simply a matter of taste - not just UX/UI. By talking to users you can spot those details and introduce small settings that improve users’ lives without changing or disrupting your product direction. As the name suggests, they are just preferences.

One of the small preferences we introduced in the Linear app is not displaying the mouse cursor pointer over links. We want to mimic the feeling you natively have on the desktop with our Mac app. Most of our users never notice it - but to some it feels really weird. So we gave them the option to make the switch if they don’t like it.

People have certain habits and preferences.
Our job as a company is to create products that fit into people’s lives, not the other way around.

Building software products is like going on a journey.

When you are on a journey, you typically look ahead. You look at the ambitious goals you set for yourself. The mountain peak you want to climb. The next milestone you want to reach.

Looking ahead keeps you on the right track. It gives you direction and serves as a reminder for why you went on your journey in the first place. But every once in a while it’s worth it to stop for a second and to take a look back.

Looking back helps you to see all the progress you have made on your journey so far. It gives you a sense of accomplishment. Sometimes it’s worth looking back just to enjoy the view.

At Linear, we are on a journey to bring back the magic to software. Our mountain peak is building tools for the next generation of high-impact companies - so that they can be more successful on their respective journeys.

But today, we are not here to talk about where we are going. We want to stop for a second and take a look back. We already publish regular changelogs about new improvements and updates (and we would encourage you to do the same) - so today we’ll look back at our entire 2021 journey. The last 347 days to be exact.

2021 has been an exciting and productive year for us. A year full of progress and momentum. We shipped 39 changelog updates featuring 58 new features and 740 fixes and improvements over the last twelve months. Highlights include our integrations for Front, Intercom & Zendesk; roadmap timeline, split inbox, issue triage, project documents and new filters, SOC 2 compliance, and many, many other new features.

We look back on 56 projects this year. Each of them is like a small mountain peak we had to climb on our journey to get to where we are today. The graph above features the ten largest projects we worked on this year - our 2021 summits, so to speak. Their height is determined by their number of issues weighted by their respective estimates.

We created our first issue of the year on Sat, Jan 02 2021 at 10:59:31 GMT. Since then, the team created 4,387 more issues. Luckily, we launched an updated issue creation UI earlier this year which made this process way faster.

We marked 2,489 issues as complete. That’s an average of 7.17291 completed issues per day. Nov 10, 2021 was our most productive day with 45 issues marked as completed.

Of the 2489 issues we completed this year, 518 were bugs that we fixed.

Our users sent us hundreds of feature requests - many of them via the Linear Slack community which has 3,306 members.

5 new team members joined us during our journey this year, bringing the Linear team to a total of 13 people. We are a fully-remote company and currently work across 11 cities across 7 timezones within GMT +8 to -2.

No great journey has ever been completed without sufficient energy supplies. That’s why we cook or bake together over Zoom at least once a quarter. In 2021, we organized 5 team bake offs which included everything from Enchiladas to Japanese roll cakes.

Looking back at everything we worked on in 2021 gets us even more excited about what’s coming in 2022. We have an ambitious roadmap ahead of us with a lot of exciting mountain peaks to climb. And we are looking for pioneering and passionate people to join us on that journey.

If your 2022 goals include taking up a new professional challenge, you should consider joining us.

Fast growing startups are built on Linear

We launched Linear exactly one year ago to help high-performing teams who wanted a better way to build software. Linear is fast, effortless, and simple to use. It streamlines core aspects of product team workflows so that they can focus on the work that matters while our tool does the rest.

We’ve grown a lot since then as a team, and so have the companies that use Linear. The challenges they and we have faced in scaling inspired many of the features that we built for this release.

Scaling product development

“We were constantly fighting our existing issue tracking tool to support EPD. We felt there was a lot of “work about work” to keep tasks and projects organized. Linear is different. It has a better model and structure for engineering orgs. Sprints, points, priority, and status are all treated as first-class properties of tasks. Search and filtering are powerful and the timeline view is one of the best I’ve seen.”

Andrew Mason, CEO & Founder, Descript

A big challenge startups face once they hit product-market fit is how to keep processes simple while their teams increase in size and their product grows more complex. Coordination is relatively easy at five, ten, and even fifteen people. Most employees are individual contributors who manage their own work and do so on small, autonomous teams. Project planning and issue prioritization is simple when you’re focused on a small feature set and handful of customers. But once a company hits that lucky spot where numbers start to go up and to the right, they go from dealing with product-market fit problems to scaling problems.

Scaling is hard. We know this ourselves, from our work on Linear and especially from our experience building products at high-growth companies like Coinbase, Uber, and Airbnb. We saw it done well and not so well.

Too often, the approach to scaling is to add layers of processes and more tooling. This ends up creating busy work and disrupting the dynamics and workflows that helped the earlier team succeed. What you actually want is a way to simplify processes, make workflows more efficient, and design ways to work together so that it doesn’t seem like you’ve added new layers even if you have.

2021–06 Release

The next generation of startups is being built on Linear. Some of the fastest-growing startups and industry-changing companies from around the world. We learn so much from how they use the product and their feedback on Linear.

This release brings new features that help them manage added complexity without losing the efficiency of small teams. At the core are two traditionally complex issues, triaging requests and roadmap planning.

Triage & customer support tooling

We build in public at Linear and put care into talking to users and getting feedback. We talk to hundreds of customers each week through our 2k+ strong Slack community, 14k Twitter followers, and to users who send in bug reports, requests, and questions through our in-app help modal which routes to a Front Inbox.

We like to link to customer conversations in Linear issues so that we can keep track of requests and get back to customers when issues resolve. As we grew, we found it harder to do that. We weren’t alone as we learned a lot of our customers faced this same problem: they had Linear issues filled with links to customer conversations. Some also had started building separate Triage “teams” where they would file all new issues, then clean up, prioritize, and move them to the appropriate team.

So we built this user experience into the product in our new Triage feature. All new issues from integrations or members outside of your team now go to a special team inbox called Triage. These issues have linked attachments back to the customer support tools where they were created.

The product team can choose how they triage issues but we’ve built in a simple workflow you can follow, too. Use keyboard shortcuts or the menu to accept an issue to the backlog, escalate it to the current cycle, merge, decline, or even snooze the issue for later. Declining an issue prompts you to leave a comment explaining why and you can keep an issue in the Triage inbox while you wait for more information.

Customer support integrations

We’ve been using Triage at Linear for the last couple of weeks and find it, along with the customer support integration with Front (in beta), incredibly useful for our team. With our new integrations, you can now create Linear issues from Zendesk, Intercom, and Front. If you’re tracking feature requests (we have a separate Linear team for this), you can attach multiple customer conversations to a single Linear issue and attach any URL such as tweets or Slack posts from your community Slack group.

This makes it incredibly easy to track requests and for product teams to get back to customers directly with follow up questions. We show issue details and status updates directly in the customer support tool and re-open customer conversations once issues have closed.

Roadmap Timeline with live predictions

Roadmaps are critical guideposts for any organization but they have a tendency to be “set it and forget it” experiences in many tools. It’s easy, almost inevitable that plans change, especially at younger, fast-paced companies and so your initial estimations go stale.

Rather than fight entropy, we designed our roadmap around the uncertainties and practicalities of product development. We generate the timeline from your project data, so you don’t have to do any extra work to lay it out in that view and the data is always in sync. The timeline updates anytime you make a change anywhere in the app to a project or its related issues. We use actual issue data and historical trends to estimate project completion dates, so you don’t just see plans but get a preview of future work based on actual velocity. This makes it easier to spot projects that need help or rescoping and to adjust plans accordingly.

What we shipped first half of 2021:

At Linear we like to build in public. We publish a weekly changelog to celebrate our progress and share it with our customers. The theme for the first half of 2021 was to improve Linear for our growing customers.

Here is what we built:

• Timeline view for Roadmap with live predictions
• Triage Inbox for teams that lets you create, prioritize, and assign new issues with quick actions including Snooze. Inbox now has snooze, too
• Customer support integrations with Zendesk, Intercom, and Front
• Private teams so you can control access to sensitive issues and projects
• Fast issue input that lets you create multiple issues in a row, save drafts, and create issues in a modal so that you don’t lose context
• Typescript SDK and new developer documentation at developers.linear.app
• Issue Migration Assistant that lets you import issues in minutes from common issue tracking tools to Linear
• Powerful backend search that can search the archive and also shows you recently opened issues
• Auto-archive that retains statistics and automatically archives your issues, cycles, and projects at a regular cadence between 1–12 months
• New integrations including Netifly, Incident.io, Codestream, and Slab
• Startup performance improvements to make Linear even faster
• Desktop clients for Apple M1 and Windows
• Improvements to issue merging, issue view layout, issue grouping, GitHub notifications, and keyboard shortcuts help. A feature to delete issues.
• Updates to the Zapier integration, new webhooks, and API improvements

Check out our newest release to learn more

—

Growing Linear team

Another milestone for us is that we’ve grown in size and continents. We added three new team members since our last launch bringing the Linear team to 11 strong working remotely in US, Sweden, Finland, Portugal, France, and Argentina. We’re hiring for engineering, design, and operations across GMT+3 and GMT-7 time zones.

https://jobs.lever.co/linear

Before we started Linear, Jori and I built another company that was part of the Y Combinator’s Summer 2012 batch. There were a lot of lessons I learned from YC. However, one thing I wish I had understood better was what effective product development looks like.

Back then, we knew how to code, design and ship but we didn’t know how to prioritize effectively, set meaningful goals, or keep the momentum up week after week. While at the very beginning this is not that critical. It becomes more when you get to the stage of having a product and user to support. You need some structure to keep making meaningful progress and not going around in circles.

We learned some of this as we went through YC, and later over the years working in companies like Coinbase and Airbnb. I wish I had this understanding then and would have been able to focus more on the right things.

I often get questions from early-stage founders asking for tips and advice on how to run product development in the early stages. This is the basic model we use as well as some advice on how to think about product development in the early days.

—

P.S. We built Linear in part to make it easier for anyone to build products and give people a tool we wish we had when we were YC founders, one that was easy to use and encouraged good product development practices so we could spend more time shipping and talking to users, and less time figuring out how to manage our work.

Active YC companies get a year free of Linear. Find details on our YC deal page.

Execution in the early stage

As a new startup, you operate with a non-existing, or small user base, unfinished product, and limited understanding. In those early days, it’s better to aim to move fast as possible, try things out, learn and then fix and adjust. Momentum matters more than anything.

Moving fast doesn’t mean you shouldn’t have any structure or goals. The structure aims to keep up pace and momentum week after week, maintain the team’s health and avoid going in circles. You should keep these structures and tools lightweight as possible and make sure each of them has a purpose and it aligns on delivering value to the user.

Build with users

Much of the early startup process is about learning what your customers want. You should seek out users or potential users for feedback, iterate, and be flexible to meet the demands of your customers and the market.

Vision vs Feedback

However, your task as a founder is to find a balance between building toward your vision/intuition and building what the users want. Too vision-based products might miss user and market needs while too reactive products become Frankenstein creations without a clear purpose. You need to keep refining your product vision based on your user feedback.

Solve the problem not the feature

Understand that users will project their needs from the context or product they currently see, not the product that you’re trying to build. It’s common for users to ask for features you should add. Whenever they do, it’s important as a product builder that you ask them questions back. What is the use case? What is the problem they’re trying to solve with this feature or solution? How would their experience of the product be different if the problem was fixed?

By pivoting the conversation away from a feature request and toward explaining the problem they are trying to solve, you move the discussion towards the pain point. In this conversation, you’ll learn whether the problem is valuable to solve or nice to have. It also allows you to explore multiple solutions to the problem, and to choose the right one within the context of your broader vision.

Build for the right users

You may also talk to users who have a lot of feedback but who aren’t in your target demographic or aren’t it now. If you think you are building for things for early-stage startups, listening to an enterprise customer will likely set you on the wrong path and it’s unlikely that they will even become a customer.

Incorporate the feedback and let it refine your product, but don’t let user feedback alone dictate what you build. You can become too reactive to user feedback. This is why it’s good to have goals and roadmaps, that help you balance the needs of the users and the needs of the company.

Set useful goals

Startups move so fast that it’s normal not to know what you’re working on the next day let alone the next week. Goals are important to remind you what matters for the medium or long term success of the company. You might not feel like you have enough users or historical data to make decisions on what your goals should be. That’s normal and in those situations, create a goal that propels you forward in some measurable way.

In the early days, it can be hard to hit those goals when you start from zero. The way to think about it is to walk back from that goal, what is the path there. Path to 10 users starts with 1 user, which starts with having a product that someone can find and start using.

During YC your goal is to achieve meaningful traction by demo day. Your first meaningful goal getting there could be to find 10 users to use your product, then 100, then $1000 in MRR. Successful startups often start with something small, figure it out, and then scale. And remember, there is no limit to how fast you can grow.

Use a roadmap set the path

When you have some idea of which goals to tackle first, the next step is to figure out how. A product roadmap in a startup is a list of things you think you need to build to get where you need to be. Roadmaps are about setting direction and writing it down helps the team align on the direction. You should also realize you cannot do everything at once. The key is to think broadly but then only choose few things to do well and likely help with the goals.

In the first months of building Linear, we used monthly roadmaps. We’d brainstorm projects based on our goals and what we learned the month prior. We then selected 1–3 larger projects we saw most impactful towards our goals. This practice repeated over months helped ensure that we kept leveling up the product and didn’t get stuck only optimizing existing features. By only choosing a few larger projects, and not planning our time 100%, we left ourselves bandwidth to work on fixes and feature ideas from the user feedback.

We have a roadmap feature in Linear that you can use to build your roadmap but in the early stages, it can be as simple as one spreadsheet or document that lists the following.

• Project title
• Project description (at this stage you can have few paragraphs or bullet points to describe what do you think the project is for)
• Why are you building this? (rationale why is it’s needed, how it’s supporting your goals etc)
• The owner (who is responsible for building or driving this if there are multiple people)

Later, as the team grows or you feel that it’s necessary, you can expand these by writing brief 1-pagers to communicate the scope and details for the whole team.

Scope projects down

At the early stages, scope projects. Design projects so that they can be completed in 1–3 weeks with a team of 1–3 people. Smaller fixes or additions should take only hours or a day. Shorter projects force you to prioritize the most important feature set, create quick feedback loops with customers and get into the habit of shipping continuously. Smaller teams help you move faster and reduce the overhead. When you’re early in the product building stage, you don’t know enough to predict whether a project will be impactful or not so it’s better to avoid massive projects. If there is no way to scope down the project, then break it down into stages.

For example, we shipped the first versions of Cycles and Projects in the first couple of months of starting Linear. The MVP version of both of these features took us about two weeks to design and build. We shipped the early versions to ourselves and private beta users in the first week and started collecting user feedback immediately and fixing them in the following weeks. We’ve made a lot of improvements to Cycles and Projects since and both of them are now the major features of the product.

Ways to Prioritize

It’s really important to learn to prioritize and have a rationale why you prioritize something. You don’t have unlimited resources or time.

First, it’s helpful to think of new features as additive enablers or removing blockers. Enablers enable new functionality that usually makes the product more valuable or interesting. Blockers are gaps or friction that prevents a user/customer to use your product. (Note: You should try to understand if the problem is truly preventing someone from using the product or nice to have). You need to work on enablers and blockers to grow.

Secondly, it’s important to consider how timely something is. In the early stages, there are a lot of things you need to build eventually, but you should prioritize things that help you move the needle this week or month. You want to ask yourself if this is important to be done now or can it be done later. If you are successful with the idea, does it help your goals?

Example: At Linear, we started only supporting Google Logins since that was the fastest way to build authentication and then move on to other features. We knew that eventually, we would have to support pure email and other login methods. This lets us move faster to learn about other features without spending our time building different authentication methods.

Weekly product development cycles

Whether you have a product roadmap or not, get your team together to discuss and decide what specific tasks the team will tackle this week.

Often with co-founders or with the team, there can be a constant stream of exciting ideas or debates. Use this one product meeting for brainstorming and discussion and then decide what is most important this week and commit to delivering on the tasks. Then get to work. Brainstorming or debating every day can be distracting and prevent the team from making progress. In the end, only shipped features matter, half-built features or winning debates don’t help your users and therefore your company.

We always assign tasks in a cycle to a specific person. This makes it clear who is responsible for delivering the task, ideally, the person is the right person to solve it and it also makes it easy to see who is overcommitted or who has more bandwidth.

As we started getting users, we would start to add bugs to our cycles to maintain product quality. Startups often forget bugs, which if left unchecked, can create enough friction that slows down your growth.

During our first months, we set our cycles in Linear to be 1-week (which we recommend for YC or generally early for the early stage):

• On Mondays, discuss end decide what to do next. Assign responsibilities and get to work.
• During the week as additional ideas or feedback came up, we would take notes personally, share them on Slack or add related tasks to the backlog but not start working or spend time debating them. This lets us capture learnings but remain focused on the work we decided to do earlier.
• On Fridays, we would review the work done, what we learned from our work, or talking to users, and then try to wrap up any open tasks if possible. The following Monday, we would start the process over again.

Don’t get paralyzed

Building with momentum

You and your whole team should always try to take swift action and make progress each day. Instead of thinking or talking about doing something, you decide to do it or not to do it. Then you do it today instead of tomorrow and this week instead of next week.

There will be also weeks when you won’t necessarily know what is the most important thing to do or you are not sure what decision to make in the product. Don’t become paralyzed in those moments–find a way to act instead. Trust your intuition and do something that seems to make sense. Talk to more users. You’ll gain more clarity as more feedback rolls in. If you’ve designed your operations to move fast and learn, then you can correct or revert decisions.

Startups rarely die because they made too much progress or because of a single bad decision, but they do die when they move too slow or give up

Build in public

It might feel dangerous to show what you’re building but often it’s more useful. If anything, your competition might be discouraged by your speed and either forced to copy you or avoid copying you.

One way to build in public is to publish a changelog. It might seem silly to summarize your work in a changelog when you don’t have many users, but we think it’s helpful. For you and the team, it reminds you every week what happened and encourages you to ship constantly. For users, it shows the product is getting better. For investors, it shows progress. At times, when you feel things not moving as fast, you can look back at how much you achieved already.

There are other reasons why the changelog can be useful. Read more: Startups Write Changelogs

Launch and keep launching

People often think there needs to be a singular moment for launch. This doesn’t have to be the case and a lot of times many startups launch multiple times. It usually works better than having one massive launch. The problem with massive launches is that it takes time to prepare and they are riskier. There is also an increased risk that the launch won’t work and all the work is wasted. By launching multiple times, you are building your story and brand over time and compounding the interested people have. Each launch builds more following, which then helps your future launches.

Secondly, in the first months or years, your product is likely not a fit for everyone. It’s better to launch early, start getting users and momentum, than trying to wait for that perfect moment.

Similar to changelogs, launching keeps reminding the market about the fact your company exists and you’re making progress.

Example: With Linear, we launched by announced the company before we had the product built. We launched when we raised seed funding and evolved the product. We launched when we opened the product for everyone and added pricing. We launched when we did a Series A and evolved the product. Each of the launches had reached more people and generated more customers than the previous ones. Had we only launched once, it would have taken us 1.5 years to get to the state and we wouldn’t have learned as much and would have as many customers as we have today.

Try Linear

While can use any tools or use no tool at all, we did create Linear to help startup teams to build momentum. Many YC and other successful startups use Linear today to manage cycles, organize roadmaps, and have that lightweight structure you need: linear.app

Active YC companies get the Linear Standard Plan free for a year. Visit the YC deals page to activate it.

Today, we’re announcing that we’ve raised $13M in Series A funding led by Sequoia Capital and a slew of new product updates aimed at re-envisioning the principles and practices of building and continue developing the best in class tool for teams to create software.

Next Generation of Startups Are Being Built With Linear

Hundreds of startups today–from early teams to growth stage companies–use Linear to develop software and build magical products and customer experiences. Linear’s tool and product development methodology is becoming the standard for high-performing teams and the 1,000 people strong Linear Slack community is a hub of builders. Startups especially mention how Linear helps keep up momentum and find product-market fit faster.

“I think that one of the things that really high performing teams do is go from product feedback and into an execution plan of how we are going to get this delivered to that customer today, this week or this month. You err towards speed of execution because that’s how you find product market fit and that’s ultimately what “make something people want” means. Linear, in my opinion, is optimized for this and where it’s best in class.”

— Troy Goode, Founder & CEO @ Courier

Tools like Linear have become even more critical as companies operate remotely. The tools are the new office and the way of making decisions and communicating ideas:

“Linear has been super helpful in transitioning to remote. Beforehand a lot of our conversations in person would ensure that nobody was doing the same work twice but now we need to have everything in Linear. Just to keep track of what’s going on. I can’t just roll my chair over and ask my coworker, “Hey, did you take a look at this.”

— Danielle Schugars, Software Engineer @ Render

The Linear team itself is fully remote and distributed across North America and Europe (we’re hiring!), and we think making a product that excels in a remote environment, means it will excel anywhere.

It’s our mission to help the next generation of startups build their companies and we’ve been especially honored to see the vast majority of our users become paying customers as we launched pricing plans this summer. This is fantastic validation of the product we have built and of course means a healthy and sustainable business for Linear.

Partnering with Sequoia Capital

Following this progress, to accelerate and to continue taking Linear to the next level we’ve partnered again with Sequoia Capital for our Series A. Stephanie Zhan who led our seed round last year will join our board. We admire and resonate with Sequoia’s and Stephanie’s long-term approach to company building and respect their exceptional track record of backing category-defining companies.

In addition, several industry leaders are participating in this round and bringing on their insights and networks: Dick Costolo (ex-CEO Twitter), Adam Bain (ex-COO Twitter), Patrick Collison (CEO, Stripe), Lenny Rachitsky (Lenny’s Newsletter, Airbnb), Harry Stebbings (20min VC) and Aston Motes (dev/color, Dropbox #1 engineer).

They will join our existing investors including Dylan Field (CEO, Figma), Emilie Choi (COO, Coinbase), Gustaf Alströmer (Partner, YC), Bobby Goodlatte (Form), Jude Gomila (CEO, Golden), Julia DeWahl (SpaceX).

The additional $13M in Series A funding brings our total funding to $17.2M. The funding and the support from our new and existing investors, give us the resources really acclerate and go after defining the new standard for software development.

Building a holistic tool for product building

Issue tracking lies at the heart of any software team’s workflow which is why we focused on solving this core pain point first. However, we know that building magical products and successful companies requires a lot more than fast and easy issue tracking. To build well, teams need a meaningful direction, clear communication and seamless coordination. Solving the human side of product management which includes implementing effective processes and then scaling them as their company grows in size as well as through different stages in the product development lifecycle.

As move to towards building product building, today we launch a few of our biggest features yet:

1. Roadmaps

One of the most important aspects when building any product or company is to set the direction. An effective roadmap shares a unified vision and aligns teams to build toward that. Without a clear direction, it’s hard for any company to make meaningful progress, especially startups who have finite product cycles available to test product-market fit before runway runs out.

Despite how critical roadmaps are to success, in many companies they’re not visible for everyone, up to date or connected to the execution of product and company deliverables. The Linear Roadmap solves this by generating a project-based roadmap–always up-to-date, accessible to all teammates and with clearly defined milestones–to encourage best practices in roadmap planning and execution.

Enable roadmaps for your workspace in settings and read more about our roadmaps in the Linear Method.

2. Extensions and integrations with OAuth

When Linear opened for everyone six months ago, we quickly started seeing companies and developers building integrations and add-ons for Linear. We see Linear as a critical tool for company building and we don’t want to lock it down. Linear should be a platform that connects with more of your external and internal tools. With this launch, we’ve added OAuth in addition to our GraphQL API, to make it easier and more secure for developers to build and use integrations with Linear.

Linear Release — Dec 2020

At Linear we like to build in public. We publish a weekly changelog to celebrate our progress and share it with our customers.

To help give a holistic picture of what is new in Linear, we created a new Linear Release page which highlights new features as well as major improvements developed in the last six months. The theme for the second half of 2020 was to improve the core experience of Linear:

• Made the interface more tactile by allowing easy list selection, drag&drop, supporting global undo with cmd+z, and having right click context menus.
• View options that let you quickly change sorting, hide and show attributes, and switch between list and board views
• Reworked our notification system to include granular controls
• Views which let you create and save custom filtered views for yourself or shared with the team or the whole company
• Made creating sub-issues more flexible
• Added SAML SSO option for more secure and controlled authentication
• Enabled themes to allow everyone to customize how Linear looks

See all the new features by heading to the Linear Release page.

Looking ahead

We started Linear 20 months ago with a simple insight: building software is becoming increasingly complicated. The current approach is to layer more processes and cumbersome tools. We want to see a world where we unwind all of this by providing the practices and tools fit to the builder workflow and letting the team focus on the act of building.

Here’s to the next 20 months. We are grateful for all the support we have received from our customers, partners and investors. Let’s make software as a craft feel magical again.

We recently added contextual menus to Linear. This makes the app faster and easier to use for people who prefer their mouse.

One small thing that you won’t see or think about but will hopefully *feel* is a detail we designed into how sub-menus work.

What are contextual menus?

You may know contextual menus as “right click” or “pop up” menus. Right click with your mouse on this post (or Ctrl+ Click with your trackpad) and you’ll see a short contextual menu appear on your screen with options to reload or save the page. Contextual menus were first popularized by applications such as Microsoft Word which added them so users could more easily copy and paste. You’ll find them in most web and desktop-based applications.

Link to tweet

Why are contextual menus useful?

Contextual menus make applications faster and easier to use when navigating a page with your mouse. On Linear, we let you take almost any action on an issue from the contextual menu: set the issue status or priority, assign the issue to a different member of your team, change the estimate, mark it as blocking or a blocker to another issue, mark it as a duplicate, add the issue to a cycle or project, copy the git branch name and even archive the issue to remove it from your active issues list.

A contextual menu in Linear

We’re learning that contextual menus are also a great tool for onboarding and teaching people how to use our popular keyboard shortcuts. You can take almost every action in Linear without lifting your fingers off of the keyboard or using a mouse at all. For instance, instead of moving your cursor to the purple plus sign and clicking on it to create a Linear issue, you can just type C.

We find many Linear users prefer keyboard shortcuts for their speed but it can take some time to learn all of them. It’s also easy to forget the less-used keyboard shortcuts such as the one that lets you move an issue between teams (Cmd / Ctrl +Shift +M). Previously you had to open the command menu with (Cmd / Ctrl + K) and then type out a search query to find a keyboard shortcut you forgot or type ? and then search our long list. Now you can simply right-click to take the action with the mouse or remind yourself of the keyboard shortcut.

How we built the contextual menu in Linear

In the first iteration of our menu, to access an item in a sub-menu you would have to move the cursor out in a straight line from the selected item onto the sub-menu, then move down from the top of the sub-menu to the item you wanted to click. You basically have to make an upside down L shape with your mouse.

The original design had a couple of problems:

One, it’s not intuitive. It feels more natural to move the cursor in a diagonal line from the selected menu item to the sub-menu item you want to click. If you did that, though, the sub-menu would disappear before you could select the sub-menu item.

Two, it takes longer. At Linear we care a lot about speed. It may only take a fraction to 1–2 seconds longer to move your mouse in an upside down L shape but the seconds add up when you’re taking the action multiple times. Some product and engineering managers take hundreds of interactions a day on Linear. Add in the time required to recoup after a menu disappears on you and the related frustration and it starts to feel like an important interaction to improve.

If you think about it, there’s no real reason why we build contextual menus that require this longer path when there’s an alternative. The shortest distance will always be the Euclidian, or diagonal, distance compared to the Manhattan distance, the distance taken when following the lines of a grid.

Diving into the code

Adding safe areas to contextual menus is not a new problem. Amazon, Khan Academy and others have all implemented mechanisms to handle contextual menus better on their web apps. Native operating systems have followed these design pattern for many years. However, it’s a detail that’s often overlooked early in a web application’s development.

There are a few ways of approaching how to build contextual menus that let users scroll easily to the sub-menu items. We thought the best way would be to draw a triangle between the mouse cursor and the sub-menu to create a safe space where the mouse could move without triggering the sub-menu to close. So we built a component to do just that.

The safe area lets you move the mouse along the shortest path without closing the sub-menu

Here’s how to build a React component that creates a “safe area”:

1. Measure the sub-menu

The component gets a reference to the sub-menu as its only prop so that it can measure its size and position on the screen.

const { x = 0, y = 0, height = 0, width = 0 } = props.subMenuRef.current?.getBoundingClientRect() || {};

2. Get the mouse coordinates

For this we built a custom hook that listens to the mouse movement. It’s used like this:

const [mouseX, mouseY] = useMousePosition();

3. Calculate the safe area

Now we have all the information we need to calculate what area to render between the cursor and the sub-menu. We need to figure out the position and size of the triangle as well as align the corners of the triangle correctly.

const positions = { x, y, height, width, mouseX, mouseY }
return (
  <div
    style={{
      position: 'absolute',
      top: 0,
      height,
      right: getRight(positions),
      left: getLeft(positions),
      width: getWidth(positions),
      clipPath: getClipPath(positions),
    }}
  />
)

The most interesting bits in the snippet above are perhaps the functions that calculate left, right, width and clipPath:

clip-path is a cool css property that lets you define a region of the component that should be drawn to the screen. In this case we use a polygon to draw a triangle.

Not too bad! It only took about 40 lines of code all in all. Hopefully people using Linear will feel the difference.

If you’re curious, here’s a gist with the full implementation.

This past year, we’ve been working on refining Linear with our early adopters. We’ve spent hours talking to company founders, managers, designers and engineers. The common theme across conversations has been how broken the current ways of working are in the software industry, the subpar quality of the tools we use to build software, and how much change a product like Linear can bring.

Engineers and creators feel that their time is drained with continuous stand-ups, retros and reviews. Teams are hindered by slow and confusing tools. These practices and tools don’t seem to improve the quality of our work but they do make us dread our jobs. We want to change that.

At Linear, we believe that the quality of software is driven both by the talentof its creators and how they feel while they’re crafting it. Teams that can focus their time and energy on the work itself build magical, high quality software.

Our tools and practices need to do their best to nurture this kind of environment and not take it away. They should be fast, integrated, save time, help to coordinate and most importantly, not get in the way of practicing our craft. This is why we’ve prioritized building an elegant, fast, and considerate product for software building teams.

Linear Method — Our practices for building quality software

To help teams create high quality software, we can’t stop at building a great product–we have to also understand how software teams work. Real change comes when tools create new habits and change our behaviors. As many of us transition to the remote age, we see new opportunities for tools to enable deep focus and better ways of working.

We’re learning about the best practices in the industry, rethinking features from their first principles, and codifying them into our product. As we build the Linear app, we’re also creating the Linear Method for software building. It encapsulates the principles, the practices and habits it enables and encourages to build magical, high quality. This way Linear can truly level up teams and let them focus on doing great work.

Try Linear with your team for free:

• Linear is available for everyone and you can get started for free with as many team members as you want, as long as you want. See our pricing if you want to upgrade
• We will continue to work on refining the Linear Method
• We are also adding documentation, Linear Guide and Gitlab integration. More on our changelog

We hope you join the Linear community and help us change how we all develop software. Sign up today at https://linear.app.

We picked up the practice of writing a changelog when we started building the issue tracking and project management tool Linear. It felt natural to share updates as our goal is to build the most streamlined tool for software teams.

Our initial aim was to share the latest product changes with our early adopters and communicate how rapidly we were adding new features and fixing bugs. In the last 12 months, we have published over 50 changelogs. After doing these changelogs for a year, it turns out it was more impacful than we ever thought.

What we learned

A changelog is a simple way to communicate your progress and culture and celebrate wins. It can be a quick way to align your team to focus on creating user value.

Momentum
In the early stages of startups, it’s important to keep moving and make progress. As Paul Graham says, startups rarely die in mid keystroke but they die because they get demoralized and give up. Having a changelog reminds you each week that the way forward is to keep making something people want.

Early Adopters
Most startups start with a core group of early adopters. These are people who are excited and willing take a risk of a newly developed software, and likely want to be part of helping to shape the product as well. Fixing things and publicly sharing the new changes and additions shows that you value the user feedback and want to improve the product for them.

Culture
Weekly changelogs help communicate that the company values execution and shipping things, which is crucial in startups. If you don’t ship your work, you are not creating value for users, and increase the value of the company. It can also be a celebratory moment for the team as a whole when team members release their first features and sees the user feedback in real-time.

Marketing
We have over a thousand people who follow and interact with the changelog updates. They find the progress, design, and other changes inspiring, and sometimes share it with their co-workers or friends, even if they are not Linear users. This spreads the word and leads to more people adopting Linear.

Recruiting
As the changelog is public, it acts as marketing for potential candidates: things about your culture, the product, and how you make progress. Most of our candidates have followed our changelog posts for a while before applying. Companies that execute fast, while valuing quality and craft, is appealing for many builders. Actions speak louder than words.

Investor relations
Likely the majority of angel investors and VCs that I met mentioned they have been following our changelog updates, and have been impressed by the progress. This means that even before talking to them, they already had some sense of how we work, how the product works and how fast we make progress. They also see the public response to these changes, further validating the product value to the users.

Investors often also evaluate the opportunities and risks of any given company. With early-stage companies, one of the risks is the execution, whether the founding team is the right team and able to build the product they envision before they run out of money. A changelog is a public way to demonstrate that you can execute on the plans you have.

How to write changelogs

Experiment to find your way and voice that works for your audience and product. For inspiration, you can check out our changelog at https://linear.app/changelog and see how we share the updates on Twitter: https://twitter.com/linear

Example changelog from https://linear.app/changelog

Our recommendation:

• Set up a schedule, like a weekly or bi-weekly cadence. Try not to slip. If you don’t have anything for a given week, try to understand why the progress is slow. Sometimes you just need to focus on large changes. We pair our changelogs with our cycle (sprint) progress Linear, so the changelog is kind of a summary of what we achieved in our cycle.
• Remember to write about things that are interesting to a human. Don’t include everything you do. Writing about database migrations is not that interesting unless it results in some performance gains or improves the user experience.
• We rotate the writing responsibility within our team. Usually it’s the person who built the feature also writes the changelog.
• Feature 1–3 larger changes, and collect all the little fixes in one section. Some of those little fixes are still important and show you care about fixing small bugs and annoying things that users might encounter.
• Depending on your audience, try to figure out what is the right voice. Technical audiences likely appreciate more technical details, but others may not.
• Include one or more screenshots or videos of the features if possible. This makes it more engaging and sometimes easier to get the gist of the change, especially for people who are not familiar with your product. We include a screenshot in the post, and then share additional videos on Twitter.
• The tool doesn’t matter, the important thing is that you write the changelogs. You can write them in plain text, put them on Github, use Notion, blog, or share screenshot on Twitter. We write ours in markdown which is then rendered on our next.js based marketing website.
• We then also share this on our Twitter account with product screenshots or demos of added features.
• We also allow people to subscribe to the updates newsletter during onboarding. You can copy the content from your changelog post, and paste it to newsletter tools like Revue or Mailchimp.

Subscribe to updates on https://linear.app

So write changelogs. It’s an easy and low-effort way to keep the momentum, get new users, recruit, and build investor relationships. All things that help your company to be more successful.

If you start writing a changelog after reading this, let us know by tweeting us at @linear or @karrisaarinen.

That’s why today we are excited to announce that we’ve raised a $4.2M seed round, led by Sequoia Capital with participation from Index Ventures and others.

This is a big milestone for our team and we wanted to share a bit about our progress and what this means for the future of Linear.

Our path so far

In April of this year, we shared our story and vision to create a more enjoyable and effective way for teams to track issues and manage software development (read the announcement here). We want to bring some of the magic back to computers and software. The software you use daily to accomplish your work should be of the highest quality. It should feel exciting and enticing. It should be fast and you should feel empowered when you’re using it.

The need for a new solution to help product teams came from our personal experiences of designing and building software for successful and fast-growing companies like Uber, Airbnb, and Coinbase. We grew frustrated by how slow, lacking and disconnected they were from today’s best practices, and how little they helped our teams to coordinate and align our work, and deliver high-quality software.

We realized there was a lack of tools solely focused on managing software projects. We also noticed a correlation between teams’ emotional connection to their work and their output and outcome. Teams that are inspired, engaged and proud of their work end up creating better software. The tools we use daily are in a position to help us maintain this inspiration and excitement (as well as steal it away from us).

We were happy to see how much our vision has resonated with other engineers and designers. Since our announcement, we have had thousands of small and large companies sign up to our waitlist, and have heard across the board that teams are eager to upgrade to a solution like Linear.

Today, hundreds of companies are using Linear daily to build software. We are especially excited to support next-generation companies like Pitch, Render, Albert, Curology, Spoke, Compound and several new YC startups like Middesk, Catch and Visly. Many companies have mentioned that they want their teams to use the best tools available since they themselves want to build the best products for their respective markets.

Our investors

To help us scale with the demand for our product, we are excited to partner with Sequoia Capital (Stephanie Zhan) as our lead investor on our seed round. This funding brings with it the opportunity to learn from Sequoia’s long history and tribal knowledge supporting category-defining and enduring companies. We are also thrilled to have participation from Index Ventures (Sarah Cannon) who has backed many existing and upcoming next-generation tools.

In addition, many experienced operators and angel investors are participating in the round. These investors will also advise the company and they include Dylan Field (Founder and CEO, Figma), Emilie Choi (COO, Coinbase), Charlie Cheever (Co-Founder of Expo & Quora), Gustaf Alströmer (Partner, Y Combinator), Tikhon Berstram (Co-Founder, Parse), Larry Gadea (CEO, Envoy), Jude Gomila (CEO, Golden), James Smith (CEO, Bugsnag), Fred Stevens-Smith (CEO, Rainforest), Bobby Goodlatte, Marc McCabe, Julia DeWahl, Dan Romero and others.

The path forward

We will continue to focus on creating the best possible issue tracking experience for our core users. Linear will remain a fast and powerful interface to your team’s work that gets out of the way, integrates well with their workflow and lets individuals focus on their work.

Secondly, we want to evolve industry practices. We believe next-generation companies should also use next-generation practices. We want to work with the most forward-looking companies in the field and evolve everyone’s practices around how software is designed and built. Linear will embody these best practices and help teams run their day-to-day coordination more efficiently, reduce wasteful meetings and bring all of their focus back to meaningful work.

To maintain the momentum (weekly changelog) as we grow, we are expanding our founding team. We are looking for people who believe in the mission of building great software. As we see the remote and distributed work model becoming the new norm, we want to help build other companies as well as our own with this model. (See our remote job openings).

Thank you for joining us on this journey. We deeply appreciate your support, and we will never take it for granted.

If you want to try out Linear in your team, sign up for the waitlist