Inside Linear's Engineering Culture
Tuomas Artman went from Big Tech to startup co-founder. He shares how they built of Linear, the working culture and learnings from Big Tech used at the startup. An exclusive deepdive.
👋 Hi, this is Gergely with a 🔒 subscriber-only issue 🔒 of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers.
Tuomas Artman is the co-founder and CTO of product tooling startup, Linear. He’s been a software engineer for more than 20 years, alternating between being a developer, a founder and an engineering manager. He previously worked at a company aspiring to be the “Disney of China,’’ at Groupon, and at Uber.
I first met Tuomas when we both worked at Uber; he was a senior staff engineer on the mobile platform team and his team was creating Uber’s new mobile architecture, RIBs. Tuomas left Uber in 2019 after five years, to co-found Linear.
Over the past year or two, I’ve increasingly heard startup founders say they use Linear to manage their workflow, while software engineers I know have praised the tool’s capabilities. In January, Linear’s CEO Karri Saarinen shared that more than 1,000 startups pay for Linear, that the company runs on a small team of 17, and that they achieved their first profitable month two years after being founded.
Earlier this year, I reached out to Tuomas to learn more about his background and how he ended up in Silicon Valley and at Uber, why he cofounded Linear, how it operates, and any lessons he’s learned.
In this issue, we cover:
From Finland to Silicon Valley
Starting a new company
The first hires
Technology stack
The working culture
Hiring
Big Tech learnings applied to a startup
See also a Deepdive into how Linear operates (with Linear’s first engineering manager, Sabin Roman), and an update on Linear, written year after publishing this article.
With that, it’s over to Tuomas.
1. From Finland to Silicon Valley
When I was 18, I won a place at university to study computer science. However, after a few weeks, I dropped out because I got a job at a company called To the Point, a business which produced CD-ROM presentations.
After a few years, a group of us friends founded a development agency called Valve Group. We had eight cofounders and I became the CTO. We built rich media presentations, and I picked up technologies like Flash and Flex on the go. In a short space of time, we became the de facto rich media house in Finland. I did this for nine years, from 2000 until 2009, by when I had grown bored and wanted to try something new.
I worked at a few startups in Finland and also founded a small consultancy. Then in 2011, I took a leap and moved to China to be CTO of a company called Apple Toon, which wanted to become the “Disney of China.” When I joined, the company employed about 250 people.
My adventure in China was interesting; it was an unusual setup in many ways. For example, none of the company’s computers were connected to the internet, because they feared theft. This was because an earlier team of theirs had worked on a game for a year and had it almost finished. But as launch day approached, the team building the game stole the software and launched it themselves.
Later and out of the blue, I got the opportunity to move to the US. A former colleague lived in San Francisco and needed more engineers, so he called me up. It turned out Groupon was buying his company, and my acquaintance was incentivised to bring in more engineers as part of the deal. The deal went through and Groupon acquired my finnish company which I was using to publish iOS applications, which is how I ended up there.
Groupon
After this acquisition, I got transferred to the US on a manager visa in 2012.
I joined Groupon right after its 2011 IPO when momentum was still strong and before it started going downhill. Back then, Groupon wanted to create a new product to take on Square. To put a team in place that would build payment functionality, Groupon initially planned to buy five smaller startups, but eventually it only bought the one I’d joined via my former colleague. So, instead of having around 50 engineers to build a competitor to Square, there were only four of us. My team built a few prototypes, but in the end we merged with the Point-of-Sale team.
After two years, I got my green card, meaning I was free to work wherever I wanted. My number one choice was Uber.
So, in 2014 I joined Uber in San Francisco.
Uber
I started developing on iOS back in 2008, when the iPhone came out. I built an RSS reader early on, and it made quite a bit of money because it was one of the first apps of its type in the App Store. From then, I was hooked and created a bunch of apps on the side. I built iOS apps, as my main jobs were more backend-related. In China, I built a sync engine, and at Groupon I started out on the backend, but after merging with the Point-of-Sale team I worked on iOS full time. When I interviewed at Uber and I wanted to work on customer facing mobile, but quickly after joining the mobile platform team was formed and I was asked to manage the team. Later I moved back to being an individual contributor (IC) working as a senior staff engineer.
2. The motivation to start a company
Gergely here. Tuomas had a great career at Uber, growing into one of the most respected mobile software engineers at the company. I asked him why he left a good, cushy job.
The motivation to start a company
I live for startups and love working at small companies. I’d founded a company in Finland and knew I wanted to do it again.
I consciously took jobs in Silicon Valley to prepare for my next startup. I wanted to learn, to build up pedigree and to create a financial buffer. Most important was the learning; I wanted to gain knowledge. For me, working in Silicon Valley was the best schooling I could get as a software engineer. It was not until later that I appreciated the significance of the pedigree which comes from working at high-profile tech companies.
Jori and Karri - the two other co-founders of Linear - had also created a company called Kippt, which got funding from Y Combinator. It was a bookmarking service which grew into a knowledge base solution for corporations and eventually was acquired by Coinbase.
So, how did I meet my co-founders? I’d met Jori a long time ago, back when I was working at a startup in Helsinki. He was interested in startups and through friends, he pinged me, asking if I wanted to talk about startups. I was like, "yeah, I'm having a beer. Come over." He joined us and we were talking from then onwards.
Karri and I met in San Francisco. When you move abroad to a new city as a Finn, you tend to quickly get to know your compatriots also living there. We’re both Finnish so we hung out. We were both doing well in our respective jobs, but wanted to launch another startup and at some point, we started talking about doing something together.
As a founder, if you want getting investment to be relatively easy, work at a big company first. After that, you're on the radar of investors. And if you have a founding team with Big Tech pedigree, the idea you’re pitching becomes less important as a selling point. In our case, our founding team came from Airbnb, Coinbase and Uber. Investors wanted to hear our idea, but I suspect we got funding easily because investors thought: "okay, here's the team which built products from scratch and knows how companies scale. So yeah, let’s invest in them."
In the end, all three of us – Jori, Karri, and myself – are entrepreneurs at heart. Having a “cushy job” was like taking a breather between founding startups.
The idea of Linear
In early 2018, we started talking about how bad all the issue tracking solutions were and arrived at two separate realizations about project management solutions.
1. ICs dislike their current project management solutions. All big project management solutions were built for management. As a manager, these solutions work pretty decently and cater for their use cases. This was why we didn’t hear many managers complain.
However, many software engineers and ICs disliked all of them; few talked positively about any of the solutions. We kept getting back to this and asking ourselves, “why hasn't anybody built a project management tool that ICs like? What are we missing?”
There was clearly a business opportunity, and Atlassian had grown huge off the back of software project management. So, it seemed like a good opportunity to start working on something better.
Still, after detecting this opportunity, we weren’t really sold on the idea. While we knew we could build a better project management solution for ICs, we were not excited by the thought of building yet another project management software.
2. Product companies don’t really have any methodology for building products. We worked at companies regarded as among the best product companies in Silicon Valley, such as Uber, Airbnb and Coinbase. But none of them had any methodology for building products. Approaches differed from team to team. Most teams used bits and pieces from Scrum and couldn’t really explain why they were working in sprints.
These two realizations helped formulate a mission we could finally get excited about. We weren’t going to build another project management solution.
Instead, we’d do this:
Help companies build better software products. Start small with issue tracking and focus on ICs working at smaller companies, initially. As these companies grow, we’d build up more functionality and support scaleups. In the end, we’d have a product which could go head-to-head against the common enterprise solutions.
We founded the company in 2019 with two engineers and one designer. We wanted to build a simple and functional product, and all three of us shared this aspiration. Also, we complimented each other; myself and Jori are software engineers, and Karri is a designer. Jori cares deeply about the customer experience, I’m into more complex technical solutions to make the application really performant, and Karri is an excellent product designer. With this team, we thought we could create the best project management application in existence, as a start.
As a throwback, here’s an early design of Linear, back in 2019:
As comparison, here’s how Linear looks like in 2022:
Funding
Our initial approach was not to raise funding before we had a hint of product market fit. . However,we were approached by Stephanie from Sequoia in April 2019, literally two days after we announced our company on Twitter. Because it was Sequoia, we took the meeting. To be precise, Karri did because the rest of us didn’t want to get distracted from building the product.
While it would make for a great story to say Karri didn’t even have a pitch deck, in reality, as I found out much later, he had put together a simple one the night before. At the meeting, Karri was clear we didn’t really want to raise money until later.
Encouraged by the meeting with Sequoia, we decided to look around a bit and Karri took some meetings with other investors, which led to us receiving a few term sheets. We inspected them and decided it made no sense for us to postpone raising money because the valuation was already high for a seed round . A few months later signed with Sequoia and Index Ventures.
In the end, raising money for us was simple because we didn’t want it.
3. The first hires
We raised our funding in the summer of 2019 and it took four months to make our first hire. We hired Miha, a software engineer, whom Jori and Karri worked with at Coinbase and were friends with. We had been talking with him for a while at that point.
For your first few hires, you can probably rely on your network. Reach out to people you worked with previously, whom you know will be good and compliment your team and lay the foundation for your culture. For that reason, we did no formal interviewing for the early hires.
Our next hire was Andreas, a software engineer, who started out as a contractor. Jori had followed him on Twitter for a long time and reckoned he’d be a great fit. He was finishing up a job at Klarna when we reached out. At first, we asked Andreas to help us out on the frontend. He shipped some really amazing things and we managed to convert him to full-time. This hiring approach was one way we get great people in.
Consider starting off with freelance contracts, and then hiring people. This is especially relevant in places like Europe where many of the most experienced software engineers often work as contractors, thanks to a variety of factors like higher earning potential, more favorable taxes, interesting projects and not needing to worry about the career ladder.
This was how we hired all of our recruiting team. We hired three recruiters a few months ago, who had been working with us on contracts for about two years. It was an easy decision to hire them full-time when they showed interest in joining us.
Our first five hires were three software engineers, one designer and a customer success hire. We hired Erin to help us with customer success, because we struggled with the pain of answering all the questions customers sent our way. Even when we were in beta, we’d get large amounts of email and messages through support channels. Customer support got to the point where it overwhelmed us. So, we hired Erin to start the function and to grow it, over time.
We try to hire people who can later grow into leading their respective functions. Erin is a good example of someone we hired, hoping she could grow a function as the company developed. This means we look for early hires with the desire and capability to grow. It doesn’t always work out as hoped for, but we do try our best.
This summer, we hired our first engineering manager. We approached this in pretty much the same way as with our infrastructure, in that we started to build out this function earlier than necessary. We could have probably grown quite a bit more before running into problems, but then we would have to act fast to fix them.
So, we started hiring for an engineering manager early on, in order to fill this role before we had a desperate need for it. Hiring sooner meant we could try out a few approaches with less risk, and it also gives the new hire more space to try things in post.
We currently have 30 employees, of whom 18 work on product; comprising 15 software engineers and 3 designers. The other 12 people work on support, administration, sales, marketing and recruitment.
4. Technology stack
We are building on top of Google Cloud. When you are choosing your cloud provider, you really have two straightforward options: AWS or GCP. On paper, they look pretty similar. However, in my view GCP is moving ahead on cost-for-performance.
In the end, we went with GCP because the user interface is much better than AWS.
For our tech stack: