Software Misadventures - Life as a Distinguished Engineer | Joakim Recht (Uber)

Episode Date: April 30, 2024

Out of thousands of engineers at Uber, there’s only a handful of Distinguished Engineers and Joakim was one of them. In this conversation we chat about Why software engineering is a lot like a sausage factory. Considerations for leaving big tech for a startup. “How to beat the promo commitee”. How can one effectively shape engineering culture? “Mentoring two people on the same team is a waste”. Much More. Subscribe now Segments: [0:01:52] The “reverse sausage” architecture [0:07:36] How to get people on board with the new deployment system? [0:13:55] What does it mean to be a distinguished engineer? [0:17:47] Under-appreciated soft skills? [0:21:28] How to improve technical writing [0:24:16] Do all senior engineers need to write and review code every day? [0:30:19] How to search out where to contribute when your time is so constrained? [0:43:10] How to maximize your impact as a mentor [0:48:52] “How to beat the promo committee” [0:52:56] Effective means to influence engineering culture? [0:57:09] Capping the company at 150 employees [1:03:33] Why join a startup instead of moving to another big tech company? [1:11:14] What Joakim is working on now at Beyond Work   Show Notes: Joakim on leaving Uber to start Beyond Work: https://www.linkedin.com/pulse/why-i-left-uber-start-beyond-work-joakim-recht-o63of?trk=public_post_feed-article-content Read Joakim’s other excellent posts here: https://www.linkedin.com/in/recht/recent-activity/all/   Stay in touch: 👋 Make Ronak’s day by leaving us a review and let us know who we should talk to next! [e-mail]

You go up the ranks and you see more and more, like you're flying closer and closer to the sun. The sausage factory is a big factory, right? There are many clean rooms until you reach the core of it. But the closer you get, the more you're also like, okay, if I'm not doing this, then who is? You have the senior engineer who is laying out this viable plan of a project which seems

very ambitious and challenging. I think having an engineer kind of describe that puts the team at a little bit of an ease knowing that they'll have some guidance and direction on an ongoing basis from an engineer, not just management is telling them to go from, let's say, go to a store, whichever language to this other language or whatever migration they have to. There's a significant material difference between a senior software engineer saying something and a senior VP saying something. If you read it off from a script, the same words coming out of two different mouths, that will, to me, make a difference.

And it might just be me projecting myself, but I know if I'm in front of a senior engineer who I trust and look up to to some degree, and there's a VP who, the thing is, you don't quite trust because they don't have this building thing going on. Like if they say the same, there's a difference. so now you're a founding engineer at a new startup called beyond work but before that you were on a distinguished engineer at uber super impressive since that's you know pretty much the highest one can go on the ic ladder so we were messaging some of the engineers that you worked with before shout out to jasper if he's listening he mentioned that we should ask you about what you call the reverse sausage architecture that y'all used to build a lot of the systems at uber can you tell us a little bit more about that

oh that's uh i think first of all let me just say there's probably a lot like a lot of terms you come up with as you go along just to just because you don't necessarily have a language for it. So reverse sausage, I don't think that's an official term anywhere. It's just a picture. And I wonder what he meant. I'm sure it's related to the fact that there's a lot of dirtiness involved in building stuff. If you don't accept that as a fact, you're going to have a hard time. So accepting the fact

that the world is messy and it's unclean and it's unperfect, I think that underlies almost everything we build as a foundational principle. Not because, of course, we don't say,

oh, nothing matters, we can just do whatever, quality doesn't matter, but just because if you build something for perfection, some people find it nice to build something that's awesome and completely correct. But also, in my experience, it turns out that you spend a lot of time doing that. And all the time, you're not getting any kind of real value while doing it you're just you're building for something and you might never be able to actually attain it

so it's much better to like get it out there and running to like experience does it work does the thing you thought would work is that actually how it how it is going to be in real life because even though you built this perfect thing in isolation put it it out there, it doesn't work. So I think there's a lot of that. And I think that both underpins all the technical stuff we built, but also how we built it, the culture we built around it, how we think about building. So yeah, it's interesting.

Was there a specific project that you can talk about that either was the epiphany of that or maybe first it got you to start thinking about, okay, this sort of research and sausage process? So most of my time at Uber was spent building deployment platforms. So we built a fairly large-scale deployment system for stateful workloads. We should talk more about this. We started doing this back when Docker was very new Kubernetes was like an alpha

The first alpha version was Then we were like We should put databases in containers And everybody was like Are you insane? Or what's going on here? Because it doesn't make any sense But we did that And it turned out to be a huge huge success and we when i left we have basically converted all of uber's non-stateless

which is called stateful but like there's so much stuff that goes into stateful that's like semi stateful whatever it was all running on one platform that we built and that platform was kind of based on the fact that nothing is perfect, which is a bit scary. We have databases, you have data, you don't want to lose it. So what do you do about that? But there's also so much like when you run a large scale infrastructure that also involves like real hardware that can fail at any point in time. Like how do you model that into a perfect system? Like you can't, you kind of have to build it in a way that basically anything can happen

at any point in time so having like a state machine or a like a a complete like oh if they're in this state and we can do this we can do this well one day somebody's going to rip the power off and then there was no state for that or whatever so building that system in a way that is like it can basically handle anything without you having to deal with it. I think that's one example of this, where once you accept that, okay, we are going to know every single change that happened. The exact chain of events that led to something, let's say server goes down, a rack is offline suddenly. The chain of events leading up to that,

you're never going to be able to fully track that. So if you build a system that is based on events sourcing to kind of determine the state of the system, it's not going to work. There's just my opinion, of course, but that's how I see it. And that's kind of the realization that if you build a system that tries to be perfect and like knows every single change in the system, it's not going to work.

And I think that kind of led us to build this deployment system that in many ways is like Kubernetes, but also quite different. So that's interesting because I think there are two aspects of what you're mentioning. At least what I'm reading is that two different parts of this. One is when you're designing a system, you can't expect everything that you rely on to be perfect because like you said, someone would pull out the power cable and you have no idea what the series of events that happen. So that goes back to like assuming failure is a regular mode of operation. It's not an anomaly. It's something that's pretty normal.

There is another aspect to this, which is as you're trying to build something, which is putting stateful systems on containers. I mean, even right now, when you talk to a lot of people about that, like, are you sure you want to do that? Do you know what you're doing? And when you talk to stateful application owners, like people who are running databases and you're like, Hey, we're going to roll this thing out and you're approaching it with pragmatism. You know, the system that you've built is not going to roll this thing out and you're approaching it with pragmatism you know the system that you've built is not going to be perfect until you actually put it out there until it runs in production until you see some failures i'm curious in your case when you're talking to the stateful application owners saying hey we're going to run your apps on on this new system we have designed it with

failures in mind but obviously we can't think of everything and there are some things we'll only see how do you go about bringing them on board to say let's let's put it here let's let's go let's take this forward because I think it's about like very similar to the advice you see startup founders getting it's like hey put a product out there if it's perfect it's probably too late already I think same is to be said about engineering systems to all the engineers don't tend to think like that it's like let's put it out there let's see how it works and then a trade, but not everyone is super comfortable

with that and I'm curious how you got people on board there. Yeah. And to be honest, we did have a lot of resistance from different parts, sometimes surprising resistance, sometimes also just completely expected. And so we came with like a set of different value propositions. Why would this be a good idea? One thing about optimizing, like feed optimization, you can kind of get rid of a lot of duplicate tooling

