Creating magical software

Transcript for Founders Talk #94


Adam Stacoviak:
So Jori, welcome to Founders Talk. It's been a journey, the past four years, building kind of in silent; not much chatter about Linear and how you're building things... You kind of keep quiet and just build awesome stuff. Is that a good approximation of y'all's style?

Jori Lallo:
Somewhat. Maybe it's just the Scandinavian background and humbleness; we're not in press, or doing these kind of engagements either. This is the first podcast I'm being part of... But I think we've just mainly done our own thing. A lot of Twitter, I would say... So you definitely probably heard about us if you're an active Twitter user, but beyond that, we've been relatively heads down and building with users.

Adam Stacoviak:
Well, very impressive. I mean, I think if you've never been to Linear.app ever, even if you've never used it, the first thing you think of is "Wow. Beautiful design, thoughtful user interface design", obviously thoughtful user experience, because you could just see the thoughtfulness in all those details. How does that manifest? How do you organize a team to get to there? Does that just happen serendipitously? Does that happen accidentally, or is that very intentionally?

Jori Lallo:
It's definitely intentional, or there's intention behind it. Going back a little bit to how we started the company, we started the company with Karri and Tuomas. Both of them good friends, and worked at different companies in San Francisco - Uber, Airbnb... Myself, I was at Coinbase for quite many years... And seeing how almost the last decade of our industry, how companies got built, it was a lot of focus around speed, and hiring, and growing... And at times, it almost felt it was mainly for the sake of growing, instead of actually focusing necessarily on the output, or at least the quality of the output.
With Linear, we're always being very focused. So just trying to focus first on the core fundamentals of the product, and get something working that we like to use, a couple of other people want to use... When we started Linear, we didn't -- this was like 2019. We were like "Let's just build. We luckily have a little savings; we can build for a couple of months before just doing the whole VC, chasing funding and whatnot." So we just started focusing on building. Luckily, people noticed it and cared about it, so after that, raising money for it wasn't that challenging when it comes to time usage. So we were able to keep building, but during the first year, we didn't hire anyone, because we were like "Okay, let's get something off the ground", instead of trying to add more people to it, and worry about then figuring out how we're gonna build a team around it.
Later we, of course, hired folks, but we always tried to hire very slow. During the first year I think we maybe hired three or four people, mostly on engineering and building... But still, very focused on the building part. And now, we're still hiring very slowly. And that's intentional. We do week-long work trials for everyone we hire, no matter if it's in engineering or design or other parts... Depending, of course, a little bit on people's situations. But we're very intentional about who we bring on, at what point of the company. I think we've talked to a lot of amazing people over the years, but not everyone's the right fit at that time of the company.
So a lot of these things are -- we think about them, and it's easier to be a little bit more maybe like slow, or intentional and careful, than trying to fix stuff afterwards. Overall, we know this is a long journey; these products have existed for a long time. We kind of know how companies work, we kind of know how people use these products... So I think that gives us a certain level of -- we can take our time to figure out the right way to do it, for at least our own way, I would say.

Adam Stacoviak:
Right. What struck me as interesting was the way you describe yourself. You say it's the new standard for modern software development. Meticulous design, we've already talked a little bit about that... You focus on speed, you're opinionated, but flexible workflows... This seems, obviously, very software team-driven, very user experience-driven, very well-designed. But how would you describe Linear? Is it issue tracking? Is it product development? What exactly is Linear?

Jori Lallo:
\[05:42\] I mean, on the higher level we just want to help people make better software. And issue tracking is the term that we've been using historically, because it's something that people already associate the product category with. Of course, it's not only that, and I think a lot of other companies might put higher level things on their website, and so on... But we're kind of honest, and it's easy to communicate - issue tracking, plus project management, but it is meant for your product teams who are building products, software products. Ideally, not only for engineers, but designers, and other folks in that spectrum. And that's also something that we -- we feel strongly that it should not only be the engineers who are in the product, it should be everyone in that org. You get your feature request or bug reports from your customers. What is that story from them flowing in, getting triaged, getting into the product, getting shipped? So kind of that end-to-end experience, and it's not just -- engineering is a very small part of it.

Adam Stacoviak:
Gotcha. I was gonna say, because when I think issue tracking, it's kind of like one part product planning, where you sort of take a roadmap or a trajectory of where you want to go, and you sort of map out user stories, and you plan things etc, you have the right kind of team members there... But then it's another part where you've got literal issues in the production software, and how do you roll that in? So I wonder, at what point does Linear end? Does it do integrations with, say, Sentry or others to do end product integrations, where you can say, "Well, I've got an issue with my JavaScript on this page, it impacted this user, so now it's into the plan, and it's a bug tracking/issue tracking"? How far does the spectrum of building products end, or begin?

Jori Lallo:
There's both product improvements, and then there's bugs and faults that need to be fixed. Sentry, for example, is one of the intakes into Linear. You can create issues from your Sentry exceptions, issues can be created from customer support tickets, they can be bugs, or they can be feature requests. It's part of the complete mix, and we're trying to find a balance between building out features and building out improvement and select these larger projects, but also keeping your software on a stable ground. At the same time, you need to fix things that are there. You need to fix the paper cuts, you need to fix the bugs, at the same time as you're trying to balance building out larger, new features.
So it's definitely our playing ground, and we try to build out workflows into like the triaging, managing ongoing things, but also more on the other side of the coin is the project management piece... Which people kind of do all around; they might use other products to prioritize things, or get user feedback, and so forth... But we of course would love to a lot of that stuff happen inside Linear, or kind of happen in any tool you use, but ideally, as long as we integrate well with that experience. I think that that's the most important thing for us. We're not trying to own everything. I think that's the wrong way to think about building products.
A lot of people use Google Sheets, and spreadsheets, managing their projects, and that's fine. If that works for you, cool. Ideally, we can integrate with that. Of course, we'd love to have a better experience for it, but we're not going to force anyone into it.

Adam Stacoviak:
Well, speaking of better experience - I mean, you've got some pedigree yourself. You were part of -- this is interesting too, about your past, Convore, and Leah Culver, and Grove... You know, way back in the day before Slack, we were trying to like "Can we just use IRC in a more modern way?" And that's kind of what you were doing there...

Jori Lallo:
Yeah.

Adam Stacoviak:
\[09:51\] ...which I just wanted to touch on really quickly, while I was mentioning your past... But you had some history at Coinbase, and other places, and you said that Linear was born out of frustration, because there were no really great project management tools out there for developers particularly, and I would imagine software teams more so than just developers, because you said that you want to be beyond just developers, and invite everyone in the product teams, into the mix, to make do etc. I'm curious, this frustration that you felt while on other teams - Convore, Grove, Coinbase etc, and your other team members that felt that same pain... What were the particular frustrations, and how did you approach with Linear solving those frustrations in particular?

