Uber Distinguished Eng On Unfair Promos, Influence, Engineering Regrets (Career Story)

Joakim Recht grew to a Distinguished Engineer at Uber and I asked him what it took to get there. We covered his full career including the project that got him promoted, what makes a great software engineer, and learnings from promo committees. 𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀: • Transcript: https://www.developing.dev/p/uber-distinguished-eng-on-unfair • YouTube: https://youtu.be/feNh_ubBAMI • Spotify: https://open.spotify.com/show/0MX9PyeCzDhdlyRv6slwIX • Apple: https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835 𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀: 00:00:00 - Intro 00:00:56 - Distinguished promo project 00:19:07 - How to grow your influence 00:22:38 - Unfair promo story 00:33:09 - On delegation 00:39:05 - Why engs don’t trust management 00:47:58 - Politics as he grew 00:57:00 - How to pick mentees 01:03:22 - Why he left Uber 01:15:16 - Biggest Uber eng mistake 01:20:15 - Uber scandals 01:24:35 - Advice for younger self 01:26:14 - Outro 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗝𝗼𝗮𝗸𝗶𝗺: • LinkedIn: https://www.linkedin.com/in/recht/ 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  A software engineer needs to write code. If you're not writing code, you're not a software engineer.

• 0:04Ryan Peterman?

  This is Yoakim Rekt. He grew to be one of the few distinguished engineers among thousands at Uber. And I asked him about how he did it. What are the typical ways to have your work influencing more and more engineers?

• 0:18Speaker 00

  I like the idea of you becoming a forceps supplier by allowing other people to work better and faster.

• 0:23Ryan Peterman?

  He was also on a ton of promo committees, so I asked him about what most engineers never get to see. What does it mean when you're saying promos are not fair sometimes?

• 0:32Speaker 00

  It gets super unfair because it all depends on how good is your manager at presenting your case? And if you are a shit manager, you have a shit case.

• 0:40Ryan Peterman?

  Is there an engineering mistake that you saw happen at Uber that was only obvious in hindsight?

• 0:46Speaker 00

  And maybe someone is going to be super angry about this, I don't know, but.

• 0:51Ryan Peterman?

  Here's the full episode.

• 0:56Ryan Peterman?

  What was the initial problem that you were solving and the story behind the project that eventually got you promoted to distinguished?

• 1:03Speaker 00

  Not that long after I started at Uber, we were at the local office in Denmark. We had been tasked with building a new data store for Uber. Like previously, we ran on just Postgres, single instance, like just a big ass machine and a lot of replicas and stuff like that, but like a single database. And that was kind of projected to run out at a certain point in time. So before that point in time, we had to have a new data store in place. So in the office, we were building a new, kind of object stored. That's called Schema List. There's also that stuff about that out there. Schema List is basically based on sharded MySQL.

• 1:40Speaker 00

  My job was primarily handling all those MySQL shards, managing and operating them, monitoring, scaling, all that stuff. And in the early setup, it was basically just like bare metal, puppet and MySQL. And so every time you had to do a promotion, a master promotion or any kind of maintenance or replacement, you had to do some puppet mangling, login, mangle puppet, hope for the best. And that was kind of, it was pretty hard and it got harder and harder because the system kind of. Scaled more and more or groomed more. And so at around that time also, like it's not that Docker was super new at that point in time,

• 2:23Speaker 00

  but consideration was fairly, fairly new concept still. Some people are using it, some people weren't. Kubernetes, I think, was out in like, it just got released in the like the first alpha version. Just around that time. So I had the, it's like I, at some point, we kind of start talking about it. I was like, why don't we actually just run the databases in Docker? So that we can both run different MySQL versions more easily. We don't have to like, have the entire host. We can actually run multiple databases on a single host. Because when you run this sharded MySQL thing, it's a bit expensive. If you want your own database and that then requires probably at least nine physical servers to run a database, that it gets pretty expensive, especially because you're not going to utilize it.

• 3:09Speaker 00

  So why don't we, why don't we virtualize or continue to write some of that so that we can improve? So we can improve the utilization, but also it becomes much more easy to manage. If we then also get, take that idea that's become very common now, but was very uncommon back then, which is let's define what we want to have, like a goal state or an intent. And then have a system that can kind of take you there. So you don't have this procedural promoters, promote a new master or replace something. You just want a cluster that needs to have nine, we want a database, we'll have nine, nine individual clusters, three nodes each, and then make that work and don't care about the details. So that was basically the idea, like roughly. We built that for Schemaless first and that worked out pretty well.

• 3:55Speaker 00

  There was like a whole ecosystem around that was also monitoring and management and version control. It was like, it was like all ready back then. It was like Git Ups, I have like a somewhat a version to Git Ups. Because Git Ups is like a one way thing. You push something, you hope for the best. There's not really any, there's no feedback involved. So you don't really know if stuff is going to work or not, or how far it is. And there's no orchestration. So we built that, the whole orchestration layer and monitoring on top of like a traditional Git Ups, Git Ups strategy. And that kind of took off and it made us. Much better at scaling and much better at monitoring and much better at operating. And so over time, we were like, okay, so we did that for that part.

• 4:39Speaker 00

  And then the next idea was basically, why don't we, why don't we do that for all the different databases that we run? It was basically what became the Odin effort. We were basically just, can we build something similar? That can run, work for any kind of stateful technology? So that we, so that ideally we have a single team that can operate an entire fleet, doing host maintenance, doing database management, doing scaling, all that stuff. Which was previously every single, back then, every database technology had its own team attached to it. And they did bare metal, they did host management, they had host monitoring, provisioning, decommissioning, database management, all that stuff.

• 5:23Speaker 00

  And it was just a lot of, everybody had their own tool chains, it was super wasteful. So basically the idea was, can we actually, can we, can we make a single platform that can handle all that? And that, that basically then became, yeah, Odin. And that took a while. Say that. For many reasons, like, there's, there's organizational, like, or like, there's just people, because they already built, many, many teams built their own tool chains, like, why do we, why should we use something else? But from a local point of view, it's like, doesn't make any sense. And so it just took a while. And while it's like, yes and yes, to convince everybody that was actually a good idea and then actually get it rolled out. And also getting it to work with, like, technologies that are not, that were, that are inherently

• 6:08Speaker 00

  not like a cloud ready or like, can contain already, like HDFS for example, or Kafka used to also be notoriously bad at, like, moving stuff around dynamically. It's like, just not a thing. Because like usernames are encoded everywhere and port numbers and like, you need to shuffle data and there's no good way of shuffling data really. So getting all that to work, it just took a lot of time and effort. But basically, this, but basically that, that project just grew and grew and grew in scope. From like a very like, a single thing where we just need, we need, just need to manage our own team and stuff, to actually managing the entire company on the stateful side.

• 6:53Speaker 00

  And when I, when I left, it was actually running all this, like, all the stateful workloads at Duol, which is like.

• 7:00Speaker 00

  I don't remember the exact numbers by now, but like when I left, I think we had like around one hundred twenty thousand physical servers under our control. And like around half a million like databases. Uh, so like all co-located and whatever and running on being being kind of operated by a team of twenty-ish people, which to me is like pretty insane. There was still like database teams that did the actual database, like Cassandra, MySQL, like expertise, but just the fleet management part of it. Um, like the ability to be able to operate a kernel with a single click. Uh, or rotate like decommission data centers or commission new data centers, all that stuff, which usually takes a whole lot of manual effort.

• 7:44Speaker 00

  Uh, that's that kind of over time got got pretty advanced.

• 7:48Ryan Peterman?

  Am I understanding the initial motivation was two main things. One is the the fragmentation of the machines. So not everyone needed a full instance. So you could save a lot of capacity. And then the other one, it sounds like maybe even the bigger one is the dev velocity or the engineering time savings, because you don't need as many production engineers to manage all of these instances.

• 8:12Speaker 00

  And also just the consistency of of that part. Like you want the kind of the same availability all over the place. You don't want to have everybody invent ways of making sure that servers are working and when do you discover something is broken? Uh, when, how do you discover that a disk doesn't work anymore or whatever it might be? Like you don't want everybody to go around doing that by themselves. You kind of want that to just be done once.

• 8:37Ryan Peterman?

  Sounds like you didn't have a grand plan for it to eventually be all of managing all of Uber's stateful workloads. So what is it that you saw at the beginning and how'd you convince people that you should start using Docker for databases?

• 8:53Speaker 00

  Well, so one of the good things about Uber, especially in the early days, was there was just a lot of freedom. That freedom also came with a lot of cost. I think at some point, somebody counted that we were using at Uber, there were like something about fifty-two, maybe different databases, technologies in use in the company, which is like, that's a lot.