that you have. If you're managing Cassandra in one way, you're managing MySQL in another way, to do different teams. There's a lot of waste involved in that. Of course, there's also like people who are doing this probably have built their own tools and they're kind of heavily invested in those like that they think they're pretty good but didn't yeah um so i think a large

part of it so we bootstrapped out of um the project called schemeless something also uber built like a like a key value store this real key value store that we built ourselves based on mysql um and that was basically something we built on part of our team so we could basically take that and like okay so we had a lot of process there so we're gonna get started there but as we kind of branched out to all the other different teams that's where more kind of tension appeared so it wasn't like a oh we didn't just like show up and say oh we're just going to do this and everybody's yeah it's like quite the opposite but it was a really long like we started this and back in like 15 and it was a long stretch up until 24 i think to kind of get everybody on board and i don't think there's any better way of doing like i don't think there's

another way because as you say you basically have to win the trust of both the people who are currently operating but also the people who are using the systems and they have to see the value and and yes of course we also screw up sometimes that's the thing um but you can also see when it actually starts when when it gets to a certain point you can start you can start doing all these fleet-wide optimizations, or you need to do a kernel upgrade, or you just click a button and it just happens. It doesn't happen just immediately, but it happens automatically. That was always the important part. All those people who are left with their own systems, they're like, oh, fuck.

We have to put up a spreadsheet or whatever, and then we start tracking. Okay. How many servers did we do? And like, whatever. And, and so people can also see both the teams themselves, but more, more importantly for something like this, managers and directors, they can see, okay, so we have this setting over here where stuff just happens. And then we have this other thing over here where there's a lot of like weird stuff happening. We can't really explain.

And like, we get new people in. They have to learn complete proprietary things. So I think there's a lot of stuff that goes into it. And I don't want to say it's just because of resistance to change. Like for people, there's also technology that is really hard. And stuff like if you're running Kafka, if you're running ACFS, there's a lot of systems out there that we run at scale

that are really not built for like a cloud-like environment. Oh yeah, absolutely not. You're not really supposed to change IP addresses or you're not really supposed to do anything except keep it running as it was when you installed it in the first place. And so there's a lot of work that goes into like,

okay, figure out how do we take something that was built for like a static, like completely static setup, how do we move that into somewhere like this dynamic environment where we, like we had a goal of every server needs to be reprovisioned every 30 days. So that means no container can run for more than 30 days.

And like for something like HDFS or Kafka, that's pretty scary. Because they work best if they never shut down. And there's a real cost to moving them around. The replication cost is a trivia. There is a real cost. And that's also why I think we spend a lot of time figuring out, okay, how can we compromise here? How can we say, oh, we want this perfect system,

but we can also see that if we need to shuffle all data, like let's say we have maybe close to an exabyte of data, and we need to move that around every 30 days, that's a whole lot of data that needs to be moved around all the time. So what do we do about that so that we can realistically do this also? So it doesn't just become this idea idea that oh some somebody just wants to do just because it sounds good on paper but also like has to actually work yeah the reason i'm smiling so much is because i work on computer infrastructure and over the last well about four years ago i was working on os upgrades pretty much trying to automate this and we were in a place where there

was a spreadsheet people were tracking stuff like that and we are in a place where there was a spreadsheet, people were tracking stuff like that, and we are in the process of moving the systems onto Kubernetes at this point. So I can very much relate to every single thing that you're talking about, although we are probably a little far behind in terms of the journey there, but I can relate to it very much.

Yeah, yeah. Yeah, I think most people can. So as a Distinguished Engineer, we wanted to kind of ask you, like, what does it mean to be a Distinguished Engineer? I mean, you see very few people with that title. And I think every role for every person at every company is different. And different companies see it differently, too. Yeah.

So curious how it was like in your experience. Yeah. So you're completely right. There's not like a distinguished india especially like across companies even half the inside the company but i think it is doing as you know it's just like the top of the rank just because it's like they're no more there's no more people there's no bit more people around like because and it's really a matter of scope to me. Like how broad is your scope?

Like how much do you think about when you build something or need to do something? Do you think about just your team? Or do you think about like your group or your organization or some kind of super organization, whatever they're called? Or is it like the entire company? And if you're thinking about the entire company, that's where it's like distinguished in your level to me. What is a company? Of course, there's always like, what is a title?

There's also because, of course, if you are a 10-person startup or even just a 10-person like whatever mature company, well, are you then distinguished in there? I don't know. Probably you don't have titles. But it's like when you have enough people around and the problem becomes complicated enough, there's also a question of, okay,

who takes the big picture into account? Who thinks about not just like your narrow little problem, but like, okay, you have your problem, they have their problem. They all need to like fit together. Who thinks about that? And think at uber at least that's where the distinguishing is comes in they have a lot of experience they have a lot of they've tried a lot of stuff build a lot of things usually and then you are in a better position to kind of think about like if you as a like a company will want to go in this direction, what does that mean?

What does that require from a technical standpoint? So I think that's, and it's really, it's kind of hard to express. Also, there's not really a, there's not really a well-described,

like, how to be a distinguished engineer kind of thing. Because it's also, there's a, compared to a few people who are at that

level i think at uber we were i guess when i was promoted i was number six something like that then we got two more and we were eight and that but that's all out of four thousand or fifty four hundred uh forty five hundred people who are engineers right so so there's quite few compared to the vast majority of engineers but somebody has to like think about these things and it's not that we all kind of think about it. Oh, well, the entire company all the time. Of course, I was in platform engineering, so I had mainly focused on platform-level stuff.

But I think the big differentiator is really about scope and how you think about it. And to a very large degree, there's a lot of technical... To me, there's a lot of technical components to being, no matter what level of engineer you are, but the higher you go, there's more and more soft skills involved so there's also just like not only about how do we pick the right technical solution but how do we pick a solution that is actually achievable how do we do something that isn't just again like a whiteboarding exercise

where we're like oh yeah this solution on paper looks pretty nice but it will never get done just because of politics or other projects need to get done or special interest whatever it might be there's so many reasons why again the optimal solution is unattainable because usually it's only optimal from like a very strict perspective if we take another perspective in it's suboptimal because somebody else wants to optimize for something else maybe you want to optimize for everything somebody else wants to optimize for reliability and now you'd like the they will really work out entirely yeah yeah for the soft skills that you mentioned was there any surprises in terms of wow like you you know when you were at when you were more junior you're like oh that's not really you know that useful of a skill set to grow but then once you did get to principal and distinguish it's like

oh my gosh i should have been like working on that a long time ago yeah yeah so first of all i don't think there's a point where soft skills are not good to have you might as a junior engineer where you might of course think well and i tend to still say this, it's all about just writing some code, then the world would be a better place. Get that done, you're pretty good. But of course, the ability to communicate with other people, I think that's important no matter what. Because if you're not able to explain what you've done,

why you're doing things, it will lead to a lot of frustration. Because yes, ideally you're judged on like fully, like purely on technical merit. But that is just not how the world is. Because one thing is you have a good technical solution, but if you're not able to articulate how other people should use it, why they should use it, or why it's good or why it's bad, then you just won't get far. And that goes already from a junior engineer.

If you're at the very junior level, maybe you can just do the technical stuff. But as soon as you just go a little bit beyond super junior, you need to be able to express this. So being able to communicate that without coming off as... i don't want to say and also be receptive to input as i go what you built wasn't right quite what we needed and maybe it isn't and go back and build some bit but we actually need that is also to me a soft