Jori Lallo:
Grove was a chat product before slack came about, and that's just mainly - of my story, and my co-founder story, we actually worked on different pre-Slack chat apps among the team...

Adam Stacoviak:
I wanted it to win, honestly. I was a Convore user.

Jori Lallo:
Oh, really? Okay, cool.

Adam Stacoviak:
Yeah. I think it was Convore \[unintelligible 00:10:51.01\] if I recall correctly. I can't recall the exact story, because this is probably --

Jori Lallo:
Yeah, Convore was first, and then it was when I started as an intern, we started working on Grove. So I worked on the web client on that, and I was in the Python, Django scene early in my career... So this was a very, very fun experience, and it was a small company. It's actually -- it ended up just being Leah and me building stuff for a little over half a year, until I moved back to Finland.

Adam Stacoviak:
That's cool. I was just like, I wanted IRC to win, and I felt like "Can we just modernize an experience on IRC that wasn't necessarily, at the time, HipChat, and a couple others I think that were trying to win?" I think Campfire was still relevant then. I think this is definitely pre-Slack, or at least the early, early days of Slack.

Jori Lallo:
It was definitely pre-Slack.

Adam Stacoviak:
Okay. I wasn't sure exactly when that fell...

Jori Lallo:
I think it was before HipChat had sold to Atlassian. I remember HipChat - those guys, they were actually on the other side of the hallway in the office building where we worked, so...

Adam Stacoviak:
Is that right? That's crazy.

Jori Lallo:
Yeah, it's a small world.

Adam Stacoviak:
Yeah. So small. So close and so small. I just remember thinking, particularly for us - like, we have a free community, changelog.com/community; we want everyone to join, there's no imposters here. Everyone's welcome. And part of that experience is real-time comms with the community that has gathered around our podcasts and our greater Changelog podcasts universe. And I just knew the future for us was some sort of real-time communication, and nothing really fit the bill. I'm like "Well, every hacker loves IRC, right?" Or desires to love it more if they don't love the limitations of it. It's hard to admin, it's hard to use, and I had super-high hopes for Convore, and then also Grove by way of Convore. I think, eventually, Slack pulled us in, and it was just -- it wasn't necessarily better, it was just different, let's just say. And obviously, we know where we're at today, because Slack has pretty much one that war. They're the biggest dog in the fight. Now, there's Microsoft Teams and others, but... IRC is still around; it didn't win, though. And I was hoping that you all would you do what you did with Linear, which was make a better experience on top of such a convoluted, frustrating process... Which is kind of where we're camping out there.

Jori Lallo:
Yeah, well, that is probably one of the reasons why I didn't really go too far, is IRC is a pretty limited protocol, and you kind of have to hack around it. So in the end, I'm happy that Slack came about and built a better product and a better experience. Personally, I think why Slack really won the game was they entered the game around the mobile era. They actually had a really good mobile app before anyone else. There were, of course, mobile apps in the chat space, but nothing on the level of what they were able to do.

Adam Stacoviak:
Well, that's what we needed from something like Grove. I want not just a chat on my desktop, but when I'm on the go, too. And I need to be on multiple devices... And IRC was primarily desktop-only. It just was not something that you could use on mobile. So we really needed that multiclient experience, just because the world is just so mobile these days. I don't watch Netflix only on my TV, for example. I use Apple TV with a TV, and then sometimes an iPad, when we're on the go, or my iPhone, it fits somewhere else... Whatever. The point is, we're just definitely a multidevice culture now< and IRC just couldn't extend there.
\[14:22\] That's interesting to think about though, because if you had succeeded, the market was still limiting, right? Slack is mainstream; it's used by enterprises, not just hackers. And IRC is very attractive to the pragmatic, which tends to be those around, or actual software engineering. That's just a thing. Because you like simplicity, you like some of those things that come with IRC... And even the freedom, the distributedness of IRC, etc. And Slack just was the exact opposite, essentially... Centralized, and all that good stuff.

Jori Lallo:
Yeah. Over the last decade we kind of went from protocols into applications. And there's probably clear reasons, too. Protocols are -- they're hard to evolve; they take time. And especially now that we're living in the era where we're kind of reinventing all of these tools... Take Slack, Notion, Linear and whatnot - you can't really build them on top of a protocol that you can control; it doesn't extend to your needs. Of course, I'm a big proponent of there should be open APIs, and it's been a little bit sad to see APIs maybe getting a little bit closed down, and that excitement to go away a little bit... But I personally really care about that, and want there to be extremely good APIs for whatever I do. Even if people don't use them at scale, but it's just like you as a hacker, or you as a developer - it's just, building something on a good API... There's something really magical about that.

Adam Stacoviak:
How does that manifest then in an open API world? How do you see that playing out?

Jori Lallo:
What do you mean, like, open API?

Adam Stacoviak:
Well, what's your perfect world? If that were true for everybody, if everybody had your belief of open APIs and accessible APIs for people to pull data out, or move, or whatever it might be, for whatever reason; or build something on top of. I think of like early Twitter days, when the API first became accessible - there were so many things built for and around Twitter, because it was proving grounds, for one, for API mashups. Let me plot out a map with my Twitter followers, for example, is a good example of an API mashup. And if that API was not available and open to use - well, that mashup would not be possible. So if that's how you feel, how do you see that playing a role in today's marketplace with products?

Jori Lallo:
Well, hopefully, let's see, at least in the social area that companies will keep opening up APIs, and so on. Of course, it's hard to build stuff around them, because the products are evolving so fast as well. I still use Tweetbot.

Adam Stacoviak:
Is that right?

Jori Lallo:
I wish Twitter would have kept their API more open. And hopefully, it'll be more open in the future. At least for business software, most companies do have APIs. So that's good. And integrating - even if they're not protocols, plugging different APIs together is becoming easier and easier with Cloud Functions, and using a couple of lines of Python or JavaScript in between to convert things and match things up.

Adam Stacoviak:
Tweetbot is a good example...

Jori Lallo:
I'm pretty optimistic about it, actually.

Adam Stacoviak:
Okay.

Jori Lallo:
Yeah. As long as you provide Markdown, for example, and JSON is pretty much good to go... Markdown still works between a lot of apps. With Linear, we don't use Markdown as the data store format, or in our own editors, but we ingest and we output it, because we know that that's the format that's extremely easy to manipulate in other apps, or put into places. When we build out a prototype -- some of our own apps, actually, like our Zendesk, and other customer support applications, they put Markdown into our APIs, just because we can still have a text area out there, and it made it easier.