• 9:15Speaker 00

  Uh, but on the other hand, we also had the freedom to basically pick what we wanted. Um. So the decision was was a fairly easy one because we didn't have to like, there were not a lot of people who had to be involved in it. There were some people, but there was not a lot of people who had to be involved in it. Um. So in that sense, it was fairly, it was fairly easy on the on like the first thing because we just did it for our team by ourselves. And that was like how Uber operated. For better or worse. Um. So that part was pretty easy. I think the the harder part was when we kind of realized we should really be doing this for everything. That became a bigger project to kind of convince people that it's the right thing.

• 10:00Speaker 00

  And I and and we also did not try to convince everybody at the same time. We said, we're going to build this thing. The long term idea is to make to do it for everything. But we're going to start like it would be a very incremental effort, going to start with with the stuff that we own in our office. Then we're going to do the things that are owned by

• 10:23Speaker 00

  our our friends uh in other departments. And then we're going to go to broader and broader to people who who are more more resistant to to stuff like this. Uh that we kind of that we knew upfront. Uh we also knew that we're like, we're not going to have like a ready platform like from day one anyway. So we don't want to have everybody on on day one. Uh but maybe it was like a like, I always have like a, I don't want to force anything down anybody's throat. Uh so I just want like, I want to build, I prefer to build something and ensure that it actually works. And then people can kind of say, okay, that maybe it isn't that bad. Then if they actually see it work somewhere.

• 11:05Speaker 00

  So a more incremental approach to to the whole thing. And I think that that helped a lot. It also took a very long time.

• 11:13Ryan Peterman?

  When you said there were challenges when you were influencing the other teams uh to adopt this, what was the main pushback that you'd hear and how did you convince people?

• 11:23Speaker 00

  Well, I think one pushback is just that we already have something and it works. So it's a waste to do something else. Um, I and I can see where I see that argument, but it's also a kind of local perspective. It's not a global perspective. Like when we built this, it was more from a like company-wide perspective of like, we want to improve the general state of stateful workloads. We don't just want to improve your thing. And so it does also come with a little bit of like, yeah, so some things will be much nicer, but some things will also be kind of annoying.

• 12:02Speaker 00

  Like, for example, because Uber didn't and still doesn't have a full

• 12:09Speaker 00

  software-defined network, where you can just like virtually move IP addresses around and host names. You're like, if you get a new host, you get a new host name, you get a random port number, and that's it. So you can't do a logical move of something. And that, for some storage signal, this makes it really, really hard. And that's, of course, pretty annoying. So that, from a local team perspective, can be like quite frustrating. If you then have to like, you have tooling that kind of works, and now you have to rebuild it in a very different paradigm. And it seems like a waste of time, but it really isn't, because you get that you get that large-scale benefit, because you also, you get a lot of stuff for free.

• 12:53Speaker 00

  Like, for example, at some point, we were like, okay, we built a basic platform. Now let's look at Numa. Numa is the whole, like, how does memory attach to C P U's? Because if you're running databases, particularly stuff that needs to do a lot of data shuffling, it's nice that the memory is aligned with the CPU that the process is running on. So how do you kind of make that happen in a nice way? Also, from a scheduling perspective, like when you need to do feature optimization, you also need to take that into account. Suppose the actual runtime needs to be kind of scheduled, we have the ability to schedule, but also the, like, the actual scheduler needs to be able to see, hmm. How do we best allocate the CPUs to memory? That's a pretty hard thing to do. And it's not something you get around to doing yourself.

• 13:38Speaker 00

  But when you have a platform like this, you kind of get it for free. And I think the more of this stuff we built, the more people were like, yeah, that's pretty nice.

• 13:46Ryan Peterman?

  It sounds like this effort was a kind of a bottoms up that kind of effort where you and some engineers realized this is a good idea. And then it gained traction and gained traction. I'm curious, like, as the the initiative evolved, like, did leadership starting to get evolved at some point? And how'd that evolve?

• 14:03Speaker 00

  We could really only get so far. Uh, because, especially because, uh, back then Uber, like, the stateful part of Uber was basically split into two. One was like the online real, uh, online databases, uh, uh, MySQL, Postgres, uh, Cassandra, stuff like that. And then there was all the data stack, uh, ACFS, Kafka, Pino, all that stuff. And that ran in a completely different org. We had no like, like, the management chain from that, like, more or less went through the CEO and back down. So they were like, eh, this thing you're talking about, it sounds pretty nice, but we really don't care. But but then at some point, there were, there was some reorging going on, but also

• 14:45Speaker 00

  we got more and more support of the management chain to say, this, by now, this is something you have to do. At some point, there was, they just said, okay, this Olin thing is the future. And you will not, you will not be allowed to have your own service any longer. You want to run something, that's where it runs. Uh, and that of course helped a little bit also with like, uh, adoption, because you, there will always be like, if you have like the full personal thing, there will also always be strikers or people who are just like, eh, we don't want to. We have our own thing going, uh, that it's super hard to like create like full alignments if you, if you're just yourself. No matter how nice the thing you have is, there's always going to be somebody out there who's like, eh.

• 15:30Ryan Peterman?

  Yeah, I mean, it's it's a huge undertaking and I, I feel like when you talk about the end state of the entire company, the scale of databases all running through this one platform, that distinguished scope makes a lot of sense. I'm curious for, for people who are wanting to know about the career side of things, like, how did that look at each step when your career was growing through that?

• 15:53Speaker 00

  I think in, in general.

• 15:56Speaker 00

  There are many opinions on how you get promoted, what triggers the promotion. I have like a somewhat maybe naive perspective on it that is fairly fair. It's not always fair, but it's pretty fair and it's tied to the scope of the work that you're doing. The amount of people you influence with what you're doing. That's kind of, that's how I see it. And so like for something like Odin that had like this natural progression of first you're basically doing it inside your teams, then you're doing it inside your local org, then you're doing it inside your

• 16:37Speaker 00

  like the wider maybe platform org and then it goes even beyond that. And that kind of reflects the job level also. Like the more people you have under your influence, not like it's not like a direct influence, but it's like the more people who are like affected by what you do, well, the higher you get in the level. So if you're actually able to kind of run a project of that scope to success, then I think that a promotion will happen, not a promotion, but a number of promotions will happen automatically. And not just for you, but like the entire team, it kind of attracts a lot of people along.

• 17:21Speaker 00

  Of course, you could say I was maybe a bit lucky in the sense that I had a single project for a very long time. And a lot of people kind of get shuffled around and then do a project or the project gets cancelled or fails and then you have to do something else. It gets much harder to kind of write that expansion. Not impossible, I've seen many things where it's definitely possible, but it's just it's much easier when like the project you're working on has that natural scope expansion. So my promotions to a very large degree followed that work. Like first.

• 18:01Speaker 00

  First, I did some background, so I did some other work before we got to the whole staple thing. And then I did the first version of it. I think that got me a promotion. Then we did more and we kind of expanded to stand out by SQL and Cassandra. And that got me another promotion to, now I forget, because the title names changed a bit on the way. But that probably got me to principal engineer. And then when we kind of, it wasn't done, done, but it was like sets, like it really didn't require me. It was handed off to the team and I could do other things.

• 18:44Speaker 00

  That really took me to the distinguished engineer level. But it was a very natural progression. It was not a progression. I was like, it was not, that was not the reason why we were doing it. It was just, it followed the work that we were doing quite nicely.

• 19:05Ryan Peterman?

  Right. I mean, those are the best kinds of promotions. It sounds like you're saying that the levels, obviously, they're tied to your impact, which is tied to the scope of your influence. And so I guess the natural question then is, what are the typical ways to have your work being influencing more and more engineers?

• 19:24Speaker 00

  So I have this personal thing, and I just, I just don't like doing things too many times. I just, I really don't like it.

• 19:36Speaker 00

  And I think I might have written something about the lazy engineer at some point, which like, I like putting these weird titles on things. But the idea that if I've done something, like for example, I need to do, if I'm operating a database and I need to replace the host and I've done that manually a couple of times, I'm like, this I don't want to do anymore. So that needs to be automated to some degree or abstracted away or whatever it might be. And so I think.

• 20:06Speaker 00

  That's it's not the only thing, but I think for me, there's a major driver because then I'm like, why are we, why do we have this waste in our systems or in our processes? And I, when you really just start thinking about maybe not just your own waste, but also the waste of other people. I think that's where you kind of, then you get into that scope expansion. So you kind of start thinking about your own stuff in your team and you kind of expand from there. So that's, that's how I think about it. I don't think about it as like, and it's not like, oh, I need to like get promoted or whatever. It's just, I just have this, I just have this natural thing and it can be pretty annoying sometimes because you all, you can kind of tend to rabbit hole a little bit also.

