Linear: move fast with little process (with first engineering manager Sabin Roman)
01:11:56 Share

You use email very little.

So we don't use email. We generally use email when we want to talk to some of our customers. And some of the tools that we use may require reach out to support, but not if you have a question, you may decide that question is urgent.

You can ask you in a group chat and people will answer really, really fast. But maybe I just spend a little bit more time and figure IT out myself. That's a good thing about not having email.

You can just send an email because it's easier that way. The goal of the goal hi, is to address all incoming reports from customers. So the first goal for the is to go to all of those requests, 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 the buying the wow, I haven't seen that in wrong one is .

the first and re manger lonely where he has a engineering linear, a project man just offer especially power with startups. The company has raised fifteen million dollars in funding and are known for unique design. Snap years experience up for having a real traction with tarps and scales.

In this conversation, we go behind the scenes on other than your team works, and we cover linear x sac and their four mode energy culture, a deep dive into how specific project was built. We look to the overhaul the new project function ally within one year, comparing how large company like uber works. Where is a small one like linear, as an interesting fact, work at uber before linear.

And so little liars go founder. See you, Thomas. Hi I one more from fact to me, and I used to work to get uber on the same team.

I hope you'll go through tactics on how an engine team can move fast with surprising a little process in place if you enjoy the show. Place's thrives the podcast on any podcast platform and on youtube. I've been welcome to the podcast to be here.

So you have started your careers back in engineer um you did java. You don't worked at orange, a tele communications company. And then later you and me we were together at over you start, you were already an android engineer senior.

And with the engineer when I joined uber, uh, 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 we've joined linear two years ago, when there were ten engineers at the company as the first energy manager. And your soul, the first energy manager, as I understand, evener.

Yeah, we have two engineering .

manager agers. You told me something really interesting before we SAT down here, which was about emails. Uber, you, both of us are managers and I remember getting like fifty one hundred emails per day and 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 to antiquity or something like that.

maybe less yeah but like you told me, like you use .

email very little, 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 think I send to three minutes to you. So those those counters the thirty um and we generally use email when we wanted talk to some of our customers. And um you know some of the tools that we use may require reach out to support and we may write an email but not for internal work.

So what is IT said?

Well, we pretty much we use slack and linear.

So like, so is and like the interesting thing is like understands slight for, like you know the the real time communication, you need to pick someone. But my understanding of email was, no, maybe this is IT about outdated understanding but is great for like acing stuff. We don't want people to respond immediately. What about those kind type of no request?

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, rights to people that you know we answered quite fast. Um and and here I mean, there can be things that need to be followed up, but then we know we have linear for that as well.

So are using leader for more the kind of a long term of storage of stuff that needs to be structure or or search.

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 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 maybe like maybe I 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 lingua and you can ask a question on the on the project directly. You can leave a comment or you can post the 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 obvious because I can't really think of many people who don't have email as as their day today.

When you joined the year, how big of a shock was this was even a shocked is again, you are a manager right? Like like your you're they started with email. That is my day. Start with emails.

Yeah um I remember sending the first male in linear um I think IT IT was I don't know I saw something interesting and I wanted think the marketing team to to to see IT um and yeah and you know I had to write on on select that I send them any email.

These episodes brought to by launched darkly when the rethink software batch happens, boxes are inevitable, but they don't need to become disasters. Launch dark reduces the risk of releasing software, giving developers the confidence to shift faster through progressive leases, proactive monitoring, targeting and rollbacks. With launch darkly you can find and fixed bugs automatically.

Do you know how risk your software releases are? Take launch darkly two minutes risk assessment to find out, go to launch dark with a calm slash risk dash meter that launch darkly the com slash risk dash meter. This episode is about to by sava is a true hercule alternative where you can deploy applications, manage databases and hole static size for free.

Savana is a platform design for teams, which is preview on python features. Developers can collaborate on any stack while being assured of the security of the workloads from staging to production. Seven hold all the major security certifications companies are typically looking for.

Their application hosting offers automatic get integration, docker mage deployment, ments hybernation for optimal cost savings, version horizontal auto scaling, C P proxy support and optional private network connections for your database. Their freedom site hosting is perfect for landing pages documentation sites, more IT also includes preview deployments for easier iterations and seamless teamwork, several features and easy use interface, unlimited seats, no head and tricks, and transparent users. Based pricing with enterprise level clouds for a little protection for workers size, sign up and deployed today, go to a civil dot com that is civil with a double l dot com.

Let's set a little context on linear because I think we all know that it's a it's a tool that you can get things done, get projects on the truck cases. But talking specifically about the the company itself, can we kind of no help imagine us what what this places is like? How many people work there, for example.

of course. Um I I actually check before the pocus. M right. We are over sixty people now for 6 people and four.

five years old. The company founded dish.

Yeah, yeah. I think, don't remember in five, six years old.

yeah. So sixty people. What kind of technologies do you use? And inside the company?

yeah. So in terms of engineering, we use type script, react, note, G C P A postgrads ule that that text tack.

For a long time you had no product managers of the company.

Do you have product managers now? We do. We do have. We have two product manager, twenty five engineers and product team including design and product um is almost forty people.

