Taste & Craft: A Conversation with Tuomas Artman, CTO Linear & Gergely Orosz, @pragmaticengineer

Awesome. So we didn't see it, but hands up if you do use Linear. And hands up if you've heard of Linear. And hands up if you want to use Linear. Awesome. Great to see you. So we could be talking about Linear, but we're going to be talking about something a bit bigger, which is a bit of a new trend that, with Tuomas, we're talking about things that are trending the wrong wayright now.

What is trending the wrong way?

The so

what happens when agents are capable of doing everything immediately for you. The fact that might be that the pendulum has swung too far into the wrong direction, where if you get a feature request, you might now be in the position to just immediately ship it.

And that might be the wrong thing to do. And I reckon that, hopefully, half a year from now or a year from now, we'll understand that shipping things without really too much thinking is a bad thing. What will happen is that you, because you have this enormous power of effectively just shipping every single request that comes in or every single thing that pops into your head, you will effectively ship a software that is not great.

Steve Jobs back in the day said that great products come out of saying no to 999 things and yes to one thing. And with AI, we might be in a place where it's just too easy to say yes and try things out and ship it and get to a very convoluted place where software actually doesn't work for the end customer nicely anymore, or that the user experience gets confusing.

We used to previously have this thing that gated us from doing this, which was the actual engineering used to be hard. So we used to think about these features and the applications that we wanted to build before we actually started engineering, because engineering was such a waste of time, and it took a long time to ship something.

So yeah.

But I want to challenge you a little bit on that. Did we not see this happen before AI, that some companies were already just shipping, putting on a bunch of features and stacking? And what are you seeing differentright now?

Are we actually seeing more companies do more of this, I don't know, feature factoring thing?

We had a common experience at Uber where we worked together, where we went through hypergrowth. And the thing about Uber was that it was a winner takes it all market. And Uber was going against Lyft back in the day in the US.

And you just had to ship immensely and just outpace the competition at all costs. And what I saw at Uber was that hypergrowth that I never want to go through again, which was at all costs, just fighting fires, keeping the infrastructure running, scaling as quickly as possible, trying out everything, and trying to come out as a winner in that front.

And I see the analogy to AI nowadays, because when everybody has the capability of shipping tons of functionalities, you always are in a competition with somebody else. Your competition might be a small team or even one person that is very capable of using AI to ship and build a product that has the same features that you do.

And in that world, I think it becomes important to stand out in a way where you build tasteful software and where you build high-quality software and thus maintain some sort of competitive advantage towards your competition.

So at Linear, even before AI came out, you were building tasteful software and focusing on those things. But then these tools came out, and they became more powerful. Specifically, since Claude Code came out, now we have Opus 4.5.

You should be able to ship faster. Your engineering team, you're a CTO, your engineering team should be able to ship a lot faster. What are you telling them? What should they be doing inside of Linear with this capability?

Should they be slowing down? No. Right? What's going on inside of Linear? Tell us.

Well, yes and no. We still think about every single feature that we put out. We don't go down the route of just trying out prototypes. We want to maintain that design angle that we have and think about the user experience, still say no to a lot of custom requests.

A lot of time hasn't gone into really just engineering. It's about figuring out what the customer wants. We do get a ton of feature requests. We usually never ship them as such. What we really want to do is get a lot of feedback from our customers, talk to our customers, figure out what their actual problem is, and then group that together and figure out what is actually the root cause of these feature requests, and then come up with a solution that is perfect for that particular group of feature requests.

And that takes time. AI can help you so much. Obviously, it can go through all of those requests and give you a summary and maybe point you to different groupings. But it still takes time to figure out what theright thing is.

And then you go into design and figure out how do you implement a great UX around the functionality that you want to build. Yes, we want to move faster, and we are moving faster. There are certain aspects of building a product that has accelerated a lot.

One is, for example, fixing bugs. Every product has bugs, and the inflows of bugs is effectively constant. And those are much easier to fix now. 10% of our bugs are automatically fixed by a single-shot AI instance. When a bug comes into Linear, be it from our engineers reporting those or a customer reporting a problem, 10% are automatically up with a PR and automatically land it without an engineer doing anything.

