Full Transcript for Karri Saarinen: How We Win

I'm a person that I don't necessarily like competing too much. I don't like to compete in all the races. What is the benefit of doing it this way or doing something the other way? I choose the races or choose the games I play and I'm trying to see what is the best thing I could create? How can I win that way and win with my own rules and not necessarily with other people's rules? First of Kind is the story of design and tech told by its pioneers, powered by Framer, Noon, Grokbot, Ramp, Vercel, Granola, and Profound.

Kari Saarinen is the co-founder and CEO of Linear. He made the pilgrimage to Los Altos, where we sat down to talk about his design philosophy in the age of AI.

A lot of people have tried to make a new product in this category, but haven't made it, like failed. And I think there's many reasons maybe for that. But I think in my mind, it was that I don't think we can win by just being faster because the market is kind of slow and we have to be really better and somehow like find some kind of unique positioning or unique place where we can win in our merits, not just because we are fast, but because...

we are better and like clearly different in some ways. Right. But you were profitable from early on. I felt like you had a lot of ball control and you had a weak incumbent that you were able to compete with effectively on your own terms. Yeah. And I think a big reason why we invited you to speak on the show is in large part because I do think you were a first of kind in terms of like picking how you were going to win.

Yeah. almost declaring it up front and having a viewpoint right from the onset saying like, I come from these iconic tech companies. I've seen how they operate. I don't agree with that mode of success. I'm going to take a very contrarian route and say that we're going to compete on quality. We're not going to compete just around growth tactics.

We're not going to move fast and break things. And we're going to go build a consequential business. And you guys have done that. It's amazing. You called your shot. And you hit it. Yeah. Are you surprised by it? Are you just sort of feel vindicated? Because what I find so fascinating about it is like that playbook worked wonderfully in this like pre-GBT era.

You think that you have to evolve the playbook now that these big technological shifts are coming or are happening in real time. Yeah, and to your first comment or point of questions, yes, I am kind of surprised that this worked out because maybe not everyone feels this way or have this thinking. But to me, it's important. I want to build a company I can be proud of, not just that the company is successful.

Because there's the mode that you may start doing things that may be illegal things or some morally questionable things just to win, which... Maybe you win by that, but I'm not that kind of person that I can do that. I don't want to do that. And to me, being a founder, I think that's your freedom to choose what kind of founder or company you want to build.

My way probably doesn't work for some other people. It doesn't match their personality or their way of operating or something. Yeah, that's the thing that I think I responded most to. It feels very authentic. It didn't feel like you manufactured this way. It always felt like from day one, the linear way was your way. And you were kind of unapologetic about it.

You were very clear with the approach you were going to take to software development. Has your way evolved over the course of all of linear success? Is it the same playbook? Or have you found, I had to make slight iterations, slight changes to the way that I've operated, how I think about design? Because you famously have been an incredible IC designer at two iconic companies.

And being a CEO is just not the same thing. It's frankly not the same thing. But there are some overlaps. And I imagine you kind of came into it with an approach that you had to kind of evolve in an applied manner. How did your journey evolve you? I'm sure there's a lot of learnings and changes I've had to make. I don't think we or I have changed the values that much.

We still think the quality is really important. And for us, the quality is... directional, it's never static. So sometimes people kind of get lost into like, well, we can't do anything because if we want to do quality things, we have to perfect it. And then I don't think that's like exactly the way to think about it. I think it's more that quality is like directional.

You just have a value that we think quality experience matters and we believe in it as a company. And there might be points on time that we can always get there, but like we try to get there. And that's like the first step is like to try to get there. But a lot of companies don't want to even do that. They don't want to set quality as some kind of goal.

They just set it as, they don't set it at all. They set like timelines or something else. So I'm sure like something has changed like over the years, but I think like what changed the most is the market now. And I did tell this to the company that I think historically we had more of this time to figure things out. And now we might not have as much time anymore.

And we do have like more urgency of figuring things out because the market is moving so fast so that there's a chance that you start thinking or building something and the market has already moved before you actually get it there. And so then I think we have shifted more that we have to be more experimental on, especially on the AI features, because we learn a lot more when we actually get people to use it versus like we try to use it.