But when you joining there are no product managers, right? So how does this time work? Like because like coming from a more like traditional tech set up, your kind of use to like okay, with an engine team.

They have a product manager, an engine manager and you didn't have that. Uh how did the engineer team Operate or who filled you know the the product a role of like what should we build? Why should we build IT?

I think everybody did. Everybody did. So um linear started off um you know filing initial 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 the with a very simple concept and with some principles around quality around you, the way you should build the product um and tested out and see if that works. So um for being ourselves a small company, using the product every day, being close to customers, that was actually A A big benefit in the year that we could be close to customers ever since the beginning um and then be up in intuition helped a lot and and .

when you say close to customers, what what does that mean you you paying people using or they paying you like on a slack channel on a .

linear 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 select channels support select channels.

We also have what we call a .

golly rotation um to try as yeah so um we have now two engineers on that rotation every week, different engineers and basically the the goal of the of the goal is to address all incoming reports from customers, may box, may be some you know small quality things that don't make sense. Um so the first goal for today is to go to all of those requests and and see if you can reproduce them and right if they have time and they will 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 one that I really loved seeing and he was at the beginning when I joined linear uh the first time I saw this I was like, wow a customer wrote about the a bug in the in the product and the engineer was like， oh, i'm looking at IT and then like make an hour two hours later like, okay, it's fixed, deployed wow, i've haven't seen that. Yeah like I feel .

like this is the software. You hear that I start up and I remember one know when we were a uber, uh we had something similar, right? We call IT uh, support engineer yes right.

And and I think what some teams that at least my team did IT and at some point we we work together as well as out of about ten 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 and also employees would report tickets. But there are thousands across the company and there will be like people filtering these.

And often product managers will have to filter down. We will get the ticket and IT would be on the support engineer as desk. But the first day part there was like as a supporting, you kind of go through, you see if you can reproduce IT.

And I think like eighty percent of the time, yeah, we could reproduce IT, but we couldn't fix that because IT was you know we were in the payments team and IT looked like a payments, but but actually was a fraud bug and the fraud am was a very different team. So we created a ticket and we escalates IT or we put IT in their support group. And I just I going to went a way you went up your support program, things just didn't really get fixed.

So like you were in that you saw this, but how did you make this work or how does this work different? That sounds like it's a way more efficient, right? Yeah ah is just because you're smaller .

or more I mean a being I mean being smaller is is generally takes a lot of complexities away from being you know ten thousand twenty thousand people company. Um but how does this works? I think there are a few a few things here that make a 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 is IT IT is IT is something that you are there front line without customer support team being in contact with the customer.

So you definitely feel more connected and 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 and that the U.

S. I. Or the u side that you think you know has the um the more information or they can do IT fairly efficiently, they can fix this iry efficiency. And here's where the second part comes in. So on top of the golly rotation, we have a zero bug policy.

No interesting. Yeah and very ambitious.

yes. And I mean, I I can show you how many boys we have opened right now. So basically the idea .

is a OK so is IT like more than or lesson .

um IT is so the the official S A is a week to fix IT and just that 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 well yeah so what happens is every morning, uh, come to work, you know, instead of doing email, you fix all the issues that you have and then you have for the for for the product work.

I like how that sounds. That sounds very utopian, but you are actually telling me that IT works.

I mean, IT started from like IT IT IT can work and 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 I think the principles behind that is if 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 way you can say I takes the same of time, yes, but the customer is much happier if if the bug fix sooner.

And also we have like a lot of things in india are based on on the best judgment of people. You can look at the bug and and say, look, IT was reported by one customer. I can't strait up, reproduce that there was no contact with the customer may be for a while, right? I'm just not gna fix IT and it's fine.

So you can rather than seeing I put in the backlog, you just go won. We have a status wonder that's what IT is for, right? So we do that as well um and we do reviews every week of of the sales for the box.

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 was I thought that is very ambitions at the beginning that I thought I 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, well, this looks like two and a half issues per week per person like once you average IT out, that's not you know if IT was ten and like stop work, figure out why you have so many box, right? But IT was a good number to start with. Um it's still working. I am really happy with IT.

Just play devils advocate. I remember again 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 knew like we had a massive bug, less flash feature requests, but a lot of IT was bugs.

And then 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 know, like you and me, we launch 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, we were 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 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 theology IT does slow down. And if you objected, 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 to a lot of decisions that linear made throughout the years um focusing on on on um 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 gonna do a black up who has more features competition with with other companies is not we don't think that that's the right way to approach.

And as interesting one because I I wonder if this thinking is a lot more value because just to be fair, in linear, by this time the year tracker, we had a lot of other tracks ers right there. There's well known ones there, last known ones. There's at least three or four public traded companies doing this.

So I wonder if if as a more general take away, we could say that when you're watching out the crowd d market, if you don't do quality, you you might as well just give up because again, like all competing on features is is a really hard to score. You need to raise a lot of money. And I think we saw some companies to do that.

But it's just a very, very different strategy. Gy, but personally, as an engineer, I I really like to hear this. It's refreshing to hear that quality is actually important and there's time for IT.

