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

Episode Date: November 20, 2024

Brought to you by:• Launch Darkly — a platform for high-velocity engineering teams to release, monitor, and optimize great software. • Sevalla — Deploy anything from preview environments to Docker images.• WorkOS — The modern identity platform for B2B SaaS.—On today’s episode of The Pragmatic Engineer, I’m joined by fellow Uber alum, Sabin Roman, now the first Engineering Manager at Linear. Linear, known for its powerful project and issue-tracking system, streamlines workflows throughout the product development process.In our conversation today, Sabin and I compare building projects at Linear versus our experiences at Uber. He shares insights into Linear’s unique approaches, including:• How Linear handles internal communications• The “goalie” program to address customer concerns and Linear’s zero bug policy• How Linear keeps teams connected despite working entirely remotely• An in-depth, step-by-step walkthrough of a project at Linear• Linear’s focus on quality and creativity over fash shipping • Titles at Linear, Sabin’s learnings from Uber, and much more!Timestamps(00:00) Intro(01:41) Sabin’s background(02:45) Why Linear rarely uses e-mail internally(07:32) An overview of Linear's company profile(08:03) Linear’s tech stack(08:20) How Linear operated without product people(09:40) How Linear stays close to customers(11:27) The shortcomings of Support Engineers at Uber and why Linear’s “goalies” work better(16:35) Focusing on bugs vs. new features(18:55) Linear’s hiring process(21:57) An overview of a typical call with a hiring manager at Linear(24:13) The pros and cons of Linear’s remote work culture(29:30) The challenge of managing teams remotely(31:44) A step-by-step walkthrough of how Sabin built a project at Linear (45:47) Why Linear’s unique working process works (49:57) The Helix project at Uber and differences in operations working at a large company(57:47) How senior engineers operate at Linear vs. at a large company(1:01:30) Why Linear has no levels for engineers (1:07:13) Less experienced engineers at Linear(1:08:56) Sabin’s big learnings from Uber(1:09:47) Rapid fire round—The Pragmatic Engineer deepdives relevant for this episode:• The story of Linear, as told by its CTO• An update on Linear, after their $35M fundraise• Software engineers leading projects• Netflix’s historic introduction of levels for software engineers—Where to find Sabin Roman:• X: https://x.com/sabin_roman• LinkedIn: https://www.linkedin.com/in/sabinroman/Where to find Gergely:• Newsletter: https://www.pragmaticengineer.com/• YouTube: https://www.youtube.com/c/mrgergelyorosz• LinkedIn: https://www.linkedin.com/in/gergelyorosz/• X: https://x.com/GergelyOrosz—References and Transcripts:See the transcript and other references from the episode at https://newsletter.pragmaticengineer.com/podcast—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

You use email very little? We don't use email at all internally. 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 internal. 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. Maybe I'll just spend a little bit more time and figure it out myself. That's a good thing about not having email.

You can't just send an email because it's easier that way. The goal of the goalie is to address all incoming reports from customers. So the first goal for the only is to go through all of those requests and fix those issues as well during the week. As they do this, they are also active on all the support channels. A customer wrote about a bug in the product and the engineer was like, oh, I'm looking at it. An hour, two hours later, it was like, okay, it's fixed. Deployed. Wow.

Wow. I haven't seen that. Subin-Roman is the first engineering manager at Lanier where he heads up engineering. Linear is a project management software especially popular with startups. The company has raised $50 million in funding and are known for their business. their unique design, snappy years of experience, and for having a real traction with startups and scale-ups. In this conversation, we go behind the scenes on how linear 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, we look into the overhaul of the new project functionally within Linear, comparing how a large company like Uber works versus a small one like Linear. As an interesting fact, Sabin worked at Uber before Linear and so did Linear's co-founder as CETO Thomas. Oh, and one more fun fact. Me and Sabin used to work together at Uber on the same team. I hope you'll enjoy as we go through tactics on how an engineering team can move fast with surprising a little process in place. If you enjoy this show, please subscribe to the podcast on any podcast platform and on YouTube. All right, Sabin, welcome to the podcast. Happy to be here. So you started your career as a back in the engineer. You did Java. You then worked at Orange

telecommunications company. And then later, you and me, we worked together at Uber. You were already an Android engineer, a senior Android engineer when I joined Uber. We worked together. I was also a software engineer. Later, for a short while I became your manager in a twist of events. And now you've joined Linear two years ago when there were 10 engineers at the company as a first engineering manager, and you're still the first engineering manager, as I understand, at Lunar. Yeah, we have two engineering managers now. Oh, you have two engineering managers. Awesome. But you're still the first engineering manager. one. You told me something really interesting before we sat down here, which was about emails. At Uber,

you know, both of us were managers and I remember getting like 50 or 100 emails per day and writing a bunch of them obviously. How many emails have you sent the past three months at linear? I don't know. I think I want to say 2030 or something like that, maybe less. Yeah, but like you told me, like you use email very little at linear? Yeah, we basically don't use it at all for the work that we do. So we don't use email at all internally. If I have to send emails, like I think I've sent two, three emails to you. So those count towards the 30.

And 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 and we may write an email, but not for internal work. So what are you instead? Well, we pretty much, we use Slack and Linear. Slack and the linear. And like the interesting thing is like I understand Slack for like, you know, the real time communication. You need to ping someone.

But my understanding of email was, you know, maybe it is a bit of an outdated understanding, but it's great for like async stuff when you don't want people to respond immediately. What about those kind of type of, you know, requests? I think in linear we, we tend to, you know, ask people for help when we really need the help. So a lot of the things, if I would write to people that, you know, we answer quite fast. And, yeah, I mean, there can be things that need to be followed up, but then, you know, we have linear for that as well. So are using linear for more the kind of long term of storage of stuff that needs to be, you know, structured or searchable? Yeah, absolutely.

So, for example, if you have a question on a project that you're building, right, you may decide, you know, 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, or you can ask a certain, like a person directly. Or you may be like, maybe I'll just spend a little bit more time and figure it out myself. So I think that that's a good thing about not having email. You can't like just, you know, send an email because it's easier that way, right? So you will, or you can go in linear and you can ask a question on the project directly. You can leave a comment or you can post a project update.

and there can be questions associated to that. Okay, 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. When you joined Linear, how big of a shock was this? Or was this even a shock? Because, again, you were a manager, right?