Over time, that will go up. I do foresee a future where it gets closer to 100% in the next few years. So that's something where you can accelerate your building. Hand off these tasks that don't really require much thinking or design expertise or thinking about functionality.

Hand that off to agents.

You care about quality, and you can tell at Linear, and you have always had. Let's talk about Claude Code. What do you think about Claude Code? And it's a safe space.

Yeah, hopefully it's a safe space.

Anthropic said that all of the functionality in Claude Code has been coded by Claude. And I think it shows. If you truly use Claude Code, either the CLI or the desktop application, you can spot problems and

small bugs, I would say. There's not really just quality fixes, but they're actually bugs in effectively a few seconds. It is a bit slow. It might be functioning in a way that you don't really see. And to me, that's sort of a side effect of moving so fast.

Obviously, again, they are in a competition with OpenAI, and they need to ship features, and they need to move really quickly, because it might be a winner takes it all market again. And the side effect of that is that the quality just isn't there.

Yeah, well, this was not a great acquisition pitch, so I don't think you're going to get there. But I absolutely you can see some of these things. But how do you measure quality? And we've talked about this before, just before we started, on Uber, how we try to measure quality and how that's influenced you to learn what you can measure about it and what you cannot.

Uber is a good example of where it is immensely hard to measure quality, and therefore you sort of don't. Uber, as an example, we had these five big metrics that everybody was looking after and looking to improve. The big one was revenue.

It is effectively a transactional application. The more revenue you generate, the better.

And the other ones were like trips taken.

Trips taken.

Trip taken.

I think the quality of the ride was one as well.

And also time to first trip, from sign-up to the first time that people did. So we had a few golden metrics.

Right. But the revenue one was that everybody looked after. So when you shipped a new feature or shipped something totally new, like Uber Pool, for example I don't know which one came first, Lyft Pool or Uber Pool. I think Uber started it, and then Lyft came around.

But obviously, if you ship a new feature that makes the price of taking a trip lower, it will increase your revenue. So how do you measure quality in that? You simply don't. If there's no other way of if there's no other platform that provides you with a pooled ride that is inexpensive, then you don't really need to have quality.

And that was my feeling throughout at Uber. We had engineers that cared. At least in the beginning, we had engineers that cared about quality. It was up to us to figure out whether something we shipped was great or not.

I still remember when I joined in 2012, I think, I put up a first PR. And back then, the Uber application used to have this pole in the middle of the screen that used to have an ETA of when your trip is going to arrive.

And I made some changes to the margins of the map. And the PR came back from an OG engineer who was on the team from the get-go. I think he was the first iOS engineer. And he was like, oh, this pole is off by two pixels.

And I was like, you measured it? Oh, yeah, sure. I measured it. And I was like, I measured it again. And yes, two pixels off. So I had to move it up by one pixel. And nobody would really care.

Nobody would see it. But people were keen on upholding the quality. And that's why, at least in the beginning, the Uber application was pretty performant, was of highest quality. But then, once you have a big enough team and you've got these incentives of just increasing revenue, you ship new features as quickly as possible.

And quality is a thing that it doesn't affect your revenue until it does. So what happens? Uber ships Uber Pool. Lyft comes ahead and ships Lyft Pool as well. So you've got two competing products that effectively have the same price points, do thus the same thing.

You can choose either one of the applications. And over time, my theory, and that's why we want to build Linear into this high-quality tool, is that over time, people will pick the one that is of higher quality. It might take a while.

People might be sticking to Uber and then trying out Lyft once a year or something. Opening it up, me like, oh, this user experience actually feels better. I feel like I'm getting the car faster, even though the price and the product that they sell is the same.

So over time, you will start losing your users. And it will be a gradual slip. There will be no A/B test that you can do in order to figure out whether you should invest in quality. It'll just happen over time.

And that's the danger of it. If you build a bad quality product, you open up yourselves to be leapfrogged by a competition. Well, not leapfrogged, slowly overtaken by the competition.

You do something really unique at Linear related to this that I've never seen before. It's called Quality Wednesdays. And I sat into one of your Quality Wednesdays. The whole engineering team gets together. It's a formal team, so everyone just dials in.