Like we use it themselves, but like our company, it's just one data point. Like we need more data points. I'm not saying like we want to like, we want to ship something we don't, it's bad, but we have to lower the bar a little bit that like, We can get it to a pretty good point and it works, but maybe it's not as polished as we would like it to be.

That's fine. And let's try to put it in some kind of beta. Let's see how people use it. And then as we learn, we can figure out what is the actual shape of the problem or what is the shape of the solution. And then we can later polish it. So the quality hasn't gone anywhere. It's just more postponed a little bit because we found that we can't learn things unless we release them to at least some of the customers and maybe all of the customers.

I'm happy to hear that. So back in December, you and one of our other guests, Rio Liu, had a very open public dialogue on the future design tooling. And I kind of feel like I want to dive into that, partially because now you have the benefit of hindsight. It's like, oh, it was back in December. And December feels like the Stone Ages already.

It feels like the market has shifted twice since then. How has your thinking evolved from that exchange? I think my position probably hasn't changed that much in reality, but I have definitely thought about it more. And I think maybe I would say it's just that I like to, a little bit with the company building aspect, I do like to take the contrarian view in a way.

Because I feel like so much of the industry is now led by like, here's this new thing. The new thing is obviously better. So you should use the new thing. It could be true or maybe like, because there's not a lot of incentives to anyone say, no, the old thing is better. Like if you invent computers, no one's going to say like paper is like better or something.

There's certain like excitement that comes with the new. it's so like simplistic, like it's almost like children, like there's a new toy. So let's play with that toy. But like, which is fine, but like you shouldn't let that new toy like dictate how do you maybe run your teams or like your company or something. But like, I think to me, I've been thinking about it every time since then.

It's like, I still don't, feel the need to design and code. And my reason is that simple fixes where I can see like, for example, in our application, something's wrong, like the border is wrong, this button is wrong, something is wrong. I might just like send it to the coding agent, like, hey, like, can you fix this this way and see if it works.

And those kind of like straightforward fixes, it feels good because then I actually can like try it live. And so there the code kind of helps But then where I'm still not convinced is a lot of my work, I still do design. I still use Figma and I open the Figma, my files, and then I have an idea. I like play around with it. And, or like, it's a product feature.

I want to like get ahead of it to think about it. Like, what is the feature about? Like, what is, what problems is actually solving? So what I'm doing there is I'm, I might like research something with our linear agent, like try to pull in some information or context. Like what are people actually, what is the underlying need? So I think today a lot of the industry is kind of like, I think that people are seeing product element as like someone says, we need this feature, let's go build that feature.

And to me, I'm always like, thank you for your input. Let's put this in a pile and look what else is in the pile about this. And so recently I was working on this team documents idea that like this comes up fairly often, like people want more documenting services and linear, like you can create team-based documents or something. And there's like, we have three, 200 different requests around it.

And I could kind of like use the agent to kind of try to understand what is the underlying need? Like what do they actually asking for, what they want? And then I take that understanding, go to Figma, try to like start designing something, putting something together. But that process, like I'm making one screen, then I have another idea. I duplicate it.

I go to the other direction. Then I might feel like, oh, actually this is not a good direction. I'll go back to the other direction. So my art, like the file ends up with, tens or hundreds of different screens. It's kind of messy. The reason why I don't think I want code there is I don't want to solve code features when I'm trying to just explore the problem or the design idea of the feature.

Once I get somewhere, I think this direction is pretty good, I'm pretty confident on it, then I might want to actually build it and prototype it or actually build it. But to me, Design is kind of like the planning stage where you can just throw things around and think about it. It's almost like sitting in a room with somebody or just discussing it.

To me, the code is not the right medium for it because it's such a

It's so, maybe it's kind of like, to me, it feels constrained, or it feels, it's almost like you start designing, you want to make a new design for this barn. And the way you do it is you get a hammer or the ax out, and you start axing things out. And then you're like, oh, actually, I shouldn't have axed that wall. I should put it back in.

So you start bashing it. What you just described is basically what happened with this barn. Yeah, okay.

I would rather take a paper and start drawing the changes I'm making before I make the changes. But what do you think now? You think code is the right medium to design? I