Like, your day started with email. I think my day started with emails. Yeah, I remember sending the first. email in linear. I think it was, I don't know, I saw something interesting and I wanted, I think, the marketing team to see it. And yeah, and, you know, I had to write on Slack that I send them an email. This episode was brought to you by Launch Darkly. When releasing software, bad ship happens. Bugs are inevitable, but they don't need to become disasters. LaunchDarkly reduces the risk of releasing software, giving developers a confidence to shift faster.

Through progressive releases, proactive monitoring, targeting and rollbacks with LaunchDarkly, you can find and fix bugs automatically. Do you know how risky your software releases are? Take LaunchDarkly's two-minute risk assessment to find out. Go to launchdarkly.com slash risk-m-meter. That's launchdarkly.com slash risk-m-meter. This episode is brought to by Savala. It's a true Heroku alternative where you can deploy applications,

manage databases, and host static sites for free. Savala is a platform designed for teams. With its preview and pipeline features, developers can collaborate on any stack while being assured of the security of their workloads from staging to production. Savala holds all the major security certifications companies are typically looking for. 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. Their free static site hosting is perfect for landing pages, documentation sites, and more. It also includes preview deployments for easier iterations and seamless teamwork. Savala features an easy-to-use interface unlimited seats, no hidden tricks, and transparent user-based pricing with enterprise-level cloud-fair DDoS protection for workloads of any size. Sign up and deploy today. go to savala.com. That is savala with a doublel.com.

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. But talking specifically about the company itself, can we kind of help imagine us what this place is like? How many people work there, for example? Of course. I actually checked before the podcast to make sure I'm right. We are over 60 people now. Over 60 people. And four or five years old, the company founded, ish?

Yeah, yeah. I think, I don't remember. I think five, six years old. Yeah. So 60 people. What kind of technologies do you use inside the company? Yeah. So in terms of engineering, we use TypeScript, React, Node, GCP, Postgres, GraphQL, that tech stack.

For a long time, you had no product managers at the company. company. Do you have product managers now? We do. We do. We have two product managers now. Awesome. So two energy managers, two product managers. Yes. And 25 engineers and the product team, including design and product is almost 40 people. But when you're joining, there were no product managers, right? So how did this time work? Like, because again, like coming from a more, I guess, traditional tech setup, you're kind of used to like, okay, we've an engineering team, they have a product manager, they've an engineering manager, and you didn't have that. How did the engineering team operate or who filled the product role of like, what should we build? Why should we build it?

I think everybody did. Everybody did. So linear started off as, you know, building an issue tracker for startups. That was the goal initially. The vision of the company was always bigger and we are now kind of achieving more and more of that vision. 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. So for being ourselves, a small company,

using the product every day, being close to customers, there was actually a big benefit in Linear that we could be close to customers ever since the beginning. And then, yeah, intuition helped a lot. And when you say close to customers, what does that mean? You ping people using it? Are they ping you like on a Slack channel or on a linear or somewhere? Yes, absolutely.

So I think from the engineering perspective, the most contact they have with customers is through Slack channels, support Slack channels. We also have what we call a goalie rotation. It's a triage feature in linear. So basically we have... So the goalie as in like the goalie is keeping the goalkeeper. Yeah, exactly.

Okay, tell me about that. Yeah, so we have now two engineers on that rotation every week. It's different engineers. And basically the goal of the goalie is to address all incoming reports from customers. Maybe it may be bugs, may be some small quality things that don't make sense. So the first goal for the goalie is to... go through all of those requests and see if, you know, if they can reproduce them and, right, and if they have time, then they will actually fix those issues as well during the week

or assign them to the right person. But as they do this, they are also active on all the support channels. So, for example, we had cases, one that I really loved seeing. It was at the beginning when I joined Linear the first time I saw this and I was like, wow. A customer wrote about a bug in the product and the engineer was like, oh, I'm looking at it. And And like maybe an hour, two hours later, it's like, okay, it's fixed, deployed. And I'm like, wow, I haven't seen that. Yeah, like I feel like this is the stuff where you hear it at startups. And I remember when, you know, when we were at Uber, we had something similar, right?

We called it a support engineer. Yes. Right? And 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 on 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, but there were thousands across the company and there would be like people filtering these

and often product managers would have to filter down. We would get the ticket and it would be on the support engineer's desk. But the frustrating part there was like as a support engineer, you kind of go through, you see if you can reproduce it and I think like 80% of the time, yeah, we could reproduce it, but we couldn't fix it because it was, you know, we were on the payments team and it looked like a payments, but actually it was a fraud bug and the fraud team was a very different team. So we created a ticket and we escalated it or we put it in their support group. And it just like, and I went away, you went up your support rotation and things just didn't really get fixed. So like you were in that, you know, you saw this,

but how did you make this work or how does this work differently? It sounds like it's way more efficient, right? Yeah, yeah. Is it just because you're smaller or more nimble? I mean, being smaller is generally takes a lot of complexities away from being in a, you know, 10,000, 20,000 people company. But how does this work? So I think there are a few things here that make it different from Uber, for example. The first one is that the engineers are close to the customers.

This is not an abstract bug that came from someone and that was probably triage multiple times before and now you kind of have to do it. It is something that you are there frontline with our customer support team being in contact with that customer. So you definitely feel more connected and you feel more the value of your work.

So that is one. 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. And here's where the second part comes in.

So on top of the goal rotation, we have a zero buck policy. Oh, interesting. Yeah. I'm very ambitious. Yes. And I mean, I can show you how many bucks we have opened right now. So basically the idea is... Okay, so is it like more than 10 or less than 10?

It is... 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. So basically what happens? Wow. Yeah. So what happens is that every morning come to work, you know, instead of doing email,

you fix all the issues that you have. And then you have time for the product work. I mean, I like how this sounds. It sounds very utopian, but you're, actually telling me that it works. I mean, it started from, like, it can work. It's always harder when you start. We had hundreds of issues when you started.

So we literally had to take time off from product work and just fix those issues, right? 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. Prioritizing that over something that the customer uses and doesn't, work doesn't make much sense, does it? Right? And it's not a zero-sum game either, right? It's not the same.