skill being able to like both do the output of like explaining what you've done and take the input of is what you're doing is that actually appropriate for what you should be doing again and this is again where the scope comes in and usually you just think about your team anything about your org and anything about whatever the company but all the all the time like that. So I think having that, having those capabilities, I think that's important no matter what. Now, as I approach more distinguished, the higher levels, like I don't want to say I have always been conscious about my own faults because I haven't, but I have at least tried to think about them.

And I know things where I'm really bad at. Like I'm really bad at anything that is repetitive. If I am to send a weekly status update,'ll do it twice maybe three times enough then then i forgot about it once and then it won't happen again or like i am yeah any of these things but i'm like also why am i doing it but that can also be weakness like and i'm also i'm not particularly good at like telling other people what i do like i i can if i'm like conscious about it but i i kind of it regresses fairly quickly where i'm like i'm just like working on my own stuff and then i'm kind of done okay okay now like okay it's also nice to kind of keep people in the loop about what you're doing and what's going on and

your ideas and whatever and that requires like for me conscious like effort and that's also one of the things that become more and more important because the more senior you get less kind of isolated you can afford to be like i'm pretty i'm pretty introvert like i'm i'm best with but just by myself so having that whole thing about going out and whatever that's that's an that's an effort and out and whatever, that's an effort. And it's an effort. That's something that gets more and more important the more she there you get also. And for communication, I assume you mean both verbal as well as written communication. Yeah.

And how did you get better? So that's actually how we first got into contact with you is reading these blog posts, which we'll link, are amazing. And how did you get better over time in terms of writing yeah it's one of those things that people ask me sometimes where i'm like i don't have a good answer and i don't know like because i didn't really i don't know it and it probably sounds like i don't know awful or whatever but i didn't really sit down and think, oh, I need to get better at writing. I think it's, I think most of it is probably just practice. You just get it done. Get it out with, don't think too much about it.

Like I have, of course, I have some techniques that I use when I write stuff, which is really about, again, really mimics how I do software engineering also, which is about getting something in, getting like the rough outline out there quickly. Not that, of course, you don't publish it. But like when I need to write something,

for example, I take a new document, add bullets for what I need, I want the content, move it a bit around. This kind of seems like a nice flow. Then I know that there has to be, well, this is something I guess I learned that there has to be a flow to what you write.

There has to be a message. You have to like read it and then think then you need to have found it interesting somehow and you usually do that by you learn something or you you read something that you didn't know or that was intriguing um and not too many things either so like a single topic where there's a clear storyline of like okay okay, there's some reason why you're doing this and then it ends up somewhere. And so I try to kind of sketch that out. Once I have a sketch, does this make sense? Then I pull in more. And then I basically just rewrite each bullet as like a section. And then that's it. And then onwards. I don't possess, for better or for worse, I don't possess the ability to rewrite and rewrite and rewrite.

I'm like, I write it and it's done. And this goes for like everything in my life, more or less. I enjoy baking and cooking food also, but I don't possess the ability to like, really like do the same thing over and over again to perfect it i'm like okay it's like 80 90 good good enough for me onwards yeah that's how you get things done in a way actually it is it is yeah exactly it is kind of how you get things done done also but it does sometimes sometimes it's also you can see you could get better if you just had the patience

to like sit down and try it again and just like do it five more times or whatever. But yeah, not happening. And I know that. I'm also realistic about it. Yeah, I think it's like, let not be perfect be the enemy of good. And I think there are many few things that actually require that perfection, like in pretty much software engineering and other aspects of life too. So you mentioned as a senior engineer, spending time writing code or reviewing code almost on a daily basis. Now as a distinguished engineer, as someone keeps growing on the IC

data, at least their scope keeps expanding, meaning they start maybe as a tech lead, then they become an Uber tech lead of sorts where they have. They're delegating a bunch of, I see what you did there with the Uber tech lead. So as an Uber tech lead, you're kind of working with a bunch of other tech leads, delegating some of the parts of design, you're relying on them to fit in a lot of the details. But it also means that wherever there is a fire, you kind of have to jump in where one aspect of the design and there is not enough clarity on what we should do, you bring in that pragmatism or business perspective or the other context to say, hey, this is the right trade-off to make.

And in those cases, it probably doesn't leave you enough time to, let's say, let me just spend an hour writing some code or reviewing some code. So it has to be extremely intentional. I'm curious how you go about balancing this. I would put it as leadership versus execution in a way. Yeah, you're completely right. It has to be super intentional because as you grow,

as you become more and more senior, people are just like, it's not as if your manager or your director or VP or whatever will kind of say, oh, let me just leave him alone. They will just keep on shoveling. If you don't say stop, let me just leave him alone. They would just keep on shoveling. If you don't say stop, it would just keep on coming.

So you just have to say stop sometimes. When I say sometimes, it's a lot. Where it's just about, because there's only so much you can do. It's not as if, oh, you're promoted to principal, or you're promoted to distinguishing. Now suddenly you have much more bandwidth. That's not the case, right like you're still the same person so so so you really have to like spend your time wisely and i think different people have different opinions on what does wisely mean and i have a very strong opinion that as an engineer you need to build stuff and that means

writing code that means reviewing code That means being hands-on. Doesn't mean 100% of the time. But to me, if you stop doing that, it's like a time class. As soon as you stop, it just starts going down. And you feel what is going on. Also, you respect from your, not necessarily your peers, but all the teams who actually do need to execute and where you rely on their trust

and goodwill to kind of get a lot of stuff done, they will kind of start perceiving you as more and more distant if you kind of stop being hands-on. So you can stop being hands-on for like a day, maybe two. And maybe you think,

oh, it's working out pretty nicely. Maybe you do it a week, maybe you do a month and it's kind of still working out. But then after a couple of months, you're like, fuck, oh, it's working out pretty nicely. Maybe you do it a week, maybe you do a month, and it's kind of still working out. But then after a couple of months, you're like, fuck, sorry. That's okay. Or maybe you actually don't see that because it's not like a moment in time.

It's just you're slowly drifting away from where the action is. And all the people who are there will also see you drifting away to like, oh, you're only doing meetings, or you show only like, you show up when there's something important or you show up when there's a presentation to be made or a credit to be claimed if people are really pessimistic about the whole thing. So to me, it's extremely important to kind of stay in touch and grounded

because it also keeps you away from these grand ideas we also talked about before, look good in a document on a whiteboard or whatever. But like when, when it really needs to happen is that it doesn't really fit any longer. Uh, so to me, super important. Every single VP director type I have talked to agrees. It's important.

I would say probably close to not a single one of them, maybe a couple, will actually do anything about it to preserve that. So it's really up to yourself. It's really up to yourself to kind of just stay in touch. And so that requires you to prioritize your time. And you cannot do it very explicitly. I've always just said,

well, I kind of ran it more on a gut feel. I have some stuff that I think is more on a gospel thing i have some i have some stuff that i think is fun to do and i have some stuff that i know i need to do and then there's some stuff that i really don't want to do but i just have to do and i kind of try to like balance it somewhat somewhat equally and then i think the whole thing about saying no and again you go up you go up the ranks and you see more and more like you're flying closer and closer to the sun. The sausage factory is a big factory, right? There are many clean rooms until you reach the core of it.