It's allocated for IT. So you're hiring process like you are quite differently than a some other other companies do just from what i've gathered so far. But you also have a famously different hiring process where you on you have this thing called the trial week. yeah. Can you tell a bit morrow about how your higher process works and what type of people you look for to have a software engineers.

of course. So I think that the hiring process starts of typical al to to that companies. So we have a, we have a recruiters phone screen.

We have a hiring manager call with you with me or tom in the U S. And if that goes well um we we have to technical um um exercises. One is coding, one is architecture. It's really nothing extract 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 um within an hour um so you know, if you ask yourself is like, oh, am I gonna given this type of exercise that I never have to do in real life, it's is 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 worker al. So the worker al IT depends on the role you have in linear. So um if you're on engineering, the world trial will be a week but for other roles, IT can be from a few days to a week um and um as part of the worker al, it's um basically the candidate gets to work with the team for a week s day as if they would have been employed um we we try to find this getting harder and harder, but we try to find Greenfield projects for everyone.

Now even for the trial .

there is even for the world trial is actually you know we have a meeting before and we tried, we have a big 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, but something that they can work autonomously. So but we managed to find good projects.

And I think the best ones are the ones that you know they build, you know we we decide to move forward. The candidate is happy, joins the team. And we had a few cases like this when the candidate as their first project shipped the thing that they build in the work.

Can you tell me what that feature was?

Um yes, I think he was a the triage responsibility. Um I think uh one of our engineers .

or so when the are you you can to sign who who needs .

to try as yeah integrate integration into IT, you can kind of automatically that the goal in our case tries but is is the person that you have in the uh page .

to o so are working on this during the work trial, make progress, join finish. yes. Also I I I love you.

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 recruit screen there. They're now talking with you up. And uh what do you usually talk about?

right? So um so first of um when the recruit has the phone screen, then I have a discussion IT can be as chronic as or in person depending on the candidate with the recruit. And we kind of try to make an initial evaluation whether we move forward to the hiring manager interview.

Of course, the recruiters is like super solid. I am confident and this no need for a discussion, just move forward. And and part of the hiring manager I have, you redoing a little bit the the story line, 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're excited about, this important if anything we are 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 this product expand quite a bit of time on on on talking about product within years and finally just going through their their experience um that wise think about some of the chAllenges, think they will .

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 sensor or product minded.

How does this .

change both the hiring and and the day today work? Because now you know like that sounds like clear. The team of you set twenty five engineers but really is twenty five engineers who are all really open and willing and wanting to do part .

work because what all right um yeah absolutely. So then IT IT definitely makes hiring you not not easy. Um I people say that, okay, we have a high bar in the year 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. Um we we want people that, as you said, have a good judged on product um have a good taste in product. And more importantly, we want people that are not more but as importantly, we want people that also have experience and and showed that they can be a great product.

Yeah and at all of this, you all work full remote, right? The whole sixty people average is full remote. How's that working? What is good about IT and what is more chAllenging, especially that at uber, both you and me? We initially work in office and then we did some force remote for remote but again, uber is now uh at the end of where you were also back in the office .

again for you was a big ah well IT works. IT works great for us and IT works great for me personally as well. 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 counter intuitive but is not the case. When I remember when we were uber and um we started moving to towards remote work, the amount of gifts that people are putting out just went up to to the point where we had discussions at the moment. They were like how people are kind of working too much so we afraid of them getting burned out.

Hi, I remember there was this all hands right after cover, or a few few months after we went and fall lockdown and that, uh, on the all hands, because both of us were there, they showed the staff. Turns out there was its internal tool that the office of the C, T. O. Or or senior directions and above could see the number of poor request as we call them. And there was a massive bike and I think I had to I I two two reactions one most like oh that's really cool .

a second what they're tracking our um yeah I mean so let's plead 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 is three focus like we don't do over time or very, very rarely but whenever people are there there truly there um and you can see that by sending a message and see how many replies you get immediately. So very, very focus.

Then IT also kind of autonomy is kind of building um you tend to get people that work remotely tend to have 不 to be more autonomy。 Ens and also kind of you know managed to unblock themselves and so on. And I I think it's it's like how do I say is like I think is less talking and more doing um so you know nothing beats a you know making a proof concept that is actually working to to show you know your product idea.

So you will see there is a lot of demos. There's a lot of trying design engineering is a lot of showing rather than surprising about IT. Because if you start servers sing in zoo meetings one after the other, you you lose track quite, quite fast.

And in terms of the chAllenges, I I would say so the thing about here, 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 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 you I mean also like being face to face is just is just 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 demonic 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.

So they like working progress things.

even working progress things, even a design, even I don't have anything, but i'm thinking of this. I look, I look like that. You click there and look IT doesn't matter. It's like it's very important to share things. And then we also meet, we have like two, three of sides per year.

And we have this, you know, if you work with somebody on the project, go like, I feel like working together with the person, you know, just grab a flight, go to see this day to three days, work together, come back. So we have a lot of stuff. So sound sounds like it's .

a healthy mix of you know people working focus. One, they're everyone is turned on and and you can come on everyone on the slack or is is available unless they they are away you for lunch or and then every now then you do get that personal connection where you actually get to have the face to face that born. And when you go back and still, you know there's a ora or something that like radiates for for a while where you have a sense of belonging known this person.

