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.