You can say, yeah, it takes the same amount of time. Yes, but the customer is much happier if the bug is fixed sooner. And also we have, like, a lot of things in linear are based on best judgment of people. You can look at the bug and say, look, it was reported by one customer. I can't straight up reproduce it. There was no contact with that customer maybe for a while. I'm just not going to fix it. It's fine.

Rather than saying I put it in the backlog, you just go, won't do. But we have a status. One do. That's what it is for, right? So we do that as well. And we do reviews every week of the SLAs for the bugs. And our goal is that every person has maximum like two issues roughly because that's normal right there, the ongoing ones.

And we've been running this for months now. And it's still working. I was surprised. I thought that this is very ambitious at the beginning. And I thought it would distract the team a lot. 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. Like once you average it out, if it was 10, then like stop work and figure out why you have so many bucks, right? But it was a good number to start with.

And yeah, it's still working. I'm really happy with it. Just like devil's advocate. I remember, again, comparing with Uber. at Uber, like, it felt to me that there was a reason that we did not spend most of our time fixing bugs, even though we knew. Like, we had a massive bug list slash feature requesters, but a lot of it was bugs. And, you know, we did try to fix the most important ones. But the thinking there was that there was more value for us to launch a new feature, which we measured the impact of it.

And, you know, 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 ourselves if we didn't grow. Growth was very important. So my question here is, like, do you think that focusing on bugs would slow down this type of building new features? Or in practice, it doesn't have to be a choice of this of growth or quality? I think theoretically it does slow down. and if you objected, you think if we wouldn't fix any bug,

then we will bid more products. But I think in reality, we don't feel it as much. And we also, it's really fundamental, like 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. And, you know, try for yourself. Think of linear, but without the quality.

Are we going to do a, like, who has more features competition with other companies? It's not, we don't think that that's the right way to approach it. That's an interesting one, because I wonder if this thinking is a lot more valid because, just to be fair, you know, linear by the time linear long-jy issue tracker, we had a lot of issue trackers, right? There's some well-known ones. There's some lesser-known ones. there's at least three or four publicly traded companies doing this. So I wonder if as a more general takeaway, we could say that when you're entering out the crowded market,

if you don't do quality, you might as well just give up because, again, like you're out-competing on features is a really hard ask. Or you need to raise a lot of money. And I think we saw some companies do that, but it's just a very different strategy. But personally, as an engineer, I really like to hear this. It's refreshing to hear that, you know, quality is actually. important and there's time for it, time allocated for it. So your hiring process, like you run quite differently than some other companies do just from what I've gathered so far, but you also have a famously different hiring process where you focus on, you have this

thing called the trial week. Yeah. Can you tell them a bit more about how your hiring process works and what type of people you look for to hire as software engineers? Of course. So I think that the process starts of pretty typical to tech companies. So we have a recruiter phone screen. We have a hiring manager call. With you? With me or Tom in the US. And if that goes well, we have two technical exercises. One is coding, one is architecture. It's really nothing abstract algorithms. I really love that. We actually took a part of the linear code and like really simplified it. So it can be a standalone exercise that you can finish within an hour. So, you know, 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? It's not the

case. Somebody had to do it in linear before. And if all of that goes well, indeed, we move to the work trial. So the work trial, it depends on the role you have in linear. So if you're on engineering, the work trial will be a week. But for other roles, it can be from a few days to a week. And as part of the work trial, it's basically the candidate gets to work with the team for a week as they, as if they would have been employed. Full remote, right? Because everyone's full remote. Yeah, exactly, for remote. We try to find this getting harder and harder, but we try to find greenfield projects for everyone. Oh, even for the work trial. Yes, even for the work trials. It's actually, you know, we have a meeting before and we tried, we have a bunch of ideas, but it's an

interesting thing because you want to balance out, of course, like seeing how the candidate does, but you also want to be something interesting, something that they can work autonomously. But we managed to find good projects. And I think the best ones are the ones that, you know, they build, you know, 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 built in the work.

Can you tell me what that feature was? Yes, I think it was the triage responsibility, I think, one of our engineers. So when in linear, you can assign who needs to triage this issue. Yeah, and you can integrate the PagerDuty integration into it. So you can kind of automatically, the goalie, in our case, the triage is the person that you're having the PagerDuty rotation. So started working on this during the work trial, make good progress and then join and then finished? Yes. Awesome. I love it. So you're the hiring manager on the hiring manager call. Just putting you on the spot here, what does a typical hiring manager call look like? Someone passes a recruiter screen. They're now talking with you, Sabin. What do you usually talk about? Right. So first of all, when the recruiter has the phone screen, then I have a discussion. It can be asynchronous or in person depending on the candidate with the recruiter.

And we kind of try to make an initial evaluation whether we move forward to the hiring manager interview. Of course, if the recruiter is like super solid, I'm confident, then there's no need for a discussion. Just move forward. And part of the hiring manager, I have been redoing a little bit the storyline, if you want, of the hiring manager interview. I think of what I landed on now is focusing on three things. I focus on the motivations of the candidate, the things that they like doing what they are excited about. it's important because if anything, we're very opinionated in linear. And, you know, it's important that the type of motivations aligned.

And then the next thing that I would evaluate is product. I spent quite a bit of time on talking about product within 10 years. And finally, just going through their experience tech-wise, talking about some of the challenges, things they build and so on. And one thing that, again, I don't think it's 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 are product-minded? Yeah, absolutely.

How does this change both the hiring and the day-to-day work? Because now, you know, like it sounds like linear is a team of, you said 25 engineers, but really is 25 engineers who are all really open and willing and wanting to do product work as well, right? Yeah, absolutely. So it definitely makes hiring, you know, not easy. People say that, okay, we have a high bar in linear. And that's true. But I think what makes it really difficult is a very specific bar.

And I think the product side of it makes it so specific. 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. Yeah. And to add all this, you all work full remote, right? The whole 60 people, everyone is full remote.

How is that working? What is good about it and what is more challenging? Especially that at Uber, both you and me, we initially worked in office and then we did some forced remote, full remote, but again, Uber is now, at the end of Uber, you were also back in the office. So again, for you, it was a big change as well. Yeah, absolutely. Well, it works, it works great for us and it works great for me personally as well. I absolutely love it. 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. 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. They were like, oh, well, people are kind of working too much. So we were afraid of them getting burned out. Yeah, I remember there was this all-hands right after COVID or a few months after we went in full lockdown. And that's on the all-hands because both of us were there. They showed this staff.