think part of the reason why I love this conversation is that I think we have more common ground than not. And the thing that's never occurred to me before today is that we are both kind of contrarian to different forms of groupthink. Much of the linear way is a contrarian take on VC culture, which tends to be very roughshod, tends to be startups without designers, tends to be like, do stuff until maybe you get lucky that you create something useful, and then maybe you will get to make it a little bit more higher quality than what you shipped.

And so what I hear is, I'm just faster with pen and paper. I'm just faster with Figma. This tool, I can ideate and sort of traverse the tree, map it out much more rapidly. And if someday a tool shows up that gives me a faster approach, then I might try that out. But we each kind of go to our tool of choice to kind of run through the exploratory phase.

Why I care so much about I think code is medium, it's just that there is like a final feel to software. And I have personally, come up with like ideas that seem great in like Figma land. We used to have the same, like Photoshop lies. We're like, you just come up with these ideas. I'm like, Oh yeah, this is going to be great. And now I'm going to go and build it.

And then, and I get to the building part and I'm like, soup tastes terrible. Like the, the, the software just feels janky. The canvas kind of lied to me a little bit and I needed to kind of spend more time in an interactive medium to get the flows to feel right. or even just to engage with the primitives. And I feel like you often talk about strong conceptual underpinnings.

And so in that respect, I agree that code can sometimes get you to commit to primitives and concepts that might be premature. But I do think that code now affords us the ability, and AI in particular, affords us the ability to explore avenues in parallel to what we do with the canvas directly with our hands. What do you think? Yeah, and I probably agree with that.

For me, it seems like a good use of AI that... if you are like thinking about a problem, maybe you have your own way of thinking about it. You can ask the AI, can you think about this differently or the opposite way or something. And I think that's great. Like maybe like where I kind of get more annoyed when the message is, I feel like a lot of times now the marketing is about the capability that yeah, you can design something fast.

But then no one says, like, is this actually better? Like, who is it better for? What is it better for? Where does it improve the workflow? Where does it have trade-offs? I think no one goes to that level. And so I have also always been a person that I think it's ideal if the designers understand code I'm less interested actually making them code.

I just don't know if it's always the good, best use of time. Like now I think, I feel like there's something like funny happening in the industry where we are like shifting the roles. Like, so BM should code now, like Google is saying, like every BM needs to code their things. And then engineers are doing design or BMing, like they're like figuring things out.

Like now every engineer needs to do BM job. And then designers like also need to code or maybe designers, will now, yeah, designers becomes engineers. To me, it's almost like, what is the benefit of reshuffling the roles if the roles still exist, the needs still exist? And I see there's some, we always operate it this way too, that we think there is a benefit of having We have small teams and we don't have a lot of PMs.

We always want the team to take more ownership of the problem. So we're solving an ownership problem because we think the quality is better if you have more ownership of the solution. And you hire engineers that have a good product sense. I feel like you've been really vocal about that too. You don't want to compartmentalize the roles either.

Yeah, so it's more like our principle or what the problem we're solving is. We want people to understand the problem and then we also have the... the ownership to change the solution if they feel like the problem is wrong or it's not constructed properly. Can we talk about understanding the problem a little bit? Because one of the things that I feel was part of my own education in design was how useful instrumentation was in understanding what people were actually trying to do.

People will self-report certain things. but then their behaviors will sometimes be dissonant with what they're actually saying. And there's like a truth sort of at the intersection of those two things. The case study that always comes to mind, we spent a couple months building this product called Notes. And so it's essentially blogging on Facebook.

And we launched this thing, and we were watching the numbers, watching how people used it. And we found that people were essentially writing notes and tagging people in them as though they were recipients. Now, at the time, messaging on Facebook only allowed for you to send to one person, one recipient at a time. And we realized people were effectively just hacking a product that we had intended for some other use case to express a desire, a latent desire to be able to just send messages to groups of people.

And that sort of kicked off an entire one to two years of my life at the company. I was trying to take that energy and put it in its right place. I don't know if we necessarily would have arrived at that approach without building, iterating, and instrumenting and sort of like hearing how people were using the product. And I've always felt as though not instrumenting your software feels like willful ignorance.

It's like everything else is hard to instrument. Software is very easy. Like why would you forego that information and incorporate that into a design process? How do you feel about instrumentation and looking at metrics as a means of like understanding, not just like efficacy on your strategy, but also product quality, like relevance. People could say X, Y, Z.

But if a number shows something else, there's a fuzzy truth somewhere in between, right? Yeah, which I think I probably agree and disagree here. I think I agree on the principle that instrumentation can help certain problems. I do think that most companies or many companies maybe just rely on it too much. And then it depends on your domain.

So your experience you're talking about is... It's a consumer product. It's kind of like hard to understand what consumers do generally. There's so many different kinds of people. But even a professional grade tool like Figma, right? If they did an instrument and think about segmentation of their own feature set, you're almost like flying a plane without any controls.

But I think there is- You're sort of doing it by feel, right? So I think that in that analogy is that you can fly the plane with the controls or you can look out of the window. Sure. So to me- Well, why not do both? Yeah, I think it's probably better to do both. But I think it feels like companies kind of pick one or the other often, like more often looking at the dials versus looking out of the window.

It's like the person driving the Google Maps directions off the cliff, right? Yeah. Yeah. So we have used instrumentation. We never done AP testing. We used instrumentation very specifically if we have a specific question we're trying to answer. Our design problem is different where our tool is kind of like a collection of many different workflows.

And then there's not like a clear metric that you say, like we track like weekly active users, we track different kinds of things, but like if we launch a new feature, it doesn't always mean that everyone should be using that feature. Not even every company in the segment, maybe it doesn't make sense to them for some reason. So there's gonna be a lot of features that make sense to some, and then they don't make sense to someone else.

And it's kind of hard to like start building metrics where you have a lot of this variance of people's needs, like company's needs are kind of similar, but also kind of different depending on the size, the culture, And so what we do more is try to talk to customers, try to understand them. We collect a lot of feedback to Linair from various discussions or automatically, sometimes manually.

And when we get a new, let's say a larger company in the pilot, we talk to them about what are their processes like, what the problems are. Once they start using the linear, we start talking to them more. It's like, what do you find problematic? And then we sometimes find problems that we didn't know that were there. And then we fix those or improve those.

And then we think the problems we're fixing for this customer, they will also scale to other customers. There's areas now, because now we've been working more of the AI features, we actually do want to monitor the usage more because it's going to tell us a little bit the story of what is actually valuable or meaningful. So I think to me, it's like, again, like the numbers or the metric or instrumentation is a tool.

I don't over rely on it. No, I agree with that. Yeah. You don't want it to guide your hand. You know, it's not supposed to tell you what your strategy is. Yeah. And I think that does happen in companies. Oh, yeah, absolutely. And that's where it becomes very insidious, right? If you sign a metric and you're just like, make that number go up, you can just find clever ways to artificially make a number go up, right? And that's not necessarily like the health metrics to a company.

But I feel as though like I do come from this like Alex Schultz school of thought around like your North Star as a company has a set of metrics. It is an expression of the value you create in the world. And if you do a really good job of articulating them, designing what they are and being really intentful, then everything can flow from that.

You can actually align yourself with your customers in a very clear way, right? It seems as though Linear is evolving away from issue tracking and you've put forward a vision for how agents can operate with people through Linear. How are you also thinking about the evolution of operating? Because I know Facebook famously turned itself inside out to become a mobile-first company.

And that came from the moral authority of the CEO, top-down. But it really started from this, I would argue, a very humble place of saying, the old way got us this far, but it is the old way. And we have to force ourselves to evolve. Otherwise, we're going to be very vulnerable to disruption in this new mobile-native environment. And so there are echoes of that transition now with AI where everyone who existed before the transition has to kind of involuntarily evolve alongside of it.

How are you navigating that right now as a design leader, as a CEO, and also in terms of like rethinking the vision for Linear? For us, Linear was always a tool for helping to build products as a team. And part of that, you have issues, like you can describe a problem or you can describe an idea and you just kind of, you store this in somewhere that you can address them.

And because pre-AI, it usually means that like you have limited resources, limited like human engineering resources that can build things. And now that's, so you have like more heavier upfront processes where you try to like prioritize those resources. And that's like where these tools, became the thing where you do a lot of this prioritization in these tools, and then the tool is almost like a tracker for the engineering resource.