Yes, absolutely. I think on on the person or not tear as a manager. Um I I think it's it's harder for managers to manage remote teams.

It's just is it's harder to you know to to build that trust, to build that connection, to get the pause of like how the people is feeling with what troubles they, what motivates them. But ultimately, you know, my job as a manager is not to make my life is here. So I I really wish that more managers would be more open to working remotely because IT does make people's lives Better. Um your team um they can focus. They don't have to spend so much time traveling the .

flexible kay. So so let me ask pointed question. Talking to all other managers. We've been interviewing a 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 are there just used to IT? How much truth do we think there is in that? Uh, because you just said that IT is a lot harder as a manager and is very uncomfortable and and you need to do that again. I'm just interested in your personal opinion. Al observations here.

It's hard for me to talk about what the other managers think, right? Um I can talk about myself when I when we moved in new ber to being remote as manager IT IT was hard. I was exhausted at the end of the day so I could see how you know you be like this is harder for me was .

that the zoom meeting was a the a lot more.

A good day was eight zoo meetings. Bad day was sixteen. I 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 i'm out of work now 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 manager your schedule remote.

Um yes so but that sounds like you have a lot your video causes well .

right yes yeah solution.

So like sounds like you figure out a way or like little figure out a way to make work a bit more. Asic, uh, like asking but also real time. Just not maybe not like in like face base video based yeah .

it's it's money. We even have a thing where like you want to talk to someone just like huddle lemons, like you don't need to ask permission, you don't need to set up a meeting, just click about huddle, you know. And if the person can answer with great, if they don't, there's absolutely no no judgment couldn't is like going to somebody's desk and not being there.

And I feel that would be a lot of easier because again, like this is just putting the managers on. But I also remember when I looked at my calender, sometimes the morning I I just stressed out by harmony meetings, I had a lot of them were just scheduled one on ones, which is like, this is our once of time a week that we are will definitely talk one of the best west ways to figure, to understand how you get things.

Let's talk about a specific project that you ve recently built. what? what? What is something that you've shipped them and we can talk about how you build IT and turned.

of course. Um I think one one that one that comes to mind that I I enjoyed um I I enjoyed being there while we build the um is and of doing the the the project page. So we wanted to have everything that you need to shape a project not only as an engineer but also as A P M.

Can you help P M to understand how you built IT set by up, especially as a software engineer taking part of project because a lot of other companies, the way this will work as product managers decide they going to build a future, they work with design, they come back with the design, they showed its engineering saying, here's what we're onna build. We always had to sign off from customers or or IT looks good and an engineers do a maybe engineer planning and build and ship IT. How did IT work in to your case?

yeah. So we we decided as a company that the next thing we are going to focus on what is features around planning. And this project was one of the core features of that.

But at that point, he had a name right like we knew we wanted to what things 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 we talk to customers trying to get a sense of kind of what are their flows is always good to to to look at how customers use the product and kind figure out the problems that they have rather than the solutions that that they ask for. So we build that understanding and they will go, okay, we're building this um so we got a team together. We team silly.

They are quite fluent. We create them for a project and then we dissolve them. And so we we created a team, uh so the the team was a to engineers um and then we had a product, we had none on the product front and then we had the we had one designer um and customer support .

also customer support are also on the project.

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, I do where we did have every now then on some projects and ops person we call the ops they also interface with customers. What that is very rare is is IT comment of um these .

folks on projects. Most of the projects that are largely scope have have a person from awesome.

So so you have 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 a had a kick off with the team. Um product came in with kind of what what is the goal, what we want to achieve um show that some um some interviews that we we had with with customers and kind of kind of just drew out and what would be a possible solution for that, but very, very high level, right.

Um and then s engineers are 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 improved from engineering, from design. And IT was just a open discussion of what we could be building, right, rather than this is what you are building.

And you know, now technically scoped IT right. And then if I remember correctly, the the discussion didn't really end with a conclusion. IT was like, okay, like feels like we need to think about IT.

Let's just meet whatever three days, right? Whatever feels right. And so then we meet again.

And now on the product front, you know a bit more thinking went through IT for based on the questions that we're in that meeting on the on the design front, I I remember um design and engineering kind of started hacking on some designs together and doing a proof concept and then we showed IT what I was saying before. right? Nothing beats showing everything right.

And then again, we discussing like, okay, this didn't feel right and that didn't feel right. Okay, cool again, again, right. And actually this was a quite complex project because of the of the U.

S. You have this thing where you have to introduce an a new persona, which is the the the product manager within the project. But you want to keep the flows that engineers are used to as streamlines before.

So actually I don't remember, but we have multiple, I probably two, three terms of of the design that you know to make you feel right. And we keep on doing this meetings that at the point feel like but we're not kind of well, we're doing a lot of things but not really moving forward. But then at the point is a stand of clicks. And I seen this in a lot of complex projects, you know, deterrent situation in the world that omega's feels good and and everybody in the team just gets IT like this feels right.