• 20:51Speaker 00

  Or it's like a, what I, what, what we kind of call a depth first approach to everything. Where you're like, oh, I'm doing this other thing, but suddenly this is annoying me. I need to build this tool. Oh, but the tool is also annoying to build, so I have to build this, I have to build the build system. Or I have to improve the build system, but the build system is also annoying. So I have to like, whatever, and then you take it on a long chain of like,

• 21:13Speaker 00

  completely sidetracking what you, what you should, what you should actually be doing. That's kind of the danger of it. But I, to me, I, I think it, it just drives a lot of, of this, like, how do you actually improve systematically and systemically? Like the company and the processes and, and in particular, your engineering organization. That's where I'm focused, but it can also touch other things, but mainly engineering.

• 21:42Ryan Peterman?

  I, I see the natural leverage that comes from it. Cause if you build some tooling or something like that, that software can then act on your behalf and help others. And then that's kind of how you scale yourself.

• 21:55Speaker 00

  Yeah, yeah. And, and yeah, so like, we also talk about this whole thing about like, yeah, how do you scale yourself? How do you, how do you become a force multiplier? And it's something I would like, it's always like, I don't know, then you can mentor people, you can kind of whatever, you can step us, we can start like.

• 22:12Speaker 00

  Doing more design so we can push that down. I like the idea of like you become a force supplier by allowing other people to work better and faster. Or maybe not even work at all ideally on the thing that they're working on. Like take that problem away, like think about how do, how do we actually take the problem that you have like out of the equation? Because I think that's the most fundamental thing you can do. The thing you're doing, if you don't have to do that any longer, what could you then be doing?

• 22:40Ryan Peterman?

  You want thing you mentioned, we're talking about promos, is you said they're typically fair. And they're based off of the impact of your work, but I'm curious, it sounds like you have some experience when promos are not fair. What, what does it mean when you're saying promos are not fair sometimes?

• 22:57Speaker 00

  Well, I think it can mean, so it can mean a lot of things and I do, but like I've been part of promo committees for a very long time.

• 23:04Speaker 00

  And the promo committee structure has also changed a lot. From like the first time I was in a promo committee was, I think the, I wouldn't say one of the scariest experiences of my life.

• 23:22Speaker 00

  But I, it's like, so the first promo committee I was in was basically for the entire platform engineering. I forget how many we were, but it was like all the managers and VPs and senior directors or whatever. And senior engineers in a room for an entire day. And then somebody asks, okay, let's go, says, let's go through all the candidates. Or let's actually go through all our employees, all our engineers, just all of them. And then the manager talks about like, well, how could other and should they get promoted? And then we just, and they were like, I don't know, 200 or 4, 500 years, like I don't know, insane number. And we all, and there was no preparation, there was no material.

• 24:07Speaker 00

  There was just like the major saying what they thought and obviously they all thought that everybody should be promoted. And then it was like, okay, and then somebody, we should have some kind of structure. Let's do some kind of point system or whatever. Like, I don't know, is this how it works?

• 24:24Speaker 00

  And, and, and it was back then apparently, and of course in, in a setup like that, it gets super unfair because it all, it all depends on how good is your manager at presenting your case? And if you have a shit manager, you have a shit case.

• 24:38Speaker 00

  You might also have a very good manager, but your work is shit. So like, so in that sense, there's a lot of unfairness going on. Which I think also kind of led to some of the early day Uber culture issues. Not just just that, but it was kind of part of it. But anyway, things did get more structured.

• 24:59Speaker 00

  But it is just super hard because you cannot, there's just no way you can objectively judge

• 25:07Speaker 00

  how a person is doing. Because there's so many dimensions, there's so many things, you're not operating in isolation. Maybe it depend on like, maybe the thing you were doing actually depend on another team and that team didn't do what they said they would do. They just like ghosted you or whatever like. They didn't do it. And it's like, so what it is, that's not your fault. Or maybe you had the project, it was running, it was almost in production, then it gets cancelled by management just for various reasons. Not your fault, but like, then was like, are you then you're not getting promoted or are you getting promoted? And if if you're getting promoted, then on what basis? Like, is it just like, oh, because you wrote a lot of code, but the code was like, you never used and nobody ever saw it again? And so like,

• 25:53Speaker 00

  it's just hard because sometimes you're also like, yeah, you did a really good effort and we don't want to demotivate you completely by saying because it didn't go to production. It was not your fault, you're not getting a promotion.

• 26:05Speaker 00

  All the times it's like, you just also have to make the thing where like, you really haven't proven anything yet. You did a lot of good work, but it's just like, it was not your fault, but you're not getting promoted.

• 26:19Speaker 00

  So, yeah, ideally, there's just fairness all around, but I think that's that is just inherently in a, because it's a human process. There's a fair amount of unfairness. And then I think there's there's a lot of people who don't really understand what it means. Like, they think it's super unfair. Because they think they did really well. And compared to maybe that team, they did super well. But it's just also because the team is not very well, very good. Or you you lived, you lived on an island and you hadn't realized it. There's another world out there that's actually very different and more whatever.

• 26:58Speaker 00

  Which I think just in the early days of like Uber used to be a Python shop. Well, first like a JavaScript Python shop, then it went into a Go kind of shop. And like, nobody knew Go. So there was a lot of like, a lot of people that's trying shit out. And so you would kind of encounter these, these kind of groups of people who kind of had been in, under their own influence. And like, and you just look at what they have produced and like, this is nuts. This is no good. This is just no good. Uh, even though you, you kind of, uh, maybe, yeah, sure, there's one of you who's better than the other, whatever, like. But it's just like, as a, as a whole, it's just no good. Uh, so we can't, we just can't promote you because you need to look at what's going on over here.

• 27:43Speaker 00

  Um, and that can, that can just feel super, super unfair to those people. Uh, because if they were not prepared for what they actually went into. I think that's also why I, I, I kind of made this effort of like trying to describe like, how do you actually get promoted? Like, what does it mean? And it's not about like, I know, like, I, I think I called something like a, a beating the promo committee or whatever. Uh, which can just like a, a catchy title. But it was really more about like, what does it actually mean to be a software engineer at Uber? Uh, because you have kind of also the ideas what that means. But the, but actually there is something, there is a way to be a software engineer at Uber.

• 28:25Speaker 00

  Like there's, and, and that way is most like different than Meta or Google or whatever. And I think it's pretty, pretty important to be aware of that. Because otherwise you kind of work towards something and that was not the thing that it should have been. Um, and that, that, that can, that can create a lot of frustration, a lot of disappointment. Uh, yeah, uh, which, uh, and it's, and it's too bad, uh, that, that people can't get into that state. And don't get the correction, uh, along the way. That they go all the way to promo, have prepared a package, written a lot of stuff, gotten feedback, getting PR feedbacks or whatever. And then the, uh, the promo committee is like, nah, it's no good.

• 29:08Ryan Peterman?

  Yeah, you you said you wrote that piece that was how to beat the promo committee. And it's basically, you know, the the way that you grow as an engineer at Uber. And it's it's not focused on actually the specifics of like the promo packets. It's actually focused on how do you become a stronger engineer? What was in there?

• 29:28Speaker 00

  Mainly, just as you say, like, good engineering practices. And something that I found surprising and like I actually found surprising during all my years at Uber, which is, well, it also meant our philosophy. But I'm like, a software engineer needs to write code. If you're not writing code, you're not a software engineer. I know that some people find that pretty controversial for some, I don't know why, but like apparently it is. To me, that and that applies to any level. Like, if your level, like, if your title includes engineer, you should be writing code. And it might be different how much code you write, but you should be writing code on a regular basis. And to me, regular basis means every day. I know for some people, might just means once a week or whatever, but like,

• 30:14Speaker 00

  I, to me, it's like every day, ideally. So, but I think the main advice in that thing was really just write code. Just don't, don't mess around. And and don't like, don't overthink it either. Like, don't like, oh, I need to write like advanced, at my level code or whatever, like, the higher my level, the more advanced my code has to be. Like, no, it's just like, just write code. Because the more, like, if you have that, if you do that, I have just never seen anybody who will not grow along with that. And just keep writing the same code, like, does that make any sense? So I think that was the main advice was actually just that, just write code.

• 30:59Speaker 00

  Also, write good code, like the secondary advice, and make make good good commit messages. And make sure to review code and make your code nice to review and all. Just like, stand that.

• 31:11Speaker 00

  Software practice, which people kind of, I don't know, forget a bit about. Many people also might not have learned it because like normally you don't actually learn like real life software engineering out of college or wherever you are. It's all theory, but like in real life, there's just, there's, there's also, there's also craftsmanship to it that you have to learn. And you don't learn that in isolation, it's almost impossible to learn it by yourself. Well, these days you can get a lot of help from, from AI and whatever. But like you, you have to like see somebody doing it in order to improve. Yeah, so I think those were really the, that was really the main thing.