Adam Stacoviak:
\[18:20\] Yeah. I think there's love and hate out there for Markdown, but it has won. So you can't deny the win, and you can't cry about it, because it's not going to change. I guess you can cry about it, but it's not going to change. So why not just work better with it, versus trying to recreate it. There's a lot of people out there who don't like it. I don't mind it. I do think it has its own issues, but it has won. So I think you all made a wise choice with that ingestion and whatnot, and how you're storing your data, and how you're presenting it to users and whatnot.
You mentioned Tweetbot, and I think that's a good example of the challenge, really, I would say, with an API... Because specifically with Twitter, they desire -- and maybe this is a challenge you can speak to, with like APIs being more open... Is that I think Twitter got to a point with their design team and experience team - they wanted a particular user experience. And Tweetbot, while good, great design, great team behind it, very thoughtful leaders behind Tweetbot - I mean, \[unintelligible 00:19:16.18\] team was pretty cool... They had great ambitions; I just wonder if that's the best example, because Tweetbot to me... I was a holdout, almost like you. Not to this day. I'm not still holding on to it, but I did hold on to Tweetbot for a long time, thinking "Man, eventually Twitter will just work more closely with them because they're so popular, to give them more rates, or less limitations", some sort of blessing on the API that no one else has. Some sort of partnership or agreement. But that's an example of an API being used in such a way that it kind of competes with the overall desired user experience for a platform. Would you agree with that, with Tweetbot and Twitter, the client they have?

Jori Lallo:
Sure, but the people using Tweetbot, out of the whole Twitter userbase, is such a minuscule amount. And I think it's short-sighted from Twitter; I understand a lot probably of to business justifications. You don't want there to be a huge third-party client ecosystem where you can't show ads. But especially today, there's a handful of us Tweetbot users still; we use it, but I don't think we're a threat in any way to Twitter. We're more or less the asset of the hardcore early users.
I think companies should embrace their early users. This is more on maybe the SaaS business software world, where things start more consumery, and then turn more enterprisy, and you kind of forget about your early fans.
I think Slack is actually one of the companies that has been able to walk that balance nicely. They are still extremely accessible to regular folk, but still, the majority of their business probably comes from more of the enterprise side. But they're doing both, while still being a business software example.
On the other side, take Dropbox. I used to be a huge fan, but then they started putting up-sells everywhere, and even you easily can't opt out of it... And I was just like "Yeah, iCloud Drive", or whatnot. So there's multiple examples of that. That's something with Linear, even if we're going upstream, and selling to larger and larger companies, I still want us to -- it needs to be accessible software. It should make everyone's life easier. Of course, it's still business software, we're gonna charge for it. Ideally, students will use it for free, and small companies use it for free... But we're not going to turn our backs against those small startups, who got us started. Lik, they were the first people getting excited about it.

Adam Stacoviak:
\[22:06\] Dropbox is an interesting story too, because here we're at odds again, because you're using Tweetbot, I'm using Twitter... The clients, in terms of the application I'm using... And then you're saying no to Dropbox, and here I am, Dropbox in my system tray here, or whatever the heck you call that thing on a Mac, as a daily driver... Mainly out of reluctance. I can't say I'm the most happiest Dropbox user, but there's still nobody, in my opinion, out there really competing with it. I mean, there's options and alternatives, but not competition, you know what I mean? The ones you mentioned are not necessarily trying to be Dropbox killers. There's no Dropbox killer out there. There are some applications that only use Dropbox to share settings and things that. Alfred is an example, where it's easy to have Alfred on multiple computers, which I do, and have my settings go from computer to computer. And I use several Alfred applications or modules or whatever you call the different things within it. And that's just one example. But I agree with you on the embrace early users; I totally agree with that.
And I would say I do use Dropbox reluctantly, because -- I wanted to take a lesson from your things you've learned, which... One of them was talk to your users. I feel Dropbox does not talk to me. Not the me-me, the actual me, but more the royal me, of the people like me. Because if they did, Paper would be different, Dropbox would be different... There'd be just differences in the way the thing works.
Now, we use it very specifically within Changelog Media to manage our workflows, and our editing... So we have large filebases that -- for example, this podcast will end up in the Founders Talk folder in our production flows. Our editor team will grab that, make the session, do all the things they do, edit the show, make it awesome... Later on I or somebody else will grab it and master it... And this is all via Dropbox.

Jori Lallo:
Yeah. And I feel like that's completely valid. And you are like a business user of it.

Adam Stacoviak:
Right.

Jori Lallo:
For individual users, I would say that internet shared file storage between devices have been pretty much commoditized. You take Google Drive, or iCloud Drive, or -- you can put files everywhere nowadays.

Adam Stacoviak:
iCloud Drive is not the greatest experience though, either. It's pretty -- they're all pretty sad, honestly. There's really no winner there. They're all pretty much losers in a winner's game.

Jori Lallo:
But it's also like how much you care about it...

Adam Stacoviak:
It's essential though, right?

Jori Lallo:
I don't use files anymore. I have my text documents there, but sure when it comes to work, I think everything started being in apps. Of course, software, but I don't put software in there. That lives on GitHub. My design files are in Figma... I think it's one of those areas that are getting commoditized. Documents is another one. Screen recording is becoming part of almost any app. Documents are starting to be part of almost any app?

Adam Stacoviak:
Well, since I mentioned one of your lessons learned that you can share, I think it makes complete sense, like hands-down sense to talk to your users, right? But there are some out there who build and don't. My gosh. Can you please extrapolate on that in particular? You mentioned build with focus, aim for quality, obviously... Can you share some more of your lessons learned that makes sense to share here?

Jori Lallo:
Yeah, it's just like having your customers and users close to you, and having a dialogue with them is extremely important. For us, that was something we started from day one. Even before we even had the product out, we started doing change logs, public change logs. Putting out there what we're working on - it helped with our own focus, keeping ourselves accountable a little a little bit, that we're constantly shipping and putting stuff out there, but also sharing with others what we're doing...
\[25:53\] We never liked to talk ahead of time, or promise things that we're going to ship, because we kind of want to manage expectations. Plans change all the time, so you don't want to make people unhappy just because you said something and you did another thing. But a certain level of openness of things that you actually do - that's something we noticed works really well for us, and also opened us up to dialogue with our customers. And we try to keep that up even as we grow, and now work with companies. We have Slack channels with a bunch of our larger customers, so that they have a way to report things to us, or ask questions, and for us to have a dialogue with them, instead of there always being some middleman there.
Of course, not all of this -- it doesn't scale infinitely. That's why we have a customer experience team working our help desk, and everything... But still, we try to have a pretty tight \[unintelligible 00:27:03.03\] product, and also integrating the customer experience team into our product building. I think a lot of companies, or at least how I've seen companies handle these things is that your engineers and designers, they kind of decide -- like, they might talk to customers, but then the other functions are maybe less important to some companies.
At Linear we try to put same level of effort when it comes to hiring and running different functions within the company as we do engineering, because all of it is part of the same experience that you get. Whenever you're applying for a job, like talking to a recruiter, or you're reading tweets that we put out - all those functions should have the same voice, the same level of quality that you find in the end product.