So just at understanding as, again, this doesn't feel all too typical. Yes, you get together in a room, engineers, a customer support product. You talk about the people show what they're thinking and then you don't reach a conclusion. But you know, you've made some progress and then people go away and then they built some stuff of engineers will will build some prototypes, products will do mops or or or other like, you know they're y'll do some structure thinking and you come back and you have more structure things and and and you have more interaction .

in in that discussion is the M I pret pretty 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 problem.

This was very different from what we did, a uber, for example, right? Because we. Had a very strict process.

We had a product requirements document to P R D, where product managers worked on IT. Sometimes they involved engineering, but IT IT was indian. IT was a specification.

Here's what we gonna build. And IT had the designs and IT had and then enduring winton. And you know, we iterated IT on with the enduring planning. But I was compared to what you said.

I was very stiff .

having done both of this. How do you feel these two .

approaches compare? I mean, I mean, I I think, well, it's different, right because in is such a such a big company were talking being like over two factors of magnitude de bigger dillinger, right? So it's very hard for anyone person to to keep all of her in mind and be able to you know to be creative as data.

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 personal that uses linearly represented in that chat, right? It's one thing that I want to engineering manager, P M, once another thing. Engineers, once another thing. And then we talk how we make a product that IT feels good for all of us.

I guess, is kind of a great place to be. One as an engineer. You're also a user because you want you are also using that.

You also want your needs to be mad. okay. So once you came together and like IT felt good at that point, you had some injuring, had some prototype, right? yeah. Was IT some folks of the of your code that they fork the code base and just do some changes there or no?

I I think we um and 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 is 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 ultimate leaders always like one code base in which we write this.

And very often this is a you ging to master. This is available for internal folks, right? So so people in the company can try IT .

even when it's just so example .

be eighties under a feature flag and sometimes we decide to roll out that feature flag quite early. Internal employees or or not. We have a developer um council and we can just easily turn IT on and we can we can start.

So in this case, uh, the injuries were building behind one or or a couple of feature flags as an on the demos you were showing the soft or or on a branch all the same thing right until emerge back. And then, okay, what happened at the point we're like, okay, this feels good. Evidence happy.

Product is happy, endings is happy. Let's shift this. Was there any additional work in terms of you know proxy ation getting? I'm sure there is there might be some additional things or stage role out what happens then.

So when IT once IT clicks, the immediate focus like how how can we discover 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 and then the discussions become out like how we can make IT even similar, 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 be employees um then ba customers that probably we talk to them before and we know that that they would enjoy to to try feature like this. We found IT like our our customers are are are 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's how we are feeling a good 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, your or or your dog food. Well, that sounds like your dog food in IT. You're getting to some beto users, your your getting product feedback and you're making changes or i'm guessing you're fixing box zero.

Yeah ah yeah, we're fixing box, of course, and doing changes based on the feedback that comes in. Um and then and then at the point we yeah when he feels good in up with set milestones sometimes right like what what does he take to you know have a Better milestone and then you have a general .

audience conveniently supports most. So once you've gotten the feedback from the beta customers and your relationship to all customers, how simple of a shipping is that? Is this just a matter of will release its everyone you have additional testing or or feature flags or your quality focus?

Yeah I mean, most of the time we are we release so we don't have any A B testing. And I mean, there are some cases in which we do incremental roll out to jay, but most of the time we we just release IT, we start with Better time. And then when we decide is good enough for G A, we just release IT. Um and sometimes we have a no marketing campaign as we release IT. Sometimes we release IT, you know a few weeks before the marketing campaign of people already start start using IT.

And from an engineers perspective, now that the project shipped, is there kind of a wrap of the 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 we're wrapping this up and do a retrospective or celebration or whatever that is.

So we put projects s once we released them to jay, there will be feedback that come 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? Do we do 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, you know that that that there are, then we spend more time and eventually just stands up in maintenance.

So we have a maintenance 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 mini follow projects, right? So sometimes you go like this this piece of feedback, and this is 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 I N and ship that makes us.

And how long this was a bit project, how long did they take this team of two engineers and sounds like three other non engineering people to .

get that done. I'm trying to remember I think but months uh, probably I want to save four months something like that yeah to to get IT in the hands of the of the customer.

And this was one of bigger ones. yes. How do so we talked about this specific project. But in general, like you, you're involved in a lot of enduring projects. In general, how do projects run? How typical or a typical 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, al, for a more .

complex project. So that sounds like a very small teams, not just engineering, but working with with, with on engineers, folks. And there I say not structure. Did I feel that? 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 you 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 is not like you need to this is the persons and then you go to this person is just like we ask our self like who should see this, right? Like who feels like maybe they you 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 was brought to you by work, to us. Every building is a APP. At some point, your customers will start asking for enterprise features like sample head, vacation, skin provisioning and find great authorization.

That's where work comes in, making a fast and panel sad enterprise features your APP there A P, S, are easy to understand, and you can ship quickly and get back to building other features. Worker will also provides a free user management suction called off kit for up to one. Among the active users is a drop in a replacement for all zero and come standard with useful features like domain verification, rule base, access control, both projection and M F A.