• 31:51Speaker 00

  And, and there's a lot of other things, smaller things about it, because we also need to be able to actually articulate what you're doing, like design documents. You also need to like be out there, like you like having like my, my, my other, one of my other philosophies is like running code beats perfect code any day. I know you can always come up with like weird S cases, but in, in the big picture, running code will always beat working like perfect code or beautiful code or whatever.

• 32:25Speaker 00

  And that could be as a software engineer, pretty hard to like, like some people, because some people are really, oh, no, no, like it needs to handle the cases and whatever. And I, I, I, I'm just much more of like, yeah, just do something. Because if you do the perfect thing, you get tied up in this, oh, in order to kind of submit code, I have to have all the, I have to have the entire thing and it must handle all cases. And then you kind of work on some, that's where you kind of start working on something. And then you refactor and you do some more and then it bends like after a month you do a commit.

• 33:03Speaker 00

  That's just not useful because you did not get any feedback. You never, nobody else saw it. You might be in a completely wrong crack, like God knows what.

• 33:10Ryan Peterman?

  One common advice I hear when people are thinking about growing in their career is that they have to scale themselves. And that often points them towards being more and more of a delegator and more and more of a tech lead. And they start getting into this zone where they're in these high level discussions in the design docs, but not actually writing any code. What's your thought on that? Because that's like a very common thing that people will push on higher level engineers. Say, stop writing code, go and delegate.

• 33:43Speaker 00

  Yeah, and like, as I said, personally, I like, I don't subscribe to that idea at all. I see that a lot. This is also like some, it's also just about like, to some degree, it's also what you, about what you find interesting. I, I, I just like finding it. I just do. I have always liked it. It's just like what I like to do. I would probably like, if I had it, if I didn't have anything else to do, that's what I do. But I would do, if I didn't have a job, I would probably also do it. So like, I just like it. But I, I think there's also just a very big overlap of between like just the, between the writing of code and the ability to like perform at any level.

• 34:25Speaker 00

  And to me, it's, it's like, it's, there are many facets to it. The one thing is, if you're not writing code, you lose touch with like the system.

• 34:37Speaker 00

  Not on day one, of course, because like on day one, if you stop writing code on day one and one month one, it's fine because you can't remember what was going on. But the system evolves all the time and you forget how it is. And you can probably get a more, more and more high level like view of what's actually going on inside the machine. So, and that just means it gets harder and harder for you to kind of

• 35:02Speaker 00

  design for the future. Like the, the signs you come up with will be more and more. Decobbled from reality and be more and more, it might be idealistic. Whereas like, and then when it gets back to implementing, it's handed off to somebody else and they're like, what is this shit? And who came up with this? That's that, that's that guy with the, with the whiteboard and like what, and the documents like, what, who's that to like, say what we should be doing because the actual problems we have are like this. Um, so I think that's, I think that's one main, that's one major thing.

• 35:43Speaker 00

  Um, and tied to that is the, is the kind of, how do you actually build a team? Because you, as I say, you need to scale yourself, that's for sure. Uh, I think another way of saying you need to scale yourself is you need to enable as many people to work as efficiently as possible. Um, which I think is a bit different than the scaling yourself. Scaling yourself, the sounds of you, they're kind of cloning yourself, which is like, usually doesn't quite work.

• 36:15Speaker 00

  But if you need to kind of make your team, when I say your team, it's like the people around you, the people you're supposed to influence. If you're kind of supposed to kind of affect change, whatever the change might be, it just is much easier to do if they trust you. They know what, they know that you know that what their pain points are. And that you, that they know that if you say something, it usually works out.

• 36:45Speaker 00

  Or if they say something, then you listen to them. Um, and so that, that decoupling kind of, it hurts in that sense. Because you get new people in, like, of course, the people you worked with before, they will know you, so they're kind of okay, but like people start rotating in and out. So you lose more and more touch with both the people and the system. And that over time gets you to, it might be a pretty bad state where, yeah, you're doing a lot of designs and you're doing a lot of documents and you're doing a lot of talking and reviewing and whatnot. But you lose more and more touch with what is actually going on. And then, um, and this might be, just be an Uber thing. But you get more and more hostility also and people won't tell you in your face, like, but you will be.

• 37:31Speaker 00

  Everybody would think, ah, who's that asshole or who's that kind of guy to like come and say whatever.

• 37:37Ryan Peterman?

  So you're saying if if you're not hands on, you lose trust and then people won't tell you that you've lost trust. And then if you try to influence them or or convince them, they're gonna, you know, not go your way.

• 37:52Speaker 00

  Yeah, I think I think at least I've seen that a lot.

• 37:56Speaker 00

  And the the the the other thing is if you're not like in there, then I need personally.

• 38:05Speaker 00

  I I don't want anybody to tell me what I'm supposed to do.

• 38:11Speaker 00

  It's not that it's that I'm not open for input, really like to talk about it. But if you don't have skin in the game, I I think you should stay out of my things.

• 38:23Speaker 00

  And then I will also promise to stay out of new things.

• 38:27Speaker 00

  If you ask for help, more than willing to help. If I ask for help, I hope that somebody will help. But and so so that's the whole thing about like if you kind of do this top down, oh, by the way, now we're supposed to do this. People don't really know you, don't know where they're coming from, don't know why why you're saying what you're saying. That just it just creates a lot of mistrust and and in in some cases, it's just plain hostility.

• 38:49Speaker 00

  And and maybe in the worst case, people will kind of say, yeah, that's a pretty good idea. And then they will just completely gaslight you and that's like go go back and not not do any of the stuff that you talked about.

• 39:03Speaker 00

  Which probably the most annoying outcome that you can get.

• 39:07Ryan Peterman?

  You said something in my research, you said something somewhere, you said if a VP says the exact same thing an engineer does, engineers will still not fully trust the VP. And so, yeah, that my question is, why don't engineers trust management?

• 39:24Speaker 00

  But I think it's back to that. That if you don't really like, if you have somebody who you feel don't really know what they're talking about to some degree. Like they might have an idea, but they don't really like and that but that idea might be completely off. Because they haven't really spent the time to kind of understand what is actually going on. Um. It might be that they're completely right. But but it's just, it's just, I don't know. I don't know if it's just human, whatever nature, or if it's just like, if it's just me.

• 40:00Speaker 00

  But I I just I just know for myself and I I from other people I've seen is like. Somebody says something and if you don't like, if you don't have a connection to them.

• 40:11Speaker 00

  Then it's just hard to like take at face face value. And if face value is all it is, or or force, like authority. If if authority is the only thing.

• 40:24Speaker 00

  It just, at least in. So this might also be a super local thing here, like in like a Danish thing, like because it's like. There's basically no structure anywhere.

• 40:35Speaker 00

  But it's also a thing. In Bay Area, where like authority in itself. Doesn't really get you all the way.

• 40:47Speaker 00

  It it and again, people might like say, yeah, nod, a smile, and yeah, that's that's nice. But if you don't truly believe it. And I've I've just seen so many times where people, yeah, that's nice. And they just, they they don't mean it. And if you don't mean it, then how are you supposed to successfully implement a project? It would just, it will always be, maybe it gets done, but it will be a bit like it won't like if you if you people don't think it's good there. They don't take ownership, it's just not going to be really nice. So I I so I think that just takes effort. And it takes much more effort than you normally like that you would like it to be. Yeah.

• 41:25Ryan Peterman?

  You had to influence a ton of people in getting your project to scale across Uber. So if, yeah, how do you influence other engineers then and avoid that situation you're talking about?

• 41:37Speaker 00

  Yeah, and and again, like. As I said before, like, there's probably always going to be somebody somewhere. Who's like. They're never going to be convinced. Uh, just. Never go for a hundred percenters like that's one thing at least. Um, but but but to me, it's really like, I I just believe a lot in leading by example. Like if you say, this is what you're going, this is what we're going to build, then you help building. And you also take a lot of the pain. And I think in particular, and there's also the thing about the, another thing that that can very quickly happen is that the, the, the, the higher level you get, uh, the more you can concentrate on the like the hard stuff.

• 42:22Speaker 00

  The stuff that you, that is only you who can do. Um, but that, but that, that's really not a lot that only you can do. Uh, there might be a couple of things, but it's really not a lot. So all the other stuff, there's, there's some tendencies for people to like say, oh, because I came up with the idea, I should also implement the most interesting stuff or what the new algorithms or whatever. Or like, I should play with the fun stuff. Um, and sometimes you do that, but, but I think most of the time you should really delegate that down. But you should delegate the hard stuff down, not, and just keep the easy, not the easy stuff, but, uh, but the stuff that is kind of boring. And you should just do that yourself, because again, you don't have to prove anything any longer.

