Latest / The Pragmatic Engineer / Linear: move fast with little process (with first engineering manager Sabin Roman)

Transcript

Linear: move fast with little process (with first engineering manager Sabin Roman) · The Pragmatic Engineer

0:00
SPEAKER_0: You use email very little?
0:02
SPEAKER_1: We don't use email at all internally.
0:04
SPEAKER_1: We generally use email when we want to talk to some of our customers, and some of the tools that we use may require reaching out to support, but not for internally.
0:11
SPEAKER_1: If you have a question, you may decide that question is urgent, you can ask it in a group chat, and people will answer really, really fast.
0:17
SPEAKER_1: Maybe I'll just spend a little bit more time and figure it out myself.
0:20
SPEAKER_1: That's a good thing about not having email.
0:22
SPEAKER_1: You can't just send an email, because it's easier that way.
0:25
SPEAKER_1: The goal of the goalie is to address all incoming reports from customers.
0:30
SPEAKER_1: So the first goal for the goalie is to go through all of those requests and fix those issues as well during the week.
0:37
SPEAKER_1: As they do this, they are also active on all the support channels.
0:40
SPEAKER_1: A customer wrote about a bug in the product and the engineer was like, "Oh, I'm looking at it."
0:44
SPEAKER_1: An hour, two hours later, he was like, "Okay, it's fixed, deployed."
0:47
SPEAKER_0: Wow.
0:47
SPEAKER_0: Yeah.
0:48
SPEAKER_1: I'm like, "Wow, I haven't seen that."
0:50
SPEAKER_0: Sabin Roman is the first engineering manager at Linear where he heads up engineering.
0:54
SPEAKER_0: Linear is a project manager in software, especially popular with startups.
0:57
SPEAKER_0: The company has raised $50 million in funding and are known for their unique design, snappy years of experience, and for having a real traction with startups and scale ups.
1:04
SPEAKER_0: In this conversation, we go behind the scenes on how Linear's engineering team works, and we cover Linear's tech stack and their full remote engineering culture, a deep dive into how a specific project was built.
1:14
SPEAKER_0: We look into the overhaul of the new project functionality within Linear, comparing how a large company like Uber works, whereas a small one like Linear.
1:21
SPEAKER_0: As an interesting fact, Sabin worked at Uber before Linear, and so did Linear's co-founder and CTO Tuomas.
1:26
SPEAKER_0: Oh, and one more fun fact.
1:27
SPEAKER_0: Me and Sabin used to work together at Uber on the same team.
1:30
SPEAKER_0: I hope you'll enjoy as we go through tactics on how an engineering team can move fast with surprising little process in place.
1:36
SPEAKER_0: If you enjoy this show, please subscribe to the podcast on any podcast platform and on YouTube.
1:40
SPEAKER_0: All right, Sabin, welcome to the podcast.
1:42
SPEAKER_1: Happy to be here.
1:43
SPEAKER_0: So you've started your career as a backend engineer.
1:47
SPEAKER_0: You did Java.
1:48
SPEAKER_0: You then worked at Orange Telecommunications Company.
1:51
SPEAKER_0: And then later, you and me, we worked together at Uber.
1:55
SPEAKER_0: You were already an Android engineer, a senior Android engineer when I joined Uber.
2:02
SPEAKER_0: We worked together.
2:03
SPEAKER_0: I was also a software engineer.
2:05
SPEAKER_0: Later, for a short while, I became your manager in a twist of events.
2:09
SPEAKER_0: Now you've joined Linear two years ago when there were 10 engineers at the company as a first engineering manager.
2:17
SPEAKER_0: And you're still the first engineering manager, as I understand, at Linear?
2:20
SPEAKER_1: Yeah, we have two engineering managers now.
2:23
SPEAKER_0: Oh, you have two engineering managers.
2:24
SPEAKER_0: Awesome.
2:24
SPEAKER_0: But you're still the first one.
2:26
SPEAKER_1: Yes.
2:27
SPEAKER_0: You told me something really interesting before we sat down here, which was about emails.
2:33
SPEAKER_0: At Uber, both of us were managers, and I remember getting like 50 or 100 emails per day and writing a bunch of them obviously.
2:41
SPEAKER_0: How many emails have you sent the past three months at Linear?
2:47
SPEAKER_1: I don't know.
2:47
SPEAKER_1: I think I want to say 20, 30 or something like that, maybe less.
2:52
SPEAKER_0: Yeah, but you told me you use email very little at Linear.
2:57
SPEAKER_1: Yeah, we basically don't use it at all for the work that we do, so we don't use email at all internally.
3:03
SPEAKER_1: If I have to send emails, I think I've sent two, three emails to you, so those count towards the 30.
3:10
SPEAKER_1: We generally use email when we want to talk to some of our customers, and some of the tools that we use may require out to support, then we may write an email, but not for internal work.
3:20
SPEAKER_0: So what do you instead?
3:22
SPEAKER_1: Well, pretty much, we use Slack and Linear.
3:26
SPEAKER_0: Slack and Linear.
3:28
SPEAKER_0: The interesting thing is, I understand Slack, for the real-time communication, you need to ping someone.
3:32
SPEAKER_0: But my understanding of email was, maybe it is a bit of an outdated understanding, but it's great for async stuff when you don't want people to respond immediately.
3:41
SPEAKER_0: What about those type of requests?
3:44
SPEAKER_1: I think in Linear we tend to ask people for help when we really need the help.
3:52
SPEAKER_1: So a lot of the things, if I would write to people, that we answer quite fast.
3:58
SPEAKER_1: Yeah, I mean there can be things that need to be followed up, but then we have Linear for that as well.
4:05
SPEAKER_0: So are you using Linear for more the kind of long-term of storage of stuff that needs to be structured or searchable?
4:14
SPEAKER_1: Yeah, absolutely.
4:15
SPEAKER_1: So for example, if you have a question on a project that you're building, you may decide that question is urgent, in which case you ask it, you can ask it in a group chat, and people will answer really, really fast.
4:26
SPEAKER_1: Or you can ask a certain person directly.
4:30
SPEAKER_1: Or you may be like, maybe I'll just spend a little bit more time and figure it out myself.
4:33
SPEAKER_1: So I think that that's a good thing about not having email.
4:36
SPEAKER_1: You can't just send an email, because it's easier that way.
4:41
SPEAKER_1: Or you can go in Linear and you can ask a question on the project directly.
4:47
SPEAKER_1: You can leave a comment or you can post a project update, and there can be questions associated to that.
4:54
SPEAKER_0: Okay.
4:55
SPEAKER_0: So this is just a really drastic change, and I think a lot of people, software engineers, listening are pretty envious because I can't really think of many people who don't have email as their day-to-day.
5:07
SPEAKER_0: When you joined Linear, how big of a shock was this?
5:11
SPEAKER_0: Or was it even a shock?
5:12
SPEAKER_0: Again, you were a manager, right?
5:14
SPEAKER_0: Your day started with emails.
5:16
SPEAKER_0: My day started with emails.
5:19
SPEAKER_1: Yeah.
5:19
SPEAKER_1: I remember sending the first email in Linear.
5:22
SPEAKER_1: I think it was, I don't know, I saw something interesting, and I wanted think the marketing team to see it.
5:32
SPEAKER_1: And I had to write on Slack that I send them an email.
5:40
SPEAKER_0: This episode was brought to you by LaunchDarkly.
5:43
SPEAKER_0: When releasing software, bad sheep happens.
5:45
SPEAKER_0: Bugs are inevitable, but they don't need to become disasters.
5:49
SPEAKER_0: LaunchDarkly reduces the risk of releasing software, giving developers the confidence to shift faster through progressive releases, proactive monitoring, targeting and rollbacks.
5:59
SPEAKER_0: With LaunchDarkly, you can find and fix bugs automatically.
6:03
SPEAKER_0: Do you know how risky your software releases are?
6:06
SPEAKER_0: Take LaunchDarkly's two-minute risk assessment to find out.
6:09
SPEAKER_0: Go to launchdarkly.com/risk-meter.
6:13
SPEAKER_0: That's launchdarkly.com/risk-meter.
6:18
SPEAKER_0: This episode is brought to you by Sevalla.
6:20
SPEAKER_0: It's a true Heroku alternative where you can deploy applications, manage databases, and host static sites for free.
6:26
SPEAKER_0: Sevalla is a platform designed for teams.
6:29
SPEAKER_0: With its preview and pipeline features, developers can collaborate on any stack while being assured of the security of the workloads from staging to production.
6:37
SPEAKER_0: Sevalla holds all the major security certifications companies are typically looking for.
6:42
SPEAKER_0: Their application hosting offers automatic Git integration, Docker image deployments, hibernation for optimal cost savings, vertical and horizontal auto-scaling, TCP proxy support, and optional private network connections for your databases.
6:56
SPEAKER_0: Their free static site hosting is perfect for landing pages, documentation sites and more.
7:01
SPEAKER_0: It also includes preview deployments for easier iterations and seamless teamwork.
7:05
SPEAKER_0: Sevalla features an easy-to-use interface, unlimited seats, no hidden and tricks, and transparent user-based pricing with enterprise-level clouds for DDoS protection for workloads of any size.
7:15
SPEAKER_0: Sign up and deploy today.
7:17
SPEAKER_0: Go to sevalla.com.
7:19
SPEAKER_0: That is Sevalla with a double L, .com.
7:23
SPEAKER_0: Let's set a little context on Linear, because I think we all know that it's a tool that you can get things done, get projects done, track statuses.
7:32
SPEAKER_0: But talking specifically about the company itself, help imagine us what this place is like.
7:39
SPEAKER_0: How many people work there, for example?
7:40
SPEAKER_1: Of course, I actually checked before the podcast to make sure I'm right.
7:44
SPEAKER_1: We are over 60 people now, over 60 people.
7:47
SPEAKER_0: Okay.
7:47
SPEAKER_0: And four or five years old, the company founded, ish?
7:51
SPEAKER_1: Yeah.
7:52
SPEAKER_1: Yeah.
7:52
SPEAKER_1: I don't remember, I think five, six years old.
7:56
SPEAKER_0: Yeah.
7:57
SPEAKER_0: So 60 people.
7:58
SPEAKER_0: What kind of technologies do you use inside the company?
8:03
SPEAKER_1: Yeah.
8:03
SPEAKER_1: So in terms of engineering, we use TypeScript, React, Node, GCP, PostgreSQL, GraphQL, that tech stack.
8:13
SPEAKER_0: For a long time, you had no product managers at the company.
8:16
SPEAKER_1: Yeah.
8:17
SPEAKER_0: Do you have product managers now?
8:18
SPEAKER_1: We do.
8:18
SPEAKER_1: We do.
8:19
SPEAKER_1: We have two product managers now.
8:22
SPEAKER_0: Awesome. So two engineer managers, two product managers.
8:23
SPEAKER_1: Yes, and 25 engineers.
8:27
SPEAKER_1: The product team, including design and product, is about almost 40 people.
8:32
SPEAKER_0: But when you joined, there were no product managers, right?
8:34
SPEAKER_1: No, no.
8:35
SPEAKER_0: So how did this time work?
8:36
SPEAKER_0: Because again, coming from a more I guess traditional tech setup, you're kind of used to like, "Okay, we have an engineering team.
8:43
SPEAKER_0: We have a product manager.
8:44
SPEAKER_0: We have an engineering manager," and you didn't have that.
8:47
SPEAKER_0: How did the engineering team operate?
8:49
SPEAKER_0: Or who filled the product role of what should we build, why should we build it?
8:55
SPEAKER_1: I think everybody did.
8:57
SPEAKER_1: Everybody did.
8:58
SPEAKER_1: So Linear started off as building an issue tracker for startups.
9:04
SPEAKER_1: That was the goal initially.
9:06
SPEAKER_1: The vision of the company was always bigger, and we are now kind of achieving more and more of that vision.
9:14
SPEAKER_1: But the founders wanted to start with a very simple concept and with some principles around quality, around the way you should build the product, and test it out and see if it works.
9:25
SPEAKER_1: So for being ourselves, a small company, using the product every day, being close to customers, that was actually a big benefit in Linear that we could be close to customers ever since the beginning.
9:37
SPEAKER_1: And then intuition helped a lot.
9:42
SPEAKER_0: When you say close to customers, what does that mean?
9:44
SPEAKER_0: You ping people using it?
9:46
SPEAKER_0: Or are they ping you on a Slack channel or on a Linear or somewhere?
9:50
SPEAKER_1: Yes, absolutely.
9:51
SPEAKER_1: So I think from the engineering perspective, the most contact they have with customers is through Slack channels, support Slack channels.
10:02
SPEAKER_1: We also have what we call a goalie rotation.
10:06
SPEAKER_1: It's a triage feature in Linear.
10:08
SPEAKER_1: So basically, we have-
10:09
SPEAKER_0: So a goalie as in the goalie, keeping the goalkeeper.
10:12
SPEAKER_1: Yeah.
10:12
SPEAKER_1: Yeah, exactly.
10:13
SPEAKER_0: Okay, tell me about that.
10:14
SPEAKER_1: Yeah.
10:14
SPEAKER_1: So we have now two engineers on that rotation every week.
10:18
SPEAKER_1: It's different engineers.
10:20
SPEAKER_1: Basically, the goal of the goalie is to address all incoming reports from customers, maybe bugs, maybe some small quality things that don't make sense.
10:33
SPEAKER_1: So the first goal for the goalie is to go through all of those requests and see if they can reproduce them.
10:40
SPEAKER_1: And if they have time, then they will actually fix those issues as well during the week or assign them to the right person.
10:48
SPEAKER_1: But as they do this, they are also active on all the support channels.
10:52
SPEAKER_1: So for example, we had cases, one that I really loved seeing, it was at the beginning when I joined Linear.
10:57
SPEAKER_1: The first time I saw this, I was like, "Wow."
10:59
SPEAKER_1: A customer wrote about a bug in the product, and the engineer was like, "Oh, I'm looking at it."
11:05
SPEAKER_1: And then maybe an hour, two hours later, it was like, "Okay, it's fixed and deployed."
11:09
SPEAKER_0: Wow.
11:09
SPEAKER_0: Yeah.
11:11
SPEAKER_1: I'm like, "Wow, I haven't seen that before."
11:14
SPEAKER_0: I feel like this is the stuff where you hear it at startups, and I remember when we were at Uber, we had something similar, right?
11:22
SPEAKER_0: We called it a support engineer.
11:24
SPEAKER_1: Yes.
11:26
SPEAKER_0: I think what some teams did, at least my team did it, and at some point we worked together as well as, out of about 10 engineers, one person was a support engineer, but in our case it was very different because it was... Well, similar but also very different, customer support teams would open tickets and also employees would report tickets.
11:45
SPEAKER_0: But there were thousands across the company, and there would be people filtering these, and often product managers would have to filter down.
11:54
SPEAKER_0: We would get the ticket, and it would be on the support engineer's desk.
11:58
SPEAKER_0: But the frustrating part there was, as a support engineer, you kind of go through, you see if you can reproduce it, and I think 80% of the time, yeah, we could reproduce it, but we couldn't fix it because it was, we were on the payments team and it looked like a payments, but actually it was a fraud bug.
12:15
SPEAKER_0: And the fraud team was a very different team.
12:16
SPEAKER_0: So we created a ticket, and we escalated it, or we put it in their support group, and it just went away.
12:22
SPEAKER_0: You went off your support rotation, and things just didn't really get fixed.
12:27
SPEAKER_0: So you were in that, you saw this.
12:31
SPEAKER_0: But how did you make this work?
12:33
SPEAKER_0: Or how does this work differently?
12:34
SPEAKER_0: It sounds like it's way more efficient, right?
12:36
SPEAKER_1: Yeah.
12:36
SPEAKER_1: Yeah.
12:37
SPEAKER_0: Is it just because you're smaller or more nimble?
12:40
SPEAKER_1: I mean, being smaller is generally takes a lot of complexities away from being 10,000, 20,000 people company.
12:51
SPEAKER_1: But how does this work?
12:52
SPEAKER_1: So I think there are a few things here that make it different from Uber.
12:55
SPEAKER_1: For example, the first one is that the engineers are close to the customers.
12:59
SPEAKER_1: This is not an abstract bug that came from someone and that was probably triaged multiple times before and now you kind of have to do it.
13:09
SPEAKER_1: It is something that you are there frontline with our customer support team, being in contact with that customer.
13:16
SPEAKER_1: So you definitely feel more connected and you feel more the value of your work.
13:20
SPEAKER_1: So that is one.
13:21
SPEAKER_1: The second one is that even if you don't have time to fix it, you will assign it to someone in the team, in the Linear team, either the US side or the EU side, that you think has the more information or they can do it fairly efficiently, they can fix it fairly efficiently.
13:37
SPEAKER_1: And here's where the second part comes in: So on top of the goalie rotation, we have a zero bug policy.
13:43
SPEAKER_0: Oh, interesting.
13:44
SPEAKER_1: Yeah.
13:45
SPEAKER_0: Very ambitious.
13:46
SPEAKER_1: Yes.
13:47
SPEAKER_1: I mean I can show you how many bugs we have opened right now.
13:50
SPEAKER_1: So basically, the idea is-
13:53
SPEAKER_0: Okay, so is it more than 10 or less than 10?
13:55
SPEAKER_1: So the official SLA is a week to fix it, and just that's because some people can take some days off and stuff like this, but actually the unofficial one, which is the one that we run by, is a day.
14:08
SPEAKER_1: So basically what happens... Yeah.
14:09
SPEAKER_0: Wow.
14:10
SPEAKER_1: Yeah.
14:10
SPEAKER_1: So what happens is that every morning, come to work, instead of doing email, you fix all the issues that you have.
14:18
SPEAKER_1: And then you have time for the product work.
14:21
SPEAKER_0: I mean, I like how this sounds, it sounds very utopian, but you're actually telling me that it works.
14:29
SPEAKER_1: Yeah, I mean it started from... It can work.
14:32
SPEAKER_1: It's always harder when you start.
14:33
SPEAKER_1: We had hundreds of issues when you started, so we literally had to take time off from product work and just fix those issues.
14:41
SPEAKER_1: But I think the principle behind it is, when you're building a new product, you're building something that the customer hasn't seen yet.
14:53
SPEAKER_1: Prioritizing that over something that the customer uses and doesn't work doesn't make much sense, does it?
14:59
SPEAKER_0: Mm-hmm.
15:00
SPEAKER_1: It's not a zero-sum game either.
15:02
SPEAKER_1: Well, you can say, yeah, it takes the same amount of time, yes, but the customer is much happier if the bug is fixed sooner.
15:09
SPEAKER_1: Also, a lot of things in Linear are based on best judgment of people.
15:14
SPEAKER_1: You can look at the bug and say, "Look, it was reported by one customer.
15:18
SPEAKER_1: I can't straight up reproduce it.
15:19
SPEAKER_1: There was no contact with that customer, maybe for a while.
15:23
SPEAKER_1: I'm just not going to fix it.
15:25
SPEAKER_1: It's fine."
15:28
SPEAKER_0: Yeah, yeah. You can use judgment.
15:28
SPEAKER_1: So rather than saying I put it in the backlog, you just go, one do.
15:29
SPEAKER_1: Well, we have a status, one do.
15:31
SPEAKER_1: That's what it is for.
15:32
SPEAKER_1: Right?
15:32
SPEAKER_1: So we do that as well.
15:35
SPEAKER_1: We do reviews every week of the SLAs for the bugs.
15:39
SPEAKER_1: Our goal is that every person has maximum two issues roughly, because that's normal right there, the ongoing ones.
15:46
SPEAKER_1: We've been running this for months now, and it's still working.
15:49
SPEAKER_1: I was surprised.
15:50
SPEAKER_1: I thought that this is very ambitious at the beginning, and I thought it will distract the team a lot.
15:55
SPEAKER_1: But actually once you go through the bulk of the issues, of course I looked at the data before and I was like, "Well, this looks like two and a half issues per week per person," once you average it out.
16:04
SPEAKER_1: If it was 10, then stop work and figure out why you have so many bugs.
16:09
SPEAKER_1: But it was a good number to start with.
16:10
SPEAKER_1: Yeah, it's still working.
16:14
SPEAKER_1: I'm really happy with it.
16:16
SPEAKER_0: Just to play devil's advocate, I remember, again, comparing with Uber, at Uber, it felt to me that there was a reason that we did not spend most of our time fixing bugs, even though we knew we had a massive bug list/feature request list, but a lot of it was bugs, and we did try to fix the most important ones.
16:35
SPEAKER_0: But the thinking there was that there was more value for us to launch a new feature, which we measured the impact of it.
16:42
SPEAKER_0: And like you and me, we launched features that brought in tens of millions of incremental dollars in revenue, and it took months sometimes to build, but we were balancing and said, "Well, look, we would throttle ourself if we didn't grow."
16:56
SPEAKER_0: Growth was very important.
16:57
SPEAKER_0: So my question here is, do you think that focusing on bugs would slow down this type of building new features?
17:07
SPEAKER_0: Or in practice, it doesn't have to be a choice of this, of growth or quality?
17:15
SPEAKER_1: I think theoretically it does slow down.
17:17
SPEAKER_1: And if you objectively think if we wouldn't fix any bug, then we will beat more products.
17:21
SPEAKER_1: But I think in reality, we don't feel it as much.
17:24
SPEAKER_1: And we also... It's really fundamental through a lot of decisions that Linear made throughout the years, focusing on growth and looking at the finance was not more important than building a quality product.
17:47
SPEAKER_1: Try for yourself, think of Linear but without the quality.
17:51
SPEAKER_1: Are we going to do who has more features competition with other companies?
17:57
SPEAKER_1: We don't think that that's the right way to approach it.
18:00
SPEAKER_0: This is an interesting one, because I wonder if this thinking is a lot more valid because just to be fair, Linear, by the time Linear launched issue tracker, we had a lot of issue trackers.
18:10
SPEAKER_0: Right?
18:10
SPEAKER_0: There's some well-known ones, there's some lesser known ones.
18:12
SPEAKER_0: There's at least three or four publicly traded companies doing this.
18:16
SPEAKER_0: So I wonder if, as a more general takeaway, we could say that when you're entering out a crowded market, if you don't do quality, you might as well just give up because again, out competing on features is a really hard ask or you need to raise a lot of money.
18:32
SPEAKER_0: And I think we saw some companies do that, but it's just a very different strategy.
18:37
SPEAKER_0: But personally, as an engineer, I really like to hear this.
18:39
SPEAKER_0: It's refreshing to hear that quality is actually important, and there's time for it.
18:44
SPEAKER_0: There's time allocated for it.
18:45
SPEAKER_1: Yeah, yeah.
18:46
SPEAKER_0: So your hiring process, you run quite differently than some other companies do, just from what I've gathered so far.
18:56
SPEAKER_0: But you also have a famously different hiring process where you focus on, you have this thing called the trial week.
19:03
SPEAKER_1: Yeah.
19:04
SPEAKER_0: Can you tell me a bit more about how your hiring process works and what type of people you look for to hire as software engineers?
19:10
SPEAKER_1: Of course.
19:11
SPEAKER_1: So I think that the hiring process starts off pretty typical to tech companies.
19:15
SPEAKER_1: So we have a recruiter phone screen, we have a hiring manager call.
19:20
SPEAKER_0: With you?
19:21
SPEAKER_1: With me, or Tom in the US.
19:24
SPEAKER_1: And if that goes well, we have two technical exercises.
19:30
SPEAKER_1: One is coding, one is architecture.
19:32
SPEAKER_1: It's really nothing abstract algorithms.
19:35
SPEAKER_1: I really love that.
19:36
SPEAKER_1: We actually took a part of the Linear code and really simplified it, so it can be a standalone exercise that you can finish within an hour.
19:45
SPEAKER_1: So if you ask yourself, it's like, "Oh, am I going to be given this type of exercise that I never have to do in real life?"
19:51
SPEAKER_1: It's not the case.
19:52
SPEAKER_1: Somebody had to do it in Linear before.
19:56
SPEAKER_1: If all of that goes well, indeed we move to the work trial.
19:59
SPEAKER_1: So the work trial, it depends on the role you have in Linear.
20:01
SPEAKER_1: So if you are on engineering, the work trial will be a week.
20:05
SPEAKER_1: But for other roles, it can be from a few days to a week.
20:09
SPEAKER_1: As part of the work trial, it's basically the candidate gets to work with the team for a week as if they would've been employed.
20:18
SPEAKER_0: For full remote, right?
20:18
SPEAKER_0: Because-
20:19
SPEAKER_1: For remote, yeah, exactly, for remote.
20:23
SPEAKER_1: It's getting harder and harder, but we try to find greenfield projects for everyone.
20:27
SPEAKER_0: Oh, even for the work trial?
20:29
SPEAKER_1: Yes, even for the work trials.
20:30
SPEAKER_1: Actually, we have a meeting before and we have a bunch of ideas, but it's an interesting thing because you want to balance out, of course, seeing how the candidate does, but you also want it to be something interesting, something that they can work autonomously.
20:48
SPEAKER_1: But we managed to find good projects, and I think the best ones are the ones that they build.
20:54
SPEAKER_1: We decide to move forward, the candidate is happy, joins the team, and we had a few cases like this when the candidate, as their first project, shipped the thing that they build in the workshop.
21:03
SPEAKER_0: Can you tell me what that feature was?
21:05
SPEAKER_1: Yes, I think it was the triage responsibility.
21:10
SPEAKER_1: I think one of our engineers-
21:14
SPEAKER_0: So when in Linear, you can assign who needs to triage this issue?
21:18
SPEAKER_1: Yeah, and you can integrate the pager duty integration into it.
21:22
SPEAKER_1: So you can kind of automatically... The goalie, in our case, the triage, is the person that you're having the pager duty rotation.
21:30
SPEAKER_0: So started working on this during the work trial, make good progress, and then join and finished.
21:35
SPEAKER_1: Yes.
21:36
SPEAKER_0: Awesome.
21:37
SPEAKER_0: I love it.
21:38
SPEAKER_0: So you're the hiring manager on the hiring manager call.
21:42
SPEAKER_0: Just putting you on the spot here, what does a typical hiring manager call look like?
21:46
SPEAKER_0: Someone passes a recruiter screen, they're now talking with you, Sabin, what do you usually talk about?
21:54
SPEAKER_1: Right.
21:54
SPEAKER_1: So first of all, when the recruiter has the phone screen, then I have a discussion.
22:00
SPEAKER_1: It can be asynchronous or in person, depending on the candidate, with the recruiter.
22:05
SPEAKER_1: And we try to make an initial evaluation whether we move forward to the hiring manager interview.
22:09
SPEAKER_1: Of course, if the recruiter is super solid, I'm confident, then there's no need for a discussion, just move forward.
22:17
SPEAKER_0: Yeah.
22:17
SPEAKER_1: Part of the hiring manager, I have been redoing a little bit the storyline, if you want, of the hiring manager interview.
22:24
SPEAKER_1: I think of what I landed on now is focusing on three things.
22:28
SPEAKER_1: I focus on the motivations of the candidate, the things that they like doing, what they're excited about.
22:34
SPEAKER_1: It's important because, if anything, we are very opinionated in Linear, and it's important that the type of motivations aligned.
22:43
SPEAKER_1: And then the next thing that I would evaluate is product.
22:48
SPEAKER_1: I spent quite a bit of time on talking about product with engineers.
22:52
SPEAKER_1: And finally, just going through their experience tech wise, talking about some of the challenges, things they build, and so on.
23:00
SPEAKER_0: One thing that, again, I don't think is too typical is how much you spend on product and how much you're hiring for engineers that can build product or interested in product, have a product sense or our product minded.
23:12
SPEAKER_1: Yeah, absolutely.
23:14
SPEAKER_0: How does this change both the hiring and the day-to-day work?
23:18
SPEAKER_0: Because now, it sounds like Linear is a team of, you said 25 engineers, but really it's 25 engineers who are all really open and willing and wanting to do product work as well, right?
23:28
SPEAKER_1: Yeah, absolutely.
23:29
SPEAKER_1: So it definitely makes hiring not easy.
23:39
SPEAKER_1: People say that we have a high bar in Linear, and that's true, but I think what makes it really difficult is a very specific bar.
23:47
SPEAKER_1: And I think the product side of it makes it so specific.
23:50
SPEAKER_1: We want people that, as you said, have a good judgment on product, have a good taste in product, and more importantly, we want people that, or not more importantly, but as importantly, we want people that also have experience and showed that they can build a great product.
24:08
SPEAKER_0: Yeah.
24:09
SPEAKER_0: And to add all of this, you all work full remote, right?
24:12
SPEAKER_0: The whole 60 people, everyone is full remote.
24:15
SPEAKER_0: How is that working?
24:16
SPEAKER_0: What is good about it?
24:17
SPEAKER_0: And what is more challenging?
24:19
SPEAKER_0: Especially that at Uber, both you and me, we initially worked in office and then we did some forced remote for remote.
24:26
SPEAKER_0: But again, at the end of Uber, you were also back in the office.
24:30
SPEAKER_0: So again, for you it was a big change as well.
24:32
SPEAKER_1: Yeah, yeah, absolutely.
24:33
SPEAKER_1: Well it works great for us and it works great for me personally as well.
24:38
SPEAKER_1: I absolutely love it.
24:41
SPEAKER_1: I think there's quite a few fears about working remotely, and I think that a lot of them may be counterintuitive, but it's not the case.
24:50
SPEAKER_1: When I remember when we were in Uber and we started moving towards remote work, the amount of diffs that people were putting out just went up to the point where we had discussions at the moment.
25:01
SPEAKER_1: They were like, "Oh wow, people are kind of working too much."
25:03
SPEAKER_1: So we were afraid of them getting burned out.
25:05
SPEAKER_1: Yeah.
25:06
SPEAKER_0: I remember there was this all hands right after COVID or few months after we went in full lockdown, and that's on the all hands, because both of us were there.
25:15
SPEAKER_0: They showed this stat.
25:16
SPEAKER_0: Turns out that there was this internal tool that the office of the CTO or senior directors on the above could see the number of pull requests, or as we call them, diffs.
25:24
SPEAKER_0: And there was this massive spike.
25:26
SPEAKER_0: And I think I had two reactions.
25:29
SPEAKER_0: One was like, "Oh wow, that's really cool."
25:30
SPEAKER_0: Second level, "What?
25:31
SPEAKER_0: They're tracking our pull requests all this time?"
25:37
SPEAKER_1: Yeah.
25:37
SPEAKER_1: I remember that.
25:38
SPEAKER_1: Yeah, I mean, so let's split it in what's good and what's more challenging.
25:41
SPEAKER_1: So I think the first thing of what's good about it is focus.
25:46
SPEAKER_1: It's really focused.
25:47
SPEAKER_1: We don't do over time, or very, very rarely, but whenever people are there, they're truly there.
25:54
SPEAKER_1: You can see that by sending a message and you see how many replies you get immediately.
25:59
SPEAKER_1: So very, very focused.
26:01
SPEAKER_1: Then also, autonomy is kind of building.
26:05
SPEAKER_1: People that work remotely tend to be more autonomous and also manage to unblock themselves and so on.
26:14
SPEAKER_1: I think it's like, how do I say it, I think it's less talking and more doing.
26:20
SPEAKER_1: So nothing beats making a proof of concept that it's actually working to show your product idea.
26:31
SPEAKER_1: So you will see there is a lot of demos, there's a lot of trying design engineering.
26:36
SPEAKER_1: It's a lot of showing rather than theorizing about it, because if you start theorizing in Zoom meetings one after the other, you lose track quite fast.
26:45
SPEAKER_0: Mm-hmm.
26:46
SPEAKER_1: In terms of the challenges, I would say, so the thing about Linear, we fix issues when they come.
26:51
SPEAKER_1: So there's nothing burning right now because we fixed a lot of them.
26:55
SPEAKER_1: But what I did notice is that it's more challenging to create this sense of belonging to a team when you don't see them face-to-face, knowing what people work on.
27:06
SPEAKER_1: Yeah, I mean also, being face-to-face, it is just you build that connection easier.
27:16
SPEAKER_1: But what we do is we have a weekly meeting, we focus it on just demoing stuff.
27:21
SPEAKER_1: Even if you don't have anything to demo it, demo it anyway, demo what you're thinking about building, so as much showing as possible so people get this sense of-
27:29
SPEAKER_0: So even like work-in-progress things.
27:30
SPEAKER_1: Even work-in-progress things, even a design, even I don't have anything but I'm thinking of this.
27:35
SPEAKER_1: "It'll look like that, you click there."
27:37
SPEAKER_1: It doesn't matter.
27:38
SPEAKER_1: It's very important to share things.
27:39
SPEAKER_1: And then we also meet, we have two, three offsides per year.
27:42
SPEAKER_1: And we have this, if you work with somebody on a project and go like, "I feel like working together with a person," just grab a flight, go to the city, stay two, three days, work together, come back.
27:51
SPEAKER_1: So we have a lot of stuff.
27:54
SPEAKER_0: So it sounds like it's a healthy mix of people working focus.
27:57
SPEAKER_0: When they're there, everyone is turned on and you can count on.
28:00
SPEAKER_0: Everyone on the Slack is available unless they're away for lunch or whatever.
28:07
SPEAKER_0: And then every now and then, you do get that personal connection where you actually get to have the face-to-face, get that bond, and then when you go back, there's a aura or something that radiates for a while where you have that sense of belonging or knowing this person.
28:22
SPEAKER_1: Yes, absolutely.
28:23
SPEAKER_1: I think on a personal note here, as a manager, I think it's harder for managers to manage remote teams.
28:31
SPEAKER_1: It just is.
28:33
SPEAKER_1: It's harder to build that trust, to build that connection, to get a pulse of how the people is feeling, what troubles them, what motivates them.
28:42
SPEAKER_1: But ultimately, my job as a manager is not to make my life easier.
28:48
SPEAKER_1: So I'd really wish that more managers would be more open to working remotely because it does make people's lives better.
28:58
SPEAKER_1: Your team, they can focus, they don't have to spend so much time traveling.
29:02
SPEAKER_1: It allows flexibility.
29:04
SPEAKER_0: Okay, so let me ask you a bit of a pointed question, but talking to other managers or even interviewing potentially other managers, there is this narrative that engineers will say, "Oh, return to office is happening because managers like to work in person, or directors, or they're just used to it."
29:25
SPEAKER_0: How much truth do we think there is in that?
29:29
SPEAKER_0: Because you just said that it is a lot harder as a manager, and it's very uncomfortable, and you need to do it.
29:34
SPEAKER_0: Again, I'm just interested in your personal opinion or observations here.
29:39
SPEAKER_1: It's hard for me to talk about what other managers think.
29:42
SPEAKER_1: I can talk about myself.
29:44
SPEAKER_1: When we moved in Uber to being remote as a manager, it was hard.
29:51
SPEAKER_1: I was exhausted at the end of the day.
29:54
SPEAKER_1: So I could see how it'd be like, "Oh, this is harder for me."
29:59
SPEAKER_0: Was it the Zoom fatigue?
30:00
SPEAKER_0: Was it a lot more?
30:02
SPEAKER_1: A good day was eight Zoom meetings, a bad day was 16.
30:09
SPEAKER_1: It took me two hours of just being a robot after trying to get the grasp back on like, "Hey, I'm out of work now, let me just enjoy my evening."
30:21
SPEAKER_1: So I can see how that can be hard before you get used to how to manage your schedule remote.
30:30
SPEAKER_1: Yeah, so-
30:31
SPEAKER_0: It sounds like you have a lot fewer video calls as well, right?
30:34
SPEAKER_1: Yes.
30:34
SPEAKER_1: Yeah, absolutely.
30:35
SPEAKER_0: So it sounds like you figured out a way, or Linear figure out a way to make work a bit more async but also real-time, just maybe not face-to-face, video based.
30:49
SPEAKER_1: Yeah, it's funny, we even have a thing where if you want to talk to someone, just huddle them on Slack.
30:54
SPEAKER_1: You don't need to ask permission.
30:55
SPEAKER_1: You don't need to set up a meeting, just click the button, huddle.
30:59
SPEAKER_1: And if the person can answer, great.
31:01
SPEAKER_1: If they don't, there's absolutely no judgment.
31:04
SPEAKER_1: It's like going to somebody's desk and not being there.
31:06
SPEAKER_1: It's fine.
31:07
SPEAKER_0: I feel that would be a lot easier because again, this is just putting the manager's hat on, but I also remember, when I looked at my calendar sometimes in the morning, I was just stressed out by how many meetings I had.
31:17
SPEAKER_0: A lot of them were just scheduled one-on-ones, which is like, "Oh, this is our once a time a week that we will definitely talk."
31:23
SPEAKER_0: So yeah, one of the best ways to figure to understand how you get things done is, let's talk about a specific project that you've recently built.
31:30
SPEAKER_0: What is something that you've shipped?
31:33
SPEAKER_0: And we could talk about how you built it.
31:36
SPEAKER_1: Of course.
31:37
SPEAKER_1: I think one that comes to mind, and I enjoyed being there while we build it, is redoing the project page.
31:48
SPEAKER_1: So we wanted to have everything that you need to ship a project, not only as an engineer, but also as a PM.
31:53
SPEAKER_0: Can you help me to understand how you built it step by step, especially as a software engineer taking part of the project?
32:00
SPEAKER_0: Because a lot of other companies, the way this would work is, product managers decide they're going to build a feature, they work with design, they come back with a design, they show it to engineering, saying, "Here's what we're going to build.
32:11
SPEAKER_0: We already had it signed off from customers.
32:14
SPEAKER_0: Or it looks good."
32:15
SPEAKER_0: And then engineers do maybe an engineering plan and then build it and ship it.
32:19
SPEAKER_0: How did it work in your case?
32:21
SPEAKER_1: Yeah.
32:21
SPEAKER_1: So we decided as a company that the next thing we are going to focus on is features around planning.
32:28
SPEAKER_1: And this project was one of the core features of that.
32:31
SPEAKER_1: But at that point, it had a name.
32:33
SPEAKER_1: I think it's called project descriptions, even a misleading name.
32:37
SPEAKER_1: We knew we wanted to do something different with the project page.
32:41
SPEAKER_1: So we started from that.
32:42
SPEAKER_1: We said okay.
32:44
SPEAKER_1: On the product side, we talked to customers, trying to get a sense of what are their flows.
32:50
SPEAKER_1: It's always good to look at how customers use the product and figure out the problems that they have rather than the solutions that they asked for.
32:58
SPEAKER_1: So we build that understanding and then we go like, "Okay, we're building this."
33:02
SPEAKER_1: So we got a team together.
33:04
SPEAKER_1: Teams in Linear are quite fluent.
33:05
SPEAKER_1: We create them for a project and then we dissolve them and so on.
33:08
SPEAKER_1: So we created a team.
33:09
SPEAKER_1: I think-
33:10
SPEAKER_0: How big of a team was it?
33:11
SPEAKER_1: So the team was two engineers and then we had a product.
33:16
SPEAKER_1: We had none on the product front.
33:18
SPEAKER_1: And then we had one designer and a customer support person.
33:24
SPEAKER_0: Awesome.
33:24
SPEAKER_0: Customer support also on the project team.
33:27
SPEAKER_1: Yeah.
33:27
SPEAKER_1: I mean, they know best what our customers are asking for and what kind of issues they're running into, what things they want to do and they can't.
33:35
SPEAKER_0: I love it, because I do remember at Uber we did have, every now and then on some projects, an ops person, we call it ops, they also interface with customer support, but it was very rare.
33:45
SPEAKER_0: Is it common to have these folks on projects?
33:48
SPEAKER_1: Most of the projects that are larger in scope have a person from customer support team.
33:55
SPEAKER_0: Awesome.
33:55
SPEAKER_0: So you had the project team.
33:56
SPEAKER_0: And then what did you do or how did engineers get involved in the beginning of this project?
34:01
SPEAKER_1: So we basically had a kickoff with the team.
34:05
SPEAKER_1: Product came in with what is the goal, what we want to achieve.
34:09
SPEAKER_1: Showed us some interviews that we had with customers and kind of just drew out what would be a possible solution for that, but very, very high level.
34:24
SPEAKER_1: And then as engineers are talking to customers often, and then we are using the product as well and we're building bigger and bigger projects, so there was a lot of input from engineering, from design.
34:36
SPEAKER_1: It was just an open discussion of what we could be building rather than "This is what you're building," and now technically scope it.
34:45
SPEAKER_1: And then if I remember correctly, the discussion didn't really end with a conclusion.
34:51
SPEAKER_1: It was like, "Okay.
34:52
SPEAKER_1: Feels like we need to think about it.
34:54
SPEAKER_1: Let's just meet in whatever, three days, whatever feels right."
34:57
SPEAKER_1: So then we meet again, and now on the product, a bit more thinking went into it based on the questions that were in that meeting.
35:04
SPEAKER_1: On the design front, I remember design and engineering kind of started hacking on some designs together and doing a proof of concept.
35:12
SPEAKER_1: And then we showed it.
35:13
SPEAKER_1: What I was saying before, nothing beats showing our thing.
35:15
SPEAKER_0: Showing.
35:16
SPEAKER_1: Right.
35:17
SPEAKER_1: And then again, we discussed it, it was like, "Okay, this didn't feel right and that didn't feel right."
35:21
SPEAKER_1: It was like, "Okay, cool.
35:22
SPEAKER_1: Again.
35:22
SPEAKER_1: Again."
35:23
SPEAKER_1: Actually, this was a quite complex project, especially because of the UX.
35:27
SPEAKER_1: You have this thing where you have to introduce a new persona, which is the product manager within a project, but you want to keep the flows that engineers are used to as streamlined as before.
35:38
SPEAKER_1: So actually I don't remember, but we have multiple, probably two, three iterations of the design to make it feel right.
35:46
SPEAKER_1: We keep on doing these meetings that at the point feel like we're doing a lot of things, we're not really moving forward.
35:52
SPEAKER_1: But then at the point, it just kind of clicks.
35:55
SPEAKER_1: I've seen this in a lot of complex projects.
35:57
SPEAKER_1: You do iteration, iteration at the moment.
35:59
SPEAKER_1: Oh my god, this feels good.
36:00
SPEAKER_1: And everybody in the team just gets it.
36:02
SPEAKER_1: This feels right.
36:04
SPEAKER_0: So just to understand, because again, this doesn't feel all too typical.
36:08
SPEAKER_0: You get together in a room, engineers, customer support, product.
36:12
SPEAKER_0: You talk about people show what they're thinking, and then you don't really reach a conclusion, but you've made some progress.
36:18
SPEAKER_0: And then people go away and then they build some stuff.
36:21
SPEAKER_0: So engineers will build some prototypes, product will do mock-ups, or other, they'll do some structured thinking.
36:30
SPEAKER_0: And then you come back and you have more structured things, and you have more interaction in that discussion.
36:37
SPEAKER_0: Am I visioning it right?
36:40
SPEAKER_1: Yeah.
36:40
SPEAKER_1: It's pretty much talk, do, show, talk again.
36:45
SPEAKER_1: It's just doing this iteration while things actually get built.
36:49
SPEAKER_0: Yeah.
36:50
SPEAKER_1: Right?
36:50
SPEAKER_1: But sometimes there is a fairly big shift in the way we approach the product.
36:56
SPEAKER_0: Yeah.
36:56
SPEAKER_0: But this feels very different from what we did at Uber, for example, because we had a very strict process.
37:01
SPEAKER_0: We had a product requirements document, the PRD, where product managers worked on it, sometimes they involved engineering.
37:07
SPEAKER_0: But in the end, it was a specification, here's what we're going to build.
37:10
SPEAKER_0: And it had the designs.
37:11
SPEAKER_0: And then engineering went, and we iterated on, we did engineering planning.
37:16
SPEAKER_0: But compared to what you said, it was very stiff.
37:20
SPEAKER_1: Yeah, yeah.
37:22
SPEAKER_0: Having done both of this, how do you feel these two approaches compare?
37:28
SPEAKER_1: I mean, I think... Well, it's different, right?
37:33
SPEAKER_1: Because in Uber, it's such a big company, we're talking over two factors of magnitude bigger than Linear.
37:41
SPEAKER_1: Right?
37:42
SPEAKER_0: Yeah.
37:42
SPEAKER_1: So it's very hard for any one person to keep all of Uber in mind and be able to be creative as they iterate.
37:52
SPEAKER_1: So I think this works very well for Linear right now.
37:55
SPEAKER_1: At the size that we have, we hope we can keep this for as long as possible.
37:58
SPEAKER_1: But it does... It's so interesting to see how every persona that uses Linear is represented in that chat.
38:06
SPEAKER_0: It's incredible.
38:06
SPEAKER_0: Yeah.
38:07
SPEAKER_1: It's one thing that I want as an engineering manager.
38:09
SPEAKER_1: PM wants another thing, engineers want another thing.
38:12
SPEAKER_1: And then we talk how we make a product that feels good for all of us.
38:16
SPEAKER_0: I guess it's kind of a great place to be when as an engineer, you're also a user because you're also using it, you also want your needs to be met.
38:24
SPEAKER_0: Okay, so once you came together and it felt good, at that point, engineering had some prototypes, right?
38:30
SPEAKER_1: Yeah.
38:31
SPEAKER_0: Was it some forks of your code?
38:33
SPEAKER_0: Did they fork the code and just do some changes there?
38:36
SPEAKER_0: O
38:37
SPEAKER_1: No.
38:38
SPEAKER_1: I think we... I'm trying to remember.
38:40
SPEAKER_1: In this project, what we usually do is we try something and then we review it, and then if we don't like it, we adjust it.
38:45
SPEAKER_1: It's not completely separate prototypes, we just kind of increment on each of them.
38:50
SPEAKER_1: Some of them may be quite different in between them, but ultimately there's always one code base in which we write this, and very often this is merging into master.
39:00
SPEAKER_1: This is available for internal folks, so people in the company can try it even when it's just prototype.
39:07
SPEAKER_0: So you put it behind a feature flag, for example.
39:08
SPEAKER_1: It is under a feature flag, and sometimes we decide to roll out that feature flag quite early to internal employees, or not.
39:16
SPEAKER_1: We have a developer console, and we can just easily turn it on, and we can start playing.
39:21
SPEAKER_0: So in this case, the engineers were building behind one or a couple of feature flags, and on the demos, you were showing the soft, or on a branch, I mean it's all the same thing until you merge it back.
39:31
SPEAKER_0: And then what happened at the point where like, "Okay, this feels good, everyone's happy, product is happy, engineering is happy, let's ship this"?
39:38
SPEAKER_0: Was there any additional work in terms of productization?
39:42
SPEAKER_0: I'm sure there might be some additional things, or stage rollouts.
39:46
SPEAKER_0: What happens then?
39:47
SPEAKER_1: So once it clicks, the immediate focus is like how can we de-scope this to the core of what the value proposition is?
39:55
SPEAKER_1: So before we were very exploratory and talking, now we become really, really focused.
40:00
SPEAKER_1: And then the discussions become of how we can make it even simpler.
40:04
SPEAKER_1: So we do that and then we try to get it as fast out there for people to use it.
40:10
SPEAKER_1: May it be employees, then beta customers that probably we talked to them before and we know that they would enjoy to try a feature like this.
40:21
SPEAKER_1: We found that our customers are so nice in giving us the time to try these features out and giving us feedback, and we appreciate it a lot, and that's how we are building a good product.
40:36
SPEAKER_0: So is it safe to say, if I use more common terms, that you're doing a kind of stage rollout of the feature?
40:44
SPEAKER_0: Well, it sounds like you're dogfooding it.
40:46
SPEAKER_0: You're getting it to some beta users, you're getting product feedback, and you're making changes, or I'm guessing you're fixing bugs because you have a zero bug policy.
40:54
SPEAKER_1: Yeah.
40:55
SPEAKER_1: Yeah.
40:55
SPEAKER_1: We're fixing bugs, of course, and doing changes based on the feedback that comes in.
40:59
SPEAKER_1: And then at the point when it feels good enough, we set milestones sometimes.
41:06
SPEAKER_1: What does it take to have a beta milestone?
41:09
SPEAKER_1: And then you have a general audience milestone.
41:12
SPEAKER_0: Yeah.
41:13
SPEAKER_0: Conveniently, Linear supports milestones, right?
41:15
SPEAKER_1: Yeah, yeah.
41:17
SPEAKER_0: So once you've gotten the feedback from the beta customers and you're ready to ship to all customers, how simple of a shipping is that?
41:25
SPEAKER_0: Is it just a matter of we'll release it to everyone?
41:28
SPEAKER_0: Do you have additional testing or feature flags or your quality focus?
41:32
SPEAKER_1: Yeah, I mean, most of the time we release... So we don't have any A/B testing.
41:37
SPEAKER_1: I mean there are some cases in which we do incremental rollouts to GA, but most of the time we just release it.
41:44
SPEAKER_1: So we start with beta, and then when we decide it's good enough for GA, we just release it.
41:49
SPEAKER_1: Sometimes we have a marketing campaign as we release it.
41:52
SPEAKER_1: Sometimes we release it a few weeks before the marketing campaign, so people already start using it.
41:59
SPEAKER_0: From an engineer's perspective, now that the project gets shipped, is there a wrap-up of a project?
42:03
SPEAKER_0: Or just how it was a little bit less structured, people just move on to the next one?
42:12
SPEAKER_0: Or do you say like, "All right, we're wrapping this up, and we'll do a retrospective or a celebration," or whatever that is?
42:18
SPEAKER_1: Yeah.
42:19
SPEAKER_1: So we put projects.
42:20
SPEAKER_1: Once we release them to GA, there will be feedback that comes in.
42:23
SPEAKER_1: So we do not end the project until what we consider the bulk of the feedback is addressed.
42:30
SPEAKER_1: The way we see it is like, can we leave the project untouched for a year?
42:35
SPEAKER_1: Do we feel comfortable that this will run for a year or even two depending on the project?
42:40
SPEAKER_1: If we don't feel like that's there yet, then we'll spend more time.
42:44
SPEAKER_1: And eventually, it just stands up in maintenance.
42:46
SPEAKER_1: So we have a maintenance status for the projects.
42:49
SPEAKER_1: So once issues come in there, we fix them.
42:53
SPEAKER_1: But also, projects kind of give birth to mini follow-up projects.
42:58
SPEAKER_1: So sometimes you go like, "Okay, this piece of feedback, I think this is a whole new part of the product that we need to build."
43:04
SPEAKER_1: So the follow-up to a big project like this one can be a smaller project that we plan for and ship.
43:10
SPEAKER_0: That makes sense.
43:10
SPEAKER_0: This was a big project, how long did it take this team of two engineers and sounds like three other non-engineering people to get it done?
43:20
SPEAKER_1: I'm trying to remember.
43:20
SPEAKER_1: I think, well, months, probably, I want to say four months, something like that, to get it in the hands of the customers.
43:25
SPEAKER_0: And this was one of the bigger ones?
43:25
SPEAKER_1: Yeah.
43:32
SPEAKER_0: So we talked about this specific project, but in general, you're involved in a lot of engineering projects.
43:37
SPEAKER_0: In general, how do projects run?
43:39
SPEAKER_0: How typical or atypical was this project to how features are usually built or even new products built in Linear?
43:47
SPEAKER_1: Yeah, I think it was pretty typical for a more complex project.
43:51
SPEAKER_0: So it sounds like it's very small teams, not just engineering, but working with non-engineering folks, and dare I say, not much structure.
44:01
SPEAKER_1: Yeah.
44:01
SPEAKER_0: Did I feel that correctly?
44:02
SPEAKER_1: Not much structure.
44:03
SPEAKER_1: We started off by not having structure at all.
44:05
SPEAKER_1: Now we are a little bit more diligent about the phases of the release.
44:11
SPEAKER_1: We just want to make sure that the people that should look at it before releasing it actually are looking at it.
44:17
SPEAKER_1: But again, it's a judgment call.
44:18
SPEAKER_1: It's not like you need to, this is the person and then you go to this person.
44:22
SPEAKER_1: It is just like, we ask ourselves, who should see this?
44:26
SPEAKER_1: Who feels like you know that they have a strong opinion there, for example, or you know that they may disagree with the approach?
44:33
SPEAKER_1: So you just want to bring those people in.
44:35
SPEAKER_0: This episode is brought to you by WorkOS.
44:37
SPEAKER_0: If you're building a SaaS app, at some point your customers will start asking for enterprise features like sample authentication, skin provisioning, and fine-grained authorization.
44:46
SPEAKER_0: That's where WorkOS comes in, making it fast and painless to add enterprise features to your app.
44:50
SPEAKER_0: Their APIs are easy to understand and you can ship quickly and get back to building other features.
44:56
SPEAKER_0: WorkOS also provides a free user management solution called AuthKit for up to one million monthly active users.
45:01
SPEAKER_0: It's a drop-in replacement for Auth0, income standard with useful features like domain verification, rule-based access control, bot protection, and MFA.
45:10
SPEAKER_0: It's powered by Radix components, which means zero compromises in design.
45:13
SPEAKER_0: You get limited customizations as well as modular templates designed for quick integrations.
45:18
SPEAKER_0: Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like Cursor, Vercel, and Perplexity.
45:25
SPEAKER_0: Check it out at workos.com to learn more.
45:28
SPEAKER_0: That is workos.com.
45:31
SPEAKER_0: So this lack of structure is very unusual.
45:35
SPEAKER_0: Why do you think you can get away with it at Linear?
45:39
SPEAKER_0: I'm trying to get to the difference that you can run like this, but most teams or even companies would struggle.
45:48
SPEAKER_0: They would crash and burn, I'm pretty sure.
45:51
SPEAKER_1: Yeah.
45:51
SPEAKER_1: I mean, you can't underestimate the difference that it makes for being still a startup and a fairly small team, as I said before, that takes away a lot of the challenges.
46:05
SPEAKER_1: But ultimately, I think it really comes down to the people that we hire.
46:11
SPEAKER_1: So people are really passionate.
46:14
SPEAKER_1: All of us are really passionate in product, building a great product, unblocking ourselves, moving things forward.
46:22
SPEAKER_1: So when people are driven, you can rely more on their best judgment and you don't need to set so much process.
46:33
SPEAKER_1: I remember actually, to give a concrete example, I remember when I joined Linear after maybe a month.
46:40
SPEAKER_1: I was like, "How is this company working?"
46:43
SPEAKER_1: I remember I was like, "We don't have any phases of a project."
46:46
SPEAKER_1: So I just put a document to kind of, "Okay, it seems like these are the phases of the project.
46:52
SPEAKER_1: Let's just put it somewhere."
46:53
SPEAKER_1: Tuomas was like, "Yeah, no.
46:56
SPEAKER_1: No, I don't want to see."
46:57
SPEAKER_1: You're saying like I don't like the circles, the circles with the bubbles of phases.
47:01
SPEAKER_1: Right?
47:02
SPEAKER_0: Yeah.
47:02
SPEAKER_0: Because that's what we did Uber, right?
47:03
SPEAKER_1: Yeah.
47:04
SPEAKER_0: You and me, I think some of it, we did it together.
47:08
SPEAKER_0: We came up with a way to visualize project status when we sent it out to sometimes dozens of business stakeholders, sometimes legal teams and everyone, what the status is.
47:16
SPEAKER_0: And we made it very, very clear to show that we're on track, or when we're not on track, what we were asking for.
47:23
SPEAKER_0: Tuomas also came from Uber, so he also had this working style.
47:27
SPEAKER_0: So it sounds like both you and him just completely did a 180 flip in, I guess, thanks to just a completely different environment.
47:36
SPEAKER_1: Yeah, absolutely.
47:36
SPEAKER_1: And I don't want to make it sound like there's no process.
47:39
SPEAKER_1: There is process.
47:40
SPEAKER_1: It's just the preference of creativity over process, and more like acting or talking in principles rather than guidebooks.
47:50
SPEAKER_1: I think that that's the... We're not going to be creative when it comes to how you react to an incident, for example.
47:57
SPEAKER_1: So we have very, very clear process with bullet points of everything that needs to be done.
48:02
SPEAKER_1: I'm actually the person in the company that does... Any process that we have, I tend to lead that one, or most of them, just because coming from Uber, I have quite a bit of experiences, like we were... Being successful in Uber meant that you can get a lot of people aligned on the way we build a thing.
48:21
SPEAKER_0: Yeah.
48:22
SPEAKER_0: We remember there are things that are no jokes, like reliability down times, that can actually really damage a company.
48:29
SPEAKER_1: Yeah, absolutely.
48:30
SPEAKER_0: So what I'm hearing is, for things where it really matters and you cannot make any mistakes and you know exactly what you need to do, you do put process, for example, reliability, and places where your goal is creativity, to create things that customers want, but they might not even know themselves.
48:49
SPEAKER_0: You kind of try to get the rigid process out of the way, or people can put it whenever it helps them, but you're not forcing on them so that hopefully, I mean so far it sounds like it's kind of working, perhaps you might be iterating faster or getting to the things that you were hoping faster.
49:04
SPEAKER_0: Is that a fair summary?
49:05
SPEAKER_1: Yeah, I think the goal is not faster.
49:08
SPEAKER_1: I don't think we... As we go through the projects, we don't talk about how fast can we get this out.
49:14
SPEAKER_1: The goal is always building something that makes sense, that feels good.
49:18
SPEAKER_1: So I think that that's the focus.
49:20
SPEAKER_1: And yes, I think creativity helps a lot if you want to achieve that goal.
49:24
SPEAKER_0: Awesome.
49:25
SPEAKER_0: So let's talk a little bit about how different it is to work at Linear as a startup still moving very quickly, a lot smaller team, and also for remote versus working at a large company like Uber where you and me worked.
49:38
SPEAKER_0: Maybe to start, we talked about a project that was pretty typical at Linear.
49:44
SPEAKER_0: Maybe let's talk about a project that was maybe not the most typical, but it was a pretty good representation of how Uber worked, which is the first project you and me worked together on, which was codenamed Helix.
49:56
SPEAKER_0: And it happened to be rewriting the whole Uber application, both iOS and Android, from scratch.
50:03
SPEAKER_0: And you were on the Android side of things, right?
50:05
SPEAKER_1: Yes, yes.
50:07
SPEAKER_1: There's so many things to talk about that, but I think if I have to pick the two, three things that really stood out for me in that project is, we need to rewrite the rider app on Android and iOS with a new architecture, with a new programming language on iOS, with a new payments framework for us.
50:28
SPEAKER_0: New payments framework.
50:29
SPEAKER_0: Yeah, everything.
50:31
SPEAKER_0: We all came up with it on the fly in a few months time.
50:34
SPEAKER_1: Yes, exactly.
50:35
SPEAKER_1: And I mean the app is core to the business of Uber.
50:39
SPEAKER_1: You know?
50:40
SPEAKER_0: So by that time, I think I did the math, we did about a billion, I think it was $2 billion run rate per month between the two apps.
50:47
SPEAKER_0: So about 50/50 Android and iOS.
50:49
SPEAKER_0: So like a billion dollar on the line in terms of revenue per month.
50:54
SPEAKER_1: Yeah, exactly.
50:55
SPEAKER_1: And then to sum it all up, we'll do it in two and a half months.
50:58
SPEAKER_0: Yep.
51:00
SPEAKER_0: And that's when I joined Uber.
51:01
SPEAKER_0: You were there a little bit earlier though, so you saw this whole thing start.
51:04
SPEAKER_0: I wasn't there at the start.
51:06
SPEAKER_0: So how typical or atypical was that project, even at Uber standards?
51:16
SPEAKER_1: I mean, it was big.
51:17
SPEAKER_1: It was big, the project, but here's the thing: It wasn't shocking in terms of how daring it was.
51:23
SPEAKER_1: It was right there with big bold bets.
51:26
SPEAKER_1: Go for it.
51:26
SPEAKER_1: So it didn't feel atypical for the culture in Uber.
51:30
SPEAKER_0: At the time.
51:31
SPEAKER_1: We can do it.
51:32
SPEAKER_1: Yeah.
51:33
SPEAKER_1: I remember the deadline specifically, I don't think almost anyone in the engineering team in Uber thought that that is an actual deadline.
51:42
SPEAKER_1: I think it was so aggressive that if we saw that is a directional one, it would be great if you can do it in two and a half months.
51:49
SPEAKER_0: Yeah.
51:50
SPEAKER_0: So if I'm not mistaken, the project started in June, June 2016 ish in the summer.
51:57
SPEAKER_1: Right.
51:57
SPEAKER_0: I think some teams, the platform teams were working earlier on the architecture, and then internal deadline was something September 16th or so to ship the app for beta users.
52:11
SPEAKER_0: And our ultimate release date was I think 2nd of November.
52:14
SPEAKER_0: And in the end, I think we did hit the 2nd of November, right?
52:16
SPEAKER_1: Yeah, I think so.
52:17
SPEAKER_1: I don't know why I remember, this is like three, four months.
52:19
SPEAKER_1: I remember it was even shorter.
52:21
SPEAKER_1: Maybe it was a thing of like in how much time we need to be internally feeling good about it.
52:26
SPEAKER_1: And then you have the productization phase and everything that took you to the beta users.
52:29
SPEAKER_0: And I think we might've had a different deadline because we were on payments, which was one of the three core pillars which needed to work because we were blocking other teams.
52:38
SPEAKER_0: So I think internally, there was a lot shorter deadlines there.
52:41
SPEAKER_0: It was like late July, early August, that kind of stuff.
52:44
SPEAKER_1: Yeah.
52:44
SPEAKER_1: Yeah, it was cool.
52:48
SPEAKER_1: So the daringness of the goal was one thing that I remember, and it's also, we did a lot of work.
52:59
SPEAKER_1: We had to work really long hours, but the resilience that build and the friendships that lasts to this day, I think that's another thing that... I would go back in time, I would do it again, 100%.
53:13
SPEAKER_0: It was an absolute pressure cooker.
53:15
SPEAKER_0: The interesting thing, I think just to scale, because I think for us it's kind of a given because remember, but it was literally all hands on deck.
53:21
SPEAKER_0: So anyone who did Android or iOS at Uber was on it, which was few hundred engineers, I don't know exactly, but maybe 200 or so.
53:31
SPEAKER_0: And then even people who didn't do iOS or Android were pulled in often to do... When I joined, I was supposed to join as a backend engineer, and I was asked to be an Android engineer because of this project, because we were low on Android.
53:42
SPEAKER_0: And then we had a few backend engineers.
53:44
SPEAKER_0: I think we realized midway that, "Oh, we actually need backend engineers for all these new mobile endpoints."
53:49
SPEAKER_0: But it was a really... Actually, that's where you and me got to work really close together.
53:57
SPEAKER_0: We spent, what, two weeks or three weeks in San Francisco?
54:00
SPEAKER_1: I think I spent six weeks, and you probably were there for most of that time as well.
54:04
SPEAKER_0: I think three or four weeks.
54:06
SPEAKER_0: I went to my Uberversity, the introduction course, and I never did it.
54:11
SPEAKER_0: We just worked on this project.
54:13
SPEAKER_1: Yeah, yeah.
54:14
SPEAKER_1: Just long nights, powering through it.
54:17
SPEAKER_1: It was cool.
54:18
SPEAKER_1: It was cool.
54:19
SPEAKER_1: It was like, it just proved if you get a lot of people motivated, how many things you can achieve.
54:27
SPEAKER_1: It's definitely not sustainable.
54:28
SPEAKER_1: You can't work like that.
54:29
SPEAKER_1: But that was in Uber, that was the number one most difficult thing we ever built.
54:34
SPEAKER_0: But this was really different because I think this was probably one of the last truly company-wide startup modes, or almost it felt like wartime where almost felt like we had an existential threat, even though there was nothing existential about it.
54:50
SPEAKER_0: But afterwards, two years later, one and a half years later, we re-rolled the driver app, which was similar in scope, but that one took I think 18 months.
54:59
SPEAKER_0: It was a lot more.
55:00
SPEAKER_0: It had all the deadlines, all the formalities.
55:03
SPEAKER_0: It was like the opposite of this project.
55:06
SPEAKER_0: So I feel the company also changed later on.
55:09
SPEAKER_1: Absolutely.
55:10
SPEAKER_0: But speaking of, you were at Uber for how many years?
55:14
SPEAKER_0: Seven?
55:15
SPEAKER_1: Seven years.
55:16
SPEAKER_0: Seven years.
55:16
SPEAKER_1: Seven years, yeah.
55:17
SPEAKER_0: And you saw it go from a more scrappy scale-up to a lot more structured company.
55:22
SPEAKER_0: What are things that you now do very differently at Linear than you did at Uber?
55:28
SPEAKER_1: Yeah.
55:29
SPEAKER_1: I mean, Uber is significantly bigger than Linear, so I find that a lot of the problems that senior engineers managers have to solve at Uber are around getting a lot of people to work together efficiently.
55:45
SPEAKER_1: So that takes a big part of the day.
55:49
SPEAKER_1: And that is not a problem at Linear.
55:53
SPEAKER_1: So then we can use that time for other things.
56:00
SPEAKER_1: Focusing on being much closer to customers, for example, is one of them.
56:05
SPEAKER_1: It's very hard to be close to customers, especially if you think Uber, from the rider perspective, you have millions of users.
56:16
SPEAKER_1: So it's much harder to get so many thousands of engineers to be that close to the customers, where in Linear you can do that.
56:26
SPEAKER_1: Yeah, I think the differences come from challenges that have to do with the difference in the size of the company.
56:35
SPEAKER_0: I guess, do you think email fits into this thing as well?
56:38
SPEAKER_0: Just loft your emails?
56:39
SPEAKER_0: Or is that more of a just completely different communication style?
56:43
SPEAKER_1: I mean, definitely email as well.
56:47
SPEAKER_1: Yeah, definitely email as well, right?
56:49
SPEAKER_1: It would be hard to imagine having everything decided in group chats at Uber with so many stakeholders, with so many-
56:57
SPEAKER_0: Yeah.
56:57
SPEAKER_0: We use email for a lot of status checks, getting people on the same page, sending out proposals.
57:03
SPEAKER_0: In fact, we even had a firehose.
57:06
SPEAKER_0: Remember?
57:06
SPEAKER_0: We could subscribe to a couple of email lists where we could have the RFCs request for comments.
57:12
SPEAKER_1: Mm-hmm.
57:12
SPEAKER_1: Yeah.
57:13
SPEAKER_0: People had to send it there, and every day there would be like 10 or 20 RFCs going out, which is teams, maybe not every day it's 120, but every week, at least 20 of new projects that will be started off in a given domain.
57:26
SPEAKER_0: May that be mobile or backend or somewhere else.
57:29
SPEAKER_0: Just a very different scale.
57:30
SPEAKER_0: So you work as a senior engineer at Uber and you hire senior engineers there at Linear.
57:36
SPEAKER_0: You work with a lot of senior engineers, you also hire them.
57:39
SPEAKER_0: How do you see a senior engineer work differently at a large company like Uber versus at Linear?
57:46
SPEAKER_1: Yeah.
57:46
SPEAKER_1: So I think there are a few things.
57:49
SPEAKER_1: First, it's much more focused and involved in product decisions as a senior engineer, much closer to customers, actually talking to them, taking meetings, being on Slack and-
57:59
SPEAKER_0: Taking meetings.
57:59
SPEAKER_0: Awesome.
58:00
SPEAKER_1: Yeah.
58:00
SPEAKER_0: So it's like video calls with customers.
58:02
SPEAKER_1: Yeah, video calls with customers.
58:03
SPEAKER_1: Quite often actually, especially when we build a bigger project.
58:09
SPEAKER_1: I think those are the two big differences.
58:14
SPEAKER_1: Yeah.
58:15
SPEAKER_0: In terms of skillset, motivation, or mentality, did you see any real differences, or not necessarily?
58:23
SPEAKER_1: Of course.
58:23
SPEAKER_1: Of course.
58:23
SPEAKER_1: Definitely on the motivation front.
58:26
SPEAKER_1: I think in Linear, the biggest motivation that people have is the customer feedback that comes from building the products that they do.
58:43
SPEAKER_1: Writing a nice RFC or designing a super scalable architecture, writing elegant code, those are just means to build a good product.
58:53
SPEAKER_1: Those are not the goals.
58:55
SPEAKER_1: It's not like there's a complete mentality shift between... You have a lot of our engineers come from bigger tech companies, but it's just in a big tech company, it's much more... I can see why in a big tech company it's easier to focus on the architecture that you build on the RFC, because you have a promo process, you have a performance.
59:21
SPEAKER_1: In a way, I think it's needed, but it definitely does distract you from why you are there.
59:27
SPEAKER_0: Yeah.
59:28
SPEAKER_0: We talked about this, by the way, before this, on how even while we were there, how Uber changed.
59:33
SPEAKER_0: You were there for seven years, so you saw it even longer than I did.
59:36
SPEAKER_0: How it changed from this type of focus where, when I joined at least, in the early years in 2016, it was all about what is right for the company, let's build the right thing, let's focus on the impact, to how very slowly the things crept into the back of your head, like, "Oh, to get promoted, I saw the people who got promoted, they had some really nice RFCs, they worked on some cross-functional projects.
1:00:01
SPEAKER_0: Oh, let me try to find a cross-functional project because it might help me get promoted."
1:00:06
SPEAKER_0: As opposed to some engineers were getting frustrated who were building really important stuff for the business and they weren't necessarily being recognized.
1:00:14
SPEAKER_0: It was just interesting.
1:00:15
SPEAKER_0: And it wasn't sudden.
1:00:16
SPEAKER_0: It was very, very slow.
1:00:18
SPEAKER_1: Yeah.
1:00:18
SPEAKER_0: And it wasn't for everyone, but it was for the majority of people after a while.
1:00:22
SPEAKER_1: Yeah.
1:00:22
SPEAKER_1: I remember when I joined Uber, we still had meetings with drivers.
1:00:28
SPEAKER_1: We would have the drivers coming in, and if you wanted to, you could go even as an engineer and listen to those interviews.
1:00:35
SPEAKER_0: Yeah.
1:00:35
SPEAKER_0: But by the time I started, I am not sure I remember having that.
1:00:40
SPEAKER_1: It was so cool to see because when you stay... Again, because the company is big, it's hard to keep everybody close to the customer.
1:00:50
SPEAKER_1: And the further away you go, the more you optimize for what you think is important for you, for your team.
1:00:57
SPEAKER_1: But I remember when you would see drivers chatting on how they use the app, especially for payments and the issues that they have, there are things that I would have not thought of because I was so used to using the product myself and it felt natural to me.
1:01:12
SPEAKER_1: But yeah.
1:01:13
SPEAKER_0: Speaking of what engineers care about, especially senior engineers care about, at large companies, levels are important in career progression.
1:01:21
SPEAKER_0: At Linear, do you even have levels?
1:01:23
SPEAKER_0: Do you have titles?
1:01:24
SPEAKER_1: We don't.
1:01:25
SPEAKER_1: We don't.
1:01:26
SPEAKER_1: Everybody's an engineer.
1:01:28
SPEAKER_0: As someone, again, you were an engineer manager, you helped a lot of people get promoted.
1:01:32
SPEAKER_0: You were promoted yourself.
1:01:34
SPEAKER_0: How do you feel this thing changes things, or it doesn't?
1:01:40
SPEAKER_1: Well, I think, again, it keeps the focus on what you are building and what the goal for the company, which is building a great product.
1:01:52
SPEAKER_1: I think that that's what helps the most.
1:01:57
SPEAKER_1: In terms of... What happens is, it's very easy, I remember when we had the rubric introduced for the performance and competencies in Uber.
1:02:07
SPEAKER_0: Yep, right.
1:02:09
SPEAKER_1: I remember we were building things and then we have this, and it started off, I was looking at the rubric, I was like, "Yeah, that makes sense.
1:02:14
SPEAKER_1: They actually did a good job mapping the type of things that are expected of us and that we do every day to a process that allows you to get a promotion."
1:02:24
SPEAKER_1: And with every promo cycle passing, the rubric became the goal.
1:02:31
SPEAKER_0: Yeah.
1:02:32
SPEAKER_1: It's just natural.
1:02:34
SPEAKER_1: It happens.
1:02:34
SPEAKER_1: So when you don't have all of that, then you can focus.
1:02:38
SPEAKER_1: It's one thing, promos are one thing, but growth is another.
1:02:41
SPEAKER_1: Right?
1:02:42
SPEAKER_0: Yeah.
1:02:44
SPEAKER_1: There is a lot of growth in Linear.
1:02:45
SPEAKER_1: But again, we think different about it.
1:02:49
SPEAKER_1: You don't grow to get the promotion.
1:02:51
SPEAKER_1: You grow to be able to... The product is becoming harder and harder to be allowing customers that are 10, 20 times the size of Linear to use Linear.
1:03:01
SPEAKER_1: It's a challenge.
1:03:02
SPEAKER_1: It's not instinctive to you, like what you need to build as an engineer.
1:03:09
SPEAKER_1: And being able to keep that product simple as you scale it up, that is a continuous challenge that becomes more and more difficult, and for you to achieve it and to smoothly achieve these products, you need to grow.
1:03:22
SPEAKER_1: So it's kind of growth with the company.
1:03:24
SPEAKER_1: Yeah.
1:03:25
SPEAKER_0: It sounds like a lot of the things that you're doing at Linear, and while I say you, I also mean the whole company, it's trying to push back on how a large tech company eventually, when it becomes thousands of people, will operate both by staying small, but also sounds like pretty mindful of what you don't want to do, or at least not just yet.
1:03:45
SPEAKER_0: One day when Linear, if you stay this successful for another 10, 20 years, I'm sure at some point you'll have some levels.
1:03:53
SPEAKER_0: Although Netflix is a very interesting example where Netflix had the senior engineer level for 25 years.
1:03:59
SPEAKER_0: They just got rid of it.
1:04:00
SPEAKER_0: I think they just changed it to have other levels, but they did it for 25 years.
1:04:04
SPEAKER_0: And a large part of that was a publicly traded company.
1:04:06
SPEAKER_0: So I guess there's examples of holding that.
1:04:10
SPEAKER_0: Who knows?
1:04:10
SPEAKER_0: You might be able to do it longer.
1:04:13
SPEAKER_0: You are an engineering manager both at Uber and at Linear.
1:04:16
SPEAKER_0: How did the two compare?
1:04:19
SPEAKER_1: Yeah, I mean it took me around two months to realize that 40% of the job that I was doing in Uber just does not apply to Linear.
1:04:28
SPEAKER_1: If you think of things like having a promo, the super complex process with all the competencies, alignment between different teams, dependencies between teams, and all of that budgets, reporting, justifying why your team needs to be there.
1:04:45
SPEAKER_0: Are you sure that was just 40%, not like 70%?
1:04:46
SPEAKER_1: Probably more.
1:04:50
SPEAKER_1: Yeah, it's not needed, it's not needed in Linear.
1:04:54
SPEAKER_1: So once I realized that, the first thing, I was like, "Well, so I'm still paid the full salary, right?
1:05:00
SPEAKER_1: What do I do with the 40% of my time?"
1:05:04
SPEAKER_1: It amuses me.
1:05:05
SPEAKER_1: Every now and then I ask Tuomas like, "Hey, how am I doing?
1:05:08
SPEAKER_1: Give me some feedback as my manager."
1:05:09
SPEAKER_1: Tuomas is one of the founders.
1:05:11
SPEAKER_1: He says like, "Well, tell me, what have you done to make Linear a better product?"
1:05:17
SPEAKER_1: It's not an easy question sometimes, especially as the work that you do is kind of indirect.
1:05:21
SPEAKER_1: But I think it's a really good question.
1:05:22
SPEAKER_1: Right?
1:05:23
SPEAKER_0: Yeah.
1:05:23
SPEAKER_1: So I found myself, I think I was the de facto data scientist for Linear for a couple of months before we hired someone, just writing queries all day.
1:05:31
SPEAKER_1: And I really enjoyed it because I felt like it helped.
1:05:35
SPEAKER_1: Definitely much more involved in product than I was in Uber, taking some customer interviews, reaching out to customers to understand what they need, even in bulk sometimes.
1:05:46
SPEAKER_1: Once, I wrote a hundred emails, I intentionally didn't want to use a tool.
1:05:49
SPEAKER_1: I was just trying to communicate with people and all kinds of things like that.
1:05:57
SPEAKER_1: And plus, of course, the normal things that you do as a manager, like you'll have the focus on people.
1:06:02
SPEAKER_1: You'll have the one-on-ones.
1:06:03
SPEAKER_1: You want to know how every person feels, what they want to work on, what they don't want to work on anymore, what the things that they need to learn.
1:06:11
SPEAKER_1: So doing all of that as well, plus all the process-related stuff.
1:06:17
SPEAKER_0: One thing that I noticed with Linear is you hire experienced engineers.
1:06:20
SPEAKER_0: And at places like Uber, we had interns, we had new grads, we had eng 1s, eng 2s who are still earlier career.
1:06:28
SPEAKER_0: And as a manager, we did spend time helping them, giving them feedback, and also of course, onboarding not just them, but other engineers.
1:06:37
SPEAKER_0: But how has that change of not having... Or do you have less experienced engineers there?
1:06:45
SPEAKER_0: And if not, does this change how you work as a manager?
1:06:50
SPEAKER_1: Yeah, it definitely does.
1:06:51
SPEAKER_1: I would say, we do have engineers with less years of experience, but whenever we hire a person, it's not just about being kind of okay, it's okay.
1:07:01
SPEAKER_1: Right?
1:07:01
SPEAKER_1: It's like a soft yes, maybe a yes, right?
1:07:03
SPEAKER_0: Yeah.
1:07:04
SPEAKER_1: It's always the question is, what does this person have that stands out, things that we admire, that we learn from?
1:07:13
SPEAKER_1: So almost everybody that we hired impressed us in a way.
1:07:18
SPEAKER_1: So it's not that much in terms of... I don't look at it as, "Oh, this person has less experience, therefore I will help them."
1:07:25
SPEAKER_1: What I find is that people are just generally very good, and whenever I give feedback to them, it's quite specific, and it's much less than in Uber.
1:07:38
SPEAKER_1: I remember in Uber, it was this moments where you go like, "Oh, you need to find three things for the person to improve."
1:07:43
SPEAKER_0: Yeah, it was a mandate in 2016 and '17.
1:07:46
SPEAKER_1: Yeah, exactly.
1:07:47
SPEAKER_1: I mean, to a certain extent I understand where it comes from, but I don't think in those terms now anymore.
1:07:52
SPEAKER_1: I'm there for all the product meetings, at least everything that we ship in you.
1:07:56
SPEAKER_1: I can see people every day how they work, and very rarely I find a thing that I think it's worth discussing about and giving some feedback.
1:08:07
SPEAKER_1: When people go like, "Oh, you are right.
1:08:08
SPEAKER_1: I haven't thought of this," or it ends up in a discussion, there's so much more, like you feel so good about it.
1:08:15
SPEAKER_1: There's so much more rewarding when you can find, even though there are not a lot, but a few things in people that are incredibly good, and you admire, and you can still feel like, as a manager, you can contribute somehow for them to grow.
1:08:28
SPEAKER_0: Yeah.
1:08:29
SPEAKER_0: But I really like how the goal, at least from Tuomas, one of the co-founders, is the measurement of your success is, have you made Linear a better product?
1:08:39
SPEAKER_1: Yeah, yeah.
1:08:40
SPEAKER_0: Which I think quite a few managers can say that this is what their manager asks of them, which is just really cool.
1:08:45
SPEAKER_1: Yeah.
1:08:47
SPEAKER_0: What are useful learnings from a large company like Uber that has helped you and still helps you to this day at Linear?
1:08:54
SPEAKER_1: I mean, you get to work with a lot of people.
1:08:59
SPEAKER_1: You get to know a lot of people and different personalities, different motivations.
1:09:05
SPEAKER_1: I wouldn't underestimate how many learnings that gives you as a manager.
1:09:13
SPEAKER_0: Are you talking about how, for example, at Uber, we were exposed to a lot of the different people, teams, conflicts?
1:09:21
SPEAKER_1: Yeah, yeah, exactly.
1:09:22
SPEAKER_1: You just build that solid foundation that when you're in a smaller company, it makes you feel like whatever happens happens, especially when it comes to people you have seen already, so not so many surprises, I would say.
1:09:35
SPEAKER_1: I think that helped me a lot.
1:09:37
SPEAKER_1: And also to just think big.
1:09:39
SPEAKER_1: You can achieve big things like I think Uber taught all of us that the big, wild, bad sport.
1:09:45
SPEAKER_0: Let's wrap up with some rapid questions.
1:09:48
SPEAKER_1: Of course.
1:09:48
SPEAKER_1: Let's do it.
1:09:50
SPEAKER_0: What's your favorite sport, and why?
1:09:52
SPEAKER_1: Scuba diving.
1:09:54
SPEAKER_1: I do a lot of it.
1:09:55
SPEAKER_1: Cheapest way to experience zero gravity.
1:09:59
SPEAKER_0: Nice.
1:10:00
SPEAKER_0: Sometimes you're working full remote, right?
1:10:02
SPEAKER_0: Do you sometimes combine work and vacation?
1:10:06
SPEAKER_1: Sometimes, yes.
1:10:08
SPEAKER_1: I would stay more in a place and stay three weeks.
1:10:11
SPEAKER_1: Two of them you work, and then one week you take off.
1:10:14
SPEAKER_1: I think with scuba diving, it's particularly hard because after a dive, there's a lot of nitrogen in your bloodstream, so you're a little bit woozy.
1:10:22
SPEAKER_1: I wouldn't work after diving.
1:10:24
SPEAKER_0: Nice.
1:10:26
SPEAKER_0: What's the best thing about being an engineering manager and also the best thing about being an engineer now that you've been both?
1:10:34
SPEAKER_1: As an engineering manager, I think the best feeling that I had as an engineering manager happened to me in Uber with the web team, definitely Linear as well, is just this being proud of your team, of the people in the team of what they achieved.
1:10:47
SPEAKER_1: I think nothing really beats that.
1:10:49
SPEAKER_0: And as an engineer?
1:10:50
SPEAKER_1: Building.
1:10:50
SPEAKER_0: Building.
1:10:52
SPEAKER_1: Building.
1:10:53
SPEAKER_0: No hesitation.
1:10:54
SPEAKER_1: Yeah, just building.
1:10:55
SPEAKER_1: Yeah, I miss that actually.
1:10:57
SPEAKER_0: Do you get to build a little bit, or not as much?
1:11:00
SPEAKER_1: Very little.
1:11:01
SPEAKER_1: In Linear, very little.
1:11:04
SPEAKER_1: I do build at home.
1:11:05
SPEAKER_1: I build stuff.
1:11:06
SPEAKER_1: I think I've been building for so many years things that have to do with products for customers.
1:11:14
SPEAKER_1: I just want to go home and build a robot that doesn't do anything.
1:11:16
SPEAKER_1: It just wobbles around the apartment.
1:11:20
SPEAKER_0: Love it.
1:11:21
SPEAKER_0: Finally, what's a movie that you'd recommend watching or that you enjoyed?
1:11:25
SPEAKER_1: Yeah, I mean, probably everybody saw it, but I'm really passionate in astronomy.
1:11:31
SPEAKER_1: I do astrophotography and stuff, so Interstellar for me was great.
1:11:35
SPEAKER_0: That's an awesome movie.
1:11:36
SPEAKER_0: Awesome, Sabin, thanks a lot for being here.
1:11:38
SPEAKER_1: Thank you so much for inviting me.
1:11:39
SPEAKER_1: I really enjoyed the time.
1:11:41
SPEAKER_0: If you enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube.
1:11:45
SPEAKER_0: And if you're interested in reading more about Linear's engineering culture, check out the deep dives into Pragmatic Engineer that goes into additional details linked in the show notes below.
1:11:54
SPEAKER_0: Thanks, and see you in the next one.