And so you have product team is coming up with this idea, then they send the ticket to the engineering, the engineer will cook, and then the code has come out at some point. But if you think about that situation, that's obviously different now. The timeline to build something has compressed a lot from days or weeks or months to minutes or hours.

And so the execution piece is now there's a lot more resources But then the problem becomes like, so we have to like start thinking about other problems. Like we cannot be anymore just like engineering resource management tool kind of. And we never thought that way, but a lot of companies just like used to working that way. Engineers won't touch anything unless there's an issue.

And then there's this whole like process of like how that works. But now I think if you have this almost unlimited power to build things, then

those things need some kind of context what to build or some kind of intent and context of what needs to be built. So linear can help to provide some of that, both for humans, but also for agents. If there is a... a problem i think what we do today is that someone reports the problem that our triage intelligence looks into the system like is this problem already reported is it is there something similar to it has we worked on it before who worked on it before so it's trying to like build the pictures like what is this problem about and then like the agent can like start looking at the code base and like what is this what is causing this problem maybe it connects to the

data doc and starts looking at the logs And then now it's evaluated. There's a clear problem here. This is the problem area. Then it can tag the coding agent to actually make the fix. And so then it's like, what it creates is this organizational leverage where engineers can still work on the things, whatever they want to work on, but the system is handling things for them.

So it's like the shield that protects their time while also improving the product. I feel like I have a responsibility to ask you, where is the field of design going in a world where we're moving from working on software to working on shaping intelligence and shaping collaboration between people and people and people and systems, people and machines, people and superintelligence? What is the role of the designer? What is the bull case here? Because I feel like a big part of the reason why I wanted to embark on this series was to get to talk to folks like you.

Because we kind of bear responsibility for showing the way. Even if we disagree on where things are headed, at the very least, one of us has to be right.

Or maybe not. My feeling now is, I don't have the full answer, but my feeling now is that the pool case for design is more... in the more like the traditional routes or the traditional workflows, more like going maybe closer to the ideal world than maybe like towards where we've been now, which is very like tactile, draw rectangles on a screen, like make this picture of how things can work.

I use the process of designing to actually more like think through the problem, not really to design it. Sometimes I also, well, my role, how I often do it is I'll just do some like designs. They're like more directional designs. I don't think it's a perfect form yet, but I can give it to the team. Like, hey, I like came up with this direction or like these directions.

Like maybe you guys can like finish it or try to like get it to like a working state type of thing. So I feel like maybe there's some of that aspect where if designers can move more towards the, like they give that the directional value on this is kind of like what it could be, or this is the direction we want to go. This is like the parameters.

So this is the constraints and try to like communicate that maybe that's through text or through design or. or like prototyping it with AI or whatever. But it's like the thinking part is the having some kind of like, what would be good? Then there's the separate questions, like what is the future of UI itself? Like, do we need UI anymore? And probably the answer is like, sometimes we don't, but...

We'll probably use more of the agents and the AI, both in the input and the output. It's kind of like sometimes it is actually better to talk to the agent to make something happen. Like you can kind of like ramble a bunch of stuff and it can do very complex workflows, which would be really hard to do in UI because it doesn't, you have to like click through all these buttons to do it, but you can just write it and then it will do it.

And so there's clear value there, like why like agent interface is better And then for the outputs, it's similar. Maybe you want some kind of information that is not super structured or it has a lot of volume, whereas it is the situations where, oh, there's 40,000 customer requests. Go look at... No one's going to be able to browse through that.

You have to... Either synthesize it in some ways or structure it some ways or find something important in that set of things. So now we don't have to build all these reporting tools because the agent can be the reporting tool. So it helps us in some ways too. But where I think the UI actually still makes sense is the having some kind of shared...

source of truth because the agent is kind of never like a source of truth because it can answer people differently and no one knows like how it answered people. But if you think about like just a simple thing that having a roadmap in your company, like what is our roadmap or what is our direction of the company? And if you ask the agent, like, what is our roadmap? Maybe it gets it right.

