Quality

Quality

• Quality is the north star. Evaluate every decision by “does this improve quality?”, not “will this ship faster?” Speed is a byproduct of a small team that already knows the standard. Karri Saarinen (@karrisaarinen), Why is quality so rare? (opens in a new tab).
• The spec is the baseline, not the finish. Meeting the ticket is the start of craft. A job board that “works” and a job board a dispatcher will live in for eight hours are different products. Karri: “It’s easy to meet the spec. It’s harder to do the craft.”
• Quality is not perfection. Start rough. Iterate toward polished with real operators. Defects are countable; excellence is not. Don’t hold a surface hostage waiting for a mythical last pixel. Karri, rule 6.
• Reduce scope to raise quality. The simplest way to make something better is to do less of it, then do that part exceptionally well. A half-finished second view is worse than one view a dispatcher trusts. Karri, rule 8.
• The best design is opinionated. Design for the operator in front of you. Broad flexibility is how products become mediocre. Purpose-built software does the heavy lifting; flexible software makes every team invent a workflow. Linear Method: purpose-built. Karri, rule 7.
• No handoff. The person who shapes the surface stays on it through implementation. PM decides, designer visualizes, engineer builds, that assembly line is how quality dies. Connected teams, shared issues, engineers in the first design review. Karri, rule 3. Ryo Lu (@ryolu_) ships the same way at Cursor: the designer writes the interface.
• Small teams, judgment over committees. Three to five people with taste beat a large review. Hire people who already show craft. Give them a standard, then get out of the way. Karri, rules 2 and 9.
• Data is a crutch. A/B tests will not tell you the surface feels cheap. Talk to operators. Trust the sense of rightness. Metrics confirm; they do not invent taste. Karri, rule 10.
• Papercuts every week. Quality is not an individual sport, you cannot see the defects in a UI you built. Tuomas Artman (@artman) made this a Wednesday habit at Linear: each engineer finds and fixes one papercut (inconsistent 150ms fade, a row that jumps a pixel, a menu that isn’t keyboardable). Thirty minutes. Like brushing your teeth. Quality Wednesdays (opens in a new tab).
• Bugs close in seven days. A known defect that sits is a decision to ship lower quality. Linear’s zero-bugs policy: fix it within a week. We keep the same clock. Tuomas Artman (@artman), Why we committed to a zero-bugs policy (opens in a new tab).
• MVPs stay internal. Incomplete products are for us. Operators get a finished job, even if the job is small. Do not A/B a half-built dispatch board in the middle of the working day.
• Build for the operator. Linear Method: build for the creators. Keeping the individual productive beats generating perfect reports. In Thorbis the creator is the dispatcher, the tech, the owner, not the admin reading a quarterly dashboard.
• Say no to busywork. The tool works for the operator, not the other way around. Remove or automate work-around-work. Don’t invent terms: a project is a project, a job is a job. Principles & Practices (opens in a new tab).
• Decide and move on. There isn’t always a best answer. Make the call, ship, watch an operator use it, correct. Momentum over deliberation. Linear Method: create momentum, don’t sprint.