• 43:08Speaker 00

  Once you, once you've reached a certain level, you don't have to prove anything. You can do what you want. And so at that point, it's much better to, in, in my view, at least push down the hard stuff to the people who can like barely manage it and then help them. Uh, make sure that they do, that kind of, they're kind of in the right direction and then let them kind of work with that. Rather than take that yourself and then delegate all the shit work. But that's, that, that doesn't help anybody. Um, and we have like, uh, we had like this expression of like shoveling shit. It's not a nice expression, but it is what it is. Uh, but sometimes there's just like, in order to do something, there's just some, some really shit work in there.

• 43:48Speaker 00

  Uh, and if you take that work, uh, and like the, the other people do the, do the, the fun work, that will also do, it will give you a lot of credit. Uh, but it will also allow them to grow much faster. Cause if they get challenged, the rest of the team, they work much faster, they, they grow much faster. And that's just to any, to everybody's benefit. Um, so like that whole thing, that's also, yeah, the coding, leading by example, and to me, leading by example just means writing code, uh, to a very last degree. Uh, and then taking all this, taking some of that stuff that other people. That you don't really want to do. It might also be improving documentation or fixing rid of bugs, whatever it is.

• 44:33Speaker 00

  And there's not a lot of like, there doesn't have to be a lot of like glory to it. There's usually not a lot of glory to it.

• 44:41Speaker 00

  But yeah, I'm a very strong believer in stuff like that.

• 44:46Ryan Peterman?

  Interesting. Yeah, that's the opposite advice I usually hear. Usually like as you go up, people say you gotta do the hardest parts, the most impressive ones as well, complex ones to kind of warrant it being worth your time. And you push out all the easy stuff to anyone that can handle it that's not you. What's the downsides of doing it that way?

• 45:06Speaker 00

  Yeah, but it's also because it usually turns out that the easy stuff has, it's easy because it's like, it might be easy to do, but then you're like, oh, this, this thing. Why, what, like, why are we doing this? Then you start thinking, oh, how can we avoid doing that? So you kind of take some of the easy stuff and it usually turns, turns out to give the, you can kind of expand that to something that is not trivial any longer, that actually, that actually did require you to come in. It was not, it was just the intention or purpose. But when you come in and look at like, why are we, why do we have this many bugs?

• 45:47Speaker 00

  What is this? And then you start thinking about, is that the, because we have bad reviews? Because we have bad testing, it's something else. And then you can kind of start like, how do we, how do we kind of make that better?

• 45:59Speaker 00

  So I think, and I, and I have, I have heard that the same advice a lot of times. And I had a lot of people come before, after, control committees or mentoring or whatever saying, oh, how do I, how do I get the right project so that I can get promoted? Or how do I like, how do I grow my scope or like? And my advice has always been saying, this is the, this is the, more or less forget about that part. And just start writing some code. Uh, focus on that. Just do something that works. Doesn't have to be great. Doesn't have to be anything. Focus on something that works. And then every time you do something, think about, Are we doing the right thing here? Like, are we introducing? Because in a lot of cases, actually,

• 46:42Speaker 00

  when you build something, you actually introduce more work to other people. You kind of build a system and then you're like, oh, this is nice for us. But then it actually turns out that for other people, now they have more work. Because they have more systems to manage or they need to configure them or something else and have more stuff in their head. Like, how do you think about what? What is the net overall result of what you're doing? And how can you make that better? It just doesn't have to be big things. But if you're like, if you're always working with that in mind, my philosophy is that then the other thing will come. You don't have to like, you don't have to be like, oh, I must find something. It will come and I've seen it.

• 47:26Speaker 00

  Not a many times, because there are not many. But I have seen it a lot of times. Where people are like, oh, I need to do like, I need to be promoted. I need to find the right scope. Like, just like, relax about that part and just focus on providing value. Because once you do that, the other thing will come. In most cases, again, back to the fairness part. That case is where it doesn't come and then click, too bad. But like, in most cases, it does. And I think it's, to me, is the by far the most successful way of getting there.

• 47:58Ryan Peterman?

  I'm curious, as you advance in your career, because I think this is a common thing some people experience is, did your role become more political?

• 48:07Speaker 00

  I'm always like, yeah, what does political mean exactly? So I think there are a couple of things to it. Of course, you have to talk to more people. So there's more talking and there's more fighting. Because you have to like promote your ideas. Well, you have to promote your ideas, but probably worse, you have to listen to other people's ideas all the time. And because they also want something like, I don't know, I think maybe I haven't a opinion or you think that is not that nice.

• 48:40Speaker 00

  So that sense, there's, there's a lot of like fatigue going on. Um, I think you also get, you get much more exposed to, to like the realities. Like when you're a junior engineer, you kind of, oh, we're doing, we're kind of doing engineering. And then somebody else has a grand, has a grand plan. They all know what's going on. It's all under control. And then you're like, you realize at some points, nobody's in control. Like, there's an illusion of control, but there's just like people randomly getting ideas and pushing them out. Uh, and that, that, I think that part is pretty scary.

• 49:23Speaker 00

  Uh, to, to, to like, as a rational engineer, to get to the point where like, okay, so we're making decisions just based on nothing? Or because you had like a vision while you were in the shower? I don't know. Uh, or like, you talked to some other guy who also don't know what they're talking about, and now that's the strategy? Um, is that politics? Maybe it is. Uh, but you get more and more like, you get, you get more and more subjected to that part. And I think that's, that's pretty scary. And it's also definitely not for everybody. Uh, I didn't like it at all. I didn't particularly like it. I can abstract from it. I can just do my own thing.

• 50:04Speaker 00

  But if you get sucked into that, then, then I, and a lot of people get sucked into that. Because there's so much like, oh, we could also do this and let's do a big plan for whatever. And then that takes like weeks and weeks to do a plan and like, it didn't work. Like, okay, now we did that. Hooray. Um, and so, and then there's the whole like, that, that idea of like, that thing about like, somebody, somebody came up with an idea. And now that needs to get implemented. And then there's a lot of pushback and all this stuff. Um, and of course, everybody has ideas. Who gets hurt? How do you get your, how do you get your idea in? So there's a lot of that. Um, my personal approach to all of that was really, back to the whole thing about like,

• 50:49Speaker 00

  I don't need anybody to tell me how I need to do my things. So I don't, also don't want to tell other people how to do their things. Uh, and I also don't like, I.

• 51:00Speaker 00

  I have no good like a career planner as such like I have not I oh this is how like I get to this. But I also have a very strong aversion to projects that I can just see a just stupid or dead ends or whatever you call them. I just stay away from them and let somebody else do that. And that's might be a little bit unfair to those other people sometimes. Uh, but that's kind of how I kind of kept my sanity. What's big to say, well, okay, this thing. I think you should like, fine, you're already enough people. Like you're plenty of people. I don't need to be the boss. I have my, I have my own thing over here that I can do. I don't need all that stuff. Uh, and of course, as long as my thing is

• 51:44Speaker 00

  significant enough, because if you don't have anything to do, you can have a little bit. Then you need to engage with something, but like as so, as long as you have something going on yourself that can kind of fill out your scope, then I like, I just say no. Um, a lot, uh, and some people might also too say too much. Uh, but that's kind of my way of staying, kind of staying a bit away from all that. Because there is just, there is a lot of noise and I don't know. I just like to be blunt about it, just like plain stupidity in my view, but like. Now, I think some people probably probably call it politics. I don't think, I don't know. Um, but I also have very low patience for it.

• 52:27Speaker 00

  Uh, for stuff like that, I think if you're, if you're doing something, let's talk about it and do it. I don't want to talk about, we should do something and we talk about that for hours or days or whatever. And then at the end of it. We was like, yeah, well, we, we actually do it next year. I'm like, okay, that was just a pure waste of time.

• 52:44Ryan Peterman?

  One thing that I hear some from some friends is they want to avoid all that stuff. So they don't want to get promoted because then the expectations get higher of more of that other stuff. So I guess is any part of you regret getting promoted to such a high level and having to deal with politics?

• 53:02Speaker 00

  Well, there were, okay, there were times where I'm like, this is like, this is just. If only, but I have heard, but again, it really also depends on how good you are at resisting pressure. And just like being like being yourself, like resting in yourself. And it was like, I don't know, some kind of voodoo stuff. But like, how confident are you in just yourself? And do you care? How much do you care about other people's opinions? And if you care a lot, it's it's hard. If you don't care too much.