Maybe it finds, like, maybe it's, like, doesn't list all the things. Maybe it lists it in a slightly different order. Maybe it hallucinates. Yeah. So it's kind of hard to tell, like, did you tell me the right answer? Or did you tell me the answer, like, are you telling the same answer to everyone? Right. Which is, like, important that, but, like, the UI can really clearly, like, you can make a roadmap view that has the roadmap.

It has to... ordering or filtering or whatever information is relevant on that, then you all can look at it at the same time. And it's etched in stone. It's like, what you see is what I see. And this is like, do we agree on this roadmap? And then like, yes. And then whenever other time, like some other person was like, what is on our roadmap? Then they can look at it.

So there's the UI. I think the value is still one is, Sometimes it helps humans to understand information, like what is this thing? What is important about this? Like hierarchy in an interface is usually the way you show importance, sometimes color or sometimes something else. But like, what is your eye drawn into? Like the hierarchy helps with understanding the relationships or like sectioning or something.

And you feel like this is still going to be the domain of people. I don't necessarily see agents couldn't do it. I think if you would give them the right guidance, I think the agents could build that UI. But then there's the other piece of where does that UI live and where is that shared truth? So I think it's still useful. I feel like the UI is in the middle and then And then the UI sometimes also, I think, even if you wouldn't have a UI, you still have to describe how the system works somehow.

So even if you just use the CLI or the API MCP, you still have to come up with an idea, like what is the project and what kind of properties it has or workflows it has. So even if there's no UI, you still have to design the system somehow. It can help you to actually design the system. It's kind of like abstract if you're trying to design the API.

Maybe some people are really good at it, but... But it shapes the way you think about it. Yeah. Right. Like there is something about even just the mere fact that we've constructed all these like typographic concepts. Right. And we formalize them. They're formalized for a reason. You know, they're just like, it's useful. It's like headers, hierarchy, you know, column widths, all these things are just our best practices because we find that there's something pleasing to the human mind.

Yeah. To engage in something that's both like artfully done, but also familiar. Something that we're already kind of accustomed to consuming. Yeah. I feel as though you are, in many respects, like a modern version of the car designer of yesteryear. And I think part of the reason why so many people find Linear to be a beloved brand is because of the idea of the CEO and the chief designer being melded into one.

That there's something aesthetic that sort of starts at the very top, cascades down. We interact with software all the time and your customers use linear daily, right? So it's a key part of their time spent on this planet. It's time spent in this environment. Much like your favorite automobile is time spent on this planet. When you look across the landscape of people doing interesting, exciting work, what are some of the inputs for you of late? What are the aesthetic things that you're drawing inspiration from? Because I feel as though there's a part of the job that's also like, yeah, you're the chief car designer.

You get to sort of think about the car of the future, right? And so what does the software of the future look and feel like? What are ways in which you're kind of thinking about the aesthetics? Or do you feel like that's largely now the domain of your team? Yeah, on the first comment, like, I think actually I do have this motivation or need that I want linear to be something that people enjoy.

And there's a certain, like, value or benefit that creates in the world. It's a moral good. Yeah, like, even if it's, even if the business wouldn't do well or something, at least they enjoyed it. Like, I would rather have, like, I don't, like, yeah, the business could do really well and then people really hate you and your product, like, I don't.

necessarily like that. Like that was like one of the reasons I even started this company. If you think about like bug tracking or something, it's not super exciting thing, but it's something like people have to do like in this industry almost every day. And so, I don't know, it just feels so bad that people have to use bad tools. And they're forced to use it.

They don't have the choice because the company chooses the tools sometimes or often. There's that definitely like my personal motivation with this, that we want the aesthetics and the feel to be good so that people can enjoy it. It's not just because we want it. I also want it, but I think there's actually some value for other people in it.

And there's an artistry to that, right? There's something about pull to refresh or something about the feeling that we have to kind of like invent to assign to a technological concept, right? Otherwise, the technological concept feels a bit opaque. It feels like you're not actually interacting with it in quite the same way. And I think like the design problems, I often think there's always many ways to solve a problem.

Right. And so a lot of times this is what you feel like is the best solution. Yeah. It's kind of like aesthetic kind of thing, whereas I just like this one better. Yeah. Can we talk about design recruiting for a minute or just like design hiring? I've always, I wish I ran a company just to impose this kind of design exercise. I think you can learn a lot about a person by how they arrange flowers.