Adam Stacoviak:
How does that manifest then? So let's say I'm on the customer experience team, or I'm out on Twitter, and I'm paying attention to our channels... And when I say "our" I mean Linear's channels... And I'm just -- I'm tracking the heartbeat of what seems to be either my actual user, a customer actually using Linear the software, or a prospective that wants to, they're still curious, they are still sort of evaluating what their next move might be, whether they're moving from the alternatives to Linear... Whatever it might be. What's the process for the team to gather that feedback, and then share that with the rest of the product team to make a choice, to say "Okay, well, we thought this was the right direction, but here's how people are actually using it, or here's what the desire to have"? How does that manifest into the actual product and something shipped?

Jori Lallo:
In different ways. Our customer experience team - they might set up a call with the customer and invite engineers into those calls. We try to do that as much as possible. We will, of course, track stuff into Linear in terms of feature requests and whatnot... That's still not on the level that we want it to be, and ideally, over time we can make that better. Most of our customers have the same problem as we do on it. It's extremely hard to prioritize these things, and surface and share between the teams... But at the state that we're at - we're a 30-person company - a lot of it I think comes to us having the relationship between the teams. Having people sit in the same meetings, instead of trying to separate the teams. For example, when it comes to hiring for our customer experience team, myself or one of the other founders are part of that process. We interview people still to this stage. They join our stand-ups, or our sync meetings. Our off-sites are for everyone. So we build out the culture to know each person, work together across those team boundaries. I feel that's just easy to forget, especially once you start to get to scale, unless you design for it from day one that your teams don't separate too much, and have different language between them.

Adam Stacoviak:
\[30:16\] Well, you're at 30 folks now; you're roughly four years old. You mentioned the first couple years you stayed pretty lean. You've hired slowly and intentionally... Do you give the teams autonomy? How do decisions get made? ...let's say in that example where our customer success team is talking to a customer, they invite an engineer on... Where do they go from there? Do they come back and talk to you or other co-founders and say "Can we do this?" Or how do you give permission to the teams, and how does autonomy happen? How does decision-making happening on the direction? The reason why I ask this is because you seem very deliberate with how you've created your culture, and you created the direction you're gonna go. And we'll talk about your readme, and other things you do to sort of vocalize that to the public, and also internally, but you seem very intentional with how you build and what you build. So how do you give that freedom to your teams, or lack thereof if you don't?

Jori Lallo:
Yeah, you try to hire people that you can trust, and ideally, they're better at their job than you are. That's one thing. But when deciding what gets built and whatnot, there's of course different levels to it. Some small thing that someone complains, if you have enough context, or if you know how the product team works from the customer experience team, or you as an engineer have a good sense of what is within our focus, what can we do, and so on... Small things you can, of course -- the best is if you just take it and fix it, and it's very clear-cut. And there's certain -- of course, it's a cultural thing that you know what those things are. Of course, as a remote company, we're still trying to figure out distributed decision-making probably as it would happen -- even if we would be in the same building, probably it would be as hard, almost... But we're still trying to figure those things out.
Of course, some things we' re -- we're very good on saying no to things, or deferring things, unless we know what the way of solving it is. Some bigger things - we talk about them, we keep talking about them, and at some point they come on the roadmap. Right now, end of the year, we're setting up the roadmap for the next year. We have a couple of big projects that are there, certain focus areas that are there. But also, we've talked a lot about things that we do not want to do yet, just because we don't have necessarily the resources, or it's not necessarily on the focus. Eventually we want to do them, but you still have to pick your battles, and stick to those decisions. But of course, things change; it's a startup, so sometimes something new comes about, you might reprioritize things... Yeah, overall, we're just trying to stay nimble, and hire people who can also make those decisions who have taste, who use the product. You can't know the limits a little bit at the same time.

Adam Stacoviak:
Yeah, for sure. Taste is a great example. And nimble is a great example, too. I think the other word might be agile, but it can get conflated, especially considering the space you're in. But I think nimble is a great example of how you want to be. Because when I think nimble, I think ballerina. I think very strong and intentional movements; very delicate, but also very powerful when necessary. That's what I think of, at least.

Jori Lallo:
Yeah. We change direction all the time also, when it comes to certain things. If you see an opportunity -- this is maybe not on which bigger product features you're going to build, but more on the company running side. If something, for example, happens on the market, you might do something differently. And as long as people have the mindset of you can change in the moment, and reprioritize, that's good, that you're not so stuck in your ways that everything needs to be on the roadmap, and very defined.

Adam Stacoviak:
\[34:21\] Can you speak to that process then? Because I think one thing that you mentioned in sort of the pre-call notes, in terms of a mistake, or something you could have done a little bit better was building that recruiting team. I think you mentioned three recruiters, one coordinator... Waiting too long to build out a team that can bring in the right people with taste. So to give that autonomy and to give that ability to make decisions without having to have a meeting with the founders or whomever every single time direction changes. You've got to have the right people in the seats, and part of that is getting the right people to evaluate that, to bring them into the team and give them all those different tools and opportunities. So how did you learn that lesson and how did you build that team?

Jori Lallo:
We've been recruiting people for three years now... And kind of a little bit backstory... So for the first couple of years of that we did not have an in-house recruiter. Then for a year we did have one person. And today we have four people on the team. It just meant that us founders were doing a lot of the -- of course, you start yourself doing everything. We did customer support, we did recruiting, we did sourcing, and managing inbound candidates and whatnot... But it takes a lot of time, and more importantly, it takes a lot of focus. So the only way to scale that, of course, is to have more dedicated resources on it, and then you can focus your time on more important things in that process.
For the longest time we only had one person on it, and when you're hiring for maybe four different roles, and trying to reach out to people, plus handling inbound, handling people in the process, coordinating that - that's quite a lot of different hats that you have to wear. So I wish we would have recognized it a little bit earlier and hired a full team around it. We did realize that this year, and started hiring for it.
It's surprisingly hard to find really good recruiters. I don't know why, but... That's a role that I care a lot, and I work a lot with our recruiters, or I try to work a lot with them... Because they're like the first line of defense, or the people screening and getting people in, into the process, that you want to get out at the end. So you really have to have really strong trust with the team, and speak the same language. It's not just a resource that you can -- or you should probably not outsource it if you want to do it really well.
Of course, for the start, we did outsource it, and it ended up working well, but it's a very different experience than having that team in-house. And I just wish we would have done it earlier, and have invested more into it. But today I'm pretty happy. Maybe we could have less on it, but I'm happy that we have more resources on it, and I love the whole team. They're amazing.