• 53:40Speaker 00

  Uh, it's it's okay. And I like, and I I I like, because I had like, the good thing about, by the way, we have a remote. Uh, the office in Denmark, small office in Denmark. Uh, we worked a lot, a lot with the the teams in in San Francisco.

• 53:57Speaker 00

  And the good thing about that is that our daytime was uninterrupted. We basically do whatever we wanted. The bad thing is we have meetings in the evening. But it's like, but you actually had a day's work. Like normal work, you could just do whatever you want. And then you have meetings in the evening. And that creates this nice, like, you like, you cannot get fully sucked into it. You really get kind of a couple of hours every day, get sucked into it. Which I think helps a lot, just having having the physical distance and the time zone distance actually helped a lot. In that, because there was like, a lot of other people were like, oh, then you pass some BP on, uh, in the hallway that, oh, could you please come along? And we just like, talk about something, yeah, but we we couldn't do that.

• 54:41Speaker 00

  Uh, so I think that also helped a lot.

• 54:44Ryan Peterman?

  We talked a little bit about influence and just last question on this. I found somewhere that you said the best outcome is when the other person thinks the idea is theirs. Can you elaborate on what you mean by that?

• 54:58Speaker 00

  Yeah. Um, and it's that it's not like, it doesn't happen very often, but I'm I'm just always, when it happens, I am, it's, those are the best days. When I hear somebody.

• 55:10Speaker 00

  Talking to somebody else, like when I overhear a conversation, maybe in the office, somebody talking to somebody else about an idea I had originally that they didn't like.

• 55:22Speaker 00

  And then maybe a couple of months later, or whatever, it's like they're saying it, and they're not saying that I said it, they're saying it with conviction.

• 55:30Speaker 00

  And it can be, it can just be small stuff, but it can also be a bit larger, some, some larger things like, I don't like, let's just say like, you have resistance on like, oh, you need to rebuild something because you already had the tooling, but now if you were actually using, you actually had the benefits, but you initially you were not like able to kind of see through, see, see through that and like go, go kind of beyond what you had yourself and see the benefits of the other thing, because you were looking only at the cost. But after a while, you might have realized that this is actually a good thing. Without having been like forced into that, you're just like a seed was planted. And then that kind of grew into something.

• 56:11Speaker 00

  And then suddenly that person is actually aligned and you didn't do a lot. Maybe you nudged it a couple of times or there was like a team kind of, not a conscious team effort, but like you get into an environment and it kind of changes you a little bit. And like, it's just a couple, I, I, I've seen it not many, many times, but I've seen it a couple of times. It's just like, it's just the best feeling. And it's not the best feeling of like, oh, you are right kind of thing. It's just, it was something to be a proud feeling of like, those guys, they learned, they, they, they're on the right track now. And it was without force, like there was no force involved. It was not just because you kind of forced it into them, you, we just need to do this.

• 56:56Speaker 00

  They were like, actually like, oh yeah, this is actually good, yeah, let's do this.

• 57:01Ryan Peterman?

  I saw somewhere that you had some unconventional advice for picking mentees, or just something that I hadn't heard before, where you pick mentees specifically outside of your org and you try to disperse them to increase your influence. I'm curious to hear more about how do you pick mentees?

• 57:20Speaker 00

  Yeah, so mentor, like, okay, so mentoring in general is like, it's a very like,

• 57:27Speaker 00

  Oh, it sounds so nice and appealing, but it's also when you look at like the whole thing about scaling yourself. It's like super inefficient, like because you cannot parallelize it. You're like, you're you're one person, you're talking to one other person. Uh, and there's only so much time, you only have so much time. Um, so like, it's just super hard to get high value out of that. Uh, so to me, it was, it was really always mainly just about having a network. Uh, and have a conversations that are like two-way conversations. It's not just me providing whatever, it's also them talking about something.

• 58:08Speaker 00

  And that's where like, if you go, if you're all mentoring inside your own like team or org, it's like. Like who's, who's actually learning what now? Uh, and like the, the, that close range mentoring, I think you can, that is much easier to do at like, not at scale. But you can kind of talk to people in a group setting more easily. About like career advice or whatever, uh, you could do a bit of like. Informal, like, oh, what about that and what about, but it doesn't have to be like scheduled or structured in that sense. Where if you go to people, you don't really know what are further away from you. There's more work in it and you also have to like, there's also more benefit for you. Uh, because you could learn something about what they're doing.

• 58:53Speaker 00

  You could give them more input on what they could be doing or why they're doing what, and so like, so that's, I think. It's nice, it's nice if you actually have to like spend the time to, to actually do it so that you also get some kind of benefit. Uh, but also so that you can kind of plant, plant seeds elsewhere. Um, because I've also seen a number of times actually that people come in and say, oh, how I just, how do I get promoted? I'm, I'm, I have, I only get shit projects and like, whatever. Um, but then you kind of, once they start thinking about, oh, maybe there's another way of thinking about the whole thing, another way of working. That will kind of rub off inside their teams.

• 59:36Speaker 00

  Uh, so you're kind of planting a small seed there that, again, it will take a while, but might actually do positive change, not only to the. But also the rest of the team and eventually the rest of the org. Um, so that's why I like.

• 59:51Speaker 00

  I prefer to like have people who are not super close.

• 59:55Ryan Peterman?

  Do you have advice for mentees on how to signal their potential to mentors? So I imagine at some point you had probably more asks for people to be mentored by you or spend time with you than you had time for. But let's say someone's really promising and they really want to mentor from some person. What would be your advice? How can they set that up in a very natural way?

• 1:00:21Speaker 00

  But I would probably start like not just by asking, oh, can you do mentoring? Because also because mentoring can be kind of a mental load. Well, not a mental load because that's something else. But like it could be kind of, it could be kind of, it could feel like a big thing and a responsibility that you might not pack at once. So it might more be like, oh, can you help us? Can you do, can you help us in something specific? Or can we just talk about like something, a design or a product we're building or whatever? Like just have a conversation and then you can take it from there. I think that's, that's one thing you can do. If it's about like, how do you actually approach in the first place? Of course, always like cold call and it works most of the time.

• 1:01:05Speaker 00

  I usually didn't have that many people reach out, but there were a couple of times. But, but, but then also like just show up, ask questions. Like if you, I had a lot of presentations like in different offices. And I always like when people like come up and talk and ask. So if you kind of ask good questions, I don't know what good questions are. But like if you ask, if you just come up and ask and signal that I think that's, that is a good signal of interest. And then just.

• 1:01:42Speaker 00

  Because I, I think it's also on the, on the mentor to kind of say, well, okay. What you, what you come and say is, is really not what you should be saying. And I, I don't think that should disqualify. Because that's the whole point. They need mentor, they need mentoring, they might not actually know what to say. Um, so, so I, I don't think that if you, if want to do mentoring, don't, don't disqualify just because they didn't send the right resume or whatever.

• 1:02:15Speaker 00

  But they do have to have some willingness to learn. And I think you get, you can kind of, you can kind of gauge that from just a, like a short discussion of like, what are they doing, what are their outlooks, what they have to be doing, what are they thinking? And see how they do, how do they react to your thing. Um, and that might take a while, uh, take just a bit of time, like ten, fifteen minutes.

• 1:02:38Speaker 00

  And that's, I think the other thing is like, to me mentoring is much better if it's just pretty informal. Like, I, I have, like, Uber has, had, had through different, like, a number of different, like mentoring systems or platforms or projects or programs or whatever. And I'm like, I don't want a plan. Uh, and I don't want a schedule, I don't want anything because like it's all individual, what people want or need. Uh, so, so also just don't make it more than it has to be. And also don't, don't be afraid to say, okay, I don't think we're like, kind of, we're done, like, or like, I don't think we're getting, going to be like, you're not getting to go, go see to get more out of it, I'm not going to get more out of it.

• 1:03:22Speaker 00

  So it's like, yeah, it was nice.

• 1:03:25Ryan Peterman?

  Coming to the end of your career story, I know eventually you left Uber. And I'm curious, what's the story behind you leaving Uber?

• 1:03:32Speaker 00

  It's not a nice story, unfortunately. Uh, I, I don't think so it is. Because I was actually pretty happy at Uber. Uh, and surprisingly so. Uh, because when I joined Uber, I was like, it was like a crazy, it's like a crazy high pace place. When I joined in fourteen. It was also a very hot place to be and people were coming from Google, Netflix, Amazon. Like Uber was kind of the place people were going to. And then you get a bit of like imposter syndrome because like I didn't come from like big tech. I came from a small tech.

• 1:04:11Speaker 00

  So, so I was like, all these people kind of are much better than me. So like, what can I do? And like I was like, so I better like, I kind of hit the ground running and never stop. And that, that, that can also, that, that you can only do that for so long. I'm like, okay, it's like. I saw it when I joined and again, I didn't have a plan, but like, I wouldn't be surprised if I'm out of there after like three or four years. Because it's like, it's like a pretty intense environment.