But the closer you get, the more you're also like, okay, if I'm not doing this, then who is? So your consciousness will also start playing, at least for me, my consciousness will kind of start playing. It's like, hmm, this is stuff that if I'm not engaged in this, like it might not end well. So maybe I should be engaged in this.

Meanwhile, there might be other things where I'm like, yeah, I could be engaged in it. But why? Like, does it make any material difference if I am? And in many cases, no. It's just because there are already plenty of senior people. Maybe there's not a distinguishing, but then there's a couple of principal engineers in there. They can do their thing.

But if there's something where somebody else can do it, then why should I do it? And that's how I think about saying those things. It's like, okay, am I absolutely needed for this? If the answer is no, then I might do it if I find it interesting.

But otherwise, I can just say, just leave me out of it. And maybe I just don't go like seek it out because you should also be careful about what you seek out. Like if you don't,

if you're not part of something, just keep your mouth shut. Don't, don't like spread your opinion about something where is that you're not part of it. But also if you're kind of asked, oh, could you please join this? I'm like, I don't know. Seems as if you're doing pretty well already.

We can, of course, just talk about it once and fine, but maybe I don't have to like be part of it as such. If you just need a bit of advice, sure. But yeah, I don't know if that answers your question as such. No, it does. I think it makes sense. Like order describing makes sense where you're being intentional about how you spend your time that involves saying no to a lot of things delegating

effectively, where it's like if someone else taking care of some of the decision making where you don't need to be the one in war, then you kind of hand that off. I think, contrary to that, let's say when it comes to writing code, because in a way, when your scope expands, you're accountable for something that's larger deliverable. And there is more than one team working on pieces of it. And typically when it comes to implementing aspects of those problems, teams are more or less self-sufficient, meaning like there are enough engineers on that team who will be able to get to a solution, may not be perfect in their literate. But then when you want to spend that time on, let's say, writing or reviewing code, because there's so many of them, like in terms of repos that you could look at, code that you could review potentially more than you have the time for, how do you pick what you actually contribute to? Either way, a review or

let's say actively writing code. And the reason I'm asking that is because it can also signal something different to the team if they don't know how you operate. Because if they see a PR from you once every week, they're like, what's really happening? Why? Why is this person picking on my fears? Am I doing something wrong? As opposed to them knowing that this person's involved with this code base for a while. So I'm curious, how do you go about this? Yeah, I think that I'm not sure this's like a perfect way of doing it yeah i think first of all you're completely right that less time you kind of guess that gets to spend on writing code even though you kind of want to spend some some amount once you kind of reach a point

where you're not coding like full-time or even like half-time or maybe quarter time it gets really hard for you to be like in critical path of more or less anything. Like if there's features that need to be delivered, it's really hard for me to promise, oh, I can get it done by this time. By this date, I will be done with this thing because you never know, like that's the time you're coding is like, yeah, it's all over the place. So I would usually not do, I would try to not do too much of that where I'm like, well, the, my output is strictly required.

It might help for some small things, but owning like a big chunk, it doesn't really work because there's no way you're going to get that done in a reasonable amount of time, then you have to team up with somebody else to have the true ownership, then you can do some of it. And then I personally did a lot of like, just like cleanups and bug fixes and refactoring and at the Uber, we moved to monorepo. And then that meant like, okay, so now we're in monorepo. And arguably, if you're monorepo, we should also look at like code reuse and like not having duplication all over the place.

So I spent a fair amount of time like, okay, we're doing this over here. Let's move that into a library, reuse that. Do this, library, reuse that instead. It's not like maybe it doesn't change the feature that you're implementing, but it just sets us up for success later on. So I spend a fair amount of time on that. I think one of the negative things about that is, of course, to say, well, for two other engineers, that might be okay.

So you get to do all the fun stuff or whatever. You have no accountability because you're just like moving stuff around or whatever and it's true to some degree that that can be a perception I think

but I think it's again about mixing it up a bit so yes much of that but also just like if you're actually contributing to building features

just small things I think that has a lot of value and then I think as a one of the things that I also did as a senior engineer

was there's a lot of value and then i think as a one of the things that i also did as a senior engineer was there's a lot of tooling that is pretty shitty yes but people just live with it and i i have a very low tolerance for tooling that's shitty if there's an alternative sometimes it's like okay we're just laying a bad world and then whatever but there's also just cases where it's just bad because nobody's looking or bad because nobody's thinking and then people just accept if you have like a team who's doing like developer experience and they're saying they're saying oh everything is fine like we are we are just on on track and our roadmap is like awesome but then on the other end you have to engineers who are like well this doesn't make any sense and like it's broken all the time or whatever but they

they might not be comfortable kind of reaching out even if they do reach out they might actually just be like brushed off but if you have a senior you know who comes along and say your your sucks it gets fixed next day yes exactly suddenly oh there's a lot of stuff that needs to be and and of course you have to be and and of course you have to use that kind of power with some responsibilities like you can't just like do that all the time but giving that voice to engineers who don't have the courage or the responsibility like the whatever to kind of reach out i think that's that's also a big part of it

and again you only know this because you're actually using it yourself and you're gonna you're gonna And you're getting impacted yourself also. I think there's a key part to what you just mentioned there. I think to be able to recognize the parts that you could move around into a library or to be able to recognize tooling that could be improved. There are a few practical things which I don't think are always true, but should be in this case. Like make sure you have your dev environment always ready to go not that you haven't touched a terminal in a

while the other aspects are like well if you are in meetings where things show up with certain problems just go look at the code and you'll identify maybe how the things that need to be changed and those could be the things you could do in your spare time or when you carve out time for coding you could pick those things up I think yes looking at active code is part of recognizing the problems that you could actually work on yeah which doesn't happen i think i think another example is so we had a fair amount of incidents so how is what it is and but the question is okay so how do we then what do we do about that how do we fix it and there's always like the cheap answer is

oh you have an incident review and somebody did a bad change. Like in retrospect, a bad change. But of course, the change was made. Somebody reviewed it. It was still bad. So now we can, of course, just blame whoever made it and we can blame whoever reviewed it. Usually that would be, okay, how could we have prevented or we could have written better tests. And yes, had you known that this would fail, you could indeed have written a better

test, but you didn't know that it was going to fail. So you didn't write a better test. So the cheapskate answer is like, you just say, oh, we're just going to write more tests. And then everybody, oh, yeah, we're going to write more tests. But you don't because you don't know all these things. So I think that's also a case where somebody needs to take a step back and say, there's something else wrong. We can't just say, oh, we just need to write more tests or we need to increase our coverage because it's not really an answer to the actual problem. Because the actual problem might be that our systems are too complicated or we don't understand the interactions or it's too loosely typed or whatever it is, there might be many different answers as to how do we actually prevent it on a systemic level instead of just doing the knee-jerk reaction of more tests or maybe more alerts is another variant of that.

Oh, yes. And that also requires somebody who, and I'm not saying it is always me, just in a general software engineering sense, it requires somebody who has a broader picture and both understands how does the code work, how does our processes work? What is the overall system architecture that's kind of got us here?

And how do we then kind of, what do we do about it? Going back a little bit. So one thing that you said that was really resonating was like the sort of the respect aspect that you get from just staying in touch with the code. I wanted to see like your take on if because for me i thought that was super real i like i wonder how much of it is actually being able to understand what's going on versus some part it's just like emotional sort of like having the sense of camaraderie of like oh yeah this person knows that shit that i have to deal with and do you think that's like i I guess, can it be overstated?

