A better way to build software
My chat with Karri Saarinen, Cofounder and CEO of Linear
Today’s Scatter Brain is brought to you by AngelList!
AngelList offers startups one platform for cap table management and fundraising. Companies like StabilityAI, Harness Wealth, and Syndicate migrated from other cap table vendors in less than a week to remove the friction from their back office. Learn more by signing up here.
Today’s chat is with the Karri Saarinen, Cofounder and CEO of Linear
Sar: You grew up in Finland. What would American tourists get surprised by?
Karri: I’m not sure if the average American tourist would notice this, but I feel it’s more peaceful in Finland, even in cities. Streets and cars feel quieter. Culturally, there is a certain respect for other people around you. If possible, you don’t want to make loud noises, invade their space, or disturb them.
Nature is always close. The Baltic Sea is also small, not an ocean that roars. When I go there, I get this inner peace quickly. In Helsinki, you can go to a public park and enjoy the sound of the trees. Or you can take a little ferry to this small island with a public sauna. You can sit there and listen to the waves lapping on the bedrock. It’s an environment to get some peace and feel calm.
Sar: What’s a memorable story from your time at Airbnb?
Karri: Airbnb was using Circular as the typeface in product and marketing. The licensing costs were massive. We weren’t always happy with the typeface, and many companies started using Circular after Airbnb did. So we started a project with a type foundry to create a custom typeface. It would be a significant cost, but it would pay off in a few years and allow us to own our typeface.
After a year of work, the CEO greenlighted a new type. We were ready to launch. However, someone in the product organization started demanding to A/B test the new typeface, which was already greenlighted. So we set up the A/B test. iOS and Android came back neutral; the Web came back slightly negative. We hypothesized that the new font added slightly longer load times because people didn’t have it cached. We tried to load both fonts to everyone and display the new font only to some to control the load time variable. We realized the A/B testing platform had a bug, and the experiment was not running properly. Our engineers spent weeks trying to debug. We couldn’t find any reason why the new typeface would perform worse. We developed it to make it more legible and work better in smaller sizes. We eventually launched the typeface regardless of the A/B testing.
This moment made me write off A/B testing as a cargo cult or a way to avoid making decisions. We wasted weeks testing something where the only outcome was to launch it anyway.
Sar: Few companies set the standards for design for the industry. Your website gets dissected for its aesthetics and usability. Talk about having a taste and paying attention to details.
Karri: We design and build a certain way because we are trying to appeal to a certain audience and drive outcomes. Many people are inspired by us. We think it's great. But where I think it can go wrong is that you forget to think about what your own unique goals with the design are. To make the right designs, you need to understand the market, how you position yourself, who and why you’re designing the way you’re designing, and how design drives success for your company.
Experience and design are quite lacking in our market. Our investment in design is partly what we want to do but also partly because the market has uninvested in it.
Linear is a high-frequency product, similar to email clients, with daily or multi-short sessions. It’s a heavy front-end product, and most actions involve managing things in the UI. You need to make it fast and eliminate friction as much as possible. A tool like Linear is about communicating and coordinating work. Getting people to use the tool requires making it as frictionless as possible and, ideally, something they want to use instead of having to use it.
Sar: Linear started as an issue-tracking tool. It now covers project management and roadmap planning. What have been the major inflection points so far?
Karri: In 2019, I got started and got a product out that works. In 2020, we launched and got the business rolling. In 2021, we became the default tool for early-stage startups. In 2022, we started scaling past early-stage startups and became the tool for growth companies like Block, Vercel, Retool, etc.
Sar: You were frustrated with the existing tools in your prior jobs. You believed the tools for coordinating software development hadn’t kept up. What disconnect did you identify?
Karri: Many tools today are “agile tools.” However, we didn’t see Agile used at Coinbase, Airbnb, or Uber. Agile was created for the software consulting world, where clients don’t know much about software, don’t know what they want, change their minds often, and probably overspec or underspec. If the project is sold as a contract, you want to minimize wasteful work while keeping the client happy. You work in smaller iterations to hedge the risk, discovering the client’s needs or wants while building functional software. Cost is very important for both the client and the consultant.
In tech companies, usually, there is a roadmap from the leadership based on the user’s needs. Most people in the product team have context for what needs to be done. It's a more complex picture than executing what the client tells you they want. Also, most tech companies are bloated in headcount and process-heavy. While they didn’t necessarily run Agile or Scrum, their PMs often brought their frameworks from whatever company they came from.
Both things focus on the process instead of outcomes. It’s hilarious how complicated or slow things get done in companies unless the CEO is involved in the project and reviews the progress weekly. Executives want to see progress, ICs want to build stuff - but somewhere in the middle, things get muddled.
Sar: Do you use Linear to build Linear? Have you had times when your instincts on what direction the product needs to take based on your usage have been at odds with the customer feedback?
Karri: We do, and it’s a constant tension between our thinking and customer feedback. Since there are many existing tools, some of the feedback comes from the fact that people are used to things, not necessarily that they are the right way to do things.
We internally talk about this tension as art and science. The science part is your research to understand the customer’s problems. The art part is you use your intuition and judgment to build. I’d say Linear is maybe 80% of our intuition and 20% of what people have asked for.
We also often default to the most constrained approach because it uncovers more reasons why the solution is too constrained. You should set constraints, see if people are hitting walls with them, and expand to find the optimal solution. If you start with the most flexible or expansive solution, you don’t get the feedback, and your users might use the feature in unintended ways.
Sar: Where does Linear’s product surface area end?
Karri: We are not trying to replace all the tools. It’s about working together with them. There are a lot of best-of-class products out there, and I don’t believe in the kitchen sink approach to software. I know there is a soothing aspect that one software platform can do everything, but I just don’t believe it is possible to do it well or be the best in anything that way.
This kind of software is a central part of product operations, so it’s easy to lose focus. Rather than features, I often think about workflows and how different loops play together in the software development process. All these software tools are about bug-tracking, but no one bothered to think about the actual workflow, how that happens, and who is involved.
For example, we have integrations with support tools and a Triage feature that creates a specific inbox for reported issues. The engineering or product team can decide what to do and can close the loop with that customer. It not only streamlines the workflow, which leads to more bugs getting fixed but also brings product, support, and customers closer together, creating better software.
Sar: You say Linear is a way to build software. You have a vision for how software development should work. Does that mean the best customers see the development the same way you do?
Karri: We are taking a pragmatic approach to software development. We codify some of our ideas in the Linear Method, but it’s not meant to be a religion. We expect people to be influenced but do their thinking based on the type of company they are in. We provide defaults and opinions.
We want to build the best tool; we believe the only way to do that is to have opinions. I don’t believe these no-code/lego blocks tools can be the best. It’s like the Linux desktop, which can be very customizable and be the best operating system if you are willing to hack it. In reality, for many people, macOS is a better experience. As a company, it’s probably more productive to deploy Mac laptops with streamlined setups than try to get everyone to hack their own Linux systems.
Having opinions is like having values; it’s hard. You have to choose them and defend them. It’s like having integrity. It’s easier to go the flexible route and say, “you do you, man.” If people complain about a feature, you could just say, “well, you could have run this function with this parameter and used this template.” While that approach might work for the personal computer or tool, I don’t think it works for a company-wide collaboration tool because it’s not productive if everyone invents their workflows.
Software development could be much simpler. In the last 20 years, our industry has had bureaucratization. We focus too much on processes and forget that we need to build stuff quickly and, ideally, the right things. Many have workflows where to report a bug, you need to fill in 40 fields, and to fix it, you need to go through 10 steps. The outcome is that people report fewer bugs and fix them less.
Sar: There’s tracking progress, and there’s making progress. I have seen some of your customers say Linear helps with the latter. Talk about how you think about momentum and moving faster.
Karri: It’s funny you mention “tracking progress and making progress.” We talk about this a lot internally. It connects with everything I’ve been saying about reducing friction, providing defaults, and designing the experience to encourage momentum instead of busy work. We should find ways to encourage people to make real progress (problems solved, code shipped). Shipping one real thing a week is better than spending hours re-organizing your backlog.
We try to build features in a way that they are direct and simple and encourage people to take action.
Cycles, commonly understood as sprints, are one of the features that help momentum. Working from a backlog that keeps growing each day can be demotivating. It’s better to select things the team should focus on for the next cycle. Cycles are scheduled automatically, rolling over the tasks that weren’t completed. Linear tracks the progress by type of tasks (bugs, project work, etc.) and workload per person so that the team can focus on making progress, not fiddling with the tool.
Sar: Were there any unexpected learnings in designing keyboard shortcuts and command line interfaces as input mechanisms?
Karri: We are all engineers and designers in the (founding) team. We built the product that we wanted to use. Vim shortcuts were one the first things we enabled. The command menu felt natural to us.
I didn’t think about it but realized later that keyboard shortcuts and command menus only feel great if your product is fast. We built Linear so that the data lives in the client and the actions happen on the client. When you hit a key, it completes the action in milliseconds and syncs the change to the server in the background. If the client needs to wait for the server response, the benefit of using the shortcut might go away. This architecture allowed us to have a global cmd+z undo function that helps with mistakes that most products don’t have.
Sar: I put Jira in the same category as Salesforce. People love to hate them, and they continue to dominate their markets. What explains Jira’s widespread adoption and sustained market share?
Karri: I think Jira is doing so well because they have built a platform that works at scale and is optimized for the buyer. The product is essentially a database platform like Salesforce.
Most software we use today could be just a database, but for most people, using a database is not a pleasant or easy experience. Jira and Salesforce continue to dominate because they solved the business case well enough and can be mangled into all setups. Traditionally, the “user case” doesn’t matter as much as the business case. Executives buy stuff from IBM because they need to make an appearance of digital transformation, while no one might ever use the stuff they buy.
Users are now getting more sophisticated and tolerate bad experiences less. The more our work becomes online, the more the tools matter. Eventually, the leadership will understand the end users’ experience should matter. Companies resisted iPhones or Macs for a long time but eventually gave up.
Sar: You recently announced Linear can now support large organizations. Your announcement had this tone of proving the critics wrong. What’s been challenging?
Karri: We focused a lot on early-stage startups because it was a market we could address immediately, and we believe those companies are the future software leaders.
However, people started to think that Linear is only for startups. With the “built to scale” release, we wanted to highlight that we have acquired quite a few large customers. Some customers started with us on day one and have become major companies. We work hard to make it easy to start and use with a small team but scale as your company grows. I think it’s rare that products do this well.
We think most of the experience scales well, and the day-to-day with engineers is similar and shouldn't change. As a company grows, there are more people, teams, layers, and complex problems. To build their feature, a team must now interact with the API, Security, and Infrastructure teams. We need to help coordinate work across the teams and layers in an understandable way. The challenge is to help manage a more complex world without overwhelming everyone and creating a convoluted product.
Sar: I have always wondered why we haven’t made much progress using software to measure an org’s engineering productivity and shipping velocity. What are your thoughts on that?
Karri: The age-old problem with measuring engineering productivity is every project is different and has multiple variables. Engineering productivity is all internal. There aren't great objective external measures. It’s easy to game. You can pad your estimates to complete more points, break issues into smaller issues to complete more issues, write more verbose code to have more LoC, or do smaller commits to show more frequent work.
In the end, you want to ship things constantly, every day or every week, and do the right things. Paul Graham says your startup rarely dies mid-keystroke. If you keep building things fast, it’s more likely you will find some success. If you don’t build anything, it’s almost guaranteed you will fail.
We don’t believe velocity or metrics provide clear answers for productivity but uncover problems or areas of improvement. We instruct teams not to focus too much on the numbers - like how many points you got done - but to look at the patterns. If you got nothing done or half done than in previous weeks, then likely something was wrong, and you should reflect on why that happened. If you have a lot of things that you added to the cycle but didn’t get done, you might look at whether you got something else done. If the team spends 90% or 0% of the time fixing bugs, that could be problems in focus.
The Analytical Reporting we are building continues the trend to help people to get these insights on larger datasets, over time or across the company, to understand how things are going and uncover potential problems. We think including these directly in the context and in the product is much more useful than using a discreet service or platform to analyze this stuff.
Sar: Linear’s team is fully distributed. What about the popular discourse around virtues of remote work do you think is overblown?
Karri: Linear started as a fully remote company in 2019. We made this decision, which wasn’t based on what other people or the industry thought. This debate between remote and in-office is pointless. I don't think anyone can ever prove one way is better because you cannot run a fully controlled study. I don’t think companies are purely optimizing with a single metric, like maximizing shareholder value in mind, so each company values things differently.
Our industry has this hyperbole approach where many new things become proclaimed “the future of X is Y.” Like “remote is the future of work.” When VCs or people removed from the activity start saying, “X is the future,” it probably won’t be the future.
Some CEOs are now inspired by Elon and want to bring people back to the office. VCs tweet, “CEOs at this dinner no longer think remote is the future.” I understand that you need to adapt as a business, but you shouldn’t flip-flop the way you operate based on Elon or a dinner discussion (unless you’re willing to replace your whole team). It’s like you are building a team for baseball and then deciding to pivot to soccer a few months later. Both are ball sports, right? No, I don't think it works. Culture is a kind of circular feedback where you attract and hire the type of people who are interested in that specific culture, and they then make it stronger. If you can’t decide what kind of company you are in, you likely won’t have consistent culture, which creates tension or “culture clashes.”
Many have proclaimed that as a remote team, you cannot do a pre-PMF startup; you can’t build well, you can’t work hard, and you don’t get good ideas. A single data point, we have done all these things while being profitable, and thousands of happy customers use Linear. Both ways of operating have advantages. The same approaches won’t work for both. So, in the end, what matters is who you hire, what kind of culture you build, and how well you operate the company.
Sar: Talk about how you think about hiring people and building teams.
Karri: We have a high bar, and technical skills are not enough. We look for critical thinking, taste, communication, and judgment in all roles. In any role, we like to think about how this person can push the role forward and execute at a much higher level than commonly expected. It is hard to source and screen for that in resumes or interviews. There is a shortage of these folks as larger tech companies often don’t give IC engineers many opportunities to execute their ideas or encourage opinions. We also tried recruiting agencies, and VCs often send us candidates, but almost never has been a fit. Now we have a four-person recruiting team that understands our bar well and focuses much more on quality than quantity. We have the patience to wait until we find the right person.
We like to keep the team small and not add lots of senior leadership and management. This magical thing happens when you have the skill to build and the agency to make decisions in the same brain. It's like having the CPU and memory on the same chip. But the tradeoff is that this puts more pressure on us as founders to hire and direct these teams.
Sar: What views have been reinforced by the Linear journey so far?
Karri: Have a small, focused, experienced, IC-heavy team as possible. For an average software startup, pre-PMF, I’d keep the headcount under ten people. Adding more people never makes things move faster, makes you more focused, or makes the quality better. Whenever I think about a time in my career when we built something great and impactful, it was always a small team, mostly ICs. This constraint makes you focus on the important things. You spend less time on alignment and more time building or learning.
Driving a startup with A/B or metrics. We have hardly made any decisions by metrics so far. We mostly think about building better products and solving problems. Some people start optimizing these things too early and focus on funnel metrics before they have a product that people are excited about. I’ve seen seed-stage startups that start setting their metrics goals before they even have a working product out.
Growth is necessary for startups but not worth sacrificing everything for. Whenever I see charts or startups saying they are the fastest company to reach a $1B valuation, my reaction is, “why.” Why would you rush it? With quickly increasing valuations, you reduce the employee equity upside. If your growth is not sustainable, you created this trap, and the company could implode if you can’t raise the next round. Your learning and operations likely didn’t scale as fast, but you likely tried to fix it with more people.
Recent chats :
Swapping homes for your next trip with Justine Palefsky, Cofounder of Kindred
Unpacking Crowdtangle's breakup with Facebook with Brandon Silverman, ex-CEO of Crowdtangle
Future of coding in India and on mobile with Amjad Masad, Founder & CEO of Replit
Adobe's transformation with William Allen, an Adobe alum and crypto founder
Building mobile esports streaming out of India with Pooja Dubey, CEO of Turnip