You give them a bunch of flowers. And just say, arrange this. Make something artful. And explain what you did and why. To your point, there is 101, a million and one ways you can arrange a set of flowers. And it's very much an expression of the individual, what they're kind of feeling in that moment, right? But I find that it's instructive to kind of hear how they explain their decision-making, why they discard these flowers, like how they kind of create structure.

Have you found a tried and true way of kind of evaluating design talent? When you sort of look at people who come into your orbit, they've expressed a lot of enthusiasm for linear. Do you have like a thing that you're looking for or an exercise or something that you find is very telling? I don't know if I have something very specific. Like we have like a little bit different process where all of our employees go to this work trial, which is like a paid project with us.

We actually design something. Which I love, by the way. I wish we can institute this across the board. I think it's like, that is very much like a- That answer is usually the question like, or like that part is, you get to see like how the person thinks and why. And like you see some of their skills, but it's kind of, It's a really rushed process, so we try to not overemphasize what's the solution, like super great or something, because they have limited context, they have limited time.

Do you feel like it's too much of a pressure cooker situation to try to like... Your best self? To some people, to some people, no. And so the people who do really well, they usually are really good. But there's people that we think could do well, but they just didn't do well this time. And so we try to not overlook it a little bit. Do we think there's still value? I want to talk a little bit about what I describe as the golden thread.

And I feel like every great enterprise has at its center the golden thread of the founder's biography. what opening they saw in the universe, like what role they needed to play in the grand tapestry of humankind. And the thing that I'm probably most unfamiliar with and that I want to give texture to with First of Kind is how design pioneers saw themselves fit to embark on doing something new, sort of stepping into the arena and trying things that hadn't been done before.

And linear is not your first company. And so work my way backwards. You know, what were the earliest versions of you as today's CEO that you remember looking back on and being like, this is where I started to find my way down this path. How can people watching this sort of recognize themselves at a much earlier age or a much earlier stage of their career paths? My first opinion or kind of like remembering it was that we went to buy me a new bicycle and we went to the store and I look at the bicycles and they're like, oh, weird colors.

Like, I don't like these colors. And then it made me think, it's like, why did they make these bicycles with weird colors? I just thought like they made a mistake. Like they made wrong colors. They like somehow this just happened. But then later I realized, well, there's actually some people in control. So

I didn't think about it that much later. But then what started happening, it was more that I didn't enjoy school that much because the school felt to me kind of fake. You are going through these motions to learn something, but you're not actually doing anything. You're not creating anything. You're kind of playing the game kind of. And so when I was like a teenager, I started looking into what can I do? So I organized some land parties with friends and we sold tickets and it helped to organize some music festivals.

And I tried to do something that I can see that actually someone can get some value out of. Somehow it felt important to me that I can do some work and someone can enjoy it. Like they get something out of it. I'm not just doing it for myself to enjoy it, but I'm doing it for someone else. And then it becomes meaningful for me. And then I ended up getting my first summer job in a local web agency when I was 16 and I could like use Photoshop and I could design things.

And I actually went there first as an engineer. I could code websites. I also learned that. But then I looked around like, these websites are not very good. And then I said, can I design them? And then they're like, yeah, go ahead. We don't have any designers. So then I started designing them. I worked in some early startups. I did some design and then also this business stuff there.

I talked to customers and tried to understand their needs. More like a BM kind of thing. And then we did kept with like a bookmarking service and with a friend, like with my current co-founder, Jory, we just built it for ourselves because we thought like the current existing like systems weren't that great and they weren't updating or something.

And we applied to YC and like luckily got in. Did you feel like that was a siren call for you, like for entrepreneurship or was it, this is the promise of joining Silicon Valley and becoming like an entrepreneur? Yeah. Before that, I had my own little freelancing agency. So I knew something about, oh, you sell some stuff, you get money, and that kind of entrepreneurship.

Buy some sweet computers, make some more stuff. But yeah, that was the first kind of startup. I had learned about startups before and I had visited Silicon Valley. I was really interested. So I think the YC really gave me a good reason to move here. The way how they demystify the startup is really useful. And it created an incredible ladder for people to join the industry or become entrepreneurs that were previously shut out.

