Taste Is Leverage: What Linear's Craft Culture Means in the Agent Era
Nov 2026Small teams, no OKRs, and my bet that the people who can say no become more valuable as agents get better at saying yes.
Why this is on my mind
Linear is the company designers point to when they say craft can be a strategy. I wanted to separate what Linear has said publicly from the folklore around it, and then ask what it implies now that agents can build a lot of software.
What's true right now
Craft was a deliberate strategy. Co-founder and CEO Karri Saarinen has said Linear started with quality and then found that people noticed, because it's a rare approach, especially for startups, as summarized in Figma's write-up of his ten rules for craft. The rules include committing to quality at the leadership level, keeping teams small, treating the spec as the baseline rather than the finish line, and recognizing that quality is a continuous standard, not perfection. He also argues that to deliver a great experience you sometimes have to surprise users, because neither data nor users themselves will tell you how.
The operating model is unusual. In a Lenny's Newsletter profile of how Linear builds product, the framing is taste over metrics, product teams over product managers, and strategy over OKRs. In the Q&A, Saarinen says Linear hasn't used OKRs and prefers that the broader team collectively thinks about how features are delivered instead of assigning a PM to every area, per the same piece.
The values are written down. Linear's careers pages say that while much of the industry optimizes for speed and metrics alone, the company believes craft and quality have lasting value, and that quality creates gravity that pulls people toward the team and product. The company also publishes its approach as the Linear Method, which one summary describes as an opinionated software philosophy built around ideas like cycles instead of sprints and paid work trials for hiring.
Craft meets AI inside the company too. Linear's design hiring materials link to a feature on how Linear's design team uses AI, so the company is treating AI as part of its design practice, not a threat to it.
A caution: plenty of third-party pages describe Linear's headcount and internal culture with confidence. I've left those out because I couldn't verify them against anything Linear has said itself.
What holding the bar means day to day
Illustrative: my own sketch, not a sourced fact.
A bar is something you can point at. If the spec is the baseline and not the finish line, then someone has to know what sits above the baseline. I picture that as a short written standard plus a person who will say no against it. Without both, quality is a mood, and moods do not survive a busy week. A short list of examples does more than a long list of principles, because examples show where the line actually sits.
It is a continuous standard. Saarinen's point that quality is not perfection matters here. Holding the bar does not mean rejecting everything. It means the gap between what shipped and what was intended stays small and visible, and someone owns closing it each time. If that gap grows, the bar has quietly moved, and it is better to notice that early than to find it in a review months later.
My hypothesis
This section is my opinion, not a sourced fact.
As agents make building cheap, the scarce resource in software teams becomes the number of people with the taste and authority to say "no, not like that," and small craft-led teams gain an advantage over large ones.
The mechanism: in a large team, quality is diluted by consensus (Saarinen's own argument about opinions piling up). When agents can produce ten plausible implementations in an hour, the bottleneck is no longer production, it's judgment, and judgment doesn't parallelize across a committee. A small team where every member holds the bar can govern a very large amount of agent output. A large team without a shared bar just produces a very large amount of inconsistent output faster.
If that's right, headcount stops being a useful proxy for capacity, and "how many people can reliably hold the quality line" becomes the number that matters.
Where I would not trust the small-team bet
My opinion, based on the tradeoffs above.
One owner is also one point of failure. A single person reviewing everything against a written bar is fast and consistent, but they get tired, they get busy, and they have blind spots. I would want to know what happens to quality the week that person is out. A backup reviewer who has been trained on the same written bar seems like the cheapest answer, though I have not tested that.
Taste can be a polite word for preference. Linear's approach works partly because the team shares a bar. If a small team's taste is narrow, agents will just scale that narrowness faster. I would not assume that small and craft-led automatically means right. I would check whether users actually feel the difference. The check I would use is simple: can someone outside the team tell which of two screens came from the more careful process?
How I'd test it
Compare two teams building the same feature with agents: one with a single owner who reviews everything against a written bar, and one with distributed approval. Measure rework rate and design-system violations after a month.
What would change my mind
If automated review (linting taste into checks) gets good enough that quality no longer depends on a few people's judgment, the advantage of small teams shrinks and process can substitute for taste.
What I would do first on a real product
Illustrative: my own sketch, not a sourced fact.
Write the bar down before using agents. I would start with a page that says what good looks like for this product, with a few examples of yes and a few of no. It does not need to be long. It needs to be specific enough that two people would reach the same verdict on the same screen. Keeping it short matters, because a long document becomes something people agree with and then ignore.
Then count who can apply it. I would ask how many people on the team could review agent output against that page and agree with each other. If the answer is one or two, that is the real capacity of the team, whatever the headcount says, and that is the number I would plan around. It also gives me an honest answer to how much agent output we can safely govern, which headcount never could.
References
- Figma, Karri Saarinen's 10 rules for crafting products that stand out
- Lenny's Newsletter, How Linear builds product
- Linear, careers page
- Glama, Karri Saarinen episode summary (Lenny's podcast)
- Designer Fund, How Linear's design team uses AI (linked from Linear's hiring materials)