That's like a huge part of why like someone even in management should like spend time doing that. I have, I have had the same kind of thoughts. Like is it an objective reason or is it all emotional? It's probably a mix. So we got a new VP of infrastructure at some point, a platform engineering at some point. And I felt he was struggling a bit getting his message out there, like what he wanted to do, the things that he wanted to do, kind of getting people to actually understand that and to kind of back it up.

I told him at some point, in my view, and I might have expressed it in a different way back then, who knows. But in my view, there's a significant material difference between a senior software engineer saying something and a senior VP saying something. If you read it off from a script, the same words coming out of two different mouths, that will, to me, make a difference. And it might just be me projecting myself, but I know if I'm in front of a senior engineer

who I trust and look up to, to some degree, and there's a VP who, the unfortunate thing is you don't quite trust because they don't have this building thing going on. Like if they say the same, there's a difference. And when I said this to him, he was like, no, but that doesn't make any sense. I don't know. Let's just say it doesn't make any sense, but it doesn't change the fact that's how it is. Maybe it shouldn't make any sense. Who knows?

Because you're saying the same thing. So it really shouldn't make any sense objectively, but it does. And is that fair or unfair? I don't really know. But I do think it is based on the fact that the people you trust, and unfortunately, you tend to trust people who are

i guess more like you and i'm not i'm not kind of advocating for for like a completely uniform culture or whatever but people who have gone through the same things that you have that can can kind of relate to the challenges that you have or that you have had i think it's much easier for you to like understand why are they saying something. To me, if you want to do a top-down push for whatever, and that's going to create a whole lot of... You just know it's going to create a lot of trouble, because realistically, also most engineers are a little picky anyway. You can't just tell engineers, oh, now we're doing this

because everybody will ask why. Like, why are we doing it? But if you have an engineer next to you who is kind of bought in on the plan, I think the chance of success goes up significantly because you will get, you'll be able to get this buy-in.

And when I say engineer, I of course mean somebody who has the trust of the rest of the organization. It doesn't really help if you hire a new one, day one comes in and say, oh, we're going to like whatever change from, I don't know, go to Rust. Maybe it's a good idea, who knows, but it will probably meet a whole lot of resistance just like that. But if you have somebody who can kind of come up with a can present a viable technical argument as why does this make sense it doesn't have to be fully sense there are times where

stuff just doesn't have to make sense but you're like okay it just becomes just because it doesn't make sense we can still make it an engineering challenge i think that's just much easier to get support for something like that from engineers if it comes from an engineer and again i do think most of it is emotional the truth doesn't really change right like if something is a good idea it doesn't really matter who it comes from like that's true whatever meritocracy is like whoever has the best solution wins but it's unfortunately not how the world is so i do think there's a difference but i do also i think a lot of it is just emotional because i think we people are just

emotional and we have to deal with it yeah yeah yeah if you try to ignore it that's basically also back to the whole thing about junior engineers have to be good at communicating both inputs and outputs it's the exact same thing if you're not able to do that if you just look at from that purely technical perspective then you might get a bit of the way but you will never get far yeah i think there's another aspect of the switch where you have the senior engineer who is laying out this viable plan of a project which seems very ambitious and challenging.

I think having an engineer kind of describe that at least in my experience puts the team at a little bit of an ease knowing that they'll have some guidance and direction on an ongoing basis from an engineer not just management is telling them to go from let's say go to a store, whichever language to this other language or whatever migration they have

to this. No, we'll have this constant guidance. There is someone who is accountable along with us and they are bought into the plan itself. Yeah, I do want to say that again it's kind of back to that whole time glass thing about if your time glass is almost empty, it's not going to help. But if it's almost full, it's going to have a lot.

So that's why, again, if you're kind of constantly in touch with engineers and building stuff and reviewing all that stuff, your chance of success for doing these big changes will be much higher than if you're out of touch. Because if you're out of touch, you might as well be a manager or VP or whatever at that point from this point of view. Totally agree, totally agree. So a couple of points.

Guang just mentioned mentoring and you have a really nice post on LinkedIn about mentorship. By the way, you have a lot of good posts and we'll link to all of them in our show notes. And we highly encourage people to go read them because your writing is really good. In terms of mentoring, there's one thing which you mentioned,

which at least I haven't seen very commonly mentioned elsewhere, which is being very intentional about who you mentor. And can you talk more about that? Like, what does that really mean? I think it's kind of part of the other discussion, right? About you only have a limited amount of time. And you don't have to be like, oh, I need to like spend 20% of my time on this

and 20% of my time on this. It doesn't have to be like that intention. But you do have limited time. So you should use it wisely. And how do you get the most of it from an inventory perspective? Well, I think of it as like you're blasting, right? Like you're blasting out,

and it's going to have a chain reaction down the lines. So if you are mentoring, let's say you're mentoring five people inside the same team, well, the team might be 10 people. And then, okay, so the total impact of your mentoring will be 10 people. Of course, they're better than nothing, but if you're mentoring one team, one another team, one senior person, whatever, there's much more scope for them

to go out, because it doesn't really stop with you mentoring one person. That person will take whatever you do, if you're successful at least, because they will change their behavior. And in a lot of cases, that change of behavior is actually a visible one. Like that might not be that people are like,

oh, it's a new person. But in a lot of the cases where I've seen, the mentoring will actually lead to change in behavior, or can lead to change in behavior, like a better focus. Of course, my mentoring is all about all this stuff that I've written about. Like remember to write code, remember to be nice, my mentoring is all about all the stuff that I've written about. Remember to write code. Remember to be nice.

Remember to think about all sorts of stuff. And people go into the teams and do that in many cases because they kind of, oh, maybe it's not too bad of an idea. And that has an impact on the rest of the teams and other people they work with because they also see, oh, there's some new stuff that matters.

It seems pretty nice. So let's do more of that so so that's why i might have written waste about mentoring too many people whatever and sometimes you pick words that also to create a bit of a controversy but from a impact perspective it is kind of wasteful because you could have maximized your impact by doing it in another way and that's really to me what mentoring again i'm like an introvert kind of type mentoring doesn't come easy to me as such i like few close relationships rather a lot of like more loose but still so you kind of need to like pick them carefully i think it's really about thinking about why are you doing it. And if you're inside a company, you're doing it to maximize the company's output or whatever engineering effort. How do you go about picking who to mentor or who to go reach out to? Or is there a lot of inbound?

Usually inbound is quite enough. But there are cases where, and that's probably more on the senior levels, maybe you have a staff engineer or a principal engineer who you can kind of see has a lot of potential, but maybe that person doesn't quite know how do we kind of keep moving forward because the expectations change, the skill requirements change a bit. You can't just keep on doing what were you doing but some people you

also just want to help them out also because it will benefit everybody of course when i seek out people who's small on the senior end because that's also where the impact is really high if you get that right impact is super high how do you start that conversation it's like hey buddy see you're struggling over there why don't i no, I've never really been a fan of formal mentoring. We have a plan and we have a schedule, whatever. It's just about, we talk about things. And it's usually also a two-way street. I learn something about whatever they're doing. I think most of the cases, it's a little bit asymmetrical. So I might learn something technical about what they're doing

and they get more of the soft skills. Because much of the senior mentoring is really about soft skills. There's very little technical. You can talk about technical stuff, but it's usually all about how do you think about stuff? How do you behave?

