I've admired Linear from a distance for years. The product feels considered in a way most software doesn't, and I always assumed there was some secret behind it. Some process, some genius, something.
So I gave myself a challenge: read everything in their Craft series, take notes like a student, and find the secret.
There isn't one. There are just habits. Small, boring, consistent habits that most teams know about and don't do. That's somehow more intimidating than a secret, and a lot more useful. Here's what I'm taking with me.
Quality is a habit, not a project
The thing that got me wasn't their famous redesign. It was Quality Wednesdays.
At an offsite, their CTO showed engineers a clip of three buttons. One faded out instantly on hover instead of over 150 milliseconds like the others. Nobody could spot it. Not even after several replays.
So they made a ritual: every engineer fixes one small papercut a week. Not bugs, just things that degrade how the product feels. Under an hour each, shown at Wednesday standup. Two years later, that's 1,000+ fixes.
But the fixes aren't the point. The point is the team trained its eye. Everyone would catch that button now, and fewer papercuts ship in the first place. You can't buy taste, but apparently you can train it, one hour a week.
The other thing that offsite proved: every person noticed flaws nobody else could see, including in their own work. Quality isn't an individual sport. You need other people's eyes on your product, regularly and on purpose.
A backlog is a polite way of saying never
Linear runs a zero-bug policy. Every bug is either marked "won't fix" or fixed within a deadline: two days for high priority, seven for everything else. The backlog isn't an option. They deleted it.
Their reasoning is almost embarrassingly simple: fixing a bug costs the same whether you do it now or in five years. The only difference is how long users suffer.
The side effect is my favourite part. Someone reports a bug in the morning and finds it fixed by lunch. A bad experience becomes the best support interaction they've ever had.
Design the problem before the solution
Karri Saarinen wrote something in Design is more than code that I keep coming back to: design projects usually fail because the problem was never clear. Stakeholders fight over solutions because each is quietly solving a different problem.
His fix is unglamorous. Write the problem down. Name the stakeholders. Repeat the problem back every time you present. If restating it causes a reaction, stop and align there, not on the mockups.
It stung a little because the industry is moving the other way. AI makes execution cheap, so the temptation is to skip the thinking and just build. His warning: you'll iterate fast, but toward a direction nobody actually chose.
Pay design debt in big sweeps
Linear ships daily, and they're honest that this is exactly what unbalances a product over time. Their answer, from A design reset, is a full reset every two to three years. Not incremental patching. The experience is holistic, and fixing one view at a time makes the whole thing more disjointed, not less.
Two tricks from how they ran it:
Call early work a "concept." Borrowed from concept cars. People attack designs; they entertain concepts.
Tie the redesign to where the company is going. Redesigns don't survive without the CEO behind them, and you get the CEO behind them by connecting the reset to a larger shift in direction.
I'd add a third: cut scope on purpose. Mid-exploration, Karri dropped navigation entirely when it turned out to be an engineering problem, not a design one. Ambition in the concept, ruthlessness in the scope.
Make iteration cheap, then iterate a lot
Their 2026 refresh was done by two people who'd been in the codebase for two months. Tooling made that possible: a dev toolbar that toggles old and new UI in one click, everything behind feature flags. When tuning the new colour palette got slow, they used a coding agent to build an internal colour tool in a couple of hours, so anyone at the company could tweak design tokens and share their recipe.
The lesson isn't "use AI." It's that when trying a variation costs nothing, you try more variations, and the work gets better. Build the tool that makes the loop fast.
Also from that piece, two questions I'm stealing for every design review: has this element earned the attention it's asking for? And can this structure be felt instead of seen? Plus my favourite line in the whole series: if most people don't notice what changed, that's probably a good sign.
Quality is a business strategy
This is the argument I'll borrow the next time someone asks why polish deserves a week on the roadmap. From Why is quality so rare?: Linear was profitable by year two and had 10,000+ paying customers by year four with effectively zero marketing spend. Quality creates gravity. One team experiences the product, tells another, and adoption spreads on its own. Craft is distribution.
How they do it underneath: teams of three to five using judgment instead of committees. No design-to-engineering handoffs; the whole team iterates until it feels right. MVPs stay internal. Intuition and customer conversations over dashboards. Karri is openly suspicious of "does it convert?" replacing "does this feel right?"
My challenge, going forward
Reading is easy. The hard part is Monday. So, three commitments:
One papercut a week. Find one small thing that degrades the feel of whatever I'm working on, and fix it. Under an hour.
Write the problem first. One paragraph before any new design work: the problem, the stakeholders, what happens if we do nothing.
Build the tool when the loop is slow. If I repeat a tedious mockup-review cycle more than twice, I stop and make it instant.
None of this is complicated. That's the lesson. Linear's craft doesn't come from genius or secret process. It comes from a team that decided quality matters, then built unremarkable habits around the decision and never skipped a rep.
A team worth admiring. More importantly, one worth copying.