• 1:04:43Speaker 00

  But it turns out it was, yeah, it was intense. Also turned out that all those people who came from the other places. But I don't want to like, they were not that much better than me after all.

• 1:04:56Speaker 00

  It turned out they were, they were also just human.

• 1:05:00Speaker 00

  And maybe more importantly, they changed jobs much more frequently. Which means it's really hard to keep a long project running and kind of get the long-term benefit of that. But, but even with the high-paced environment and the performance, performance management and the the promos and all that stuff that is like not natural to like a Danish work environment. It was also just a whole lot of fun. And we had an office with a very outsized

• 1:05:36Speaker 00

  influence. We had a lot of senior engineers compared to like, we were a small office, but like, we had very senior engineers more or less from the get-go and we just kept on getting more. Because, and we grew most of them internally. A lot of people grew to high levels.

• 1:05:55Speaker 00

  So in our office, we grew through to think, to think of it in years, which is like out of, at that point, like a seventy people. It's like. Out of four and a half thousand years, that's that's pretty insane. Um, so it was a lot of fun and and we had this very like these these projects that we're working on were very like challenging and satisfying to work on. And it was all the stuff that if you're just like in a normal company somewhere, you go to a conference or whatever, or you read about blog posts and you're reading about these people who get to like do these optimizations, automations like, ah, if only, if only we had that, like, if only we could do that. And but we had that.

• 1:06:36Speaker 00

  Uh, so like a lot of good stuff. Unfortunately, it just happened that management changed. Um, and that just created this uh, change in engineering culture. That just meant that more and more people did not like it. Uh, uh, and my manager decided to leave at some point. He was like my local manager. And was also the sidekick. He decided to leave. Then the the first distinguished engineer in our office decided to leave at around the same point. Other people started to leave. A lot of people left in the U S also. And that just meant that it got less and less fun.

• 1:07:21Speaker 00

  And there was more and more top top down kind of management going on because initially in the early days it was very engineering oriented, especially in platform engineering where where I was. Uh, so very much, uh, very much not necessarily only driven by engineers, but engineers were kind of part of the process. When you're designing something, you were you were there. Uh, you were not always like it was not always the thing you wanted to do that actually was decided to do, but at least you were there. You understood the reasoning, you could kind of stand behind it, no, almost no matter what. But it kind of went to a place where it was just like, oh, now we now we need to do this. And you're like, that seems pretty stupid.

• 1:08:03Speaker 00

  Um, and like there was this decision of going to cloud, to to cloud. Google had on prem, uh, was operating on train. Benefits and had the downsides. And there was a decision that we should move to cloud. And the decision was based on price. That it was going to be cheaper to run in cloud. And no engineer believed that. Also turned out not to be true. The only thing turned out to be true, because then we had to cut cost of platform by almost fifty percent. Then it was cheaper. But we would also have done that on-prem and have had like, then we just have even cheaper. But so that whole like top-down management

• 1:08:47Speaker 00

  just led to a full-on drain of especially senior engineers. Because they, nobody really wants to be part of it, you know.

• 1:08:57Speaker 00

  Nobody wants to be left out to some degree also. So at some point, I was also like, I could stay, but staying would basically mean that I would have to like work in an environment where a lot of a lot, I wouldn't be able to kind of stand behind the decisions that were made. And as a, as a senior engineer, if you're not behind the decisions that are made, it's really hard.

• 1:09:28Speaker 00

  Then you can just choose. My, one of my peers or one of my managers, managers, like he said to me when I was like, I'm, I think I'm going to leave. He was like, yeah, but don't you, why not just stick around and you just do your own thing? And just take the money, but more or less, I'm like, yeah, sure, the money, the money is pretty nice. But I just, I don't think I can do it. I don't think I can witness what other people are going through and just like do my own thing. I just don't think I can do it. So at that point, I was like, I, then I was like, then I have to leave. Because I have tried enough to change how things are done, no, no effect.

• 1:10:07Speaker 00

  And that just means in my view, that Uber does not have the need for engineers at that level. The simple as that. And then I was like, then, then, yeah, at that point I have to leave. But so to me, it's a pretty sad thing, because. It's like a self inflicted thing that Uber did. For no, for no good reason in my view, but it just lost, lost so many really, really good people. Mostly due to Databricks by now, by the way, but whatever. It's like parallel world going on there.

• 1:10:42Ryan Peterman?

  What made you want to go to a startup instead of maybe Databricks or like a big company again?

• 1:10:47Speaker 00

  Yeah, so I think there are two parts to it. Databricks pretty, pretty, pretty nice. They had also a local office, opened a local office. A lot of people moved there, a lot of people I knew, but also just to build this, to, to build more infrastructure. And more or less to build the same thing we had built once in a while. And I like, we already built this. It wasn't that shit. So I don't know if I want to do it again, like it was a lot of fun, but like, I don't know. Maybe it's like, if I'm, if I'm, if I'm moving somewhere, there should be some kind of change. And it's nice to have it like a, and, and like a, what's called a, like a cultural change is nice. But it would also just be nice to like, do something else.

• 1:11:32Speaker 00

  The other thing is, as, as it's nice to be a senior engineer, but it's also scary. Scary when you change jobs. Because suddenly you get into an environment where you don't know anybody. They don't know you, you have no reputation. Well, you have some reputation from the outside, but you have no personal reputation. And what I have seen a lot of times is like, people come in, super like senior years come in, they have like, and they come in to fix something usually. They're like, oh, they fixed this thing over here, they will come in and they will fix it for us also. And it's just never that simple. It's just never that simple.

• 1:12:13Speaker 00

  There's almost no chance that you can take whatever you did over there and apply again with success. It's just like, it just doesn't happen. So those people are just in for a very rough ride. Because they will face resistance from everybody, not everybody, but like, there was a lot of resistance. Everybody was like, yeah, what told you? And will more or less cheer when they, when they fail. It's like, I don't know, it's not super attractive to be a senior engineer like that because like. The expectations when you when you come in are so high. Like, some companies do quite well, because you kind of just, they say, well, we can't like start slow and embed you into the team or whatever, not the, you're not from on day one, kind of.

• 1:12:56Speaker 00

  But still, there's just a lot of like catching up to do and you have to like prove yourself. So it's not that it's kind of be done, and I'm not saying that I didn't want to do it all, but like, I just didn't want to do this like a let's all move to another company, which just do the same. I just like, I was like, if you're doing something, we might as well do do something real, like drastic. And the drastic thing is just to take the the complete opposite of four and a half thousand engineers, it's like

• 1:13:26Speaker 00

  two million years, whatever it is. So that that was basically my my reasoning around it. It's just like, okay, but like, this just, and because the other thing, we always do the other thing. You know, it's like, can always just go to data bricks or one of the other places. Can you go back to Uber if you wanted to? I don't want to, but like, there's always, there are always the other options. So doing the startup thing is like, if you're doing it, then yeah, why not? Why not just go all in on that? So that was my kind of thinking around it.

• 1:13:59Ryan Peterman?

  Right. And since you've joined the startup, how how has it been compared to your expectations?

• 1:14:05Speaker 00

  It has been very interesting, I would say. It's been a lot of fun. Like, we do, we have like an AI enterprise automation startup going. It's super interesting and we built so much stuff

• 1:14:22Speaker 00

  every day. And we're kind of navigating a space that nobody has ever been in before. So it's like, and so you have to really be on on the edge always, which is like, and I like it, and I like, and I like also being, and we're building a product. We're not just building infrastructure. I love building infrastructure, but it also gets you very disconnected from like the reality. Where here we're like building the entire thing, and I just like that a lot. I don't like a lot the ah, the fundraising and oh, we're about to run out of money and then what? And like, that whole thing is getting a bit stressful.

• 1:14:59Speaker 00

  And yeah, so.

• 1:15:02Speaker 00

  It's been good. It's been harder than I thought it would be. For now, I would say still worth it. Not in money, yes. I hope it will eventually.

• 1:15:18Ryan Peterman?

  Coming to the end of the conversation, I wanted to ask you some career reflections. So is there an engineering mistake? The biggest engineering mistake that you saw happen at Uber that was only obvious in hindsight?

• 1:15:33Speaker 00

  I think it's hard because there were a lot of choices that did not scale. But at the point where they were made, it was kind of the right choice. It was just, it got so painful later. Does that mean that you have done it differently? I don't necessarily think so.