How do you handle weird conflicts? How do you handle weird conflicts how do you handle politics whatever it is so i think it becomes a little bit asymmetrical in that sense which is fine i think it's perfectly fine but it also kind of gives you a nice entry path into like oh could you explain me how this system works or how you build this thing then you're already going and you ask how things going like interesting yeah like when the when they're like not looking for feedback i guess like intentionally like how do you i guess so the sort of the pretense would be like oh yeah let me

learn from you about yeah usually of course like you don't go up to somebody say i think you suck at this you should do this better obviously any variant of that i think mentoring and in almost all other things the best best outcome is that if the other person thinks it was his or hers idea so if you can kind of talk to him and say okay could we maybe also talk about how does a promotion look for for the next level yeah we can talk about that and usually those questions kind of creep up when you just start talking about work life and technical stuff and yeah so i usually don't go into it with like oh i saw this behavior you had or whatever we need to fix that it's more about like actually learning

about people learning about people and have them grow hashtag inception i like it i like it yeah so it makes sense in one of those blog, you mentioned that at Uber, you had this document called Being an Engineer with essays from different engineers across the company on different topics and practices. This sounds super cool. And I'm curious, how did this actually start? Yeah, it's a good question. The exact inception of it, I don't quite remember. So somebody might correct me later on if i take all the glory and fame but uber was and i guess probably still is a very like a promotion driven culture like you're hired and then you get

promoted and get promoted some more and people are like oh i want i also want to get promoted and people are like oh how do we get promoted and then i somebody doesn't get promoted and that person's like, oh, I didn't get promoted. It's like PDD. Yeah, yeah. And so my view on that whole thing is, if you do the things that I kind of usually advocate, like you're hands-on, you code, you execute, you deliver stuff, promotion will be like a side effect of that. It's not the primary goal, but it will happen.

And I know people who are like, yeah, it didn't happen to me. And I go, yes, there are sad cases out there for sure. But there's also just a lot of cases where you just weren't ready or you were actually doing the wrong thing. So at some point we decided,

okay, given that there's so many people who kind of are focused on this stuff and it really shouldn't be, people shouldn't be spending so much time on getting promoted. They'll be spending time on building stuff and by building stuff you get promoted not the other way around so we were like okay and i forget if this but like we had i think i started a document that was called something like how to beat the promo committee or something like that. Very provocative.

I like it. I bet it was the most weird document. Yeah. But which really was, and that basically became how to be an engineer. But that basically just describes how you're actually a good software engineer. Like, how do you write code? How do you ship stuff? How do you make sure you do good software engineer like how do you write code how do you like ship stuff how do you make sure you do good reviews all this stuff nothing magic about it it's just

the title was a bit uh uh provocative but but the reality was that so i've been in a lot of promo committees uh at the world uh back from like and uber has been through a lot of different setups of how it works from like super unstructured like wild west crazy to like completely promo committee with like many many documents that people have to write and like whatever but i have always looked for people who kind of do this thing about you write code you have a good balance it's not about only you write code but you write code you talk to a good balance. It's not about only you write code, but you write code, you talk to people, you communicate your things. If you build something, you go out there and make sure it gets used.

If it doesn't get used, it doesn't matter. All this stuff. But we've never really put it into a form where, to me, it was understandable by engineers. It was always like HR, whatever, kind of made these rubrics of like, oh, you expect to do this and this, but it was always like slightly like non-tangible. Intangible, yeah.

Yeah. So I think that's the way it started. We just wanted to like have a description of an informal engineering-driven perspective of like, what does it actually mean to work as a software engineer at Uber? It's not the one universal way of working as a software engineer at Uber? Like you could, it's not the one universal way of working as a software engineer ever, but this is the kind of the things that we believe that Uber values and also makes sense

for what we're actually doing. Not the less. It also has to make sense for the company, right? It can't just be about you building awesomeness from like a whatever, oh, you got 100% coverage and like whatever, but if it doesn't get out there, get used and yeah. So I think that's kind of how I started.

And then it kind of expanded from there to have like more and more people would just submit stuff and yeah, just, oh, this is nice. And then people write about commit messages or how to do stack diffs or whatever it is. Like a lot of different topics kind of within there over time. Sounds like one of the goals that this would also achieve is not just giving

people kind of a perspective beyond the HR guidelines on what a promo looks like, but also defining what the engineering culture should be to an extent, because it's coming from a lot of people who are senior at the company who are defining, how do you do engineering that results in building stuff that results in a byproduct of things that results into promotion yes are there other effective means of influencing the engineering culture that you've noticed as a distinguished engineer effective i think is a i think that's what it was interesting yes because culture like culture is really hard to like... You can't just say, oh, now we have culture or whatever. Our culture sucks, let's get a better one.

That's not how it works, right? Not something you buy, yeah. No, it's something that you kind of need to... If you want to be conscious about culture, you have to... It's a long play, right? You can't just... There's no changing in a day or week or month or even a year.

It's a slow, slow, slow process. And it's one of the things that we think we tried to do as much as we could. Like Uber, many people have been through a lot of like rough stuff. By now, most people who went through those things are no longer at Uber, not on the management level and not on the engineering level. But then the other thing happens is you get a lot of new people in and there's a lot of churn. And especially in COVID times where people also don't really meet any longer, you just sit at home and you don't really talk too much.

And that creates a different kind of culture. So whatever culture you want, I wouldn't say it has to be super conscious, but you have to make an effort to keep what you want. So if you want to have a builder's kind of culture, you have to nurture that in just the right way. And it gets really hard. One example, back to the promo stuff again,

I've seen a fair amount of promotions to semi-senior, like senior kind of staff level engineers. When they come from promo, they haven't really built anything for a while. They kind of start building and now they're just talking and designing or whatever. And I'm like, okay, you should build more. The other stuff is also fine, but you should build something and then come back when you just need to see more of that.

So get back on that and then come back later. And everybody kind of, well, everybody, I wouldn't say everybody, but a lot of people agreed on that, including management. And then one day Dara gets up in all hands and says, okay, code is actually so important that we're going to go, we're going to start counting how many pull requests people are doing. Not on an individual level as such, but on an aggregate level, just to check, like, are we moving, are we regressing, are we moving upwards?

Because we have been regressing for quite a while. So it kind of makes sense. And it also, like, the underlying idea is to say, like, building is important. We want people to build. That's the underlying idea. But of course, when people hear, oh, you're going to count. Oh, that can be perceived. People go completely berserk.

Number of peers doubled in a year. To a degree where it doesn't make any sense either. But that's why, again, you want the culture, but you can't just say you want the culture. You have to somehow hint at it without saying it, and you hope for the best. And that's where it's really inefficient, right? There's no efficient way of changing a culture. If you just want to maintain it, there are of course a lot

of ways. Like there's all this stuff about writing through promos, through meetups, through mentoring. There's a lot of stuff you can do to just keep it where if you're at a good place, keep it there. Even that requires a lot of effort. But actually actively changing it, it's like, I guess it's almost impossible it's not completely important but it's just very close to because it requires so much like intentional but hidden efforts of like yeah and it's such a manual it's just a manual thing that's like super interesting uh we're chatting with joshua who like commented on this sort of the pros and cons between like the hard power of management versus the soft power of like a senior pros and cons between the hard power of management

versus the soft power of a senior IC. And one of the things was how you can change the culture or influence it. But to a point, it's very much early on. You're setting, you're putting in these guardrails or systems to make people better engineers. But then to a point, once that's already set in place