Adam Stacoviak:
Well, the reason why I was digging deeper into that - because I think it leads to the ability, obviously, to add people to the team with taste, that you can trust... But four people a 30-person company - it seems a lot. That's 13% of your workforce. Right? I mean, if you were doing layoffs - which I'm not seeing you do, but it seems to be the status quo these days, to do layoffs... And if you laid off four people, that's 13%. That's the entire team. By no means am I saying do that. I'm just using the numbers and the state of the beings.

Jori Lallo:
Luckily, we don't have to do that, because we've been profitable for over a year at this point, so...

Adam Stacoviak:
Excellent.

Jori Lallo:
We're only looking to hire, although I still keep the hiring at a good pace... But no one's getting laid off, that's for sure.

Adam Stacoviak:
Well, I'm glad you spoke to that, because that's not what I want, for sure. Just using it as an example. But four seems high, is the point. I mean, four seems like a lot for a 30-person company. Is that normal, I guess? Is that common, to have a four-person hiring team?

Jori Lallo:
\[38:15\] When I joined Coinbase in 2014, the team was roughly 20 people, and they had two in-house recruiters. And they were both amazing. I'm still friends with both of them. And that can be a really strong asset for the company, especially if you're hiring for a lot of different roles, which we are, and which Coinbase was hiring us for.

Adam Stacoviak:
When you say different roles, what do you mean by different roles? Quantify different roles.

Jori Lallo:
Different types of roles. So engineering, design, customer experience, customer success, sales, and so forth. We're probably hiring four or five different teams currently, and engineering is only one of that. So you'll want to have dedicated resources for each one of them, so that you don't switch your focus every single day that you can actually focus on the one area, and build good competency on it.
A lot of roles that we're hiring today are also the first time we're hiring for them... So it's a lot about learning "What do we want to see in that role at Linear?" As I said, we want every team to be excellent, so we just don't want to like "Okay, let's just get someone to do that." That's not how we work. We want to see who is the inspiring person who cares about their craft, and is really good at what they do in that specific area.

Adam Stacoviak:
Yeah. How does that translate then? So if you're hiring for the first time for a role, the recruiting team - is it their job or part of their responsibility to sort of evaluate the process of onboarding that kind of new role, and that learning process? How does that learning manifest? Is it founder-driven, is it team-driven from the recruiting side? Who's responsible for that learning process?

Jori Lallo:
The recruiting team overall runs the process, designs the process, with founders, but also people who would be working for the team, or who is the hiring manager for the team. Of course, they have a lot of experience hiring for different kind of functions, and they can bring that to the table, and that's kind of like the starting point. But then it's more about a team effort of us figuring out what we want to see in that role, or the people in that role. And we probably start from somewhere - we look at people we worked with in the past, how we've seen that function work in our previous jobs, potential candidates, but then we start talking to people and we start calibrating based on those experiences. Often, the first people you talk to are not going to be the ones that you hire, because you didn't know what questions to ask, or what qualities to look at... We're still small enough that we try to hire generalists, or people who can think on their feet, and not just people who come in later in the game, when the whole team has been already established; it's more about getting those initial people to seed the team, to figure out how what's the Linear way of doing that function.

Adam Stacoviak:
That's a challenge, right? I mean, it's gotta be probably the most perplexing challenge, especially as small as you are currently, to hire well, to have such great taste. I'm camping out here because the design is flawless, from an actual interface perspective. And then the software is amazing as well. And to be able to build at the pace you have been building, at the caliber you've been building, you have to have the right people. And what a process it might be, and is, to recruit for those folks, learn through the process, brand new roles etc. and do it all in-house, versus have external teams doing that for you. Because you can probably get mixed results. They don't understand the culture very well, they can't be part of these nimble meetings, where directions may change etc. So I can only imagine how strong this is for your team, and how others might learn from this lesson, which is like "Hey, invest sooner in your own in-house recruiting team."

Jori Lallo:
\[42:22\] You have to use the time upfront, when you set up those new teams. But once you have the foundation, and they're part of your culture, and everyone speaks the same language - it's much easier to scale then. So you design products, but then you kind of have to design the companies as well, that are building those products. And just use a similar level of care in that process. And of course, not always you get it right. Same with products; you have to sometimes course-correct a little bit, or maybe you ship bugs and whatnot... But as long as you're able learn from it, then...
This is, of course, the first time for me to be in this role, hiring for different kind of roles... And same for my co-founders. So you're educating yourself at the same time as well, but trying to keep an open mind, and not just do what you saw at your previous company.

Adam Stacoviak:
From the outside perspective, you seem to be doing very well at it, so congratulations on the perception of success, even if it's not true, or if it is true. Because from the outside, it seems pretty awesome what you're building... Which leads me to the readme y'all have out there. It's Linear.app/readme. And I think this is -- I can't help but keep camping out in this recruiting process, because I think at the end, I was like "Wow, okay, this was a great story", but this was the ultimate velvet rope for Linear and those who may be curious about your story, and then potentially want to be part of your team... Because this sets the stage quite well with how much intention you put into your story. You say that like all good stories, this is a story about magic. And you go on to describe the past, and you even have an audio clip of an old-school modem dialing up to the internet, which I had to listen to, end to end. It was about a 30-second clip. And I was like "Man, this is what the internet sounded like back when we dialed into the internet", versus broadband, which is ubiquitous now, which we've never even looked back, right? Of course, the internet is always there... And you sort of set the stage with the journey, the past, the present, and where you're trying to go. And it ultimately leads you to choose your own career, which -- but tell me about this page. How did this manifest? There's so much intention here, from the old Apple 2 on the left-hand side, changing as you scroll... Very, very intentional, sharing your story. How did this page manifest? Tell me the story.

Jori Lallo:
The story goes back to when we first started hiring for Linear, roughly three years ago. We did have a version of this page that we called Readme... It was just text. It was just how we think about the world, how we think about building products, how we think about craft behind building things... And now, of course, the current iteration is much more well-designed; there's a little multimedia, and the team did a really amazing job at it. But - I mean, it all comes down to the people that we want to hire. I'm approaching late 30s at this point; I grew up pre-broadband era. I was calculating minutes on the dial up that I was online on the IRC server... And there was this magical feeling to computers when we were growing up, and we kind of lost a little bit of that magic over the hypergrowth days over the last boom cycle, with like Facebook, and A/B testing... All these things became very, very prominent, and the growth took the front and center, from actual building the product details, in many ways.
\[46:14\] We really care about the product details, we care about building out good products that people want to use, and sustainable software... And we're trying to communicate how we want products to be built. We know that there are older people who feel the same way. Of course, this is not the most efficient way to recruit, of putting this couple of couple of pages worth of text, and videos, and audio and whatnot... And you kind of have to go through it, and get to the end... But if you do, and you're excited, you're the person that we want to talk to. You think about it the same way. I don't know, it's like The Matrix; remember when they were like "Oh, I feel like there's something wrong about the world", and you just feel it, and then you find your people, and you get sucked in... Just, that excitement... I want to work with people who have that excitement to their work. \[unintelligible 00:47:19.05\] but you actually really care about what you're building. And this doesn't mean that you're working insane hours, or anything. You just care, and it shows in the output that you do.
That page is -- it's not designed by me, it's not written by me or any of the founders. It's designed and built by the team that I get to work with every day... And it's an amazing feeling to come to work and be inspired by the people around you.

