Linear: move fast with little process (with first Engineering Manager Sabin Roman)

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 but 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 customer so the first goal for the ho 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 was like okay it's fixed deployed and I'm wow i' haven't seen that Subban Roman is the first engineering manager at linear 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 unique design snpp 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 functionality within linear comparing how a large company like uber Works where is a small one like linear as an interesting fact Sabin worked at Uber before linear and so did linear's co-founder and CTO thas 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 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've started your career as a backend engineer uh you did Java you then worked at Orange uh telecommunications company and then later you and me we worked together at Uber you start you were already an Android engineer a senior Android engineer when I joined Uber uh we worked together I was also 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 lunir yeah we have two engineering managers now oh we have two engine managers awesome but you're you're still the first one yes you 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 and writing a bunch of them obviously how many emails have you sent the past three months at linear I I don't know I think I want to say 2030 or something like that maybe less yeah but like like you told me like you use email very little at at we basically don't 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 um and we generally use email when we want to talk to some of our customers and um you know some of the tools that we use may require reaching out to support then we may write an email but not for internal work so what are you use instead well we pretty much we use slack and linear slack and linear so is and like the interesting thing is like I understand Slack for like you know the the real-time communication you need to Pink someone but my understanding of email was you know maybe there's a bit of an outdated understanding but is great for like acing stuff when you don't want people to respond immediately what about those kind type of you know requests I I think in linear we we tend to you know ask people for help when we really need the help um so a lot of the things if I would write to people that you know we answer quite quite fast um and I mean there there can be things that need to be followed up but then you know we have linear for that as well so are you using linear for more the kind of long-term of storage of stuff that needs to be you know structured or or searchable yeah absolutely so for example if you have a um a question on a on a project that you're building right you may decide you know that question is urgent in which case you you ask it you can ask it in a group chat and people will answer really really fast or you can ask certain like a person directly um or you may be like well 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 um so you will um or or you can go in linear and you can ask u a question on the on the project directly you can leave a comment or you can post a project update and you know there can be questions Associated to that okay so so this is just a really drastic change and I 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 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 like your your day started with emails my my day started with emails yeah um I remember sending the first email in in linear um I think it it it it was I don't know I I saw something interesting and I wanted I think the marketing the to to to see it um and uh yeah and uh you know I had to write on on slack that I send them an email this episode was brought to you by launch darkley when releasing software bad Ship Happens bugs are inevitable but they don't need to become disasters launch Darker reduces the risk of releasing software giving developers the confidence to shift faster through Progressive releases proactive monitoring targeting and roll backs with launch darkley you can find and fix bugs automatically do you know how risky your software releases are take launch dark's 2-minute risk assessment to find out go to launchd dark.com risk- meeter that's launch dark.com risk- meter this episode is brought to you by Savala it's a true heru alternative where you can deploy applications manage databases and whole static size for free Savala is a platform designed for teams with is review and pipeline features developers can collaborate on any stack while being assured of the security of their workloads from staging to production SE holds all the major security certifications companies are typically looking for their application hosting offers automatic G 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 documentations sites and more it also includes preview deployments for easier iterations and seamless teamwork seel features an easy to use interface on limited seats no hidden tricks and transparent usage based pricing with Enterprise level cloudfare dos protection for workflows of any size sign up and deploy today go to seal.com that is seala with a l.com let's set a little context on linear because I think we all know that it's a uh it's a tool that you can get things done get projects done track track statuses but talking specifically about the the company itself can we kind of you know help imagine us what what this place is like how many people work there for example of course um I I actually checked before the podcast to make sure I'm I'm right we are over 60 people now over 60 people and four or five years old the company founded is yeah yeah I think uh I don't remember I think five six years old yeah so 60 people what kind of Technologies do you use inside a company yeah so in terms of engineering we we use typescript react node um gcp POG gra graphql that that next deack for a long time you had no product managers at the company yeah do you have product managers now we do we do we have we have two product managers now awesome so two engine managers two product managers yes and 25 engineers and the product team including design and product um is about almost 40 people but what but when you joined there were no product managers right no so H how did this time work like cuz again like coming from a more I guess traditional Tech setup you're kind of used to like okay we have an engineering team they have a product manager they have an engineering manager and you didn't have that uh how did the engineering team operate or or who filled you know the the product um role of like what should we build why should we build it I think everybody did everybody did so um linear started off as um you know building an issue tracker um for startups that was the goal um initially the the vision of the company was always bigger and we are we are now kind of achieving more and more of that Vision but um the founders wanted to start with a with a very simple concept and with some principles around quality around the way you should build a product um and test it out and see if it works so um for being ourselves a small company you 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 um and then yeah in intuition helped a lot and and when you say close to customers what what does that mean you you paying people using it or they paying you like on a slack Channel or on a linear or somewhere yes um absolutely so we um um I think the um from the engineering perspective the the the most contact they have with customers is um through slack channels support slack channels we also have um what we call a goalie rotation um it's a triage feature in in linear so basically we have so a go goalie as in like the goalie who keeping the goalkeeper exactly okay tell me about that yeah so um we have now two Engineers on that rotation every week it's different Engineers um and basically the the goal of the of the goalie is to address all incoming reports from customers may may be bugs may be some you know small quality things that don't make sense um so the first goal for the h is to go through all of those requests and and see if uh you know if they can reproduce them and right and if they have time then they would actually fix those issues as well during during the week or assign them to the right person but as they do this they are also active on all the support channels um so for example we we had cases is one that I really loved seeing it was at the beginning when I joined linear the first time I saw this I was like wow um a customer wrote about um a bug in the in the product and the engineer was like oh I'm looking at it and then like an hour two hours later was like okay it's fixed deployed and wow i' haven't seen that yeah like like I I I Feel Like This Is The Stuff where you hear it at startups and I remember when you know when we were at Uber uh we had something similar right we we called it uh support engineer yes right and and I think what some teams did at least my team did it and some point we 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 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 desk but the frustrating part there was like as a support enger 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 cuz it was you know we were in the payments team and it looked like a payments bug but actually was a fraud bug and the fra team was a very different team so we we created a ticket and we escalated it or we put it in their support group and it just kind of went away you went off your support rotation and things just didn't really get fixed so like you were in that you know you 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 or more Nimble I mean um being I mean being smaller is is generally takes a lot of complexities away from being in a you know 10,000 20,000 people company um but how how does this work so I think there are few 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 a abstract bug that came from someone and that was probably trash multiple times before and now you kind of have to do it it it it is 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 of your work so that 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 in the team in the linear team either the US side or the EU side that you think you know has the 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 um so on top of the goalie rotation we have a zero bu policy oh interesting yeah very ambitious yes and I mean I can I can show you how many bugs we have opened right now so basically the idea is okay so like is it like more than 10 or less than 10 um it is so the the um official SLA is a week to fix it and just that's because like 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 yeah wow yeah so what happens is that every morning uh come to work you know instead of doing email you fix all the issues that you have and then you have time for the for the for for the product work I mean I I like how this sounds it sounds very utopian but you're actually telling me that it works I mean it it started from like it it it can work like 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 um but the I think the the principle behind it is it when you're building a new product you're building something that the customer hasn't seen yet y prioritizing that over something that the customer uses and doesn't work doesn't make much sense does it mhm right and it's not a zero sum game either right it's not the you can say yeah it takes the same amount of time yes but the customer is much happier if if the bug is fixed sooner and also we have like a lot of things in linear are based on on best Judgment of people you can look at a bug and 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 right I'm not I'm just not going to fix it it's fine so you can rather than saying I put it in the backlog you just go one do we have a status one do that's what it is for right so we do that as well um and we do reviews every week of of the slas for the bugs and our goal is that every person has maximum like two issues roughly because that's normal right they are the ongoing ones and we've been running this for months now and it's still working I was surprised I was I thought that this 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 2 and a half issues per week per person like once you average it out that's not you know 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 um and yeah it's it's it's still working I'm really happy with it just play Devil's Advocate I remember again comparing with 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 we we knew like we had a massive bug list slash feature request is 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 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 you know months sometimes to build but we we were balancing and said well look it we would throttle ourself if we didn't grow growth was very important so my question here is like do you think that focusing on on bugs would slow 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 um I think theoretically it does slow down and if you objectiv you think if we wouldn't fix any bug then we will be more products but I think in reality we don't feel it as much and we also it's really fundamental like through through a lot of decisions that linear made throughout the years um focusing on on on you know 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 like a who has more features competition with with other companies it's not we don't think that that's the the right way to approach it that's an interesting one cuz I I I wonder if this thinking is a lot more valid because just to be fair you know Linear by the time linear L Issue tracker we had a lot of issue trackers right there 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 if as a more General takeaway we could say that when you're answering about the crowded Market if you don't do quality you you might as well just give up cuz again like you're on features is a 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 I really like to hear this it's it's 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 uh some other 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 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 hiring process starts off pretty typical to to tech companies so we have a we have a recruiter phone screen we have a hiring manager call with you with me or Tom in in us and if that goes well um we uh we have two tech technical um um exercises one is coding one is architecture it's it's really nothing abstract algorithms I I 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 um within an hour um 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 it's not the case somebody had to do it in linear before um and if all of that goes well indeed we move to to the work trial so the work trial it depends on the role you have in linear so um 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 yeah um and um as part of the work trial it's um basically the candidate gets to work with the team for a week as they as if they would have been employed full remote right cuz every full Remote Full remote yeah exactly full remote um we we try to find it's getting harder and harder but we try to find Green Field projects for everyone oh even for the work trial yes even for the work trial it's actually it's you know we have a meeting before and we tried we have a b bunch of ideas but it's an interesting thing because you want to you want to balance out of course like seeing how how the candidate does but you also want to be something interesting something that they can work autonomously so um but we managed to find good projects and I think the best ones are the ones that you know they they build you know we we we decide to move forward the candidate is Happy joins the team and we had a few cases is like this when the candidate as their first project shipped the thing that they buil in the work can can you tell me what that feature was um yes I think it was um the triage responsibility um I think one of our Engineers oh so so when in linear you can assign who who needs to triage this yeah and you can integrate the uh pager Duty uh integration into it so you can kind of automatically the the goalie in our case of the tri it's is the person that you have in the um pageor Duty rotation so so started working on this during the work trial make good progress and then join then finished yes ex awesome yeah I I I love it so you're the hiring manager on the hiring manager call just putting you on the spot here what what does a typical hiring manager call look like someone passes a recruiter screen they're they're now talking with with with with you Sabin uh what do you usually talk about right so um so first of all um when the recruiter has the onone 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 I'm confident then there's no need for a discussion just move forward um and part of the hiring manage I have been redoing a little bit the the storyline if you want of the hiring manager interview I think of what I landed on now is focusing on three things um I focus on the motivations of the candidate um um the things that they like doing what they are excited about it's important because if anything we're very opinionated in linear um and um you know it's important that the type of motivations aligned um and then the the next thing that I would evaluate is product I spent quite a bit of time on on on talking about product with engineers and finally just going through their their experience um tech-wise talking about some of the challenges things they be this on and 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 are interested in product have a product sense or are product minded yeah absolutely how does this change both the hiring and and the day-to-day work because now you know like it sounds like L 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 um yeah absolutely so the it it definitely makes hiring you know not not easy um I um people say that okay we have a high bar in linear and and that's true but I think what makes it really difficult it's a very specific bar and I think the product side of it makes it so specific um we we want people that as you said have a good judgment on product um 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 and showed that they can build a great product yeah and to add all of this you all work full remote right the whole 60 people Everyone is is full remote H 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 uh 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 I I absolutely love it um I think there 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 when I remember when we were in Uber and um we started moving to towards remote work the amount of diffs that people were putting out just when up to to the point where we had discussions at the moment they were like oh W people are kind of working too much so we were afraid of them getting burned out yeah yeah I remember there was this all hands right after Co or a few few months after we went in full lockdown and that's uh on the All Hands cuz both of us were there they showed this stat turns out that there was this internal tool that the office of the CTO or or senior directors on the above could see the number of poll request or as we call them diffs and there was this massive Spike and I think I had two I I had two two reactions one was like oh wow that's really cool second La what they're tracking our polar cast all the time yeah I remember that um yeah I mean so let's split it in what's what's good and what's more challenging so I think the the first the first thing of what's good about it is focus it's it's really focus like we don't do over time or very very rarely but whenever people are there they're truly there um 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 um you you tend to get people that work remotely tend to have a to be more autonomous and also kind of you know manage to unblock themselves and so on and I I think it's it's like how do I say it's like I think it's less talking and more doing um so you know nothing beats uh you know making a proof of concept that it's actually working to to show you know your product idea um so there 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 theoreti about it because if you start theoreti in Zoom meetings one after the other you you lose track quite quite fast M um and in terms of the challenges I I would say so the thing about linear we kind of we fix issues when they come so um there's nothing burning right now because we fixed a lot of them but what what I what I did notice is that it's more challenging to create this um sense of belonging to a team when you don't see them face to face right knowing what people work on um um and yeah I mean also like being face to face is just it's just you build that connection um easier um but what we do is we focus our we have a weekly meeting we 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 get 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 you look it doesn't matter it's like it's very important to to share things and then we also meet we have like two three offs 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 the city stay two three days work together come back so we have a lot of stuff so sounds like it's a healthy mix of you know people working focused one they're everyone is turned on and and you can count on everyone on the slack or is 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 the face to face get that that Bond and then when you go back it's still you know there's a aura or something that like radiates for for a while where you know you have that sense of belonging or knowing this person yes absolutely and I think on a on a personal note here as a manager um I I think it it's harder for managers to manage remote teams it just is um it's harder to you know to 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 my job as a manager is not to make my life easier so I I'd really wish that more managers would be more open to working remotely because it does make people's lives better um your team they can focus they don't have to spend so much time traveling that you know it allows flexibility okay so so let me ask you a bit of a pointed question but you know 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 or they're just used to it how much truth do you think there is in that uh because you just said that it is a lot harder as a manager and it's very uncomfortable and 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 um I can talk about myself when I when we moved in Uber to being um remote as a manager it it was hard I was exhausted at the end of the day so I could see how you know You' be like oh this is is harder for me was it the zoom fatigue was it the the a lot more a good day was eight Zoom meetings a bed day was 16 I I was I was just it took me two hours of like just being a robot after trying to um trying to kind of get the grasp back on like hey I'm out of work now let let me just you know enjoy my evening um so I I I can see how how that can be hard before you get used to how to manage your your schedule remote and um yeah so but sounds like you have a lot fewer video calls as well right yes yeah absolutely so like it sounds like you figured out a way or like lit figur out a way to make work a bit more async uh like async but also real time just not maybe not like in like face based video based yeah it's it's funny we even have a thing where like if you want to talk to someone just like huddle them on slack no you don't need to ask permission you don't need to set up a meeting just click the button huddle you know and if the person can answer great if they don't there's absolutely no 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 I I also remember when when when I looked at my calendar sometimes in the morning I 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 best ways to figure to understand how you get things done is let's talk about a spefic specific project that you've recently built what what what is something that you you've shipped and and we could talk about how you built it and turned of course um I think one one that one that comes to mind and I I enjoyed um I enjoyed being there while we build it um is um kind of redoing the 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 the design they show what to engineering saying here's what we're going to build we already had a sign off from customers or or it looks good and then Engineers do a maybe an engineering plan and then build it and ship it how did it work in your case yeah so we 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 um so we started from that we we said okay um on the on the product side um you know we talk to customers trying to get a sense of kind of what are their flows it's always good to to to look at how customers use the product and kind of figure out the problems that they have rather than the solutions that that they as for so we build that understanding and then we go okay we're building this um so we got a team together we teams in Linea are quite fluent we create them for a project and then we dissolved them and so on so we we created a team um I think how big of a team was it so the the team was um two Engineers um and then we had a product we had none on the product front and then we had um we had one designer um and um 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 the 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 an Ops person we call it Ops they also interface with customer support but it was very rare is is it common to have um these folks on projects most of the projects that are larger in scope have um have a person from customer support yeah awesome so so you had the project team and then what what what did you do or or how did engineers get involved in the beginning of this project so we basically have um had a kickoff with the team um product came in with kind of what what is the goal what we want to achieve um showed us some um some interviews that we we had with with customers and kind of kind of just drew out kind of what would be a possible solution for that but very very high level right um and then as Engineers are 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 um and it was just a open discussion of what we could be building right rather than this is what you're building and you know now technically scope it right and then if I remember correctly the the discussion didn't really end with a conclusion right it was like okay like feels like we need to think about it let's just meet in whatever 3 days right whatever feels right so then meet again and now on the product front you know a bit more thinking went into it for based on the questions that were in that meeting on the on the design front like I I remember um 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 it's nothing beats showing a work thing right and then again we discussing like okay this didn't feel right and that didn't feel right and 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 the 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 I don't remember but we have multiple probably two three iterations of of the design that to to you know to to make it feel right and we keep on doing these meetings that at the point feel like but 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 the moment oh my God this feels good and and everybody in the team just gets it this feels right so just so to understand because again this doesn't feel all too typical yeah you get together in a room Engineers 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 they build some stuff so Engineers will will build some prototypes product will do mockups or or or other like you know they'll they'll do some structured thinking and then you come back and you have more structured things and and and you have more interaction in in that discussion is am 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 the 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 documented PRD where product managers worked on it sometimes they involved engineering but it it was 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 engering went and and you know we iterated on we did engering planning but it was compared to what you said it was very stiff yeah yeah now having done both of this how do you feel these two approaches compare uh uh I mean I mean I I think well it's different right because in Uber it's such a 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 to keep all of uber in mind and be able to you know to be creative as they iterate um so I think this works very well for for linear right now at the size that we have we hope we can keep this for as long as possible but it 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 is 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 want to 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 was it some Forks of the of your code that they Fork the code base and just do some changes there or no I I think we um 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 uh you know merging into Master this is available for internal folks right so so people in the company can try it even when it's just you put it behind a feature flag for example it could be it is under a feature flag and sometimes we decide to roll out that feature flag quite early to internal employees or or not we have a developer console and we can just easily turn it on and we can we can start playing so so in this case uh the engineers were building behind one or or a couple of feature flags as and on the demos you were showing off or or on a branch I mean it's all all the same thing right until you emerge 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 roll outs or what happens then yeah so on once it clicks the immediate focus is like how how can we descope this to the core of what the value proposition is so then we become really like before we were very exploratory and talking now we become really really focused right and then the discussions become of like how we can make it even simpler right um so we do that and then we try to get it as fast out there to be you know for people to use it um May It Be employees um then um beta customers that probably we talked to them before and we know that that they would enjoy to to try a feature like this and we found it like our our customers are are U are so nice in in in kind of giving us the time to try these features out and giving us feedback and we appreciate a lot and that's how we that that's how we are building a a good product so is it safe to say if I kind of use you know like more kind of common terms that you're doing a kind of a stage roll out of the feature you're or or or you're dock food well it sounds like you're dock fooding it you're getting it to some beta users you're you're getting product feedback and you're making changes or I'm guessing you're fixing bug you have a zero bug policy yeah uh yeah we're we're fixing bugs of course and doing ch is based on the feedback that comes in um and then and then at the point we yeah when it feels good enough we set Milestones sometimes right like what what does it take to you know you have a beta Milestone and then you have a general audience Milestone right yeah conveniently linear supports milest 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 release it to everyone do you have additional testing or or feature Flags or your quality Focus yeah I mean most of the time we uh we release so we don't have any AB testing and um I mean there are some cases in which we do incremental roll outs to GA but most of the time we we just release it so we start with beta and then when we decide it's good enough for GA we just release it um and sometimes we have a you know marketing campaign as we release it sometime we release it you know a few weeks before the marketing campaign so people already start start using it and from an engineer's perspective now that the project is shipped is there kind of a wrap up of a project or or just like how it was a little bit kind of uh less structured you people just move on to the next one or or do you say like all right we're wrapping this up and you know we'll we'll do a retrospective or celebration or whatever that is yeah so we put projects once once we release them to G there will be feedback that comes in so we do not end the project until what we consider um the bulk of the feedback is is addressed the way we see it is like can we leave the project untouched for a year like do we 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 maintainance status for the for the projects so once issues come in there um 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 um 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 well months um probably I want to say four months something like that yeah to to get it in the hands of the of the customers and 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 you're involved in a lot of engineering projects in general how do projects run how typical or atypical was this project to how how features are usually built or or even new products built in linear yeah I think it was it was pretty typical for a more complex project so sounds like it's very small teams not just engineering but working with with with non in folks and there 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 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 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 or 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 you just want to bring those people in this episode is brought to you by workos if you're building a SAS app at some point your customers will start asking for Enterprise features like Sam authetication skim provisioning and F green authorization that's where work comes in making it fast and painless ad Enterprise features to your app their apis are easy to understand and you can ship quickly and get back to building other features worko is also provid provid a free user management solution called authkit for up to 1 million monthly active users it's a drop in replacement for OD zero and comes standard with useful features like domain verification role base Access Control bot protection and MFA it's powered by radic components which means zero compromises in design you get Limitless customizations as well as modular templates designed for quick Integrations today hundreds of fast growing startups are powered by work OS including ones you probably know like cursor versel and perplexity check it out at work.com to learn more that is work os.com so this lack of structure is is very unusual why do you think you can kind of get away with it at at linear like the I I'm trying to get to to the 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 the the difference um that it makes for being still a startup and a fairly small team um that that as I said before that takes away a lot of the challenges but ultimately I I think it it yeah it really comes down to to to the people that we hire um so people are are really passionate all of all of us are really passionate in in in product building building a great product unblocking ourselves moving things forward right so when you when people are driven you can you can rely you know more on their on their on their best judgment and you don't need to set so much process things just I I remember actually give you 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 put a document right it's like to 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 l Thomas was like yeah no with no I I don't want to see you was saying like I I don't like the circles right like the circles with the bubbles of like phases right yeah cuz that that's what we at Uber right like like you and me we we I think we some of we did it together we came up with a way to visualize project status when we sent it out to sometimes dozens of business stakeholders like sometimes legal teams and everyone what the St 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 work working yourself so sounds like both you and him just completely did a 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 there is process it's just a preference of creativity over process and more like acting or talking in principles rather than you know guide books um I 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 any incident for example so we have 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 to to lead that one or most of them just because I 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 um yeah and and and remember like you know there are things that are are no jokes like reliability downtime that can actually really damage a company yeah absolutely so what I'm what I'm hearing is for things where it really matters and 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 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 sounds s like it's kind of working you're getting perhaps you might be iterating faster getting to the things that you were hoping faster is that a fair summary yeah I think the the goal is the goal is not faster I 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 that um so I 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 a startup still moving very quickly a lot smaller team and also full remote versus working at a large company like uber where you and me worked and and maybe to to start we talked about a project that was pretty typical at at linear maybe let's talk about a project that was maybe the most TP not the most typical but it it was a pretty good rep representation of how Uber worked which is the first project you and me worked together on which was cold named Helix and it happened to be rewriting the whole Uber application both IOS and Android from scratch uh and you were on the Android side of things right yes um ah there's so many things to talk about that but I think like if I have to pick like the two three things that really stood out for me in that project is the 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 payments frame workk for us new payment frame 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 so by that time I think I did the math we did about a billion I think it was like2 billion run rate per month between the two apps so about 50/50 Android and iOS so like a billion dollar on the line in terms of Revenue per month yeah exactly and then to to sum it all up we'll do it in two and a half months yep and that's when I joined Uber you were there a little bit earlier though so so you saw this whole thing start I I wasn't there at the start so like how typical or atypical was that project even at Uber standards I mean it it was I I 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 Bal bats go for it right so it didn't feel atypical for the culture in Uber we can do it yeah and it was like I remember the 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 is 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 if I'm not mistaken the project started in June right June 2016 ish right in in the summer I think some teams the platform teams were working earlier on on the AR architecture and then our deadline was internal deadline was something September 16th or so to get the to to ship the app for beta users and our ultimate release date was I think 2nd 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 shter 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 productionize and everything that took you to the back and I think we might have had a different deadline CU we were on payments which was one of the three right core pillars which which needed to work because we were blocking other teams so I think we we internally there was like a lot lot short deines there was like ear Late July early August that kind of stuff yeah yeah it was cool it was like so the the the the daringness of the of the of the of the goal was 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 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 deck so anyone who did Android or iOS at Uber was on it which was few hundred Engineers I I I don't know exactly but maybe 200 or or so 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 it was 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 but it was it was a really real and and actually that that's where I you and me got to work really really close together we we spent what two weeks or three weeks in San Francisco I think we SP I spent six weeks and you probably were there for most of that time as well I think three or four weeks I I I I went to my Uber Uber Verity the introduction course and I never did it we just worked on this project yeah yeah just long nights powering through it it was cool it it was cool it was like it 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 this was a you know really different right because this was I I think this was probably one of the last like truly companywide startup modes or almost it felt like war time where almost felt like we had an 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 roll the driver app which was similar in scope but that one took I think 18 months it was a lot more it it had all the deadlines all all all the the formalities it was like the opposite of of this project so I feel the company also changed later on absolutely but but speaking of your you were at Uber for how many years seven seven years seven years seven years and 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 it is Uber is significantly bigger than linear so I find that a lot of the problems that senior Engineers managers have to solve at Uber is are around getting a lot of people to work together efficiently so that takes a a big part of the day um and that that is not a problem at at linear so then we can use that time for other things and um focusing on you know being much closer to to customers for example is is one of them it's very hard to be close to customers like especially if you if you think like uber from from the rider perspective um you have millions of of users right so it's it's much harder to get so many thousands of Engineers to be that close to to to to the customers whether in linear you can do that um yeah I think there are mostly challenges that have to do with with the differences come from challenges that have to do with with the 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 L your emails or is that more of a just completely different communication style um I mean def definitely email as well um yeah definitely email as well right like it would be hard to imagine like have having everything decided in group chat at Uber with so many stakeholders yeah we we we use 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 rfc's request for comments people had to send it there and every day there would be like 10 or 20 rfc's going out which is teams Maybe not maybe not every day 10 or 20 but every every week at least 20 of new project that will be started off in a given domain may that be mobile or backend or or or somewhere else just a very very different scale so you worked as 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 um 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 um um being on slack and taking meetings awesome so like video calls with customers video calls with customers quite quite often actually um especially when we build a bigger project um and uh yeah I think those those are the the two big the two big differences yeah and in terms of skill set motivation or or mentality did you see any real differences or not necessarily of course of course definitely on on on the motivation front um I think in in um in the biggest motivation that people have is kind of what the customer feedback that comes uh from building the products that they do um the you know um writing a nice RFC or designing a super scalable um architecture writing elegant code right those are just means to build a good product those are not the goals and it's it's not like there's a 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 um you know it's I can see why in a big tech company it's it's easier to to to focus on the architecture that you build on the RFC because you have you know you have a promo process you have a performance and it kind of in a way I think it's needed but it definitely does distract you from why you are there and yeah we 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 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 got promoted they had some really nice rfc's they worked on some cross functional projects oh let me Tred to find a cross functional project because it might help me get promoted as opposed to some Engineers were getting frustrated who were building really important stuff for the business and they weren't necessarily being recognized it was just interesting and it 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 I remember when I joined Uber we still had um like meetings with 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 I started I I'm not sure I remember having that so it was so so so cool to see like because you when you when you stay again because the company is Big it's hard to keep everybody like 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 um but when I remember when you would see drivers chatting on how they how they use the app especially for payments and kind of the the issues that they have there are things that I I would have not thought of because I was so used to the using the product myself and it felt natural to me but yeah and speaking of what Engineers care about especially senior Engineers care about at large companies levels are are important in career progression at at linear do you even have levels uh do you have titles we we don't we don't everybody's an engineer and and as someone again you were you were 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 um well I I think it again it it it keeps the focus on on on on what you are building and what the goal for the company is which is building a great product um I I think that that's that's what helps the most uh um in terms of what happens is like it's it's very easy I remember when we did the 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 rub 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 it's just natural it it happens so when when you don't have all of that then you you can focus and it's you know it's one thing promos are one thing but growth is another right and 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 the promotion you 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 to use linear right it's it's a challenge it's it's you know you're not used to it's not instinctive to you like what you need to build as a as an engineer and being able to keep that product simple as you scate 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 this products ship this products you need to grow um so it's kind of growth with a company yeah it it sounds like a lot of 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 10 T 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 you know one one day one linear if if you stay the successful for another 10 20 years I'm sure at some point you'll you'll you'll have some levels although Netflix is a very interesting example where Netflix the senior engineer level for 25 years they 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 of uh holding that who knows you might be able to do it longer you are an inuring manager both at Uber and at linear how did it two how did the two compare um yeah I mean it took me it took me around two months to realize that 40% of the job that I was doing doing in Uber just does not apply to linear right like if you think of things like having a promo the the super complex perf process with all the competencies um 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 was just 40% not like 70% probably more yeah they just not that's it's 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 the full salary right like what do I do with the 40% of my time right um and it 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 it's not an easy question sometimes especially it's 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 defao data scientist 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 um definitely much more involved in product than I was in in Uber taking some customer interviews uh you know reaching out to customers to understand kind of what they need you know even in bulk sometimes like I I once I wrote a 100 emails I intentionally didn't want to use a a tool right I was like just just you know trying to communicate with with people and um yeah all kinds of things like that and plus of course the the normal things that you do as a manager like you will have the focus on people you'll have the one-on-one you want to know how every person feels what they want to work on what they are you know what they don't want to work on anymore how they 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 experienced engineers and you know places like uber we we had interns we had new grads we had Eng 1es twos who were like still earlier career if and and as a manager we did spend time helping them uh giving them feedback U and also of course onboarding not not just them but other Engineers but how is that change of of not having or do you have less experienc Engineers there and and if not does this change how you work as a manager yeah it definitely does I would say um we do have Engineers with less years of exper but we hire a it's it's not just about being of okay it's okay right it's like a soft yes maybe a yes right it's always the question is U what does this person have that stands out things that we admire that we we we learn from so almost everybody that we 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 would help them um 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 it's much less than in Uber you know I remember in Uber it was this moments where you go like oh you need to find three things for the person to improve yeah it was a mandate 2016 and 17 exactly I mean to a certain extent I I understand where it comes from but I think I don't think in those terms now anymore I'm just I'm I'm there for all the product meetings at least everything 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 is worth discussing about and giving some feedback and you know when when people go like oh 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 you feel so good about it right it'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 yeah yeah but I really like how the goal at least from from Thomas one of the co-founders is you know the goal of your or 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 what is 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 um you you get to know a lot of people and um different personalities different motivations like I wouldn't underestimate how much how many learnings that gives you as a as a as a manager um 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 exactly you just build that that solid foundation that makes you feel when you're in a smaller company it makes you feel like whatever happen 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 like I think Uber taught all of us that you know the Big B bats part let's let's uh wrap up with some rapid questions of course let's do it what's your favorite sport and why uh scuba diving uh I do a lot of it cheaper way to experience zero gravity nice and sometimes you do it when you're working full remote right do you sometimes combine work and vacation some sometimes yes um um I would stay more in a in a place and you know 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 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 that you've been both 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 um definitely in linear as well is just this 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 building building no hesitation yeah just just building yeah I missed that actually do you get to build a little bit or not as much uh very little in linear in linear very little I do build at home I build stuff um I think I I've been building for so many years um um 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 in the apartment love it and finally what's a movie that you recommend watching or that you enjoyed yeah I mean um probably everybody saw it um but I'm I'm I'm really passionate in in astronomy I do astrophotography and stuff so Interstellar for me was 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 engine and 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 next one