An Interview with Tuomas Artman of Linear
So for those of you that know me, I have probably mentioned Linear once, twice, maybe five dozen times. It is a product that I've been obsessed with for several years. One and for two reasons really. The first one being the business is fairly interesting. I think they took a strategy that is pretty counter to what most of the advice that you hear today is.
Speaker 1:It's influenced pretty much everything I do. And then two, I believe that it's actually probably the best web app that I have ever seen by a far margin, particularly because they use a fairly unique architecture that is not really well known and is quite different from where, like, the status quo and what generally web developers think about. So with that teaser, I'd like to welcome, Thomas Artman, co founder and CTO of Linear. How are doing today?
Speaker 2:Doing good. Thanks so much for having me.
Speaker 1:For those of you that don't know, Linear is a project management tool. And this is not a unique idea. Every developer in the world has probably at some point hit their project management tool, has had an idea to start a new one. There are dozens, if not, it might be a 100. I don't know what the market size is.
Speaker 1:Not a unique idea at all. So it feels weird to start a company saying, I am going to build yet another project management tool. And it's shocking to see that actually was quite successful. So I'd love to hear about, the, original kind of at beginning, like when you chose to found the company, what was the mindset? How are you guys thinking about it?
Speaker 2:It was actually, you know, pretty interesting. It took us a while to to sort of, you know, get behind the idea of of, you know, doing project management or software for project management. Because ultimately, like in beginning, we thought it was a pretty boring space to be in. Like, you know, the founders, we all came from sort of consumer companies. I was working at Uber back in the day.
Speaker 2:Jori was at Coinbase and Karri was at Airbnb. And we started talking probably like, you know, six years ago now with Jori about sort of the state of issue tracking and project management at all of these companies. I think Uber was using using Fabricator for sort of engineering. They were moving, you know, essentially, you know, over to Jira just after after I left. Coinbase was using, I think, GitHub issues, but moved over to Jira as well pretty pretty quickly, and Airbnb was on Jira, you know, from from from the get go.
Speaker 2:Sort of it was I think it was me and Jori who started talking about sort of, like, the sense that we have gotten from the state of, you know, project management at these, you know, product companies. And we sort of felt that, you know, ICs really didn't enjoy and didn't like what they were using. And that, you know, it was usually mandated by sort of, you know, project for product management or project managers or middle management, and then sort of engineers in your ICs just had to use, you know, whatever tool middle management came up with. And we continued hearing, you know, from all these different companies that we just, you know, randomly chatted with, that ICs really were under serviced by the issue tracking needs or by the needs of their project management. Like, to ICs, project management is very different than, you know, for your, you know, product managers or managers, per se, because like, you're just working off of a list of things that you know you need to do.
Speaker 2:So, visibility and your sort of interaction with the tool is much more constrained than when you're planning out, you know, what you want to build at a large company. And it seemed to us that, you know, none of the existing tools were really servicing the market of ICs. And, you know, for the longest time, we were just like, you know, sort of wondering about why nobody has tackled the market, you know, from the side of the IC, like why nobody has come up with a tool for ICs and tool that ICs will be happy to use. And it seems like sort of a great market opportunity and great opportunity to build something. You would immediately have quite a few customers in the smaller segment, like if you started targeting smaller startups or companies with, you know, less than 50 employees, you would sort of be able to quite quickly come up with a product that would be useful for them.
Speaker 2:And it took us a while to actually jump on this, because, as I said, like we found the idea of working on project management for the next years, you know, quite boring. And, you know, the space itself wasn't really enticing to us. And, you know, even more when we talked with Curry. Like, Curry was even more sort of, you know, not very interested in the space, being a designer himself. But I don't know what led to the realization, but we, at some point, understood that it's not really about, you know, project management or issue tracking or any of that.
Speaker 2:There's an underlying mission behind sort of what we actually wanted to achieve, which was helping product companies be better at building and shipping product. And that felt like something that we could sink our teeth into, and that we felt was much more interesting, and was a mission that we could get behind and work on for the next ten or so years. And with that realization, we started sort of, you know, to sink our teeth into issue tracking at first, because again, like that's the way to get to the market is to build an issue tracker, because, you know, you immediately had all the smaller startups that, you know, would enjoy using the product and where the product could be useful. And, know, once you started working with the startups, you know, those people are usually very vocal, and you can sort of easily chat with them and sort of understand, like, you know, get an understanding of what they need, and startups hopefully grow as time passes. So, as they grow, so does our functionality and features that need to grow as well.
Speaker 2:So from the start, like, think we call ourselves an issue tracker for the first two years of our existence, but we always knew that we wanted to do something different, something more than issue tracking, and even something more than project management. Like, wanted to change how companies build products. And in a sense, that was sort of a selfish mission as well, because, you know, we're users of software, and we sort of have these pivotal moments in our lives when, you know, we've used new hardware, new software that has literally changed our lives. Like the first time we saw iOS, for example, and used iOS ourselves felt super magical. Not so much in the recent ten years, like we don't think much has happened.
Speaker 2:I don't know why, but maybe it is because, yeah, people have become less good at building products or, you know, trying to do new things. And, you know, we just thought that if you can build an issue tracker that feels magical and feels like, you know, an application that, you know, people would look up to, then there's really no reason for anybody else to sort of, you know, do something less good. If your issue tracker is something that, you know, you enjoy using and that you look up to as a piece of software, then, you know, hopefully, that is a motivation for you as well to build better software.
Speaker 1:Yeah. And I can't understate how how true that ended up being. Like I said, I we started so prior to, using linear for everything, the initial point you made about the lack of focus on ICs is a really good one. I tried a bunch of tools
Speaker 2:and we actually settled on
Speaker 1:just using Airtable because Mhmm. We couldn't really find a tool that as an IC, all you typically, what you wanna see is you wake up, you see a list of tasks for you in, like, a very clear way and you can knock them out. And then as someone that's in a different role, you need to see, like, across and plan across people. And you're right, like, very few tools really just thought about it in that simple way. And we just ended up using Airtable because we were able to create the views that we needed for the project managers and the views that we needed for for the day to day.
Speaker 1:So finding linear was was excellent because it it kind of served exactly those those two purposes. And, yeah, like once we started using it, was like, this tool is so good. Why have I never cared about all these little details that I got right? And my software just kind of became better. Like, what's kind of thing, once you see it, you can't unsee it.
Speaker 1:Now that I know that it exists, like, I really gonna not shoot for something of that quality? So yeah, don't know why it hasn't been as common, but it might be as simple as like just people just weren't thinking about it. And now that they're thinking about it, there's a it's kind of like a breakthrough. So, yeah, I think that I think that intention has definitely been been successful.
Speaker 2:Yeah. I know. It's it's easy to, sort of, you know, not know or not care about the user experience. Like, when you're looking for product market fit, like, it's the you're not you don't want to sort of, you know, spend your time, you know, polishing the product when you don't know if you're gonna succeed, or not. And, you know, maybe that then becomes sort of the norm where, like, because you never have cared, you know, too much about the spit and polish of your product, you just don't remember to do it once you actually have a follower following and once you have users.
Speaker 1:Yeah, that's actually exactly what was referring to the beginning. The level of detail and polish that Linear has is quite opposite to most advice that you get. Right? You know, don't waste time on that stuff when you don't even know if your business is gonna be successful. But what's different about Linear is that is a differentiator.
Speaker 1:Right? Of course, there's a lot more than just that. There's a lot of thought into the product, but a key differentiator and key advantage and key edge that you have is the fact that it's very good. And I think prior to me seeing linear, I never realized that that could just be the thing that you differentiate on. Did you guys realize that very early on?
Speaker 1:Like, was that intentionally the initial pitch, like, when you're pitching investors, etcetera? And did people understand that?
Speaker 2:That was literally the reason why we started Linear. Like, just like, the the market existed. Like, we weren't inventing anything new. Like, Jira had been around for, you know, twenty years at that point already, and there were, like, you know, hundreds of different project management tools. And our, you know, idea from the get go was just to be better, Like, you know, better to the user, better as a user experience, better in in all kinds of things.
Speaker 2:And, you know, we care deeply about the the product, like, you know, the the founders. Like, we've we've always sort of, you know, have been interested in design and good UX and all of that. And, you know, part of our careers have been built on that as well. So it was sort of, you know, easy to get started with that. And I do remember, like, when we started, like, started prototyping just on the weekends on, you know, what would an issue tracker look like, and we still have the history of, like, the first ticket that we or the first issue that we put into Linear.
Speaker 2:It was sort of built the command menu, which is kind of a silly thing to do if you don't have a product, like, you know, start with building building out a command menu. But we were, you know, keen on on figuring out whether we can build something on the web that felt more like an application. And obviously, Superhuman was out back then. That was a big inspiration for us, to look at their command menu keyboard shortcuts and try to build something that felt like a true native application on the web. And yeah, like from the get go, we knew that, you know, we weren't, you know, building anything new, but the way for us to win the market would be to just be better.
Speaker 2:So hence, sort of the focus on quality and UX.
Speaker 1:So I don't know when you started raising money, but in the process, in the early process of of pitching and explaining that, did investors understand that concept or did it seem like like, were you able to show something to prove that or they kinda just have to go on on your word?
Speaker 2:I mean, we had we had an easy time raising money. Like, I keep on saying that, you know, the the experience of of building Linear has been a very, you know, easy and and different one. Like, usually, you know, startup comes with ups and downs. We've been just sort of coasting upwards. Like, there have been no sort of, you know, bigger problems or challenges to begin with, which is, you know, super strange.
Speaker 2:Like, I think we got, you know, just, you know, hugely lucky. So, like, our fundraising for for a seed round was, you know, literally just a few weeks, and and it was not of our our own accord. Like, we initially didn't want to raise money, like, wanted to build essentially a prototype. I mean, just bootstrap it, get a few customers, and and have a product that sort of, you know, exemplified on on what we want to build. And and then, you know, if if need be, go go ahead and raise money.
Speaker 2:But, you know, as it as it turned out, Sequoia sort of, you know, was scouring through LinkedIn and and sort of found out that, you know, one guy from Uber and one from Airbnb and one from Coinbase had founded the company and they've, you know, put out a blog post and, you know, Twitter is, you know, a bit abuzz about, you know, what they're building. So they reached out to us and then sort of was, you know, rather quick at sort of, you know, getting getting the seed in. So we didn't really have to explain too much or or, you know, show the product because we, you know, back then, we didn't have have anything to show for. Like, yeah, we did have a few prototypes. We did have a few designs, and I'm sure Carrie put them on the on the deck.
Speaker 2:But it was it was very early. But, you know, I I think they, you know, believed in the same mission of, like, you know, first targeting ICs, building it upwards from there, and just building a a product that people enjoy using.
Speaker 1:Cool. So switching gears to something else that you said. So a key part of building something like Linear is it's not just a product. You also need to think about what your opinion on the right way to build products is and you kind of bake some of that philosophy into the product itself. And I think linear also has like I forgot what you guys call it.
Speaker 1:You have like an actual like document. Like a linear approach or what was remember what it was called?
Speaker 2:Yeah. We have the linear method.
Speaker 1:Linear method. Exactly. Was that something you discovered as you built the product or upfront did you guys kind of all like find alignment on on that?
Speaker 2:The the method itself was something, and it's still in flux, like we haven't completed the method yet. Like it's something that we someday want to want to finish up and get closure on. But in the beginning, like, we did have this idea of like, you know, we don't want to build just a product, like we want to have some sort of, you know, mission statement or idea or methodology behind it. And that same came from the insight that we had when, you know, we were working at these larger companies that people looked up to when they were building products. And we sort of all realized that, you know, none of the internal teams really knew how to build product or what the methodology was.
Speaker 2:Like everybody, you know, depending on team, you usually use something akin to Scrum. When you ask people, like, why are you using Scrum or why are sprinting, people wouldn't really know what the answer was. And they were like, no, I know, everybody does it like this, so I guess it's terrific development, so it makes sense. I always found it strange that, you know, Scrum has been invented for a very different world. Like Scrum initially was made when you had sort of a non technical customer and a technical team, and the non technical customer wanted working software from that technical team.
Speaker 2:And the technical team didn't want the customer to sort of get involved when they were actually working on stuff. So, know, we came up with this framework that worked for both companies, before the customer and the technical team, and, you know, every four weeks or so, the customer would get something out of it, and for the rest of the time, the customer would sort of, you know, give the team space to implement whatever, you know, was asked for. And that's not how product companies work nowadays anymore. Like, sort of needs to be a different different way of of building products. That makes much more sense for the for the, for the current, world where, like, you have integrated teams within the company building their own software.
Speaker 1:Yeah. And especially at smaller companies, this thing where that's a good point about the customer not being super involved, like, kinda giving space and that's how what it was designed for. This is exactly the issue I had with a lot of the approach earlier in my career with companies that are building software. You would plan out something like some kind of like long longer term thing. We're gonna do exactly x y and z things.
Speaker 1:And then three days later, your customer you would have an interaction with a customer and you would get suddenly really excited to solve some problem that wasn't on your roadmap. Because when you are not when you're not talking about your customers, all issues kind of seem equal. But the moment, like, someone has a problem, suddenly an issue is like the top of your mind. So, yeah, having that flexibility, I think the reality is and I've I've only ever worked at really early stage companies. It's very hard to know what you're gonna be excited about week to week.
Speaker 1:So a lot of these tools are about like locking in these long term plans. And I found that that almost never never really worked out.
Speaker 2:Totally. Like, it's almost like, you know, building it water fully, which was what, you know, Scrum
Speaker 1:Wasn't supposed to not do.
Speaker 2:In in the beginning. But, yeah, I was was was trying to avoid.
Speaker 1:Yeah. It's been my experience as well. Everyone is doing Agile, but if you actually look at what they're doing, it's like yeah. It's entirely a waterfall process. Yeah.
Speaker 1:So I think that's that's really awesome where there's like a whole document teaching you how to how to build product. So it's the the three of you came from at least the last I mean, I'm sure you've had other experiences before, but the last job you were at prior to founding this was at bigger companies. So when you're kind of developing this method, did you feel like there's a trade off with what works with smaller companies, what works with bigger companies, or do you generally find that there actually is a good approach that works pretty well for everyone?
Speaker 2:I mean, no approach works works the same for everybody. And I I think, like, people, when they sort of look at the linear method and and what we've described there, it is it is sort of common sense stuff. Like, is not very descriptive, you know, for for the plain reason that you have to take it and sort of make it your own, because no company is is alike. But but, you know, the idea was that, you know, it it there there's nothing inherently in in building building a product that that would be different than a large company and a small company. I think the the method and the way of working still still still works regardless of size, because rather than, you know, sort of getting teams of of hundreds of engineers, like, you know, companies tend to, you know, break up teams into smaller pieces and work on, you know, functionality individually.
Speaker 2:So if you have a small company, you just have less stuff that you're working on at the moment. If you have a larger company, you've got sort of more initiatives, but the initiatives themselves sort of work in the same way.
Speaker 1:Yeah. That makes sense. Yeah. Because I think a lot of times, when companies see how a smaller company operates, they they might think that could never work for us because we're big or they don't have some some reason. But I think I found that, yes, it's not exactly the same, but roughly the principles are the same.
Speaker 1:It's usually the the low level principles that you need to get right. And when things are broken, it's usually not it's due because you're not following
Speaker 2:some of those some of those some
Speaker 1:of those ideas. That's so that's a lot on like linear as a business, a product. But, you know, my audience is mostly engineers. I'm trying to get them thinking more about those things, but I'd love to talk about, stuff in that category. But let's kind of get in some of the some of the technical details, right?
Speaker 1:With Linear, when you're using the product, every interaction you do is near instant. So or it's living instant, you probably can't tell. So whether that's something simple like marking an issue is done or something more complicated like searching through all your open issues, every keystroke instant response. And I think I remember initially the landing page or at some point landing page like very clearly said that or maybe you continue to say that. When was that, like, the prospect when did you guys decide that that was the perspective you wanted?
Speaker 1:That was, like, a rule, like, you needed to have instant reaction times and everything?
Speaker 2:Again, from the get go, like, before we even started started working on anything. The way we started prototyping an issue tracker or the first sort of prototype of of Linear was, like, I had spent, I don't know, eight, nine years working on mobile, and I was totally burned out by by sort of sort of mobile native engineering. And even before we decided to sort of, you know, start working on Linear, I took a few weekends to sort of dabble with web technologies, which I had sort of, you know, done ten years prior, but, you know, a lot of stuff had happened in between. And I was, you know, totally unaware of, you know, sort of technology stack of web when I started toying around. I had done a few sort of synchronization engines before, and just, you know, thinking about the idea of like, know, if you had an issue tracker, like, would you want it to be?
Speaker 2:And it always, like, I always wanted to, you know, build an application that was fully, you know, built on a synchronization stack. I tried it at Uber. When I joined Uber, I built a synchronization engine for them. I was a bit too late. Like, the company was hyper growing.
Speaker 2:We did have sort of a Swift client and a Java client and a JavaScript client out and a Go implementation for the server to do full synchronization on on on the Uber stack, but, you know, the company was just going so fast and nobody else shared the same vision. So I wasn't able to push it through. To this day, I still think that Uber would have been much better off if they had adopted some sort of sync technology because, you know, for the next three years, they were trying to do something similar with, you know, much, you know, various results and something that just took them took them a long time to do because it wasn't natively built in into any of the of the mobile stacks. So I I had this idea that, you know, the the next project that I wanted to do, be it, you know, mobile or be web, I wanted to do it on on sync. So, when I started, you know, toying around with, you know, this issue tracker in in back head, I just wanted to try out synchronization technologies on the web.
Speaker 2:And that was literally the first sort of prototype that I did, like, how can I do sort of a very simple issue tracker that was real time synchronized across multiple clients? And when we saw it with, you know, it was Jori and I sort of hacking on these things, you know, back in the day. And when we saw it working, it just felt, you know, absolutely fantastic. And you could imagine, like, you know, with synchronization, like, you can be in an offline state, like, where every single operation essentially happens on the client, and then sort of transactions get sent out to the server, you know, behind the scenes. And if you can build your application in a way where every operation is optimistic, where sort of the client can fathom that, you know, this operation will succeed on the back end, then you can be optimistic on the client as well.
Speaker 2:So when you do an operation on the client, you can already apply it on local state and, you know, present the view as it will be, you know, a few seconds from now when the server accepts this change, because so so few transactions actually, you know, get reverted on on on the back end. And and with that in mind, like, were able to build a sort of a quick prototype that just showed how how quick, you know, your application can be. When you start building out things, like, everything is fast, right? Like, your first program will always be fast because you run it on your local computer, but we sort of knew that, you know, the the speed wouldn't really drop from here. Like, we the the architecture itself lend itself to be real time always, right, regardless of how much data you had or how big your application grew.
Speaker 2:And we just thought that, you know, that was the best user experience that you could build. And starting with the idea, like, you know, once we started started working on linear, like, knew that we just, you know, needed to build something better. So it was sort of an obvious choice to go with full synchronization, so that we could build an application that was just super fast.
Speaker 1:Yeah. So just just for for clarity for people that are are just don't have the context. So when you say, syncing, the this is a specific architecture pattern that linear follows where a large portion of your working set of data is actually synced locally so that all the operations are happening locally. So when you're doing search, it's searching off of what's in your browser. It's not making remote calls every time you press a keystroke.
Speaker 1:And this applies to, you know, all the actions that you take. It's a very different architecture. I think I've seen it now called as like a local first architecture. I think it's different than like I think people conflate this with like offline apps. I don't think linear is really meant to be used like fully offline.
Speaker 1:I'm sure a lot of it will work but Mhmm. It's not really for the use it when you don't have internet reason. It's more for if you can sync a large set of the data locally, everything can be really really fast because there's no remote call. And it doesn't matter if your server is potentially slow or if you have a lot of different users on your server, most operations are hitting it asynchronously. And that's kind of the idea behind the the sync engine, I think you guys call it, right?
Speaker 1:And I've seen this pattern show up more, but it's still rarely deployed. I think there's very few applications I see that takes approach. And I think oftentimes I when I describe this to people, they immediately think that can't work. Like, there's no way that could work or like, sync the whole dataset locally. What do mean?
Speaker 1:That's like too much data. So do you have any thoughts on kind of that initial reaction that people have?
Speaker 2:Yeah. I mean, it totally depends on your application whether it can work or not. Like, you know, local first or sync or whatever you wanna call it, works for, when you have a finite set of data, that, you know, can load to the client almost fully. Like, we started with a full synchronization, like when, you know, when the client would boot it for the first time, they would load the entire state of that workspace locally, it worked for, you know, two, three years. And then we got sort of bigger customers where we couldn't load the entire dataset anymore because, you know, it was 200, 300 megabytes of data.
Speaker 2:So we had to sort of implement something that, you know, still felt like you had all the data locally from sort of the engineer's perspective, But behind the scenes, we would sort of, you know, stream data in if needed. But, like, yeah, if you want to do, I don't know, like an application with a lot data that sort of, you know, changes all the time, then synchronization probably isn't the best use case for you. But if you have a finite set of data, like if you're working on what you normally or, you know, twenty years ago would have built as a sort of desktop application that had sort of a remote backend where you would then store the data or synchronize the data to, then yes, synchronization can definitely work for you. The one thing that sort of we got surprised ourselves as well was like the benefit of it. Like, we initially thought that, you know, the user would get the benefit, the user would sort of, you know, get an application that was super fast, and they did.
Speaker 2:But I think like the biggest benefit for us as a company was that we were just, you know, extremely quick at, you know, iterating on the product itself. Because suddenly, like, you didn't have a web app anymore. Like, you remember not working on an application where you had to sort of, you know, do remote procedure calls or, you know, think about error handling on the back end or sort of, you know, sanitizing your data or whatever is involved in sending data to the back end and then, you know, receiving it. But literally what you had once Sync was implemented was sort of a local structure of, you know, of data representing the state of your application. And that was all that you had to work with.
Speaker 2:You never had to go to the back end. You never had to literally do anything because, you know, the sync engine would handle all of it for you. You didn't have to think about error cases because the sync engine, again, would handle most of these error cases for you automatically. So you were just like, you had a local set of data, you would manipulate that data, and, you know, eventually would call save on, you know, some of the objects that you actually wanted to commit to, and that was all you needed to do. So, when you wanted to build a new feature, you just essentially, you know, add it to that data, show it a new UI, and you were done.
Speaker 2:It it makes it so much faster to build, you know, build the product. And I think, you know, it's one of the the biggest reasons why we're so quick at, you know, shipping new functionality, at Linear.
Speaker 1:Yeah. Exactly. And that that's been that's been my my experience as well. It's a little bit of setup initially, to get everything set up correctly. And it's a little bit of a mental model shift because it's it's quite different from how most people build things.
Speaker 1:But once that's done and we just so we hit we released a v one, like a beta of of our new product. And that was a good amount of effort, good amount of concentrated effort. This past week, we've just been adding new features on top of it. It's been insanely fast. Like Mhmm.
Speaker 1:Like I I I I'd allocate like two days to do something, I would finish it in two hours, you know. It's it's kinda like it's not just a slight improvement, it's like a multiple improvement. It's it's really really incredible. The other thing that you mentioned is a finite set of data. I think this is pretty interesting because I think when people hear that, they might think, oh, it's a very narrow use case that fits there.
Speaker 1:Because obviously data is always growing, data is always changing. But you can be pretty creative about what that means, right? So with linear, obviously your issues can grow forever for all of time. Right? So you would think that's not finite.
Speaker 1:But practically, there is like a working set of issues that you care about. You know, there's maybe ish maybe you expire out issues. I don't know what exactly linear logic is, but maybe you expire out issues that have been closed that are more than thirty days old. And it's unlikely that that set of data is gonna grow infinitely because your the rate at which your team creates issues probably is staying the same. So I think a lot of applications actually can work under this model because you have natural ways of partitioning things like b to b applications like linear.
Speaker 1:You're not syncing all the customers issues, just your own workspaces issues. Right? Right. And even like b to c applications, like you said, Uber, it's not a social app. You're not like downloading everyone else's information.
Speaker 1:It's just your own information, you're on trips. So that does cover like a good portion of use cases. Right?
Speaker 2:It does. And to give you an example of sort of the finite dataset of Uber. Uber, you know, when I joined, they were using what they called, hopefully it's no longer there, they called Ping, which was a ping to the server every three seconds that would fetch all the data that the user could ever see. Oh, wow. It included sort of user accounts and trips and past trips and and future trips, everything.
Speaker 2:And they would sort of ping the server every three seconds with that. So they sort of almost were on sync, just a very sort of bad sync because they would, you know, every single time sort of get the entire set of data. So yes, most applications, if you're not talking about sort of the social graph of sorts, do have a finite set of data. And even in linear, where you're constrained to one workspace at a time, we still, within that workspace, are able to partition the data in a way where we're sort of kind of optimized what we load in the beginning and what not to load. So, do load everything that sort of has some sort of, you know, finite, you know, finite set, which is sort of your teams and your users and your not the issue, like teams users, organization and labels and things that sort of we have under thousands of issues.
Speaker 2:You know, we do see customers who have, you know, hundreds of thousands of issues, so we don't want to load them all because they're usually associated with a team. And, you know, if you have a large organization, like, you will only be part of a few teams here and there. So it's not necessary for you to load up, you know, the issues of all teams in order to, you know, have them locally available. You can do that dynamically, like, when you, you know, when you look into a team that you haven't looked in a while, we can load up the issues of that team at that point. Even if you go into sort of the issue itself, like we've got comments and issue history, which are only available and visible in in just a few screens.
Speaker 2:So we were selective of, you know, not loading them at startup just to get you to the first UI as quickly as possible, even if you're starting with a cold client. But when you then sort of navigate to a team, in the background, we start streaming in the data that, you know, we anticipate that you'll need in the future. And worst case, like if you look at an issue, and we haven't loaded any of the data, you'll see a blank screen, a quick loading screen for like half a second, and then the data streams in because it gets prioritized of what we load at that point in time. From a sort of engineering perspective, the easiest way to build an application would be that everything is local and actually in memory, because then you don't need to sort of work with asynchronous data. You would have just a struct of, you know, in memory data, and you could just render your UI as you please.
Speaker 2:The moment when, you know, things can pop in, you know, you need to work around it a bit and sort of, you know, account for that, you know, you might not be able to show some UI elements or some UI elements might pop up, pop in, you know, a few milliseconds later after your initial render because you need to hydrate them either from disk or, you know, go to the network. So it becomes a bit more problematic, but, you know, it's still, you know, quite quite easy to implement.
Speaker 1:Yeah. Exactly. And it's kinda like a like 80% of your stuff fits on that first case, and it's kinda like it kinda diminishes. Like, there are some cases where you need to handle it specifically. So me and my wife also, we work on another app together and it's very similar.
Speaker 1:Like, 95% of the day to day usage of the app fits into that very simple, everything is local, operation running locally model. But there are, you know, some situations where they're looking at reporting and they're looking at larger they're asking larger questions of the app. And for there, we'll fall back to something more traditional. But to me, it's like progressive. Like, you try to do it locally.
Speaker 1:If not, then you kind of progress to the more more network power things. And you'll find that, yeah, most most day to day operations can can exist locally. So one of the questions that I get a lot and I actually see in the chat right now is, I think when people hear this model, they think like words like CRDTs or like, kind of eventual consistency. But it's quite different. Right?
Speaker 1:Syncing is very different than like collaborative conflict resolution type stuff. Do you have any thoughts on on the differences there?
Speaker 2:Yeah. Sure. Like, so we've beaten use CRDTs for the longest time. Now we're actually implementing, you know, final CRDTs for our, you know, description editor. Yep.
Speaker 2:Hopefully, we'll have it live at at some point, because that was literally the only only, you know, point in the application where it didn't feel like, you know, being real time, yet. But if you look at an issue, for example, like, issue can have a priority, and if you modify that priority, like, there's nothing related to CRDTs that you can do there. Like, somebody sets that priority and, you know, the last one will win. Like, if if, you know, I set it to high and you set it to medium, what should it actually be? Like CRDTs can't resolve that for you and sort of set it to medium plus or or something.
Speaker 2:So for the most of the the properties on on our model objects, like, we we just utilize the last one wins schema. We don't even show you any conflicts, like if people flip it at the same time, like, we don't show you that, you know, it was just changed as you made the change, because it's really not that necessary, and people very infrequently modify the same data, even if you're at a large company. But yeah, like the editor was the last piece that, you know, we always felt wasn't wasn't great, and we've postponed it for for a pretty long time. Like it's been on our on our backlog for, I think, three years. And we always wanted to make a sort of fully collaborative editor that utilizes CRDT so that, you know, multiple people can edit it at the same time, see all the changes coming in, and sort of have conflict resolution in the editor itself.
Speaker 2:But, you know, we we just realized that, you know, it's not that many people that edit issue descriptions at the same time. So, it wasn't really a priority for us. Now that we want to use the editor for for a few other things, where we do anticipate that there will be multiple people joining into a session, you know, we wanna make that use case, work well very well as well, and just use CRDTs for text editing.
Speaker 1:Yeah. It's funny. Right before you joined, someone asked someone asked a question, hey, can you ask them why I think that there's there's a linear docs feature, why the editing there feels off. And I actually guessed that it was exactly this. So I'm gonna take the mantle that I know more about linear than anyone that hasn't worked there.
Speaker 1:So I've just looked at it so much. But, yeah, so that that kind of confirms that question, which is, again, it goes to that, like, eighty twenty thing, like 80% of your application is not collaborative real time editing. It's just very simple data synchronizing. And there's small a portion that does need that and you can kind of progressively look into that. I think the the thing that people kind of conflate this stuff is they when they hear this, they like think about, oh, is it like peer to peer?
Speaker 1:It's like that type of situation, but it's not peer to peer, looks somewhat similar because you're synchronizing states. The difference between peer to peer and this is there's a very important peer which is the server which has ultimate authority on when something happened, what order it happened in, what's the last thing that happened. So when you have that in play, which is how most web apps work, most web apps aren't really peer to peer applications, you don't need the complexity of DRDTs for the majority of things. Like you have this authoritative states, authoritative server that can determine authoritative states, and it massively simplifies everything. So this isn't as complicated as people may have seen with, kind of peer to peer technologies.
Speaker 2:For sure. Yeah. And, like, you know, you could make Linear a peer to peer network as well, but, you know, I don't know what the benefits would be. Like, you know, even with our current model, like when we run, which was like the third thing that we got out of sync, interestingly enough, is, you know, hugely smaller resource requirements on the back end. Like, we're running this, you know, with so few servers that, you know, you could hardly imagine, because most of the operations, again, happen on the client, like there's no queries that the client sends to the back end, so it's only mutations essentially being, you know, saved or, you know, being operated on the back end.
Speaker 2:And you do still still want to sort of, you know, do all kinds of validation and, you know, have an API where people can sort of submit the same mutations as well. So, you know, we need a back end for those operations.
Speaker 1:Yeah, there's another thing that we've noticed as well. I think before performance work looked like trying to make my back end faster, trying to make my database faster, trying to, like, make all those response times faster. I haven't thought about that in so long. I have no idea how slow my back end is. It could be super slow for all I know, but
Speaker 2:Nah.
Speaker 1:You just cannot tell when when you're using the application. So, yeah, I I I always found it interesting where I think when people think about performance, they think about optimizing like very specific things like I'm gonna optimize this code block. I'm gonna, you know, make my database faster, like these individual components. But performance oftentimes just comes from your architecture. Like what is the architecture you chose that can make certain things really easy, other things really hard?
Speaker 1:And yeah, it's it's quite fascinating because I think right now, if you look at I mean, it's hard to say what is a correct source for this. But if I look look at the conversations that a lot of web developers are having, it's all about optimizing server rendering speed and building these server rendered applications. Or like, you know, building new frameworks that are more performant. And I love to point to them that, you know, linear, which is feels as a user feels way more performance than majority of applications. And correct me if I'm wrong on this, it's just a React application and it's just a traditional SPA.
Speaker 1:Right? Nothing fancy going on there.
Speaker 2:Nope. It's straight up. Well, sure. Like, we have, you know, optimized it and made sure that performance, you know, on the client is is is good. So a lot of work goes in there.
Speaker 1:Yeah. But it's it's like just the same technology that's been around for Yeah. For a while just, you know, implemented in an architecture that allows it to be really fast. And, yeah, that's why I'm excited to talk to you and kind of make this more make you more aware of this because, yeah, there's there's there's a there's there's just a gap. Have you seen more companies now that you guys are out there doing it with this this approach?
Speaker 1:Have you seen more companies take this approach? I'm telling you that we're we're doing it, but have you seen it grow a little bit more?
Speaker 2:I mean, not really. I I would assume that, you know, startups that start, you know, are founded nowadays would have a look at synchronization, like if a good use case for them. I haven't personally sort of, you know, used, I don't want to say any apps that use synchronization, but, you know, most of the applications that I use probably don't. I wouldn't know if they do. Yeah, don't know.
Speaker 2:Hopefully, will just take time, you know, for people to sort of start toying around with this. The problem is that, you know, when you're building something where you really don't have product market fit, it's insane to start with a synchronization engine. Like, it's kind of wasteful and useless, like, to throw it all away, all that hard engineering. It's not something, it is hard engineering. Like, it takes you time to build a good synchronization engine, and the off the shelf solutions, you know, might work for smaller companies, but at some point, like, you'll have to build it yourself in order to optimize the use case for your users.
Speaker 2:So it's a big investment, and if you don't know, like, you know, what your product is going to be, or whether it's gonna gonna take off, then, you know, you probably don't want to make that investment. And once your product takes off, like, you know, it might be too late to make that investment already.
Speaker 1:Yeah, exactly. That's why the business part ties in really well, right? You were you guys were entering a very established, clear market. You weren't trying to create a new market, very established in the market and very clear that you're the entire edge that you're gonna have is the execution. So it made sense to kind of invest upfront.
Speaker 1:So speaking of off the shelf solutions, have you heard of Replicash?
Speaker 2:I have. Yeah.
Speaker 1:So we that that's what we use for our products. And it was interesting because I, you know, I had been researching linear for a while. Was like, okay, am I gonna do this? And I was looking around and eventually stumbled upon it and on their on their homepage, their demo is a linear clone.
Speaker 2:And I
Speaker 1:was like, this is the best way to advertise because this is what everyone is looking for. Or not everyone, again, really small set of people that I think have discovered this are interested in this, but I am fairly excited about that. And I think this is what I love to see in technology where it wasn't solution led. I found a product that I loved and I loved it so much that I just had to know how it was built. And I imagine the Replicash founders also probably saw linear at some point.
Speaker 1:You kinda see the approach proved out in a product for the end user, then you kinda build a solution afterward that can make it more accessible to more people. I think a lot of times we see solutions kind of put forth and you're like, that looks cool but I haven't actually what like, show me a product built with it, show me why it actually feels good to use or what's what's a cool thing you can build with it. And this is a great example of going in the direction that I think actually actually makes sense, right? So I'm pretty optimistic for replicash. Again, like you said, I can already see in places where we're gonna outgrow it in some ways but just to make that initial, you're going to build your own sync engine.
Speaker 1:It's still and I I want to make this clear for everyone listening. It's hard. Even when you're using an, off the shelf solution, it's just very different from what you're used to and it does take effort. But if your goal is to out execute everyone else, it's just gonna take effort. Right?
Speaker 1:Mhmm. But it's definitely it's definitely worth it in my opinion. Cool.
Speaker 2:Yeah. You know, people should definitely look into it. And, like, there obviously, there's other solutions as well, like fire Firebase being the the oldest one of of them all. Like, that was actually, you know, one of the initial sort of, you know, proofs of concept that we did. We like, my first implementation was was on coach based.
Speaker 2:I'm sorry, couch based. Couchbase.
Speaker 1:The Couch and PouchDB and all that.
Speaker 2:Yeah. Exactly. Yeah. CouchDB. And then then and Firebase as well.
Speaker 2:And we sort of quickly realized that, you know, they they wouldn't work for us. Like, I think CouchDB, you know, just didn't have any any access control. Mhmm. You know, back then, I don't
Speaker 1:know if they
Speaker 2:if they do now. And then Firebase, like, we did a small quick calculation on on the costs and, you know, our use case would have been cost us, you know, millions of dollars to to access and load all that data, so it wouldn't have been wouldn't have worked for us. But it might work for you, like, you're working, you know, on something small and you want to just, you know, add synchronization as an add on to a portion of your application, like, you know, yes, go go ahead with, you know, existing solutions and and try to, you know, start there and see how we can benefit from from from doing sync.
Speaker 1:Okay. So people did ask, is it long polling? Like, what's the actual tech stack that you guys use for synchronization? So I I think you've given a few talks, and it's probably well documented, but if you can kind of just list it out here.
Speaker 2:Yeah. Yeah. There's I do have a few talks on on how how, you know, our sync engine engine works. But, essentially, what we have is a WebSocket connection for all the synchronization stuff, and then mutations still happen on a GraphQL connection, or a GraphQL request essentially that we make, because we wanted to have the same backend for the public API and then our clients, we didn't want to duplicate it. So, if you make a change on the client, the client will create a transaction, send that over, you know, over GraphQL to the backend and the backend will create a sort of log of changes that happen to your workspace and then send those changes back to the user over the WebSocket connection.
Speaker 2:So you'll be receiving all all the changes that you've made and all the changes that everybody else has made through WebSockets.
Speaker 1:Yeah. And that's what's interesting because it's a you guys do use GraphQL under the hood, it's a marriage of Mhmm. The synchronization but still relying on, the type safety and all all other benefits you get from from GraphQL. Yeah. Because like like you said, I think most companies will need a lot of companies, especially if you're building for other companies, you're gonna need an API.
Speaker 1:Just having something that makes sense internally and externally does does make a lot of sense. Okay. Cool. So I think that's that's really everything I had. Thank you so much for joining.
Speaker 1:This was really awesome. Like I said, I just want more people to know about how this stuff works under the hood and and kinda be inspired to do the same. Again, thank you for joining, but also thank you for building Linear. Like I said, hugely influential on everything that I do today, which sounds like is what you guys hope set out to do. So hopefully, it's a it's a nice data point.
Speaker 2:Yeah. That's so that's that's so great to hear.
Speaker 1:Yeah. So appreciate it.
Speaker 2:Thanks so much for having me.