Adam Stacoviak:
Yeah.

Jori Lallo:
And hopefully that, of course shows on the product that we put out, but also other things that we put out. We want our tweets and everything to be things that we also care about ourselves, and that we find inspiring ourselves.

Adam Stacoviak:
I think it's a lot of brands and a lot of teams -- I said this before on a podcast, we were talking to Arun Gupta at Intel; he works as essentially head of open source ecosystems for Intel... And they have a really interesting story; you would never imagine it, as big as Intel is and how focused they are obviously on hardware, how focused they also are on software, and open source in particular. And one of the points was like "Well, Arun, how does Intel tell that story?" And the topic essentially was there is so much in the story; and I think what you've done with this page is you've shared your quest, for a lack of better terms. Exactly what you say on there, which is your story. And I think people underplay that.
Today, to attract the right kind of teams, to build the right kind of direction, and hire people that have taste, that you can trust to make decisions, begins with telling your story in a way that captivates them, and makes them see the world the way you see it. Because it's all about beliefs, right? If I believe what you believe, then it's easy for you and to be unified. That's why there's so much fracturing in society today; there's a lot of disbelief, or a lot of anti-beliefs, or just not a lot of sameness in beliefs. A lot of congregations and whatnot, but the point is, if you believe that I believe, it's easy for us to unify on the mission, and do the work at hand for said mission. And that's what you've done with this page; you've shared that story and you said "This is what we believe. And if you believe what we believe, and you agree with this journey - well, hey, you should probably join us."

Jori Lallo:
\[49:44\] It makes my job easier, because -- yeah, of course, I believe in this, but... Building out companies and building startups is hard. Often you don't know what -- well, first of all, no one really knows what they're doing, or what is the best way. You just have to pick a way. But when you're starting a company, when you are building your first product, you might not have your customers, you might not know what the product even is. There's this journey, and it's extremely draining when you don't know, but you still have to show up and put on a little bit of a show for the people that at least believe in something, that this is the direction, and accept the direction for the team... Because if there's no company, then people won't stick around. Luckily, that hasn't been a problem for us, because we didn't have to really imagine this problem that we're solving. It's something we always felt.
We think we have a lucky viewpoint into building a better product in that space... But now it's also about communicating that inside our own company, but also to people who want to use the product. \[unintelligible 00:50:56.01\] companies are storytelling in the end. Of course, Apple is one of the best ones in that game...

Adam Stacoviak:
For sure.

Jori Lallo:
...but even as a customer, you want to get behind something. And for us, we care about craft; we want to bring magic back into building software. And that is something we genuinely believe; it's not some made-up mission statement somewhere. But luckily, that's where we are today, and it makes our lives much easier. It's genuine.

Adam Stacoviak:
This is making me think about how much you personally get to work on Linear the product, versus Linear the business, which are two separate things. I'd imagine four years ago you were knee-deep in the actual product, and today you're probably a couple of steps removed, just by nature of growth, just by nature of how things pan out. Can you speak to, for a lack of better terms, what is it you do here, kind of thing? How often do you get to work on Linear the product, versus Linear the company? Because it seems like you're an enabler; it seems like you are getting the right kind of people on the team to build the right kind of product, with the right kind of mindset, and less about doing the actual building of Linear today, the actual product.

Jori Lallo:
It's definitely on the founder journey one of the harder things, to figure out when to step down from certain functions and replace yourself. I stopped coding this summer, more full-time. Before that, I tried, but I always felt like I was behind, because I didn't have time for it... But luckily, one of my employees said that "Jori, maybe you should not code anymore." And it's almost like someone giving you permission... But it felt so good. And then, I guess I decided, "Okay, I won't be part of building out bigger product features anymore." And it felt so liberating.
Then I unlocked all of this time, or angst that I had for -- I was okay having stuff on my calendar, because I didn't have this other job that I had to perform anymore. So now - I don't know, I try to do a lot of things. So whatever I feel it's the highest impact for the company... It varies a lot. I do a lot of hiring, of course... Hiring especially for engineering, but I also care a lot about -- I'm helping out our sales team set up their tooling right now, for example. I care a lot about internal tooling, period, because I think that's the fundamental system to make things work at scale. Instead of hiring people, you build out systems, you build out tools that enable people to be more efficient. And that should be something -- engineers, of course, are amazing at that. You can automate all the things, because you have the skills to do that. But not all the other functions have that, so I'm trying to augment and get the team to build out some of those things.
Actually, now at the end of the year we're swapping a whole lot of tools and we're building out a lot of internal tools, just to get rid of these manual processes that we have, or swapping out tools that we don't particularly, into better ones.

Adam Stacoviak:
\[54:15\] Dropbox. \[laughter\] I'm just kidding, I'm just kidding. That's smart to do though, right? I mean, there's a lot of people who will say "Don't build internal tools."

Jori Lallo:
Yeah. But then there's a lot of brands who have shown that you should build internal tools... Because everything you build and maintain is "a distraction" from product. And a 30-person team - I'd imagine maybe you want to be 35 the next few months, just based on pace... But that's still a lot of people to have an internal tools team. I mean, at some point it's like "Does that really make sense?" You have to quantify, Invented here vs Buy elsewhere.

Jori Lallo:
It's a balance, of course. Some things you want to buy. But it's also then deciding which product do you buy? A lot of new tools, the teams behind them are using Linear, so we hear about them relatively early.

Adam Stacoviak:
Oh, nice.

Jori Lallo:
We're using a lot of those tools...

Adam Stacoviak:
Any you can name? There's gotta be one you can name, at least. Maybe two.

Jori Lallo:
\[laughs\] On the sales side, for example, we're now getting to use -- Census, they've been using us. They're, of course, a couple of years old already. \[unintelligible 00:55:20.08\] is another tool for CRM space; they've been using us, and we're now about to start using them... There's a lot that I could name, but it's really nice to have these relationships with these other builders, because we give each other feedback, and we try to learn... And also, we get to use this next generation of tools while building Linear.
But then the other side is some things that we have to built on top of, or integrate into these tools, and integrate across different tools... So that's something -- I hope we can bring the team together, so that we have more continuous process on this, and everyone contributes to it, instead of there being a separate internal tools team whose responsibility this is. Maybe it would be down the line, but today all the problems are in a way everyone's problems, because there's no dedicated person assigned to a certain thing. But if we can create efficiencies, and make our own lives happier by building out good product experiences inside the company, I think that helps out a lot on the culture and how people work.