Turns out that there was this internal tool that the office of the CTO or senior directors on the buff could see the number of pull request or as we call them diffs. And there was this massive spike. And I think I had two, I had two reactions. is one was like, oh, wow, that's really cool. Second law, what? They're tracking our poll requests all the time. I remember that.

Yeah, I mean, so let's split it in what's good and what's more challenging. So I think the first thing of what's good about it is focus. It's really focused. Like we don't do overtime or very, very rarely. But whenever people are there, they're truly there. And you can see that by sending a message and you see how many replies you get immediately. so very, very focused. Then it also kind of autonomy is kind of building.

You tend to get people that work remotely, tend to be more autonomous and also kind of, you know, manage to unblock themselves and so on. And I think it's like, how do I say it's like, I think it's less talking and more doing. So, you know, nothing beats, you know, making a proof of concept that it's actually working to show your product idea.

So you will see there is a lot of demos, there's a lot of trying, design engineering. 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. And in terms of the challenges, I would say, so the thing about linear, we kind of fix issues when they come. So there's nothing burning right now because we fixed a lot of them.

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. And, yeah, I mean, also, like, being face-to-face is just you build that connection easier. But what we do is we focus our, we have a weekly meeting, we focus it on just demoing stuff. Even if you don't have anything to demo it, demo it anyway. demo what you're thinking about building, right? So as much showing as possible, so people get this sense. So even like work in progress things.

Even work in progress things, even a design, even I don't have anything, but I'm thinking of this. It will look like that. You click there and it doesn't matter. It's like it's very important to share things. And then we also meet. We have like two, three off sites per year. And we have this, you know, if you work with somebody on a project, go like, I feel like

working together with a person, you know, just grab a flight, go to city, stay to three days, work together and come back. So we have a lot of stuff. So sounds like it's a healthy mix of, you know, people working focus. When they're there, everyone is turned on and you can count on everyone on the Slack is available unless they're away, you know, for lunch or whatever. And then every now and then you do get that personal connection where you actually get to have a face-to-face, get that bond. And then when you go back, it's still, you know, there's a aura or something that, like, radiates for a while where, you know, you have that sense of belonging or knowing this person. Yes, absolutely. And I think on a personal note here as a manager, I think it's harder for managers to manage remote teams. It just is. It's harder to build that trust, to build that connection, to get a pulse of like how the people is feeling, what troubles them, what motivates them. But ultimately, you know, my job as a manager is not to make my life easier. So I'd really wish that more managers would be

more open to working remotely because it does make people's lives better. Your team, they can focus, they don't have to spend so much time traveling, that allows flexibility. Okay, so let me ask you a bit of a pointed question, but, you know, talking to other managers or you've been interviewing potentially other managers, there is this narrative that engineers will say, oh, return to office is happening because managers like to work important. person or directors or they're just used to it. How much truth do you think there is in that? Because you just said that it is a lot harder as a manager and it's very uncomfortable and you need to do it. Again, I'm just interested in your personal opinion or observations here.

It's hard for me to talk about what other managers think, right? I can talk about myself. When we moved in Uber to being remote as a manager, it was hard. I was exhausted at the end of the day. So I could see how, you know, it'd be like, oh, this is harder for me. Was it the Zoom fatigue? Was it a lot more? A good day was eight Zoom meetings, a bad day was 16. I was just, it took me two hours of like just being a robot after trying to kind of get the grasp back on like, hey, I'm out of work now.

Let me just, you know, enjoy my evening. So I can see how that can be hard before you get used to how to manage your schedule, remote. Yeah. But it sounds like you have a lot of your video calls as well, right? Yes. Yeah, absolutely. So it sounds like you figured out a way or like linear figure out a way to make work a bit more async. Like, async but also real time, just not maybe not like in like face space, video based.

Yeah. It's funny. We even have a thing where like, you want to talk to someone just like huddle them on Slack. You don't need to ask permission. You don't need to set up a meeting. Just click the button. Huddled. And if the person can answer, would great. If they don't, there's absolutely no judgment. Couldn't. It's like going to somebody's task and not being there. It's fine. I feel that would be a lot easier because, again, like this is just putting the manager's hat on. But I also remember when when I looked at my

calendar sometimes the morning, I was just stressed out by how many meetings I had. 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. So yeah, one of the best ways to figure, to understand how you get things in us, let's talk about a specific project that you've recently built. What is something that you've shipped and we could talk about how you build it and turned? Of course. I think one that comes to mind and I enjoyed being there while we build it, is kind of redoing the project page.

So we wanted to have everything that you need to ship a project. Not only as an engineer, but also as a PM. Can you help me understand how you built it, step by step, especially as a software engineer taking part of the project? 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, we already had a sign off from customers or it looks good, and then engineers do maybe an engineering

plan and then build it and ship it. How does it work in your case? Yeah, so we decided as a company that the next thing we are going to focus on is features around planning. And this project was one of the core features of that. But at that point, it had a name, right? Like we knew we wanted to, I think it's called project descriptions, even a misleading name, right? We knew we wanted to do something different with the project page. So we started from that.

We said, okay, on the product side, we talked to customers, trying to get a sense of kind of what are their flows. It's always good to look at how customers use the product and kind of figure out the problems that they have rather than the solutions that they ask for. So we build that understanding and then we go like, okay, we're building this. So we got a team together. Teams in line are quite fluent. We create them for a project and then we dissolve them and so on. So we created a team. How big of a team was it? So the team was two engineers and then we had product. We had none on the product front and then we had one designer and a customer support person. Awesome. Customer support also on the project team. Yeah. I mean, they know they know best what our

customers are asking for and what kind of issues they are running into what things they want to do and they can't. I love it because like I do remember at Uber we did have every now and then on some projects that an ops person we called ops. They also interface with customer support, but it was very rare. Is it common to have these folks on projects? Most of the projects that are larger in scope have a person from customer support. Awesome. So you had the project team and then what did they do or how did engineers get involved in the beginning of this project?

So we basically have a kickoff with the team. A product came in with kind of what is the goal, what we want to achieve, showed us some interviews that we had with customers. kind of just drew out kind of what would be a possible solution for that, but very, very high level. And then as engineers are talking to customers often and that 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. And it was just an open discussion of what we could be building, right, rather than this is what you're building and, you know, now technically scope it.