and you're trying to change it, i think it gets really tricky but so you're you're a founding engineer at a new startup now like how are you thinking about it uh sort of kind of inceptioning the wow so much inception going on today um like the engineering culture like from day one like how do you think about that so i think first of all our initial team is mainly senior engineers who've like tried different things we like two from uber by now and we've all seen a lot of things we've tried small companies which are big companies we know exactly what we like and what we don't like i don't think we have a i think we're trying to stay naive to some degree and say we'll just pick all the stuff that we want to have and then we'll not do all the stuff that we don't want to have.

At some point that's probably going to break down. But I think we try to be fairly intentional about like, what do we value? Do we value building stuff? Do we value people like middle? I don't want to be too off putting on like middle management or whatever but i don't know to me it's a fact of life when you grow an organization becomes bigger and bigger there are more people whose work is like slightly undefined or defined by themselves and that means when they're hired they invent work and it's not always good work it's like pseudo work or meta work just because

you are paid you feel obliged to like spend your on something. So if you're in HR, well, maybe I'll come up with a promo process. Or if you are a project manager, like a middle manager, maybe I'll come up with some reporting tools or whatever so that I can create nice reports. But is this actually contributing anything in particular? In some cases, it actually might be negatively affecting the company. So we have this possibly very naive idea that we want to cap the number of employees at 150. 150 is all we're ever going to be

because that removes all that middle layer of meta work. Of course, arguably, you could say, well, 150. There's a reason why Uber had like 4,000 engineers, because it was not possible to build with like a hundred engineers. So how can we possibly build something? Because we want to be the same scale as Uber, like business-wise. But how can you do that? Well, I think it's a good question. We don't have all the answers. But I think there are two parts to it. One thing is, if you go to Uber now and you ask anybody in software engineering, whether it's a manager or a director, would you be able to work more efficiently with fewer people?

The answer is, I think 99% of people we ask will say yes. Fewer people, better. Okay, so why are we that many people? Well, again, you're hiring somebody to hire people. What do you expect happens? What happens? Well, you hire more people. And they don't all have good charters.

And there's a very big reduction to like, so you have one group of people that are doing whatever. They're doing one thing. They have another group of people doing another thing. They have each of their manager. Now, if you want to do either a third thing or make it more of one, are you actually going to move people from there to there?

Very rarely does that actually happen. Almost never. Unless people actively say, I would like to try something new. Could I maybe go over here? Then they go over there. They get a backfill. And then it's back to normal. So this whole rebalancing of resources almost never happens.

That just leads, again, to waste. Because you're building things that might not be necessary. And to be honest, we've had discussions sometimes sometimes of like i will keep on building on this deployment system just because we have the time or is it actually the thing that makes the most sense for the company and it gets really hard to like either it gets really hard to judge as like somebody who's building it almost impossible but i i truly believe that if you are super tight on prioritizing what you put your effort into, and you don't start building everything yourself, you just use what is out there. And yes, maybe it will cost a bit more, like in dollars.

But the gain in just like company efficiency, I think will outweigh that. And then, of course, there's a whole, we're doing AI, right? So the promise of AI is, of course, that you can do more with less. So that's what we're building. We're building more with less. And that's also what we're selling. And if we cannot apply that to ourselves,

well, we have kind of failed anyway, so it doesn't really matter. So anyway, so I think that, I don't know, it fully answers your question, but at least we try to be quite intentional about what we put our time into, what kind of people we get on board. Also, I'm a lot about building and executing. I also fully realize that it's not the only type of people we need.

So being conscious about what are the exact people we need or the exact profiles we need for the things that we think we're going to build and then be picky about what we're actually building ourselves, what are we buying, what are we just saying, this is going to be too hard or too wasteful or too expensive, let's not go there. So I think that's somewhat. And as I said, we have a lot of senior engineers, we have tried a lot and we are fairly aligned with all this, all the stuff that I've been writing about. Half of it is actually just also explaining

how do we want to operate as a company i see i see i see that makes sense a lot of it a lot of it is actually just to explain to candidates so we don't have to talk about it we just made it pretty effective i would say um how did we come up with the 150 number actually like that's very specific yeah it's like it's one of those things right it could be having 200 it could be having 100 but like 150 seems like a it seems like a good number i i forget i think there was i might be completely off base here but i remember something some some study done where it said like beyond 150 the communication channels start kind of getting down there is something about how many people can you reasonably fit into like your mental model and that is just around 150 it's not like a completely random random number there are some i think it's like a pseudoscience

i would probably say but yeah uh like deciding to go from uber to a startup i mean a lot of engineers at big companies especially in a position like yours have a ton of opportunities like you could have decided to go almost at any place any other startup or any other big company too what made you decide to start up at this point yeah so i wouldn't say i was like completely like i just need to get out i need to do something else but i had been considering like maybe it's time to kind of do something else the culture at uber i think felt kind of was changing a bit wasn't quite what i wanted to do any longer uh so i was like i'm looking then what like what are my realistic options uh and yes i

could go to a big company there aren't that many of them out there, right? And many of them have, I don't know, reached over the past year or two, the reputation has kind of gone down quite a bit. Like Google is not, it doesn't seem like a place where people like want to go. They go there because of whatever the perks or whatever. But there's also, it seems there's a company, like politics and whatever.

And like your personal impact is like almost something you cannot measure in any way. Facebook has also gotten a fair amount of heat. Netflix, I don't know. And also like if I were to go somewhere else, like what would I actually be doing? Would I build more? I had offers to go to other big companies. We're building like a deployment platform. Like you can go build a deployment platform companies. We're building a deployment platform.

You can go build a deployment platform. I kind of built a deployment platform. I didn't feel it was shit. So I'm not sure I want to do it again. I don't know. It also took quite a while. And I'm sure you want me to come in and then just be done in like six months or whatever,

and then we're done. That never happens. No, done. That never happens. No, exactly. It never happens. So how would it actually look if I were to go to another company? And I wouldn't say I was fearful about it, but I've seen senior engineers come and go, and usually they come with high hopes and expectations, and they leave defeated.

And a lot of unfulfilled promises. And I think a lot of it is because when you're like a senior engineer or senior like manager for the vp kind of type you come in and like you're kind of hailed as like the person who will fix a lot of problems where like realistically you're not going to fix them as such you're going to work on them over time you might be able to fix them but you don't it's not as if you coming in in itself will fix it and then the thing is you come in and you have no maybe you know a couple of people worst case you know nobody and now all that trust that you had all the reason why you were able to get stuff done it's now gone and you have to start from scratch and in a lot of cases there's not a

whole lot of time to start from scratch you maybe have a month and then two months or whatever but that's not a lot of time to like build all this the the trust that you need to get stuff done and of course also just understand what is going on and maybe if you're unlucky enough the thing that needs to be fixed is like locked in some kind of weird thing where politics or whatever some people did this some people that they cannot there's no way they can kind of agree with each other like what are you supposed to be thing where it's politics or whatever. Some people did that, some people did that. There's no way they can kind of agree with each other. Like, what are you supposed to be doing? You cannot fix that.

Then there might be like a CEO level decision that needs to be done before you will be able to do what you should be doing. So the whole idea of kind of doing that transfer wasn't particularly attractive to me. Especially because it wasn't as if Uber was like complete shit. If it was, then maybe it would have more... To me, at least, it wasn't. But there was still something.