Adam Stacoviak:
Yeah.

Jori Lallo:
And then we don't have to hire that many people. \[laughs\]

Adam Stacoviak:
Yeah. Well, good luck with that, because I think that you're probably gonna hire a few more people... But what strikes me when I hear you say that is it seems a good idea, but I wonder how it will affect focus. Because, when you have product team folks not focusing on product, it seems an inefficiency, right? But I guess you all prove it; you prove us if that's true or not... Because it seems a distraction. You want them to have feedback into the tooling you all use, whether it's internal or external, that you buy... But I just wonder how it will play out when you have everyone owning, versus a team that takes feedback. Kind of like customers. That's what internal teams who build internal tools get the advantage of, is they get to be their own team building for -- and their customer is essentially the company it works for. So I wonder, I'm just curious how that will play out for you, or how much examination you've done on that whole philosophy.

Jori Lallo:
\[57:51\] At this point, our engineering team is a little over 10 people... But we do move -- even when we're building out product features, we move people around the product area. So people get to work on different areas, and different projects, so you're not a team that just works on integrations, for example. We kind of like pass the torch a little bit to get people more exposed to the different areas, and not getting too bored into one.
And now that we've been building some of these internal tools, a lot of engineers actually really like it, because it can be less stressful. The stakes are lower. You're not changing something drastic into product that requires help from design, it requires change management figuring out all the edge cases, and talking to users, and so on. You're gonna just take a month and build something for your co-worker, or for yourself, that makes you all more happy. I think that's really powerful, and I hope we get to do it. Actually, I've been getting back into coding more, but I mainly work on these non-critical path internal things or improvements into the product that are not really on the critical path; no other person has to rely on my pull request go out at a certain time.

Adam Stacoviak:
That leads to this YouTube I've found, which was the recent AMA, the live at Figma, which I just see -- it was just a month ago. And you transition from the old and busted, really awesome homepage and website, to the new, phenomenally almost double better - you can market that, double better... New site. And you show -- this video essentially is about three minutes long. There's no sound that I can tell, but it's just like everybody inside of Figma designing out, commenting about the direction... So it seems you're drinking your own champagne when you say "Everybody's involved in building everything", because it seems like way more than just your design team. It seems everybody's in here. I don't know, speak to this AMA... What is this about?

Jori Lallo:
Yeah, it happened roughly, probably a little over a month ago. So we had a DDoS attack. We hadn't had one before, we weren't completely prepared. Luckily, it was at the end of the day, so our engineering -- engineering team, designers and whatnot of course set up Slack and started solving it, and we were able to bring the site up, at least on the way to get into the application, relatively fast, through CloudFlare workers, just because Linear is a single-page JavaScript application, so we were able to bring that up.
But on the day before that, we had launched our new website, our new homepage, and we had a dedicated URL, linear.app/homepage, so that we can share it on Twitter, and if logged in people go to it, they still see it. So we had put that out, and the tweets were still going a day later... And as we had this DDoS going on, we brought the site back up, but it really bothered me that people who saw those tweets would just end up in our login page, which is a little less grandiose... Still nice, but nowhere near what they were probably expecting to see.
So I just asked our web engineer who built the site, and our designer, "Hey, guys, can you put up a public Figma file of the design that we can redirect this one path into it from our Cloudflare worker?" \[unintelligible 01:01:37.20\] it's going to be a weird experience when they land into Figma. The team was a little bit hesitant to start to do that, but I kind of forced my way on them to do it. And people loved that. And we actually had some of the other designs there.
\[01:01:59.16\] I went to have dinner at that point, but the party kind of got started, and people joined the Figma file, and our team basically did an ad-hoc Ask Me Anything by purely -- of course, without audio or anything, people were using Figma's commenting system to ask questions, and our team was writing notes on the answers. And then they did that for a couple of hours, and I hadn't -- this was completely unplanned. But this is one of those things, like I mentioned before, you have to change direction. There's really no risk of doing it, but it seemed like people really liked it, and hopefully we can do more of this kind of community engagement in the future as well.
So it was not people designing together, but it was like a video of this ad-hoc thing that just happened to happen. And luckily, we were able to resolve the DDoS, and later we brought the site back up... But this was one of those extremely nice things that just kind of happened without any design.

Adam Stacoviak:
Well, it was interesting to watch, that's for sure, because I was like "What is exactly happening here?" But it also gave us a tour through your Figma file, which obviously is designs of the interactive website that you see at linear.app. It's not the real thing, but you can, as you said, comment in Figma. And this ad-hoc AMA is a good way, I would say, to utilize that negative time, right? Because you kept things positive.

Jori Lallo:
Yup. And also, maybe gave people a little bit of peek behind the curtains how we do things, just because they saw the iterations that went into them, and also saw some of how we use Figma and how we use our design system, which is not that complicated, I think, even when it comes to engineering and building products.
Of course, we want to talk a little bit more how we do things, because I think sometimes I realized that people have misconceptions of how we build out things, or how we think about things. I've heard, for example, stories where some founders think that "Oh, we want to build this feature like Linear. Let's use a couple of months on it, let's get it perfect, and so on." That could not be further from the truth how we do stuff. Sometimes we try to get stuff out - still polished, but as fast as possible, to learn, and it's not perfect... And when it comes to design systems, ours is -- it's messy, it's small, but it's nimble, and it's perfect for our size today. It doesn't need to be this big, fully thought out system, because in the end, that might actually slow us down, because we need to still iterate a lot around it.

Adam Stacoviak:
Well, that also gives you a chance to change, too... Because if you put so much ceremony and so much investment into it, and it's like "Well, six months from now this isn't really working. We want to make some changes", it's harder, because you've built yourself a Titanic, versus a speedboat. And speedboats are obviously more nimble than a Titanic, just based on just sheer history, right?
Very interesting... So what are some of the goals for you personally, Linear, for the future? I know where you're at now, 30-ish people, building intentionally, hiring as fast, but slow as you can, with intention, getting the right kind of people that have taste on the team, so that you can make wise decisions, and give that trust, and give that autonomy, where it makes sense, obviously... Learning by recruiting on your own... A lot of fun stuff you've done there. I think that's a really interesting lesson. But where are you guys heading in 2023? What's happening?

Jori Lallo:
\[01:05:53.19\] Trying to grow with our customers, I would say. Linear's being used by larger and larger teams all the time, some of them we have as public references, for example Vercel, and even Cash App; their engineering team is using us.

Adam Stacoviak:
I love Cash App.