Where do you feel like your personal approach is most divergent from YC? Like when you sort of think about, well... These things are like, I'm not sure if everybody should get orange pilled with this, right? In some ways, it's hard to answer because I think YC has changed over the years. It's never the same, which is probably a good thing.

But their advice is often that go do this thing fast, like try it out. And because they've seen it, it works. Like you have smart people, you just push them to go do something and they will figure out something. And like sometimes a lot of the companies start with like, kind of like not a good idea, but then they like stumble on something and then they actually make it into like something good.

So I think it's probably the right advice they give, but I just don't personally believe it. It's kind of like the MVP, like advice, just go build this like very simple thing. And we never did that. Like we kind of like did the opposite where it's like, we moved fast, but we always try to like, can we build a good thing? And then that's the advantage.

It's like, that's like how we actually show, differentiate or like are unique. Because we are trying to be good and not- Best in class and useful, right? Yeah, yeah. So if you were to imbue the linear way, or at least a new school of thought with design at its center, how would you articulate that? You can make that the linear accelerator.

Mm-hmm. One, I wouldn't start a company that I know nothing about. I'm not going to start a company, I don't know. Making soap. Yeah, or something. Maybe if I could get really excited about it, maybe I could learn. But I feel like I'd probably start a company in something I already know about and I'm interested in. I have some domain knowledge.

And then if you have some kind of like domain knowledge, then you can take like a position in that, that like, what do I really believe in? Like, what is the future of this category look like? So what are those mantras? When you sort of think about those right now, what are the things you find yourself repeating to yourself, to your team, to your customers? What are the things you're like, man, put this on my gravestone.

This is like what my life has taught me to be true. There's a tendency with everyone, I think, and every team is that you start working on a problem, you start learning more about the problem, you start noticing more and more problems. The actual core problem was maybe pretty simple, but you started learning too much about the problem and you're not trying to solve too many things.

And you're starting to get lost in what is actually the main problem you're solving. So I often try to, whenever people are working on their projects or showing something, I'm trying to push them, what do you think is the main workflow, use case, problem, something you're trying to accomplish with this? And why I'm pushing for it is it's hard to optimize, hard to make decisions on designs when...

you don't know what are you optimizing for. You cannot optimize for everything. So who are you optimizing for? Like what are you optimizing it for? And that's like the clarity I'm looking for. And I love that linear is a tool for achieving this clarity of scope, like a clarity of problem. Like what is it we're trying to accomplish here? And that's kind of like what we always wanted to influence people with is like, Can we move the industry towards what is an actual quality experience? But we can't tell what companies should do exactly.

They will do what they do. We think linear can influence some of the things. And we have sometimes customers who say that they buy the tool because they want to influence their teams with the tool. They want to show it to their teams, maybe especially product teams or engineering. And when they build their own solution and it's kind of slow or janky or something, they can say like, why don't you build it like Linear does it? This is the platinum standard.

This is what software could feel like and look like. They're creating like a standard bar. And then because people use it every day, I think it will help to actually calibrate those people who are using it. Because what happens in any kind of domain, once you start experiencing good things, it's kind of hard to go back to the bad things. This happened to me with coffee.

I drank coffee when I was younger, and then I drank bad coffee, like regular whatever coffee. And then I started going to these new coffee shops that actually serve good coffee. And I'm like, oh, wow, there's all this... different flavors the coffee can have and different feelings or like things. And then now if I go to drink the standard coffee, I can kind of drink it, but I don't enjoy it.

And so my palate changed because of just doing this more and more. And I think that can happen with, with these companies too. It's like, if they use linear more and more, they start like recalibrating their palates and then they go use their own tools. Like, why is this so slow or something? So, yeah. I appreciate that. I feel like I want to thank you for helping refine the tastes of software makers worldwide.

by leading through example and inspiring so many designers to seriously consider the path of entrepreneurship. You are truly like an icon to an entire generation of software designers. I appreciate you taking the time to chat with me. Thanks for having me. This was fun. First of Kind is a story of design and tech told by its pioneers. Powered by Framer, Noon, Grokbot, Ramp, Purcell, Granola, and Profound.

Follow us on X, YouTube, Threads, Spotify and Apple Podcasts. The future belongs to designers who build.