And then, if I remember correctly, the discussion didn't really end with a conclusion. It was like, okay, like it feels like we need to think about it. Let's just meet in whatever, three days, right? Whatever feels right? So then we meet again. And now on the product front, you know, a bit more thinking went into it based on the questions that were in that meeting on the design front. I remember design and engineering kind of started hacking on some designs together and

doing a proof of concept. And then we showed it what I was saying before, right? Nothing beats showing a work thing, right? And then again, we discussed it. Like, okay, this didn't feel right and that didn't feel right. And it's like, okay, cool. Again, again, right? And actually, this was a quite complex project, especially because of the, of the

UX. Like, 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. So actually, I don't remember, but we had multiple, like probably two, three iterations of the design that to, to, you know, to make it feel right. And we keep on doing these meetings that at the point feel like,

we're not kind of, like we're doing a lot of things, but not really moving forward, but then at the point, it just kind of clicks. And I've seen this in a lot of complex projects. You know, you do iteration, iteration in the moment, oh, my God, this feels good. And everybody in the team just gets it like, this feels right. So just to understand, because, again, this doesn't feel all too typical. Yeah.

You get together in a room, engineers, a customer support, product. you talk about a people show what they're thinking and then you don't really reach a conclusion but you know you've made some progress and then people go away and then they they build some stuff so engineers will will build some prototypes product will do mockups or or other like you know they'll do some structure thinking and then you come back and you have more structured things and and you have more interaction in that discussion is the am i visioning it pretty much it's it's pretty much talk, do, show, talk again. Right?

And it's like just doing this iteration while things actually get built. Yeah. Right. But sometimes there is a fairly big shift in the way we approach the product. But this feels very different from what we did at Uber, for example, right? Because we had a very strict process. We had a product requirements document, the PRD, where product managers worked on it. Sometimes they involved engineering.

But in the end, it was a specification. Here's what we're going to build. and it had the designs and it had and then injuring went and you know we iterated on we did engineering planning but it was compared to what you said it was very stiff yeah yeah having done both of this how do you feel these two approaches compare uh i mean i mean i i think well it's different right because in uber it's such a it's such a big company we're talking like over two um factors of magnitude bigger than linear, right? So it's very hard for any one person to keep all of Uber in mind and be able to, you know, to be creative as they iterate. So I think this works very well for

linear right now at the size that we have. We hope we can keep this for as long as possible, but it does. It's so interesting to see how every persona that uses linear is represented in that chat, right? It's one thing that I want as an engineering manager, PM wants another thing. Engineers want another thing and then we talk how we make a product that it feels good for all of us. 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. Okay. So once you came together and like it felt good. At that point, you had some engineering had some prototypes, right? Yeah. Was it some forks of the, of your code? Did they fork the code base and just do some changes there? No, I think we, I'm trying to

remember in this project, what we usually do is like we try something and then we review it, and then if we don't like it, we adjust it. It's not like completely separate prototypes. We just kind of increment on each of them. And some of them may be quite different in between them, but ultimately there's always like one code base in which we write this. And very often, this is, you know, merging into Mester. This is available for internal folks, right? So people in the company can try it even when it's just... So you put it behind a feature flag, for example? It could be under... It is under a feature flag. And sometimes we decide to roll out that feature flag quite early to internal employees or not.

We have a developer console and we can just easily turn it on and we can start playing. So in this case, the engineers were building behind one or a couple of feature flags. And on the demos you were showing this off or on a branch, I mean, it's all the same thing, right, until you merge it back. And then, okay, what happened at the point where like, okay, this feels good, everyone's happy, product is happy, engineering is happy, let's ship this. was there any additional work in terms of, you know, productization, getting, I'm sure there's, there might be some additional things or stage rollouts or what happens done? So once it clicks, the immediate focus is like how can we discope this to the core of what the value proposition is.

So then we become really like before we were very exploratory and talking out, we become really, really focused, right? And then the discussions become of like how we can make it even simpler, right? So we do that and then we try to get it as fast out there. to be, you know, for people to use it. May it be employees than beta customers that probably we talked to them before and we know that they would enjoy to try a feature like this. We found it like our customers are so nice in kind of giving us the time to try

these features out and giving us feedback and we appreciate it a lot and that's how we, that's how we are building a good product. So is it safe to say if I kind of use, you know, like, like more kind of common terms that you're doing a kind of a stage rollout of the feature. You're or your dog food. Well, it sounds like you're dock fooding it. You're getting into some beta users. You're getting product feedback and you're making changes.

Or I'm guessing you're fixing buck because we have a zero buck policy. Yeah. Yeah, we're fixing bugs, of course, and doing changes based on the feedback that comes in. And then at the point, we, yeah, when it feels good enough, we set milestones sometimes, right? like what does it take to, you know, you have a beta milestone and then you have a general audience milestone. Yeah, conveniently linear supports milestones, right? Yeah.

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? Is it just a matter of we'll release it to everyone? Do you have additional testing or feature flags or your quality focus? Yeah, I mean, most of the time we release. So we don't have any AB testing. And I mean, there are some cases in which we do incremental rollout to GA, but most of the time we just release it.

So we start with beta. And then when we decide it's good enough for GA, we just release it. And sometimes we have a marketing campaign as we release it. Sometimes we release it, you know, a few weeks before the marketing campaign. So people already start using it. And from an engineer's perspective, now that the project gets shipped, is there kind of a wrap-off of a project or just like how it was a little bit kind of less structured, people just move on to the next one.

Or do you say like, all right, we're wrapping this up and, you know, we'll do a retrospective or a celebration or whatever that is? Yeah. So we put projects once we release them to GA, there will be feedback that comes in. So we do not end the project until what we consider the bulk of the feedback is addressed. The way we see it is like, can we leave the project untouched for a year? like do we feel comfortable that this will run for a year or even two depending on the project right and if we don't feel like that's you know that that that's there yet then we'll spend more time

and eventually it just ends up in maintenance so we have a maintenance status for the for the projects so once issues come in there you know we fix them but also projects kind of give birth to me follow-up projects right so sometimes you go like okay this piece of feedback i think this is a like a whole new part of the product that we need to build so the follow-up to a big project like this one can be a smaller project that we plan for and ship. That makes sense. And how long, 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? I'm trying to remember, I think, but months, probably, I want to say four months, something like