And it was 30 minutes. And every engineer I think we had about 25 engineers on that call would show one fix that they did was quality. And it went from a one-pixel change. It was literally a one-pixel to, oh, I just made our backend way more efficient and using less things.

And it was just boom, boom, boom, boom, boom. And I think it took 37 minutes for the 25 people, but it was less than two minutes. How did this start? And was this you?

It was me, yeah, for sure.

The big one was like I mean to go back, I think it was three, four years ago. We have this thing in the application. If you use it, you can spot it. Every single highlight needs to highlight instantaneously when you hover over it, because that makes the application feel fast.

But when you hover out, there needs to be this very quick fade out of a button, because that makes the application feel smooth. It has to be this instantaneous highlight and then over 150 milliseconds fade out, because that adds a bit of quality to the user interaction.

And that was in place since the beginning, the early days. And then I got frustrated, because I had to point this out to engineers. Because if you're not looking for that very small, minute detail, you're just not going to find it.

You implement new functionality, and you just forget to implement it, or you don't even see it if you don't know what you're looking out for. So what I did at one of our offsites, because I got frustrated of reporting these, I was like, let me show everybody what they should be doing and how they should be implementing these small quality fixes.

And what I took is a very small portion of the application. And it was like where I noticed that the highlights were missing. And I brought the team together, and I told them, let's spend an hour trying to figure out what's wrong with this particular view.

And in my mind, it's about just the highlights. And everybody ducked in. And what we found, it was one of the view option menus. We found 35 problems with that tiny UI. And I was, holy crap. I didn't see those.

I had no idea that we had all these small problems that you wouldn't notice when you're not really looking. So from that, what I thought we would want to do is have everybody always chime in and try to find problems in the product, because apparently, we were full of small quality problems.

If a small menu has 35 things to fix, then the rest of the application has thousands. And to date, we've probably fixed 2,500 or 3,000 of these small, minute details in the application. And that's how it has become better and has the highest quality bar.

That was the start of it. But then we realized there's a nice side effect to this. And what we told people is that every Wednesday, you have to find a problem yourself. We won't hand them to you. You have to go into the product and find it.

So people started doing that every single week, finding a problem. And it used to be in the beginning, it was easy. Then it became harder, because the quality fixes went down. But people kept on finding problems in the product.

And the side effect of that was that everybody was, whenever they were building something, totally unrelated feature, they were always on the lookout for these small quality fixes, because they knew they had to come to the next Wednesday meeting with a fix.

That's a good word, fix, then.

Yeah. So they were always looking for those. And that meant that they were introducing less and less regressions or at least small quality regressions into the product anyway. So if you think about quality all the time and if you are aware of quality things, then you're bound to make less mistakes.

I mean, this practice, I haven't seen it elsewhere. And it seems both awesome, also pretty aspirational. So I mean, if you're a small startup, you should probably try it out if you can, because especially nowadays with agents, it shouldn't be that difficult to do.

And you might get.

If you're a big startup, you should even more try it out.

There we go. But one thing that is not as aspirational and a lot easier to do, especially now that you have been doing, even before agents, zero bug policy. Tell me about this. What does zero bug policy mean for you?

And what does it mean in practice? You have bugs, surely,right? I'm just playing devil's advocate here.

Sure. Zero bug policy literally means that if a bug gets reported, it gets assigned to somebody automatically, immediately, using agents, obviously. They will find who has created this bug or who has been working in this area. And that becomes your highest priority.

You drop everything else. The morning you wake up, you go to my issues list, and you see a bug assigned to you. That's the first thing you pick up and you fix it. Or you can also decide not to fix it.

That's important. Not every bug gets fixed if it's super hard or gnarly and it applies to 1 out of 100,000 users. You probably shouldn't waste your time on it. But every single bug gets fixed immediately. And the start of this came from the idea that bugs are created at a constant rate at every company.

When you create features, when you create functionality for any engineer, you will be creating bugs. And most of the companies, and we prior to our zero bug policy, we put them in a backlog. We're like, when we get some time, we'll fix them.