• 1:15:54Speaker 00

  Like, for example, I said like, at some point, we were operating like 50 different databases or whatever. Was that wrong as such? Well, maybe that, there may be somewhat that was wrong. But it came out of the idea of like, let builders build. If you need to do something, go nuts, let nobody block you. Which, once you're 10 years into it, is an insane strategy. That's going to like kill you. But in the early days, like you don't want a lot of structure. You just, because you don't know what you're doing. You don't know if you're going to be successful. You have no idea what's going to happen. So it's go nuts.

• 1:16:37Speaker 00

  I think the hard part is like, when do you like? When do you expand? When do you contract? Like, how do you kind of manage that in a good way? And that's super hard. And I think, I think some of the things is that I think Uber really should have, and I don't really, I have not really reflected much on how we should have done it. But that's definitely something where like, we should have better at doing those transition from like full freedom to more structure.

• 1:17:07Speaker 00

  Like one of our prime examples is, at some point, we started tracing back when Jäger was built for this with tracing.

• 1:17:17Speaker 00

  Pretty nice and everybody thought this is pretty nice. And then there was like a mandate to say, okay, we need to, we need to enable tracing on all our services. Because we have microservices, we have like a thousands of microservices. Nobody knows what's going on. Let's do tracing because that will give us a lot of benefits. And then there was an email going out. And I don't remember the exact dates. I'm guessing the first email was in fifteen saying, oh, okay, we're doing tracing. All teams must implement tracing.

• 1:17:45Speaker 00

  And then it probably was a deadline. Three months later. And then three months later, it's like the same. Because it had not happened surprisingly. And then it, there was just like, maybe until maybe seventeen, eighteen, there was like, okay, this, now we're doing it. Now we're doing it. And but it never got done. And somehow the emails just stopped coming, but it never got done, like for real.

• 1:18:09Speaker 00

  So that's inability to kind of affect like global change.

• 1:18:18Speaker 00

  Just made so many projects so hard. And it's really a, to very last degree, a cultural problem. But I think it's not just an engineering problem, but it's like, it's an engineering culture problem. And I think that, I think to me, that is probably the, one of the biggest things that

• 1:18:36Speaker 00

  that to some degree hurt the company. Because there was a lot of waste, a lot of waste going on. That was not necessary later on. It was necessary in the beginning, but they don't know.

• 1:18:48Speaker 00

  So I don't think, I don't have like a concrete like, oh, then we did this and then it was kind of stupid and we should have done that. Where, where it was like super obvious. Well, okay, I'll just mention one thing. And that is, at some point, and maybe somebody's going to be super angry about this, I don't know. But at some point, we tried to implement a kind of software networking stack.

• 1:19:15Speaker 00

  And the, the team building it was like, yeah, so we're going to do this thing where you're like, we're going to build a software network.

• 1:19:25Speaker 00

  Where like if you are, when, when, when services need to communicate, it goes into an ingress. And then it gets routed through a network and to a, to, to, to the right service. And that whole thing, we implement in node.

• 1:19:38Speaker 00

  And I was like, I just distinctly remember it was like a platform TikTok or about it like, this is like insane. But it was back in sixteen or whatever, and I was like, not that senior yet. So I, okay, but those people are pretty senior. They must know what they're talking about. Turns out, they did not know what they were talking about. And that that caused a lot of pain. And many years of untangling and whatever. So I think that that was a pretty bad decision.

• 1:20:11Speaker 00

  Sorry to anybody who who don't think it was, but I think it was.

• 1:20:15Ryan Peterman?

  About Uber's culture. Earlier, you mentioned that, especially with the promo committees, that there's a bit of a unusual culture of, you know, everyone needs to sell. Their managers just present their reports and you just sell it in a big group. And you alluded to that. At that time, there was also some other cultural backlash. And I vaguely remember that too, like around, maybe it was twenty seventeen or something like that, where there was a lot of stuff going on at Uber. What was it like for you experiencing that at the time?

• 1:20:49Speaker 00

  There's a very big cultural difference between Denmark and Silicon Valley. Very interesting. And in many ways, quite entertaining.

• 1:21:01Speaker 00

  So like, so it was a bit weird to experience because like, many of those problems with it was we just were like, are these like, is this how people behave? I thought we were just like coding and having fun.

• 1:21:17Speaker 00

  What are you doing over there? Apparently doing something very different. So it was like, it was very, first of all, quite disconnected because like, we were not, like, we were quite far from that whole thing.

• 1:21:33Speaker 00

  Or maybe it's just me. I was like, maybe I was just very naive. I don't know.

• 1:21:39Speaker 00

  But first of all, it was it was good to be at a distance because we like there was a lot of stuff going on. We could just keep on like executing and doing our thing. So that sense was nice. But there was also it was also insane like so much that much stuff that was happening and people leaving, getting fired, board members getting kicked out, Travis getting kicked out, a lot of stuff going on. It was like every day you that's like, what's going to happen now?

• 1:22:04Speaker 00

  But again, daytime, quiet here because nine nine hours time difference. We can just do our thing and then whatever happens, happens. And there's not really anything we can do about it. It's not like not our fault. Uh, there's some of it, of course, we also have to adapt to.

• 1:22:22Speaker 00

  But there was very much, like when I joined, there was very much like every everything was very much about you. Like performance reviews, you, promo, you, conversation, you. Like when you get hired or and you negotiate each other, it's just about how good you are at negotiating. So it's all about you. It's not about the team. The team doesn't matter at all. It doesn't play into anything, more or less. Uh, which is insane to me. Like, it's like, I don't get it. So even though that was kind of how how Uber works, we had never like gone fully into that mindset. Uh, so for for us, there wasn't that big of a of a difference.

• 1:23:02Speaker 00

  Uh, it was more like, okay, now you're like, because I always thought like, I just thought that was how it was in the U S. Uh, so I was like, okay, so, oh, it's not actually, it's like, you actually wanted to be different. Like, I thought I thought you liked it like that, but but you're still talking, I don't want, I don't know why, why you did it like that then. Yeah, but anyway, uh, but it was very interesting times and there was just a lot of scandals also where we were like, why, why did you do that? Why did you decide to go to a strip bar? Or like, why did you decide to to kind of open up somebody's private data and see where they went? Like, what motive did you do that? I don't know. But like, what motive is a board member to like on a live stream

• 1:23:47Speaker 00

  to the entire company after a sexual harassment scandal? To say something like, yeah, it's going to be nice to get a woman on the board because they talk more.

• 1:23:56Ryan Peterman?

  Oh, no, no.

• 1:23:58Speaker 00

  What?

• 1:23:59Ryan Peterman?

  That's so bad.

• 1:24:00Speaker 00

  What? Like, what? What are you thinking about? What is this insanity? I have mixed feelings about it. It was just, I was just happy to be at a distance and but sometimes you could also just feel like, okay, bring out the popcorn and like, see what's happening. Yeah, because like, it was just, it was very interesting times. When I went to the US to visit before seventeen, you go to someone's offices, people like fist bump. And then, do you want a whiskey? I don't know. And it's like Tuesday at two P M. I don't know. Do I want whiskey? I don't think so. Like, I don't know. You said a thing?

• 1:24:35Ryan Peterman?

  If you look back on your career so far and you're knowing everything you know now, if you were to give yourself advice when you just started in your career, what would you say?

• 1:24:46Speaker 00

  Just try stuff. And don't, don't be afraid just because it looks hard or because those other people look much better than you. Because they may, might be better than you. Sure. But, but, but you can also get there. It's not, it's not, it's not rocket science. It, it is, it's just computers. If you like computers, you're pretty well off. If you just keep going with that. So I think that's probably the main thing. In my view, it's like, just let, let, let your curiosity take you where, wherever. And don't just, don't assume that what you're doing right now is the best thing you can be doing.

• 1:25:28Speaker 00

  Because there's probably something that's even better or will be soon. And then don't just discard that just because you're kind of having fun now or whatever.

• 1:25:42Speaker 00

  Of course, it might be hard to tell which what is better than what you have done. You also just have to take a chance sometime.

• 1:25:49Ryan Peterman?

  Awesome. Well, yeah, thanks so much for your time. I really appreciated it for the guests. I'll link to your socials in the show notes. Is there anything else, though, you want to point people to? Maybe something you're working on or anything like that?

• 1:26:06Speaker 00

  I think my LinkedIn profile is the most relevant place because that's where all the stuff I write goes.

• 1:26:12Ryan Peterman?

  Okay, cool. Well, thanks so much. I really appreciate it.

• 1:26:15Speaker 00

  Awesome.

• 1:26:17Ryan Peterman?

  Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or on Spotify. If you want to drop a review, that'll be super helpful. And if there's any guests that you want to bring on to, please let me know. I feel like sourcing very senior ICs. There's no well-studied list out there on Google that I can just search this up. So if there's someone in your org or at your company who you really look up to and you want to hear their career story, let me know and I'll reach out to them.