And then I was like, okay, I could also go the other direction. Like a startup is always... It sounds appealing, right? From the, like, oh, you're like sitting there, they're just having fun, doing all the new fancy stuff. Like, who wouldn't want to do that? Of course oh you're like sitting there they're just having fun do they all the new fancy stuff like who wouldn't want to do that of course you're like yeah yeah of course you're like you're

like 45 you have kids and you have a house and you kind of get used to the pay so like how to there's something about reconciling those things um but then there's also like, I have my personal opinion is, I like building technology. I like building infrastructure. I like it a lot. But I've been at Uber and I know like, we were like, oh, couldn't we, why don't we use this open source thing? You know, whatever. Why don't we just buy this? I'm like, yeah, it's kind of expensive, and there's a lot of hassle. So there's also reasons why a large company doesn't just go out and buy something, especially if it's like infra-level stuff. It's super hard to sell.

So that's why I'm like, okay, so if I go to a startup, I cannot do a startup myself. I cannot be the primary founder of a startup because I have no ideas. I have no ideas where I could come up with something that I would buy myself. I cannot be the primary founder of a startup because I have no ideas. I have no ideas where I could come up with something that I would buy myself

that I would actually pay for or be able to convince people that we should pay for it. I know just about no infrastructure. Of course, there's AWS or whatever, but that's kind of taken.

But there are very few infrastructure projects out there where you're just like you can build a big ass business on it and it's like it's something that you can actually sell yeah it exists that's not to say it doesn't exist but it's just like i cannot do that and i would also much rather have something that i can actually explain to non-technical people. I would much rather work on something where I can explain to my mom or somebody I meet on the street, oh, this is what we're doing. Like Uber, we could kind of explain it, even though we were a deployment platform,

it could really have been built anywhere. It wasn't really Uber-like at all. But it was still like a business story. And I would like to be in a place where I could say, okay, there's a real-world problem that we're solving that affects real people in a relatable fashion. Now, it's not as if they're just floating around out there, startups waiting to be taken. If only.

Yeah, if only. But then I had the... By chance, I met up with a guy I worked with before who also founded the company I worked at before Uber. And he was like, he also wanted to do something new. And he was like, oh, we should do some AI stuff. And I was like, yeah, sure, AI. And I was like, crypto, AI.

More or less the same. I don't know, a lot of hype. A lot of value. Well, a lot of value well a lot of value but like unreason like value that cannot be reasonably explained

yeah but then but then we started talking about it and we came up with something maybe there is actually something

where we can actually build something that would actually make sense and he's like more of a business person he has like a vision

and he has a huge network he's raised like a lot of money I guess close to a billion dollars so he has like a vision and a huge network he's raised like a lot of money i guess close to a billion dollars so he has like network for and we did enterprise we did like an enterprise company before so and we're doing enterprise ai now and it requires a a nice big network and it requires funding it requires a lot of stuff and so he had all that business side of it and i had the

technical side of it okay maybe this is not too stupid. And then we kind of went from there. And then at some point we were kind of working on it in the weekends. At some point we were like, okay, I can see where this is heading. I also know where my mind is at. So this is kind of, we just need to do this now.

And then here we are. Yeah. Oh, yeah. The infrastructure space, I would say, selling to engineers is probably the hardest because every engineer would be like we can build it in a month

why would we buy this thing yeah exactly and even if you manage to actually sell it to the engineers the engineers have to then sell it

to them oh yeah absolutely and that's even worse absolutely so we're coming towards the end of our conversation

but before we let you go we would love to know what you're building at Beyond Work I mean you've talked about AI you've mentioned it but can you tell us

more about what you're building yeah I think we're on purpose trying to be a bit vague about it and it's not because we don't have anything

but we're trying to paint this what's called event horizon almost of like we talk about how we work, where we work, things we're doing, but we don't actually talk about like.

What exactly it is. Strategically. You're teasing a little bit. Okay, okay. That's fair. No, but we're talking about that. It's not that it's like super secret or such. But basically what we're building is using AI

to solve what I call stupid work, which is all the work that when you have a company, it's all the work that you're forced to do that is not related to the core of the company. If you are a carpenter, and I'm not saying we're kind of building for carpenters, right? It's just an example. But if you're a carpenter, you go out out you use your hammer and chisel or whatever you do carpentry stuff wood woodworking whatever it is but then you also have to do invoicing and you might have some employees so you have to do hr you have to go do contract management you have to do payment management you have to do invoices

credit notes you have to send out reminders all this stuff reply to emails I don't know how many emails there is in carpentry but whatever but there's all this process that's just to have a company you need to do but you're not really good at it

and you probably don't want to do it so what do you do? well you probably use different systems but now you just have like you have an invoicing system and then you have the support system and you have some

time management and you have expense whatever there have all these weird systems out there so okay so now you're that far but you're still in many cases like transferring from each system to one substitute the other getting an email copying from there to there there's a lot of things that even though there are computers involved there's also just a whole lot of people involved and as you scale this up like a carpenter yeah, he might spend an hour or two a week, not a big deal. But as you scale it up, if not linear, it might actually become more, not exponential,

but it's more than just linear. As you scale up the company, you get more and more of this weird process. And you end up with these very large enterprises that might have thousands and thousands of people sitting around, typically in like maybe Eastern Europe, India, whatever. And like what they're more or less doing is the work of a computer.

But because the computer is kind of stupid, it cannot do it. Because they take data from one side, pass it up and put it into somewhere else. And that's more or less always what's going on. You only deal with have those sorts. Yeah. Maybe the data is an email. Maybe the data is an XML file that you need to kind of copy something out from because it's in

XML, but there's a node field somewhere. You need to take some stuff out of the node field and put it into another field that you know. So why is this? And that's because computers are pretty stupid. Because you have unstructured data coming in on one end and you need structured data on the other end and ironically the irony is there's not like unstructured because it's actually formed usually it's

it's actually formatted might be an xml file json file a yaml file whatever it is but it's not formatted as you want it and and usually it's also formatted in a way that there's like another one-to-one mapping. So once there's not like a one-to-one mapping, it kind of gets hard for computers, as it kind of was. But with the rise of AI and LLMs, it's actually much easier to get a computer to do it not again, not 100%, not perfect, but pretty good. So if you can build a system that does that and you can also build a system in such a way that pretty good is good enough then you're really onto something at least that's our that's that's at least how we see it then you're onto something because there's there's so much waste going on in a lot of large enterprises

and they all know it they almost desperately want to get rid of it they cannot get rid of it but by by using a system like ours and again i haven't really talked about what it is or how hopefully soon hopefully soon yeah exactly but using a system that can use ai to reduce the burden of this work if we can manage that i think there's a very large opportunity to be had there so that's basically what we're working on for sure for sure and we have something running and we have a system of customers trying to keep it like a yeah no that's pretty cool uh maybe when you're talking about it a little more openly we would love to have you back on the show uh and talk a little more about it beyond work and

you're okay this has been an awesome conversation we have learned a lot and i'm sure there's a lot for our listeners to learn as well people can find you on linkedin you have awesome posts we'll link to all of them as well as your profile in our show notes and we highly encourage people to check it out and you're welcome again thank you so much for taking the time this was awesome yeah thank you very much for having me it was a super pleasure thank you so much hey thank you so much for listening to the show you can subscribe wherever you get your podcasts and learn more about us at softwaremisadventures.com you can also write to us at hello at softwaremisadventures.com

we would love to hear from you until next time take care