And what happens over time is your product gets worse and worse. And at some point, you're like, oh, man, we've got 500 bugs in the backlog. We need to do something about it. And that's when you start fixing from the top.

And what happens is that the rate at which you have to fix bugs is, again, constant. It doesn't matter whether you fix them two months from now or immediately. Once you hit that threshold of we've got so many bugs, you're now effectively fixing all the bugs that come in except two months later.

So with that small notion in mind, there's a very small trade-off that you have to do in order to get to zero bugs. If the rate that you have to fix bugs is constant, all you need to do is stop development of new features for as long as it takes you to bring your bugs to zero and then enforce that you're going to keep on fixing your bugs.

Because it's not more effort to fix bugs immediately than to fix them three months from now if you care about the overall sum of your problems. So to us, that meant we spent effectively three weeks of not working on any new functionality, of just fixing bugs, getting that down to zero.

And from there on out, every bug gets fixed within seven days, usually in two hours or three hours. And what that means to users, users get super excited when they report a bug. And two hours later, they get an email saying, oh, we fixed it.

If you refresh your browser, we've got it covered for you. That makes your users super happy, because you don't really have that experience too often with companies.

OK, curveball question. If I'm working at Linear and there's a Quality Wednesday coming up and I get assigned a bug, does that count?

No, that does not count. That's a defect. You have to find a quality fix.

Oh, man.

Bugs are separate. They are immediately created. And now with AI being capable of at least pointing you where that problem is and helping you immensely fix bugs, I think literally every company should have a zero bug policy. It doesn't make sense to not have one.

One thing that when we talk about and think about AI agents, we think about speed, code generation. We rarely use quality and AI agents in the same sentence. Why is that? With the tools getting better, should AI agents not be better to have feedback loops?

You know they can write unit tests. Should they not be able to produce better features, better UIs even?

No, they don't feel. They have no taste.

They simply don't. They are not human beings. I think the last question that we'll have to tackle at some point, and maybe we'll get there, maybe we won't, is have tasteful AI being able to create UI that is purpose-built for that specific feature you're building for, the product that you're building, has great design, and has the ability to figure out what a user feels when they use your application.

To give you an example, AI doesn't have a concept of time. And currently, how it interacts with your browser is effectively timeless. They take screenshots, or they look at the DOM. And if you ask it to create a very high-performance application, yeah, it can go back and look at all the things that have been written about, like go to Vercel to host your next app or use caching or whatever.

But it won't be able to use your application and get frustrated because a click took two seconds. It knows that one second is better than two seconds, but it doesn't know whether two seconds is slow enough. The other aspect that goes into it is it doesn't really see.

And it doesn't know what, for example, a good use of animation is. Emile, one of our design engineers, just yesterday posted on X where he did this trial of having agents build certain animations for certain functionality, like bringing up a pop-up or highlighting a button or moving things around.

And agents were totally capable of doing all of this. And then he took a manual step and was like, well, if I now take it and just improve it and make it feel good, here's the outcome. And he has it up on his side where he can try out what the agent did and what he then fixed.

And at least to me, and I hope everybody else, his animations just feel natural. They feel like they're well-designed, whereby the agent did all theright things but had an ease in as an animation or did it a bit too slowly or too quickly.

And it just felt unnatural.

I wanted to talk a little bit about the culture at Linear, what it's like working there, how you created this team that really cares about quality, good customer experience. What are things that you do specifically there? Can we talk about it?

What engineers are exposed to who joined the company from day one?

Yeah. We hire for that specifically. And we have a specific hiring process where we make sure that we get people that think like us and want to build high-quality software that is beautiful. Most of our engineers are product engineers.

We obviously do have technical challenges. We have a synchronization engine. We have scale. We need to scale our infrastructure. But what we wanted to do is have most of our engineers just be focusing on the product and build features and functionality for customers and engage with the customers at a very high level.

So first of all, we hire for that. We have a work trial that we do with every single employee that.

It's like several days,right?

It's a full week.

It's a full week.