Jori Lallo:
Those are much, much bigger organizations than we are, and they have different kinds of needs. There's a new stakeholders, or new user profiles of the product. Of course, we started building for the ICs, for the engineers, for the designers, but now we have directors, and product managers, and so on. They just require a different lens into product, while still using the same product.
So we're trying to figure all that stuff out. Also, how to automate some of these more manual processes that people have, and integrating -- like, building more things from customer and like other inputs into the output that is the product. We want that end-to-end experience to be really well, to be really good... And there's a lot of different systems that go into it, a lot of different solutions... People work a little bit differently, but just enable people to build better products in that framework.

Adam Stacoviak:
Gotcha. So Vercel, Cash App, or big teams... What stage is Linear right now in terms of acquisition customer type? While those might be bigger teams, would you say that you have been, and been better at smaller teams, say 5, 10, 15, 20 people, maybe 100 people on a team? Vercel and Cash App are obviously larger than that... Would you say you're now in this space where you're attracting more attention from enterprise, and you maybe have to shift your directors and whatnot? Is that what's happening? Customer type-wise of what you're attracting.

Jori Lallo:
We want to serve both. The small teams are where we started, and we want to build a really good product for them going forward. But of course, some of our focus is also serving these larger teams of several hundred people and thousands of people. But we're not trying to leapfrog into being the tool for a large IBM, or a company that. We just know that's gonna take time, and we're trying to learn from our existing customers.
The beauty of startups and building for growth stage companies is they're growing... We're just in it for the ride, almost. We try to learn from them, what do they need, and how can we make the product better for them, instead of artificially try to leapfrog in front of it. So we've been very fortunate on just trying to keep up with the demand, and building for the companies that come to us.
Of course, when we get to larger companies, people who want to adopt Linear inside the company, they have their own hurdles. These organizations are extremely complicated, and that's where sales comes in as well for us. It's not us spamming people with email, like cold emails of buying Linear. It's more about helping these companies that want to try out Linear to figure out how can they do that most successfully. Because it's not something like you can pick this tool up yourself as an individual engineer; you have to get your team behind it, and then in the end it's the whole company or the whole organization that uses the same tool.

Adam Stacoviak:
\[01:09:35.10\] I would imagine, since you mentioned earlier that you play a role in working with sales -- because you said you're not coding as often; I imagine that part of what you do is work with sales on maybe specific sales scenarios. And so maybe you've got your eye on a couple of different "enterprises" that are 100 people, 200 people, 500 people, that you got -- maybe dream customers, so to speak. Like, "Let's attract them, so that we can 1) serve them, but 2) learn from what they need", because you want to maintain... I'm assuming this, at least; tell me if it's true. You want to maintain based upon what you said before, which is you want to support your early users, which is smaller teams. So you don't want to build Linear to the point where it's like "Well, it serves these larger teams, but now we have sort of lost touch with product direction wise and user experience wise the smaller teams." Because a small team doesn't have the same needs as a larger team. It just starts to manifest; you need different dashboards for directors, directors want to see \[unintelligible 01:10:31.16\] because they're not really interested in the actual issues, or the work to be done; they're more like what happened, was it successful, is this on time etc, which are things that I've seen in your user interface. I imagine that's probably what you're doing, right? Are you working with the sales team and saying "Okay, while we may not be cold calling, but let's also have some ideas of who might be the best earlier, larger brands to work with, to learn from, and to serve?"

Jori Lallo:
Yeah, of course, there's a few of those companies that we've been talking to for a while, and trying to figure out what they need, and when we could serve them... But then I work with actually other founders, both companies relatively small stage, where they're picking up something, like learning how to use Linear effectively; we want to educate them, make them successful running their companies, not figuring out how you should use your issue tracking tool, or whatnot. Ideally, Linear can also give you some guidance on that outside the tool itself. We have some materials around Linear Method, that we hope will build out more of our thinking into how to build better products... But then it's also, we talk to some of -- even the founders of larger companies, who care about their teams, and want to make their teams more efficient and more happy, with new tools, but it's always the struggle of finding the time and the focus to figure out like "Is this the right tool? Is this the right time? And if we would pick this, how would we migrate into it?" Because they're probably already using something, but the tool is only as useful as how much it's being used in the organization. That's what we noticed - people actually using Linear, and use it, so there's more data. And it's not a tool for the data's sake, but it's an organizational pulse, like seeing what other people are doing. And once you have more people there and active there, collaborating, it makes you more efficient.

Adam Stacoviak:
\[01:12:44.14\] Yeah, I would imagine, because it seems like Linear has the opportunity to sort of bridge gaps, to unify some of the conversations, to unify some of the wins, which I think is something that you all do with your changelog, which is celebrating wins. I think that if Linear helps those teams do similarly what you've done well - which, I think you've done pretty well with that - then that to me would be a big win, because you're bringing the right kind of people together to sort of see where you've been, and not a lot of tooling out there is doing a great job. You don't see that in Slack; you see sort of the drive-by wins if you're there, or the random AMA Figmas that might happen, for example, which you may go to dinner on, and hey, that's great, but you missed out on the other two hours where there was more conversation and more things happening. When you have a tool this, you're able to showcase a lot more of the win, of the direction of the product.

Jori Lallo:
And people are builders... You know, we love building. Software engineers, they love coding; they love what they do often. And it's -- yeah, you should celebrate the small wins and accomplishments, and the details that you get right in your products, no matter what the product is. So we want to enable people to do their best work, and to do it more enjoyably.

Adam Stacoviak:
What can we share in closing? What's on the horizon for you, that not many people know about, that you can share? Not so much an absolute secret, but -- I know you don't really talk too much of the future, but what's something that people can expect in, say, January or February, that you know you're going to do, that you can sort of tease or talk about here today?

Jori Lallo:
I don't think there's going to be any drastic changes, but we're definitely trying to focus on improving the workflows that we have inside the application. Some things that we've been thinking a lot is how triaging for example happens,; when new things come in, how do you figure out if you have the right amount of information to do the thing, make the call, getting in the right place. Reporting around data as well. We started building out analytics this year, and we're going to release more on that next year. But it's also an area - we are just trying to figure out what is the Linear way of doing it, and how can we make our customers more successful in it. Because I know \[unintelligible 01:15:08.14\] they're powerful, but they can be also easily misused. And no one wants to manage their team by lines of code committed, and these kinds of vanity metrics. So it's more about figuring out what's the health of your team, and how can you build things faster, with better quality.

Adam Stacoviak:
Very cool. Well, Jori, thank you so much for coming on and deep-diving in some of these topics with me. It's been fun catching up with you, learning about your journey, learning about some of the crossover we had with Convore, and other things... That's really interesting, to see some of our paths indirectly cross. And I'm also just a big fan of Linear. I think you've done a great job with leading, definitely doing some cool stuff, with the right kind of lens and motivation in building your team and building your product. So I appreciate you coming on Founders Talk, man. Thank you so much.

Jori Lallo:
Thank you so much for having me. It was a pleasure to have the chat to open up a little bit how we're thinking about the world.

Adam Stacoviak:
It was awesome.