that, yeah, to get it in the hands of the customers. And this was one of the bigger ones. Yeah. How do, so we talked about this specific project, but in general, like, you. You're involved in a lot of engineering projects. In general, how do projects run? How typical or atypical was this project to how features are usually built or even new products built in linear?

Yeah. I think it was pretty typical for a more complex project. So sounds like it's very small teams, not just engineering, but working with non-engineering folks. And dare I say, not much structure? Did I feel that correctly? Yeah, not much structure. Like we started off by not having structure at all. Now we are a little bit more diligent about the phases of the release.

And kind of we just want to make sure that kind of the people that should look at it before releasing it actually are looking at it. But again, it's a judgment call. It's not like you need to, you know, this is the person and then you go to this person. It's just like we ask ourselves like, who should see this, right? Like who feels like maybe they, you know that they have a strong opinion there, for example. Or they, you know that they may disagree with the approach, right? So I just want to bring those people in. This episode is brought to you by Work OS.

If you're building a SaaS app, at some point your customers will start asking for enterprise features like Sammel authentication, skin provisioning, and fine-grade authorization. That's where Work OS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand, and you can ship quickly and get back to building other features.

WorkOS also provides a free user management solution called OffKit for up to one million-month active users. It's a drop-in replacement for all the zero and come standard with useful features like domain verification, rule-based access control, bot protection, and MFA. It's powered by Radix components, which means zero compromises in design. You get limited as customizations as well as modular templates designed for quick integrations. Today, hundreds of fast-growing startups are powered by WorkOS,

including ones you probably know, like Cursor, Versal, and Perplexity. Check it out at Workoos.com to learn more. That is WorkOS.com. So this lack of structure is very unusual. Why do you think you can kind of get away with it at linear? I'm trying to get to the difference that you can run like this, but most teams or even companies would struggle. Like they would crash and burn, I'm pretty sure.

Yeah, I mean, you can't underestimate the difference that it makes for being still a startup and a fairly small team. that, as I said before, that takes away a lot of the challenges. But ultimately, I think it really comes down to the people that we hire. So people are really passionate, all of us are really passionate in product, building a great product, unblocking ourselves, moving things forward. So when people are driven, you can rely more on their best judgment, and you don't need to set so much process.

Things just, I remember actually, to give a concrete example, I remember when I joined Linear after maybe a month, I was like, how is this company working? Like, I remember, I was like, we don't have any phases of a project. So I just put a document, right? It's like to kind of, okay, it seems like these are the phases of the project. Let's just put it somewhere, right? And I got a lot.

Thomas was like, yeah, no. I don't want to see. You're saying, like, I don't like the circles. right like the circles with the bubbles of like phases right yeah because that's what we did at uber right like you and me we i think we some of it we did it together we came up with the way to visualize project status when we sent it out to sometimes dozens of business stakeholders like sometimes legal teams and everyone what the status is 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 so and thomas also came from

uber so he also had this working style so sounds like both you and him just completely the 180 flip in, I guess, thanks to just a different, completely different environment. Yeah, absolutely. And I don't want to make it sound like there's no process. There is process. It's just the preference of creativity over process and more like acting or talking in principles rather than, you know, guidebooks. I think that that's the, but we do have like, if you think of, like, we're not going to be creative when it comes to how you react to an incident. For example, So we have a very, very clear process with like bullet points of everything that needs to be done. 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, like, coming from Uber, you know, I have quite a bit of experiences. Like we were, you know, being successful in Uber meant that you can get a lot of people aligned on the way we build a thing. So. Yeah. And we remember, like, you know, there are things that are no jokes, like reliability, downtime, that can actually. really damage a company. Yeah, absolutely. 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 you actually, your goal is creativity to create things that customers want, but they might not even know themselves. You kind of try to get the rigid process out of the way or, you know, 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. you're getting perhaps you might be iterating faster or getting to the things that you were hoping faster. Is that a fair summary? Yeah, I think the goal is the goal is not faster. I don't think we like,

as we go through the projects, we don't talk about like how fast can we get this out. The goal is always like building something that that makes sense, that feels good. So I think that that's that's the focus. And yes, I think creativity helps a lot if you want to achieve that goal. Awesome. So let's talk a little bit about how different it is to work at linear, a startup still moving very quickly, a lot smaller team and also full remote, versus working at a large company like Uber, where UME worked. And maybe to start, we talked about a project that was pretty typical at linear. Maybe let's talk about a project 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 code name Helix. And it's a pretty good representation of how Uber worked, which is the first project you and me worked together on, which was code name Helix. happened to be rewriting the whole Uber application, both iOS and Android from scratch. And you were on the Android side of things, right? Yes. 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 writer app on Android and iOS with a new architecture, with a new programming language on iOS, with a new payment's framework. work for us. New payments for it. We also, yeah, everything was, we all came up with it on the fly, right? Like in a few months' time. Yes, exactly.

And, I mean, the app is like core to the business of Uber, you know. So by that time, I think I did the math. We did about a billion, I think it was like $2 billion run rate per month between the two apps, so about 50-50 Android and iOS. It's like a billion dollar on the line in terms of revenue per month. Yeah, exactly. And then to sum it all up, We'll do it in two and a half months.

Yeah. And that's when I joined Uber. You were there a little bit earlier, though. So you saw this whole thing start. I wasn't there at the start. So like how typical or atypical was that project, even at Uber standards? I mean, it was, it was big. It was big the project.

But here's the thing. It wasn't shocking in terms of how daring it was. Like it was right there with, you know, big bold bets. Go for it. So it didn't feel atypical for the culture in Uber. At the time. We can do it. Yeah.

And it was like, I remember the deadline specifically. I don't think almost anyone in the engineering team in Uber thought that that is an actual deadline. I think it was so aggressive that if we thought that it's like a directional one, right? Like it would be great if you can do it in two and a half months. Yeah. So if I'm not mistaken, the project started in June, right? June 2016-ish in the summer.

I think some teams, the platform teams were working earlier on the architecture. And then our deadline was internal deadline was something September 16th or so to get the to ship the app for beta users. And our ultimate release date was, I think, second of November. And in the end, I think we did hit the second of November, right? Yeah, I think so. I don't know why I remember because this is like three, four months. I remember it was even shorter.