So we obviously pay for that effort. But we work with a person for a full week. They usually implement a greenfield project or product or feature. Sometimes they even ship it after that week, which is pretty amazing. But what we want to get out of that experience is just to see them drive a product from start to finish, figure out what is needed.

So a pushback here would be like, hang on, a whole week. You pay for it, sure, but someone has to take time off of it. A bunch of great people will say, no, I either cannot or will not do that.

Well, that's totally fine. Those people didn't want to be here in the first place. So

it's a self-explanation.

But after you go through this pretty rigorous hiring process, it's a lot longer than I think any other process. I mean, you have a day-long process. At most places, they're stacked across. Did you see any different result than, for example, when you hired at Uber?

When you were hiring at Uber, you did the usual, like five interviews, six interviews, and so on. What's the outcome difference that you're seeing?

Certainly. We've had very few misses. Most of the people that we've hired, and sure, there always are a few where we just missed something. And going back into the loops, there's inklings of us being a bit uncertain. And then we went ahead and hired the person anyways.

But those are just like a few, a handful of people. I think most of our engineers are really excellent. And our engineering bar is super high and constantly increasing.

And then once those engineers enter, you told me something interesting about the Slack channels and customers.

Right. We do have Slack channels with all of our big customers. It's open to anybody. Anybody can jump in. And most people do. You browse through customer requests. You browse through what problems people have. And we also record every single meeting that we have with customers.

And we have a lot of meetings, not only on the CX side or support, but our PMs have constantly talked with larger customers to figure out what we should be building next. And all of those are recorded. And any interesting points are tagged.

So anybody can go in and then look at and even search for certain functionality and figure out what are customers saying, what do they want. So everybody gets exposed to customer needs. And that is super critical if you want great product engineers.

It's almost like if you enter Linear, you get this fire hose of what are customers' feedback. And you cannot really escape seeing and feeling the customer pain or joy or whatever that is.

Certainly, yeah. Because we built it for customers. Linear started off as a product where we built it for ourselves. We, as engineers, were the primary customer. We've grown out of that. We built it for larger corporations and enterprises.

And we are no big enterprise. So we have to build things that we wouldn't use ourselves. And the only way to do that is to talk with your customers and figure out what they need.

If you had to look a year ahead, you sometimes have strong opinions. So let's bring those out. A year ahead, how do you think the role of the software engineer or product engineer will change? Because we do have these powerful tools.

They're getting better in certain areas and maybe not so much better in others.

I think everybody will become a product engineer in some sense. If you think about how AI has progressed, go back like four years, it wasn't able to write a single line of code. And now it's commandeering code bases.

Go four years ahead. And if you still believe that the exponential growth is still there and we don't hit a wall, which I don't know if we will, but if it keeps on growing like this, you won't be needing engineers that pipe data from one place to another.

You still will be needing engineers who know what a customer wants and what a good feature looks like or what a good user experience looks like. So I think engineers will have to move to become product-oriented and product-focused.

They will have to be mini PMs who talk with customers, are engaging in that layer, and then can implement functionality that your customers want.

Oh, man. So I remember the 2000s. As a programmer, you could just use one language. Then it was multiple languages. Then the QA job, you got the QA job. Then you got DevOps. Now you're saying we're getting the product job and the customer support job as well.

Oh, everything else has dropped now. You just need to do the PM job.

OK. And as closing advice, you are hiring for product engineers. You said that you actually hire for that. Now, not everyone might have the opportunity to work in a role that is a product engineerright now. But if you're a software engineer, what are things that you can do to grow this product sense, to change your work to be closer to what a product engineer does?

I mean, it's all about getting closer to your customers if you're working at a company or just building stuff. The best way to learn is to actually get your hands dirty, try something out, build it for yourself. That's the easiest part.

You can think about what you need. You can build it and you learn from that experience. Then you ship it to the world. Hopefully, somebody else uses it as well. And then you've got your first customers that you can get experience from, whether you're building theright thing or not.

Obviously, there's literature as well. You can read through Apple's Human Interface Guidelines. That's the best book. If you want to do good UX, just follow what they say and you'll be good. And yeah, those are two big things.

Awesome. Well, Thomas, thank you so much.

Thank you.