It's powered by radix components, which means zero compromise. In design, you get limited customizations as well as module temples design for quick integrations. Today, hundreds of fast growing shrubs are powered by worker s, including ones you probably know like cursor versa and perplexity check IT out of the work of us dot com to learn more, that is work or s dot com.

So this lack of structure is is very unusual. Why do you think you can kind of get away with that? At at lunch the I I am trying to get to to to the difference that you can run like this but most teams are even companies would struggle like there was crashing burn, i'm pretty sure.

Yeah I mean you can't unrest, mate the the the difference um that IT makes for being still a start up and 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 IT really comes down to to to the people that we hire um so people are um are really passion ate all all of us are really passionate in in product building, building a great product and blocking ourselves moving things forward, right? So when you when people are driven, you can you can rely in a more on their on on their best judgment and you don't need to set so much process things. Just I I remember actually hear 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. I just put put the document right.

This like kind of okay. This seems like this are the phases of the project just put IT somewhere right? And I got I was I know we don't know. I don't I don't want to see you saying like I don't I don't like the circle. IT s the bubbles of that's what we do.

right? Like like you and me, 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 sometimes dozens of business stakeholders like a sometimes legal teams and everyone what the city.

We made a 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 yourself. So sounds like both you and him just completely the one A D flip in, I guess thanks to just a different, completely different environment .

yeah absolutely. And I don't, anna, make IT sound like there's no process. This process is just the 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 we're not gona be creative when IT comes to how you react to an incident, for we have very, very clear process 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 to lead that one or most of them just because I coming from uber now, I have quite a bit of experiences like we were you know being successfully will be that you can get a lot of people aligned on the way we build the thing. So um yeah remember .

like know there are things that are no jokes like reliability downtime that that can actually damage the company yeah sorry so 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 the process, for example, reliability and places where you actually that 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 people can put IT whenever IT helps them, but you're not forcing on them. So that hopefully, I mean, so far sounds like it's kind of working. You're getting perhaps you you might be iterating faster or get into the things that you were are hoping faster.

Is that a fair summary? yeah. I think the the go the goal is not faster. I don't I don't think we like as we go through the projects, we don't talk about 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 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 that is to work at linear of a start up, still moving very quickly, a lot smaller team and also for remote versus working in a large company like uber where U. M. I worked. And maybe to start, we talked about the project that was pretty typical at athena. Maybe let's talk about a project that maybe the most, not the most typical, but IT IT was a pretty representation of how we work, which is the first project you and me worked together on, which was cold name helix and IT happened to be rewriting the whole u per application, both values and android from scratch um and you are on the android side of things.

right? Yes, that's so many things to talk about that. But I think like I have to pick like the two three things that really stood out t for me, that project is the we need to rewrite the rider APP on android and IOS with a new architecture, with a new programing language on IOS, with a new payment framework for us.

new payments frame. We also yeah everything was we all came up with IT on the floor, right?

Like in a few months time. Yes, exactly. 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 I was a two billion dollar run rate per month between the two apps, so about fifty android. And I was so like a billion dollar a on the line and is .

a revenue month do IT into a half months yeah and .

that's when I joined uber. You were there a little bit earlier, though. So so you saw this whole thing start.

I wasn't there at the start. start. So like how typical or a typical was that project? Even other were standards.

I mean, IT IT was I? He was speak, he was speak the project. But here's the thing. He wasn't shocking in terms of how daring IT was like IT was right there with, you know, big ball bet, go for IT, right? So I didn't feel a typical for the culture in uber to do this. We can do IT a and IT was like, I remember that the deadline specifically, I don't think almost anyone in the engineering team in thought that, that is an actual deadline. I think he was so aggressive that if we thought is like a directional one, right, like you would be great .

if you can do IT in two and a half month. S so if I, if not mistaken, the project started in june, right june twenty sixteen. Ash, right in the summer.

I think some teams, the platform, things are working earlier on, on the architecture. And then our deadline was international deadline was something september sixteen or so to get the to ship the APP for beta users. And our ultimate released date was, I think, second of november. And in the end, I think we did had the second november, right? Yeah, I think so.

I don't know why I remember because this is like three, four months. I remember he was even short. Maybe 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 productions ization phase and everything that .

took you to the I might have a different deadline as we were on payments, which was one of the three core pillars which which needed to work because we were blocking others team. So I think international, there was like a lot that there was like a late july, early August.

that kind of stuff. And I was cool. IT was like, so the the the the darkness of the of the of the of the goal was just like one thing that that I remember.

And it's also the we did a lot of work like we had to look work really long hours. But the kind of the resilience that that built 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, one hundred percent.

He was after pressure. Occ, and you know, the interesting thing, I think just a scale because I think for us as kind of a given because remember, but IT was a literally all hands on deck. So anyone who did android or IOS at ur was on IT, which was few hundred engineers.

I I I don't know exactly, but maybe two hundred or or so. And then even people who didn't do I also, android were pulled in often to do what when I joined, I was supposed join us back in engineer, and I was asked to be an android engineer because of this project is were low on android. That was, I was then wait a few back in engineers.

I think we realized midway that, oh, we actually back in engineers for all these new mobile and points. But but I was, I was a real and and actually that that's where I can. You and me got to look really, really close together. We we spent about two weeks or three weeks in some.