Maybe it was a thing of like in how much time we need to be internally kind of feeling good about it and then you have the productionization phase and everything that took you to the business. I think we might have 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. So I think we internally there was like a lot of sure that there was like late July, early August, that kind of stuff. Yeah.

Yeah. It was cool. It was like so the the daringness of the of the of the goal was like was like one thing that that I remember. And it's also the, we did a lot of work. Like, we had to work really long hours,

but the kind of the resilience that, that build and the friendship, that friendships that last to this day, I think that's another thing that I, like I would go back in time. I would do it again, 100%. It was an absolute pressure cooker.

And, you know, 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 decks. So anyone who did Android or iOS,

Uber was on it, which was a few hundred engineers. I don't know exactly, but maybe 200 or so. And then even people who didn't do iOS or Android were pulled in often to do what when I joined. I was supposed to join as a back-in engineer. And I was asked to be an Android engineer because of this project because we were low on Android. It was, and then we had a few backend engineers. I think we realized midway that, oh, we actually need backend engineers for all these new mobile endpoints. But it was a really real. And actually, that's where, like you and me, got to work really really close together we spent what two weeks or three weeks in san francisco i think we spent six weeks and you probably were there for most of that time as well i think three or

four weeks i i went to my uber uberversity the introduction course and i never did it we just worked on this project yeah yeah just long nights pouring through it it was cool it was cool it was like it just proved like if you get a lot of people motivated like how many things you can you can achieve it's it's definitely not sustainable like you can't work like that but that was in uber that was the number one most difficult thing we ever built but but this was a you know really different right because this was i think this was probably one of the last like truly company-wide startup modes or almost it felt like war time where almost felt like we had existential existential threat even though you know there was nothing existential about it.

But afterwards, two years later, we had, or one and a half years later, we rolled the driver app, which was similar in scope. But that one took, I think 18 months. It was a lot more. It had all the deadlines, all the formalities. It was like the opposite of this project. So I feel the company also changed later on. Absolutely.

But speaking of your, you were at you prefer, how many years? Seven years. Seven years. Seven years. And you saw it go from a more scrappy scale up to a lot more structured company. What are things that you now do very differently at linear than you did at Uber? Yeah. 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. So that takes a big part of the day. And that is not a problem at linear. So then we can use that time for other things. And focusing on being much closer to customers, for example, is one of them. It's very hard to be close to customers, especially if you think, like, Uber from the rider perspective, you have millions of, of, you have millions of,

users, right? So it's much harder to get so many thousands of engineers to be that close to to the customers, whether in linear you can do that. Yeah, I think they are mostly challenges that have to do with, the differences come from challenges that have to do with the difference in the size of the company. And I guess, you know, do you think email fits into this thing as well? You know, just loft your emails or is that more of a just completely different communication style. I mean, definitely email as well. Yeah, definitely email as well, right. It would be hard to imagine like having everything decided in group chats at Uber with so many stakeholders. Yeah, we use the email for a lot of like status checks, getting people on the same page,

sending out proposals. In fact, we even had a, we had a fire hose. Remember, we could subscribe to a couple of email lists where we could have the RFCs, request for comments for people have to send it there and every day there will be like 10 or 20 RFCs going out which is teams maybe not maybe not every day it's 120 but every week at least 20 of new project that will be started off in a given domain may that be mobile or back end or somewhere else just a very different scale so you work at a senior engineer at Uber and you hire senior engineers there at linear you work with a lot of senior engineers you also hire them how do you see a senior engineer

work differently at a large company like Uber versus at linear. Yeah. So I think there are a few things. 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. Taking meetings, awesome. So it's like video calls with customers. Yeah, video calls with customers.

Yeah, quite often, actually, especially when we build a bigger project. And, yeah, I think those are. the two big, the two big differences. And in terms of skill set, motivation, or mentality, did you see any real differences or not necessarily? Of course, of course. Definitely on the motivation front. I think in linear, the biggest motivation that people have is kind of what the customer

feedback that comes from building the products that they do. the you know writing a nice RFC or designing a super scalable architecture writing elegant code those are just means to build a good product those are not the goals and it's not like there's a complete mentality shift between right like you you have a lot of our engineers come from bigger tech companies yeah but it's just in a big tech company it's much more you know it's you know it's 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 performance. And it kind of, in a way, I think it's needed, but it definitely does distract you from why you are there.

Yeah, we talked about this by the way before this, right, on how even while we were there, how Uber changed. You were there for seven years, so you saw it even longer than I did, 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. Oh, let me try to find a cross-functional project because it might help me get promoted, it as opposed to some engineers were getting frustrated who were building really important stuff for the business and there weren't necessarily being recognized. It was just interesting.

And it wasn't sudden, right? It was very, very slow. Yeah. And it wasn't for everyone, right? But it was for the majority of people after a while. Yeah, I remember when I joined Uber, we still had like meetings with drivers. Like we would have the drivers coming in and you could, if you wanted to, you could go even as an engineer and like kind of listen to those interviews.

Yeah, but by the time I started, I'm not sure I remember having that. 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. And the further away you go, the more you optimize for what you think is important for you, for your team. But I remember when you would see drivers chatting on how they use the app, especially for payments and kind of 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 felt natural to me. But yeah. And speaking of what engineers care about, especially senior engineers care about, at large companies, levels are important in career progression. At linear, do you even have levels?

Do you have titles? We don't. We don't. Everybody's an engineer. And as someone, again, you're an engineer manager. You helped a lot of people get promoted. you were promoted yourself. How do you feel this thing changes things or it doesn't?

Well, I think, again, it keeps the focus on what you are building and what the goal for the company is, which is building a great product. I think that that's what helps the most. In terms of what happens is, like, it's very easy. I remember when we had the rubric introduced for the performance and competencies in Uber. Yeah. Right. It started off like, 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. They actually did a good job mapping the type of things that are expected of us and that we do every day, right, to a process that allows you to get a promotion. And with every promo cycle passing, the rubric became the goal. Yeah. It's just natural. It happens.

So when you don't have all of that, then you can focus. And it's, you know, it's one thing, promos are one thing, but growth is another, right? And there is a lot of growth in linear, but again, we think different about it. It's not, you don't grow to get a promotion. You grow to be able to, like, the product is becoming harder and harder to be like, allowing customers that are 10, 20 times the size of linear to use, to use, you know, and you can't, linear, right? It's a challenge. You know, you're not used to, it's not instinctive to you, like what you need to build as an engineer. And being able to keep that product simple as you

