Linear's method trades detailed specs for speed and trust

What the company's materials describe

Linear's about page states the company was founded in 2019 by Karri Saarinen, Jori Lallo and Tuomas Artman, and says the issue tracker is now used by more than 40,000 companies, naming OpenAI, Coinbase and Ramp among them. That is a current claim from a living page, not a founding-day measurement, and should be read as such. The product itself is an issue tracker: work is logged as issues that can be split into sub-issues, marked as blocking or related to other issues, grouped into cycles, and moved through custom statuses, according to Linear's documentation. None of that is unusual by itself; other trackers offer similar objects. What distinguishes Linear is the opinion published alongside the software about how those objects should be used.

An opinion, not just a feature set

Linear's own published method argues directly against a common practice: writing user stories before writing an issue. It calls the format a cargo cult ritual that feels good but wastes a lot of resources and time, and instructs that everyone on the team should write their own issues rather than delegating that writing to a product manager or dedicated ticket-writer. The stated reasoning is that writing an issue yourself forces a person to think through the problem at a deep level, and that user-experience discussion belongs at the product-planning stage, not repeated inside every task. This is an editorial framework published by the vendor, not a study; it describes what the tool wants a team to believe about process, which is different from evidence that the belief produces better outcomes.

What accepting the opinion costs

The method's own logic states the trade plainly: a team gains speed once planning is done, in exchange for accepting thinner, less prescriptive written requirements. That works when the people writing issues already understand the user and the problem well; the method openly assumes a team that understands the user experience intuitively. A team without that shared understanding, or one that relies on detailed specifications to coordinate across time zones or with external stakeholders, would be adopting a documented gap along with the tool. The keyboard-first, high-speed interface that draws people to Linear works the same way: it rewards people who invest in learning shortcuts and can feel unfamiliar to occasional users who expect a tracker to behave like a form.

Questions to ask before you adopt it

• Does your team already share enough context that brief issues would replace, rather than lose, necessary detail?
• Who is expected to write issues under this method, and do they have time to do it well?
• What happens when an external partner or client needs documentation more detailed than an issue provides?

Linear is explicit that its tool encodes a philosophy, which is more honest than pretending a tracker is neutral. The question worth asking is not whether the philosophy is well argued, which it is, but whether a given team's actual working habits match the assumptions it makes.