I think we I spent six weeks and probably were there for most of that time as well.

I three or four weeks I I went to my ber uber versy the introduction course and I never did IT. We just worked on this project.

Yeah yeah. Just long nights power into IT IT was cool. IT was cool.

IT was like IT just proved that if you get a lot of people motivated, like how many things you can, you can achieve, this is 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 been.

But this was a you are really different, right? Because this was I I think this was probably one of the last like truly company White start up modes, or almost, I felt like war time where almost felt like we had to exist, existence al threat, even though, you know, there was nothing essential about IT. But afterwards, two years later, we had one, and a half years later, we rule the driver up, which was similar in scope.

But that one took, I think, eighteen month was a lot more IT had all the debt lines, all all the the formalities. I was like the opposite of of this project. So I I feel the company also changed later on.

But but speaking of .

your you are do you per for years, seven years, seven years and then you saw IT go from a more scrappy scale up to a lot more structure company. What are things that you now do very differently linear? Then you did a uber.

yes. 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 and that there is not a problem at at linear. So then we can use that time for other things. and. Focusing on you know being much closer to to customers, for example, is is one of them is very hard to be close to customers, especially if if you think like uber 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 dead close to to to to the customers, whether engineer you can do that. Um yeah, I think there are mostly chAllenges that have to do with with the difference is 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 is into as well? You know just laugh. Your details are as more over or just completely different communication style.

Um I mean, definitely email as well. Um yeah, definitely email as well, right like this would be hard. Imagine like having everything decided in group chats at work with so many stakeholder.

with a lot of like status checks, getting people on the same page, sending up proposals. In fact, we even had a we had a firehole. Remember, we could subscribe to a couple of email this were we could have the rfc request for comments people have to send out there. And every day there will be like ten or twenty rfc is going out, which is teams maybe not, maybe not every day, ten or twenty, but every every week, at least twenty of new project that will be started off in a given domain may not be mobile or back and or somewhere else, just a very, very different scale. So you work as a senior engineering at ur and you hire senior engineers there healing er you work with a lot of senior engineer, you also hired how do you see a senior engineer work differently at a large company like uber versus eller?

So I I think there are a few things. Um first is much more focus than involved in product decisions as a senior engineer, much closer to customers actually talking to them, taking meetings. Second.

T I especially .

when we build the bigger project. And I think those those are the the two big the two big differences yeah。

And in terms of scale, set, motivation or or mentality that you see any real differences are not necessarily.

of course, of course, definitely on on on the motivation front. Um I think in in the biest motivation that people have is kind of what the customer feedback that comes a from billing the products that they do the you know writing a nice rfc or designing a super stable um 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 A complete mentality shift between right, like you have a lot of our engineers come from bigger tech companies. 没有， but it's just in a big tech company, it's much more um you know it's I can see why in a big that 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 promo process, you have a performance and it's kind of in a way I think it's needed, but IT definitely does distracts you from why you are there.

And now we talked about this, by the way, before this right on how even while we were there, how uber changed, you were there for over seven years. So you thought even longer than I did. How to change from this type of focus were when I joined, at least in the in the earlier in two thousand six scene, that was all about what is right for the company that has built the right thing.

Let's focus on the impact to how very slowly the things crept in to the back of your head, like, oh, to get promoted. I saw the people got promoted. They had some really nice rfc as they worked on some cross functional projects.

Oh, let me try to find a cross functionally 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 were necessary being recognized. That was just interesting.

IT wasn't sudden, right? IT was very, very slow now. And is everyone right? But IT was for the majority people after a while.

Yeah I I remember when I joined over, we still had um like meetings with with drivers like we will have the drivers coming in and you if you wanted to, you could go even as an engineer and I kind of listen to those .

interviews yeah by the time I I started, I am not sure I remember having that.

He was so 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 further way 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 drive first, chatting, how they how they use the APP, especially for payments and kind of the the issues that they have, they are things that I I would have not thought of because I was so used to the using the product myself and felt natural to me. But yes, and speaking .

about what engineers care about, especially senior engineers care about at large companies, levels are are important. Career progression at at linear, do even have levels.

do have titles. We we don't without everybodys an engineer .

and and as someone, again, you you an injured of manager, you help a lot of people get promoted. You are promoted yourself. How do you feel this thing changes things or 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 call for the company is, which is building a great product. Um I I think that that's what helps the most um in in terms of what happens, it's it's very easy. I remember when we did the when we had the rubrics introduced for the performance and competences in noble.

Yeah right. I started off like I remember we were building things and then we have this and he started off. I was looking at the room like, make sense that actually the 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 brubeck became the goal. Ah it's it's just natural IT IT happens.

So when when you don't have all of that, then you you you can focus and it's you know it's one thing, promise are one thing, but growth is another, right? And and there is a lot of growth engineer. But again, we think different about IT is not you don't grow to get a promotion, you you grow to be able to like the product is becoming harder and harder to be like allowing customers that are ten, twenty times the size of linear to to use linear, right? It's it's a chAllenge.

It's you know you're not use is 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 scare 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, shift these products, you need to grow. Um so it's kind of growth with the company.