scale it up, that is like a continuous challenge that becomes more and more difficult. And for you to achieve it and to like smoothly shift these products, ship these products, you need to grow. So it's kind of growth with the company. Yeah. It sounds like a lot of things that you're doing at linear and why say you, I also mean the whole company. It's trying to push back on how a large tank tap company eventually when it becomes thousands of people will operate, both by staying small, but also it sounds like pretty mindful of what you don't want to do, or at least not just yet. You know, one day, one linear, if you stay the successful for another 10, 20 years, I'm sure at some point you'll, you'll have some

levels. Although Netflix is a very interesting example where Netflix had the senior engineer level for 25 years. They just got rid of it, I think. They just changed it to have other levels. But they did it for 25 years, and a large part of that was a publicly traded company. So I guess there's examples of polling that. Who knows, you might be able to do it longer. You are an engineering manager, both at Uber and at linear.

How did it to compare? 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. If you think of things like having a promo, the super complex perv process with all the competencies, alignment between different teams, dependencies between teams, and all of that, you know, budgets, reporting, justifying why your team needs to be there.

Are you sure that will just 40%? It's not like 70%. Probably more. Yeah, it's just not needed. It's not needed in linear. So the first thing, once I realized that the first thing I was, like, well, so I'm still paid full salary, right? Like, what do I do with 40% of my time, right?

And it amuses me, like, every now and then I ask Thomas, like, hey, how am I doing? You know, give me some feedback as my manager, right? Thomas is one of the founders. And he says, it's like, well, tell me, what have you done to make linear, like a better product? I'm like, it's not an easy question sometimes, especially as the work that you do is kind of indirect, but I think it's a really good question, right? So I found myself, you know, like I think I was.

the defecto data sent is for linear for a couple of months before we hire someone, just writing queries all day. And I really enjoyed it because I felt like it helped, right? Definitely much more involved in product than I was in Uber, taking some customer interviews, you know, reaching out to customers to understand kind of what they need, you know, even in bulk sometimes. Like once I wrote 100 emails, I intentionally didn't want to use a tool, right? I was like just, just, you know, trying to communicate with people. and yeah, all kinds of things like that. And plus, of course, the normal things that you do as a manager.

Like you will have the focus on people. You'll have the one-on-ones. 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. So doing all of that as well, plus all the kind of the process related stuff. One thing that I noticed with linear is you hire experience engineers.

And, you know, places like Uber, we had interns, we had new grads, we had Eng ones. Eng twos who are like still earlier career. And as a manager, we did spend time helping them, giving them feedback. And also, of course, onboarding not just them but other engineers. But how is that change of not having or do you have less experienced engineers there? And if not, does this change how you work as a manager? Yeah, it definitely does.

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 a, okay, it's okay, right? It's like a soft yes, maybe a yes, right? It's always the question is, what does this person have that stands out, things that we admire that we learn from? So almost everybody that we hired, like impressed us in a way, right? So it's not that much in terms of, I don't look at it as, oh, this person has, you know, less experience, therefore I will help them. What I find is that there are, people are just generally very good. And whenever I give feedback to them, it's, you know, it's, it's, it's quite specific and it's much less than in Uber.

You know, I remember in Uber it was this moments where they're like, oh, you need to find three things for the person to improve. Yeah. It was a mandate of 2016, then 17. Exactly. I mean, to a certain extent, I understand where it comes from, but I think I don't think in those terms now anymore. I'm just, I'm there for all the product meetings, at least everything that we ship in you, I can see people every day, how they work. And very rarely, I find a thing that I think, you know, it's worth discussing about and giving some feedback. And, you know, when people go like, you know, you're right, I haven't thought of this,

or like it ends up in a discussion, there's so much more, like, you feel so good about it. It's so much more rewarding when you can find, even though they're 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. Yeah, but I really like how the goal, at least from Thomas, one of the co-founders, is, you know, the goal of your measurement of your success is have you made linear a better product? Yeah, yeah.

Which I think quite few managers can say that this is what their manager asks of them. Yeah, which is just really cool. What is it useful learning from a large company like Uber that has helped you and still helps you to this day at linear? I mean, you get to work with a lot of people. You get to know a lot of people and different personalities, different motivations. I wouldn't underestimate how much, how many learnings that gives you as a manager.

And are you talking about how, like, for example, at Uber, like we were exposed to a lot of different people, teams, conflicts? Yeah, yeah. Like, you just build that solid foundation that makes you feel when you're in a smaller company, it makes you feel like whatever happens, especially when it comes to people you have seen already. So not so many surprises, I would say. I think that helped me a lot. And also just think big, you can achieve big things.

I think Uber taught all of us that, you know, the big potpets part. Let's wrap up with some rapid questions. Of course. Let's do it. What's your favorite sport and why? scuba diving. I do a lot of it. Cheapest way to experience zero gravity.

Nice. And sometimes when you're working full remote, right? Do you sometimes combine work and vacation? Sometimes yes. I would stay more in a place and stay three weeks, two of them you work, and then one week you take off. I think with scuba diving is particularly hard because after a dive, you're, you know, there's a lot of nitrogen in your bloodstream, so you're a little bit woozy. woozy. I wouldn't work after diving. Nice. 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? As an

engineer 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. It's just this being proud of your team, of the people in the team of what they achieved. I think nothing really beats that. And as an engineer building. No hesitation. Just building. Yeah, I miss that, actually. Do you get to build a little bit or not as much?

Very little. In linear, in linear very little. I do build at home. I build stuff. I think I've been building for so many years, things that have to do with, like, products for customers. I just want to go home and build a robot that doesn't do anything. Just wobbles around the apartment.

Love it. And finally, what's a movie that you recommend watching or that you enjoyed? Yeah, I mean, probably everybody saw it. But I'm really passionate in astronomy. I do astro photography and stuff. So interstellar for me was great. It's an awesome movie. Awesome, Sabin.

Thanks all for being here. Thank you so much for inviting me. I really enjoyed the time. If you enjoy this podcast, please do subscribe on your favorite podcast platform and on YouTube. And if you're interested in reading more about Lunar's engineering culture, check out the deep dives into Pragmatic Engineer that goes into additional details linked in the show notes below. Thanks and see you in the next one.