And that sounds like a lot of things that you're doing at Linda and Y C U. I also 的 然后 company。 It's trying to push back on how a large hand cut top 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 day, one dinner, if if you stay the successful for that or ten, twenty years, I am sure at some point you you have some levels. Although netflix is a very interesting example where netflix have the senior engineer level for twenty five years, they just got rid. I think they just changed IT to have other levels, but they did IT for twenty five years.

And a large part of that was a public attract 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 injured manager of super and a linear. How did you?

How did IT to compare? Um yeah, I mean, he took me, he took me around two months to realize that forty percent of the job that I was doing in uber just does not a bite to linear, right? Like if you think of things like having a promo, the the super complex per process with all the competencies, alignment between different teams, dependencies between teams and all of that no budgets reporting .

justifying why your team needs to be there.

Yeah that just not is not needed, is not needed linear. So the first thing once I realized that the first thing I was like, well, so i'm still play the full salary, right? What do I do with the forty percent of my time, right?

Um and IT IT the music is like every now and then I Thomas like, hey, how am I doing you know give me some feedback as my manager, Thomas is one of the founders and he says, like, oh, tell me what have you done to make lennar like a Better product and like it's it's not an easy question sometimes, especially is the world that you do is kind of indirect, but I think it's a really good question, right? So I found myself, you know I I think I was the defect of data science st for the year for a couple of months before we hire some just writing queries es all day. And I I really enjoying because I felt like IT helped right.

Um definitely much more involving product that I was in in uber taking some customer interviews, you know reaching out to customers to understand and of what they need. You know even in but sometimes like I I once I wrote a hundred years, I use A A tool right I was like just just you know trying to communicate with with people and um and all kinds of things like that and plus of course, the Normal things that you do as a man like you will have the focus on people. You have the one or once you wana know how every person feels, what they want to work on, what they you know, but they don't work on anymore, how they but 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 engineers, you hire experience engineers, and you know the places like Cooper, we had in turns, we had new croats, we had and ones and tools were like still earlier career. And as a manager, we'd spend time helping them a, giving them feedback a and also of, of course, on boarding. Not not just them, but other engineers, but.

How is that change of of not having? Or do you have a less experience engineers there? And if not, does IT change how you work as a manager?

Yeah, he definitely does. I I would say, um we do have engineers with less years of experience, but whenever we hire a person, it's it's not just about being kind of okay. It's okay, right is like a soft yes, maybe yes right ah it's always the question is up 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 impress us in the way, right? So it's not that much in terms of I don't look at IT as all this person has you know less experience. Therefore I will 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's it's much less than in uber. You know I remember in uber IT was this moments where you like you need to find three things for the person to improve and extend. 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 meets at least everything that to ship in you. I can see people every day how they work um and very rarely I find the thing that I think you know is worth disgusting about and giving some feedback and you know when when people go like or you know you're right, I haven't sort of this sort like IT ends up in the discussion. There's so much more like you you feel so good about IT is so much more rewarding when you can find, even though they 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. But I really .

like how the goal, at least from from Thomas, one of the good founders, is, you know, the goal of your measured, of your successes. Have you made linear a Better product? Yes, which I think quite few managers can say that this is what their manager ask of them. Yes, which is just really cool. What what is the useful learning from a large company like goober 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. I wouldn't underestimate how much how many learnings that gives you as a as a as a manager.

And are you talking about how like for example, of super like we were exposed a lot of the different people, teams.

conflicts yeah is like you you just build that that solid foundation that makes you feel when you in a smaller company IT makes you feel like whatever happen happens, especially when he comes to people you have seen already. So not so many surprises, I would say. I think that help me a lot. And also, I just think big you can achieve big things like, I think you were thought all of us that, you know, he called that smart.

let's a rapper put some rapid questions.

of course.

Let's IT what's your favorite .

part and why a school but I think um I do a lot of IT cheapest way to experience .

zero gravity nice. And sometimes you do when you are working full remote, right? Do you sometimes combine work in vacation?

Sometimes yes. Um um I would stay more you in a place and you know stay three weeks to have them, you work and then one week take off. I think we school is particularly hard as after a dive your you know there's a lot of nitro jhn in your blast stream so you're a little bit woozy. I wouldn't work after diving.

nice. What's the best thing about being an area manager and also the best thing of being an engineer. Now that you have been .

both as an engineer manager, I think the best feeling that I had an engineer manager happened to me in uber with the web team um definitely in 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 bad.

An engineer building? no.

And you do you get to .

build a little bit or not as much .

very little engineer， uh engineer very little. I do build at home. I build stuff. Um I think I been billing 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 robles around the apartment. Love IT. And finally.

what's the movie that you recommend watching or that you enjoyed?

Yeah I mean um probably everybody saw IT, but i'm really passionate in in astronomy. I do sta photography and the stuff of the for me was great.

It's also some thanks for being here.

Thank you so much for inviting me.

I really enjoy if you enjoy this podcast, please do describe on your favorite podcast platform and on youtube. And if you're interested in reading more about lunars engine culture, check out the deep type of parameter engineer that goes into additional details. Linton, the shown news below. Thanks, and see you in the next one.