The Peterman Pod - Uber Distinguished Eng On Unfair Promos, Influence, Engineering Regrets (Career Story)

Episode Date: November 11, 2025

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 - Intro00:00:56 - Distinguished promo project00:19:07 - How to grow your influence00:22:38 - Unfair promo story00:33:09 - On delegation00:39:05 - Why engs don’t trust management00:47:58 - Politics as he grew00:57:00 - How to pick mentees01:03:22 - Why he left Uber01:15:16 - Biggest Uber eng mistake01:20:15 - Uber scandals01:24:35 - Advice for younger self01: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

A software engineer needs to write code. If you're not writing code, you're not a software engineer. This is Joachim Recht. 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? I like the idea of like you become a force-go supplier by allowing other people to work better and faster. He was also on a ton of promo committees,

so I asked them about what most engineers never get to see. What does it mean when you're saying promos are not fair sometimes? It gets super unfair because it all depends on how good issue manager at presenting your case. And if you're a shit manager, you're a shit case. Is there an engineering mistake that you saw happen at Uber that was only obvious in hindsight? And maybe someone's going to be super angry about this, I don't know. But... Here's the full episode.

What was the initial problem that you were solving and the story behind the project that eventually got you promoted to Distinguished? 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. Previously, we ran on just Postgres, single instance, like just a big-ass machine, and a lot of replicas and stuff like that, but 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 like to have a new data store in place. So in the office, we were building a new kind of object stored. That's called schemeless. There's also those stuff about that out there. Schimelis is basically based on shot with MySQL. MyC job was primarily handling all those MySQL charts, 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 master promotion or any kind of maintenance or replacement, you had to do some puppet mingling. Log in, mangled 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 grew more.

And so around that time also, it's not that Dugger was super new at that point in time, but concernization was fairly new concept still. Some people were using it, some people weren't. Kubernetes, I think, was out in like, it just got released in the first alpha version just around that time. So I had the, at some point we kind of start talking about,

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 started 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 the database. It gets pretty expensive, especially because you utilize it.

So why don't we visualize and considerize some of that so that we can improve so we can improve utilization, but also it becomes much more easy to manage. If we then also take that idea that's become very common now, but what's 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.

We want a cluster that needs to have nine. We want a database. We'll have 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 schemelers first, and that worked out pretty well.

There was like a whole ecosystem around that was also monitoring and management and version control. It was like all right back then. It was not Git-ups. I have like a somewhat version to get-ups because GitHub 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 tradition.

GitHub 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. 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 efforts. we probably 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 held monitoring, provisioning, decommissioning, database management, all that stuff. 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 make a single platform that can handle that?

And that basically then became, yeah, Odin. And that took a while. I said that for many reasons, like, there's organizational, like, or like, there's just people, because they already built, many teams built their own tool chains, like, why do we, wife would be used 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 there was actually a good idea and then actually get it rolled out.

And also getting it to work with, like, technologies are not, that were in, that are inherently not like a cloud ready or like container ready, like HDFS, for example, or Kafka used to also be notoriously bad at moving stuff around dynamically. It's just not a thing. Because host names are encoded everywhere and pod numbers and you need to shuffle data and there's no good way of shuffling data really. So getting all that to work, you just took a lot of time and effort. But basically that project just grew and grew and grew in scope

from like a very single thing where we just need to manage, our own team stuff, to actually managing the entire company on the Stakefold side. And when I left, it was actually running all the stakeholders, like all the Stakeful were close. Which is like, I don't remember the exact numbers by now, but like when I left, I think we had like around 120,000 physical servers under our control and like around half a million databases. So like all co-located and whatever.

And running on being kind of. operated by a team of 20-ish people, which to me is like pretty insane. There were still like database teams that did the actual database like Cassandra, MySQL like expertise, but just the fleet management part of it. Like the ability to be able to operate a kernel with a single click or rotate like decommissioned data centers or commission new data sets, all that stuff, which usually takes a whole lot of manual effort. that kind of over time got pretty advanced.

Am I understanding the initial motivation was two main things. One is 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.

And also just to consider, consistency of that part. 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, how do you discover that a disk doesn't work any log or whatever it might be. You don't want everybody to go around and doing that by themselves. You kind of want that to just be done once.

It 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 did you convince people that you should start using Docker for databases? Well, so one of those good things about Uber, especially in the old days, was that it 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, they were like something like 52 maybe different databases technologies in use in the company, which is like, that's a lot.

But on the other hand, we also had the freedom to pick what we wanted. So the decision 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. There were some people, but there was a lot of people who had to be involved in it. So in that sense, it was fairly easy on the first thing because we just did it for our team by ourselves. And that was like how Uber operated for better for worse. So that part was pretty easy. I think 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 is the right thing.

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 do it for everything. But we're going to start, it would be a very incremental effort. Going to start with the stuff that we own in our office. Then we're going to do the things that are owned by our friends in other departments. And then we're going to broader and broader to people who are more resistant to stuff like this. That we knew upfront.

We also knew that we're not going to have like a ready platform. form like from day one anyway. So we don't want to have everybody on day one. But maybe you boss like a, like I always have like a, I don't want to force anything down anybody's throat. So I just want like I want to build, I prefer to build something and show that it like it works. And then people can kind of say, okay, that maybe it isn't that bad.

Then if you think it works somewhere. So a more incremental approach to to the whole thing. And I think that that's helped a lot. It also took a very long time. You said there were challenges when you were influencing the other teams to adopt this. What was the main pushback that you'd hear and how did you convince people? Well, I think one pushback is just that we already have something. And it works.

So it's a waste to do something else. And I can see that argument. But it's also a kind of local perspective. It's not a global perspective. When we build this, it was more from a company-wide perspective of like, we want to improve the general state of stateful workloads. We don't just want to improve your thing. 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. Like, for example, because Uber didn't and still doesn't have a full software-defined network where you can just like virtually move IP address 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 take to a logical move of something and that just for some story signal it makes it really really hard and that's of course pretty annoying so you

so that from like 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 bit 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. 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 GCPUs? Because if you're running databases, particular 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. For both the actual runtime needs to the kind of schedule, we have the ability to schedule, but also the actual schedule that needs to be able to see how to 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.

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, that more people were like, yeah, that's pretty nice. It sounds like this effort was kind of a bottoms up kind of effort where you and some engineers realize this is a good idea. And then it gained traction and gain traction. I'm curious, like as the initiative evolved, like did leadership start getting evolved at some point and how'd that evolve? We could really only get so far, especially because back then Uber, like the stateful part of Uber was basically split into two. One was like the online, real online databases, MySQL, Postgres, Cassandra, stuff like that. And then there was all the data stack, ACFS, Kafka, Pino, all that stuff.

And that ran in a completely different org. We had no like the management chain from that. I could 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 then at some point, there was some re-orking going on, but also we got more and more support of the management chain. So, by now, this is something you have to do. At some point, they just said, okay, this Olean thing is the future, and you will not be allowed to have your own servers any longer. You want to run something, that's where it runs.

And that, of course, helped a little bit also with like adoption. Because there will always be like, if you have like the full personal thing, there will also always be distract us or people who are just like, we don't want to. We have our own thing going. It's super hard to like create like full alignments 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, yeah.

Yeah, I mean, it's a huge undertaking. And I feel like when you talk about the end state of the entire company, the scale of database is all running through this one platform. That distinguished scope makes a lot of sense. I'm curious 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? I think in general, there are many opinions on how you get promoted, what triggers the promotion. I have like a somewhat maybe naive perspective on it that it's 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, like the wider 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, it's not like a direct influence, but the more people who are 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 drags a lot of people along. Now, of course, if you 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, another project cancel or fails, and then you have to do something else. It gets much harder to kind of ride that expansion.

Not impossible. I've seen many things where many cases where it's definitely possible, but it's just it's much easier when the project you're working on has that natural scope expansion. So made my promotions to a very large degree follow that work. Like first, first I did some backflow, so I did some other work before we got to the whole stateful 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 to standard by SQL and Cassandra and that got me another promotion to

I forget the because the title names changed a bit on the way. But that probably got more to principal engineer. And then when we kind of, Odeen was more, it wasn't done, done, but it was like sets, like it really didn't require me any longer. It was maybe handed off to the team. And I could do other things. And 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're doing quite nicely. 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 influencing more and more engineers? So I have this personal thing. And I just, I just don't like, doing things too many times. I just really don't like it. And I think I might have written something by the Lacey engineer at some point, which like, yeah, I like putting these weird titles and 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 manual a couple of times, I'm like, this I don't want to

do it anymore. that needs to be automated to some degree, or abstract that way, or whatever it might be. And so I think that's not the only thing, but I think for me there's a major driver because then I'm like, why do we have this waste in our systems or in our processes? And when you 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 and you use your team and you kind of expand from there. So 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 natural thing. And it can be pretty annoying sometimes because all you can kind of tend to wrap it a little bit also. Or it's like a what we kind of call a depth first approach to everything. where you're like, oh, I'm doing this other thing, but suddenly, are this annoying? I need to build this tool. 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 completely sidetracking what you should actually be doing. That's kind of the danger of it. But to me, I think it just drives a lot of this like. how do you actually improve systematically and systematically like the company and the processes and in particular your engineering organization.

That's why I'm focused, but it can also touch other things, but mainly engineering. I see the natural leverage that comes from it because 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. Yeah, yeah. And yeah, so like we also talk about this whole thing about like, yeah, how do you scale yourself? 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, we can start like doing more design so you can push that down. I like the idea of like you become a force multiplier 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. Take that problem away. Think about how do we actually take the problem that you have out of the equation? Because I think that's the most fundamental thing you do.

The thing you're doing, if you don't have to do that any longer, what could you then be doing? One 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, or what does it mean when you're saying? saying promos are not fair sometimes? Well, I think it can mean, so it can mean a lot of things. And I do, but I've been part of promo committees for a very long time. 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. 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 and senior engineers in a room for an entire day. And then somebody asks,

okay, let's go through all the candidates. Let's actually go through all our employees, all our engineers, just all of them. And then the manager talks about, like, how good are the end? should they get promoted? And then we just, and they were like, I don't know, 200 or 500, 800 years, like, insane number.

And there was no preparation. There was no material. There was just like the manager saying what they thought, and obviously they all thought that everybody should be promoted. And then it was like, okay. And then we should have some kind of structure. Let's do some kind of point system or whatever. And like, is this how it works?

And it was back then apparently. And of course, in a setup like that, it gets super unfair because 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. You might also have a very good manager, but your work is shit. 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 that, but it was kind of part of it.

But anyway, things did get more structured. But it is just super hard because you cannot, there's just no way you can objectively judge how a person is doing. Because there's so many dimensions, there's so many things. You're not operating in isolation. Maybe it depends on, like, maybe the thing you were doing actually dependent 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 they, it's, That's not your fault. Or maybe you had the project. It was running. It was almost in production. Then it gets canceled by management just for various reasons.

Not your fault. But like, then what? Are you then not going to promote it? Are you getting promoted? And 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, 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. Other 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 was just like,

it was not your fault, but you're not getting promoted. So yeah, ideally there's just fairness all around, but I think that's, there is just inherently, because it's a human process, there's just a fair model. unfairness. And then I think 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 the team, they did super well. But it's just also because the team is not very well. Well, you lived on an

island and you hadn't realized that there's another world out there that's actually very different and more, whatever, which I think just in the early days of Uber used to be a Python shop, well, first, like a JavaScript Python shop, then it went into a Go kind of shop. And 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 kind of groups of people who kind of had been under their own influence. And like, and you just look at what they have produced. I'm like, this is not, this is no good.

This is just no good. Even though you kind of maybe, yeah, sure, there's one of you who's better than the other whatever, like, but it's just like as a whole, it's just no good. So we can't, we just cannot promote you because you need to look at what's going on over here. And that can just feel super, super unfair to those people. because if they were not prepared for what they actually went into, I think that's also why I kind of made this effort of like trying to describe, how do you actually get promoted?

Like, what does it mean? And it's not about like, I think I call it something like beating the promo committee or whatever, which can just like a catchy title. But it was really more about like what does it actually mean to be a software engineer at Uber? because you have kind of also the ideas what that means. But actually there is something. There is a way to be a software engineer at Uber. Like that way is more like different than meta or Google or whatever.

And I think it's pretty important to be aware of that. Because otherwise, you kind of worked towards something. That was not the thing that it should have been. And that can create a lot of frustration, a lot of disappointment. Yeah, which, yeah. And it's too bad that people can't get into that state and don't get the correction along the way. That they go all the way to promo,

have prepared a package, written a lot of stuff, gotten feedback, getting peer feedbacks or whatever. And then the promo committee is like, nah, it's no good. Yeah, you said you wrote that piece that was How to Beat the Promo Committee. and it's basically the way that you grow as an engineer at Uber, and it's not focused on actually the specifics of the promo packets, it's actually focused on how do you become a stronger engineer?

What was in there? Mainly just, as you say, good engineering practices and something that I found surprising and I actually found surprising during all my years at Uber, which is, well, I don't know, it also met our philosophy. But I'm like, a software engineer needs to write, If you're not writing code, you're not a software engineer. I know that's from people find that pretty controversial for something.

I don't know why, but like apparently this. To me that, and that applies to any level. Like if you level, 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,

once a week or whatever, but like, to me it's like everything, ideally. So I think the main advice in that thing was really just write code. Don't mess around 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 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. Also write good code, like the secondary advice, and make good commit messages and make sure to review code and make you a code nice to review. and all this, just like standard software practice, which people kind of, I don't know, forget a bit about. Many people also might not have learned it. Because 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 also a craftmanship 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 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 other one of my other philosophies is like like running code beats perfect code anything. I don't know, you can always come up with like weird cases, but in the big picture, running code will always beat working

like perfect code or beautiful code or whatever. And that could be as a software engineer pretty hard to like some people, because some people are really, oh no, no, like it needs to handle the cases, and whatever, I'm just much more, 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 the entire thing and it was handled 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. And like that's just not useful because you did not get any feedback. you never maneuver your sword, you might be completely wrong, correct, like God knows what.

One comment 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 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 yeah and like as like personally i like i don't subscribe to that idea at all i see that a lot uh this is also like some it's also like some it's also about like to some degree that's also what you about what you find interesting and i just like i just like finding joke

i just do i have always liked it it's just like what i like to do i would probably like if i If I didn't have anything else to do, it's what I would 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 think there's also just a very big overlap between, like, just the between the writing of code and the ability to like perform at any level. And to me, it's like, there are many facets to it. One thing is, if you're not running code, you lose touch with the system.

Not on day one, of course, because on day one, if you stop running code on day one and one month one, it's fine because you kind of remember what was going on. But the system evolves all the time and you forget how it is and you can't probably get a more and more high level 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 design for the future. The signs you come up with will be more and more decoubled from reality

and be more and more, it might be idealistic. And then when it gets to actually 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 guy with the whiteboard and the documents, like, you, who's that to like say what we should be doing?

Because the actual problems we have are like this. So I think that's, I think that's one major thing. And tied to that is the kind of how do you actually build a scene because you need to scale yourself. That's for sure. 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, which I think is a bit different than just scaling yourself.

Scaling yourself the size of the view of cloning yourself, which usually doesn't quite work. But if you need to kind of make your team, when I say your team, 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, they know that if you say something, it usually works out. Or if they say something, then you listen to them. And so 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 those 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 other documents and you're doing talking and reviewing and what that, but you lose more and more touch with what is actually going on. And then, and this might just be an Uber thing, but you get more and more hostility also. And people won't tell you to your face.

but you will be everybody will think who's that asshole or who's that kind of guy to come and say whatever so you're saying 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 convince them they're going to not go your way yeah I think

at least I've seen that a lot and the the other thing is if you're not like in there, then personally, I don't want anybody to tell me what I'm supposed to do. It's not that I'm not open for input. I really like to talk about it. But if you don't have skin in the game,

I think you should stay out of my things. And then I will also promise to stay out of new things. If you ask for help, more than willing to help. If I ask for help, I hope that somebody will help. So that 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 you're saying, what you're saying.

It just creates a lot of mistrust and in some cases, they're just plain hostility. 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 let's like go back and not do any of the stuff that you talked about. Which is probably the most annoying outcome that you can get.

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, my question is, why don't engineers trust management? 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,

but that idea might be completely off because they haven't really spent the time to kind of understand what is actually going on. It might be that they're completely right. But it's just, It's just, I don't know if it's just human, whatever nature, or if it's just like, if it's just me. But I just know from myself and from other people I've seen, it's like, somebody says something. And if you don't, like, if you don't have a connection to them, then it's just hard to, like, take at face value. And if face value is all it is, or force, like authority.

If authority is the only thing, it just at least in, so this might also be a super local thing here, like a Danish thing, because there's basically no structure anywhere. But it's also a thing in Bay Area where like authority in itself doesn't really hit you all the way. Again, people might say, yeah, nod, a smile, and yeah, that's nice. But if you don't truly believe it, and I have just seen so many times where people, yeah, that's nice, and they just, 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 would be a bit, like, it won't, like if people don't think it's a good idea, they don't take ownership, it's just not going to be really nice.

So I think that just takes effort And it takes much more effort than you normally That you would like it to be Yeah 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

Yeah And again like as I said before Like there's probably always going to see There's somebody somewhere Who's like They're never going to be convinced. Just never go for 100%. That's one thing at least. But to me it's really like, 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, like, another thing that can very quickly happen is that the higher level you get, the more you can concentrate on the hard stuff, the stuff that you, there's only you can do. But that's really not a lot that only you can do. That might be a couple of things, but it's really not a lot. So all the other stuff, there's some tenets for people to like say, oh, because I came up with the idea, I should also implement the most interesting stuff or what are the new algorithms or or whatever, or like I used to play with the fun stuff.

And sometimes you do that. But I think most of the time you should really dedicate that down. You should dedicate the hard stuff down and just keep the easy, not the easy stuff, 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. Once you have reached at 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 my view, at least, push down the hard stuff to the people who can barely manage it and then help them, make sure that they do it, they're kind of in the right direction, and then let them kind of work with that. Rather, take that yourself and then delegate all the shit work. That doesn't help anybody. And we have like, we had like this expression of like shoveling shit. It's not a nice expression, but it is what it is.

Sometimes there's just like in order to do something, there's just some really shit work in there. And if you take that work, and like the other people do the fun work, that will also give you a lot of credit. But it will also allow them to grow much faster. Because if they get challenged with the rest of the team, they work much faster. They grow much faster. And that's just to everybody's benefit. So that whole thing, the coding, leading by example, and leading by example just means writing code

to a very last degree. And then taking all this, taking some of that stuff that other people, that you don't really want to do. Might also be improving documentation, or fixing rid of bugs, whatever it is. And there's not a lot of like, there doesn't have to feel a lot of glory to it.

There's usually not a lot of glory to it. But I'm a very strong believer in stuff like that. Interesting. Yeah, that's the opposite advice I usually hear. Usually, like, as you go up, people say, you got to 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?

Yeah. But it's also because it usually shows 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 thing, 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 out to give the need to kind of expand that to something that is not trivial any longer, that actually did require you to come in.

it was just the intention of purpose but when you come in and look at like why are we why do we have this many bucks like what is this and then you start thinking about it's that because we have bad reviews because we have bad testing

there's something else and then you can kind of start like how do we kind of make that better so I think and 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 get the right project so that I can get promoted? Or how do I, like, how do I grow my scope? And my advice has always been the same. This is more or less forget about that part. I just start writing some code. Focus on that. You just do something that works.

Doesn't have to be anything. Focus on something that works. And every time you do something, think about, I'm doing the right thing here. Are we introducing, in a lot of cases, actually, when you build something, you actually introduce more work to other people. You can't build a system, and then you're like,

oh, this is nice for us, but they actually turn aside that for other people, now they have more work. Because they have more systems to manage, or they need to configure something else and have more stuff in their head. 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 always working with that in mind, my philosophy is that then the other thing will come. You don't have to be like, oh, I must find something. It will all come and I have seen it not many times because there are not many, but I have seen it a lot of times where people like, oh, I need to be promoted and I need to find the right Let's go, 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 take too bad. But in most cases, it does. And I think it's to me is the by far the most successful way of getting there. 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? 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 not 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 you don't have I have an opinion or you think that is not that nice. So in that sense, there's a lot of, like, fighting going on.

I think you also get, you get much more exposed 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 plan. They all know what's going on. It's all under control. And then you're like, you realize at some point nobody's in control. There's an illusion of control, but there's just like people randomly getting ideas and pushing them out. And that, I think that part is pretty scary 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, or like you talk to some other guy who also don't know what they're talking about and now that's the strategy. Is that politics? Maybe it is. But you get more and more like you get more more subjected to that part and I think that's pretty scary and it's also definitely not for everybody. 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. But if you get sucked into that, 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, then what? Like, okay, now we did

that. Hooray. And so, and then there's the whole like that idea of like that thing about like somebody that somebody came up with an idea and now that needs to get implemented and then there's a little pushback and all this stuff. And of course, everybody has ideas. Who gets hurt? How do you get your idea in? So there's a lot of that. My personal approach to all that was really, back to the whole thing about like, I don't

need anybody to tell me how I need to do my things. So I also don't want to tell other people how to do their things. And I also don't like, I have never been like a career plan. as such, like, I have no, like, oh, this is how like I get to this. But I also have a very strong aversion to projects that I can just see. Just stupid or dead ends or whatever you call them. I just stay away from them and let somebody else do that. And that might be a little unfair to those other people sometimes.

But that's kind of how I kind of kept my sanity. What's basically to say, well, okay, this thing, I think you should like, fine. you're already enough people. You have plenty of people. I don't need to be able. I have my own thing over here that I can do. I don't need all that stuff. And of course, as long as my thing is 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 as long as you have something going on yourself that can fill out your scope, then I just say no. A lot. And some people might also say too much.

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 claims to pituitary in my view. But like, I think, some people probably call it politics. I don't think, I don't know.

But I also have very low patience for it. For stuff like I think. If you're doing something, let's talk about it and do it. I don't want to talk about us, we should do something, and we talk about that for hours or days or whatever. And then at the end of it, it was like, yeah, we'll actually do it next year. I'm like, okay, that was just a pure waste of time. One thing that I hear 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 is any part of you regret getting promoted to such a high level and having to deal with politics? Well, there were, okay, there were times when 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 hard. If you don't care too much, it's okay.

And I like, and I, I, like, because I had like, the good thing about by the way, we would remote office in Denmark, small office in Denmark, and we worked a lot a lot with the teams in San Francisco. And the good thing about that is, Our daytime was uninterrupted. We basically do whatever we wanted. The bad thing I was like, we don't have meetings in the evening.

But you actually had a day's work. Like normal work. You can just do whatever you want. And then you have meetings in the evening. And that creates this nice, 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 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 in the hallway that oh could you please come along and we just like talk about something yeah but we

couldn't do that so I think that also helped a lot 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 Yeah. And it's not like it doesn't happen very often.

But I'm just always, when it happens, I am, those are the best days. When I hear somebody 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. And then maybe a couple 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. And it can be just be small stuff, but it can also be a bit larger, some larger things. Like, I don't like, let's say, like,

you have resistance on like, Oden, where 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 were not like able to kind of see through that and like 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 forced into that, you're just like, a seed was planted. And then that kind of grew into something. And then suddenly that person is actually aligned and you didn't do a lot. Maybe you're nudged a couple of times. So 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've seen it not many, many times, but I've seen it a couple times. It's just like, it's just the best feeling. And it's not the best feeling of like, oh, you're right kind of thing. It's just to some degree a proud feeling of like those guys, they learn, 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. We just need to do this. They were actually like, oh, yeah. This is actually good. Yeah, that's true. 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? Yeah. So mentoring in general is like, It's a very like, I know, it sounds so nice and appealing. But it's also when you look at the whole thing about scaling yourself, it's like super inefficient.

Because you kind of parallelize it. You're like, you're one person, you're talking to one other person. And there's only so much time. You only have so much time. So like it's just super hard to get high value out of that. So to me, it was really always mainly just about having a network and having conversations that are like two-way conversations. It's not just me providing whatever, it's also them talking about something.

And that's where like if you go, if you're all mentoring inside your own like team or org is like who's actually learning what now. And like 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 sitting more easily about like career advice or whatever. 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 or they're further away from you, there's more work in it and you also have to like, there's also more benefit for you. Because you could learn something about what they're doing, you can give them more input on what they could be doing or why are they doing what. So that says I think it's nice if you actually have to spend the time to actually do it so that you also get some kind of benefits, but also so that you can kind of plant seeds elsewhere.

Because I've also seen a number of times actually that people come in and say, oh, how do I get promoted? I only get shit projects and like whatever. 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. So you're kind of planting a small seat that will take a while,

but might actually do positive change not only to the mentee, but also the rest of the team and eventually the rest of the org. So that's why I prefer to have people who are that super close. 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. 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? But I would probably start not just by asking, oh, can you do mentoring? Also because mentoring can be kind of a mental load. Well, not a mental load because there's something else. But like it can be kind of, it can feel like a big thing and a responsibility that you might not pack it once.

So it might more be like, oh, can you help with, can you help with 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 you can take it from that. I think 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. I usually didn't have that many people. But there were a couple of times. But then also like just show up, ask questions. ask questions. Like if you, I had a lot of presentations

like in different offices and I always like when people come up and talk and ask. So if you kind of ask good questions, I don't know what questions, quick questions are, but like if you just come up and ask

and signal, that I think that's a good signal of interest. And then just, because like, I think it's also on the, on the mentor to kind of say, well, okay, what you come and say is really not what you should be saying.

And I don't think that should disqualify. Because that's the whole point. They need mentoring. They might not actually know what to say. So I don't think that if you want to do mentoring, don't disqualify just because they didn't send the right resume or whatever. 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 their outlooks, what they have to be doing, what are they thinking, and see how do they react to your thing. And that might take a while.

I'll take just a bit of time, I've 10, 15 minutes. And as I think the other thing is like, to me, mentoring is much better if it's just pretty info. Like, I have, like, Uber had been 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 and I don't want a schedule. I don't want anything because, like, it's all individual what people want or need. So, so also just don't make it more than it has to be. And also 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 like

you're not getting to go get more out of it. I'm not going to get more of it. So it's like, yeah, it was nice. 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. It's not a nice story unfortunately. I don't think so. It is because I was actually pretty happy at the war.

And surprisingly so. Because when I joined Uber, I was like, this is like a crazy, like a crazy high-paced place. When I joined in 14, 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 small tech. So I would like, all these people kind of are much better than me. So like, what can I do?

And like, I would like, so I better like, like, I kind of hit the ground running and never stop. And that, that can also, 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. But it turns out it was intense. Also turned out that all those people who came from the other places,

they were not that much better than, after all. It turned out. They were also just human. 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 even with the high-paced environment and the performance management and the pro-mos and all that stuff that is not natural to a Danish work environment, it was also

just a whole lot of fun. And we had an office with a very outsized influence. We have a lot of senior engineers. We were a small office, but we had very senior years, more or less from the get-go, and we just kept on getting more. And we grew most of them internally. A lot of people grew to high levels.

In our office, we grew two distinct, which is like out of, at that point, like 70 people. It's like out of 4,500 years. That's pretty insane. So it was a lot of fun. It was a lot of fun. And we had these projects that we're working on were very 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

conference or whatever or you read about blog posts and you're reading about these people who get to like do these automations, automations, like, ah, if only we had that, like, if only we we could do that. And we had that. So like a lot of good stuff. Unfortunately, it just happened that management changed. And that just created this change in engineering culture that just meant that more and more people did not like it.

And my managers decided to leave at some point. He was like my local manager, who was also the side-lead, he decided to leave. when the first distinguishing in our office decided to leave, around the same point, then other people started to leave, a lot of people left in the US also. And that just meant that it got less and less fun. And there was more and more top-down kind of management going on.

Because initially, in the old days, it was very engineering-oriented, especially in platform engineering where I was. So very much, not necessarily only driven by engineering, engineers, but engineers were kind of part of the process. When you're deciding something, you were there. 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, almost no matter what. But it turned, it kind of went to a place where it was just like, oh, now we need to do this. And you're like, that seems pretty stupid.

And there was this decision of going to cloud, who had on-prem, was operating on-prem, had 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. It also turned out not to be true.

It only turned out to be true, because then we had to cut cost of platform, by almost 50%, then it was cheaper. But then we would also have done that on-prem and have it, like, then we just have even cheaper. But so that whole, like, top-down management just led to a full-on drain of, especially senior engineers, because nobody really wants to be part of it anymore.

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 senior engineer, if you're not behind the decisions that are made, it's really hard. Then you can just choose one of my peers or one of the managers actually said when I was like, I think I'm going to sleep. He was like, why not just stick around and you just do your own thing and just take the money

more or less? I'm like, yeah, sure, 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, then I was like, then I have to leave. Because I have tried enough to change how things are done, no, no effect. That just means, in my view, that UPA does not have the need for the devious at that level.

As simple as that. And then I was like, 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 good reason in my view, but it just lost so many really, really good people. Mostly two data breaks by now, by the way, but whatever. There's like parallel world going on there. What made you want to go to a startup instead of maybe Databricks or like a big company again?

Yeah. So I think there are two parts to it. Data breaks pretty nice. They had also a local office of open. the local office. A lot of people moved there. A lot of people are new. But also just to build us, to build more infrastructure. And more or less to build the same thing we have built once in the way. And we already built it. It wasn't that shit. 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 moving

somewhere, there should be some kind of change. And it's nice to have it like a, and like, have what's called like a cultural change, it's nice. But it would also just be nice to like do something else. The other thing is, it's nice to be a senior engineer, but it's also scary. Scary where 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 senior years come in, they have like, and they come in to fix something usually. They're like, oh, they fix 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. There's almost no chance that you can take whatever you did over there and apply again with success. 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 they will face a lot of resistance. Everybody who said, yeah, what told you? And will more or less cheer when they fail?

It's like, I don't know. It's not super attractive to be a senior idea. Like that's because like the expectations 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 you can impede you into the team or whatever. but you're not on day one kind of, 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 it. I'm not saying that I didn't want to do it at all, but like I just didn't want to do this like, let's hold move to another company where to just do the same. I just like, I'm like, if you're doing something, we might as well do something real, like drastic. And the drastic thing is just to take the complete opposite

of four and a half thousand. It's like two really years. Whatever this. So that was basically my reasoning around it. It's just like, okay, but this is just, and because the other thing, we can always do the other thing. You can always just go to Databricks or one of the other places. I can even 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, And yeah, why not just go all in on that? So that was my kind of thinking around it. Right. And since you joined the startup, how has it been compared to your expectations? It has been very interesting, I would say. It's been a lot of fun.

We have like an AI enterprise automation startup going. It's super interesting. And we built so much stuff every day. 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 the edge always, which is like, and I like it 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 of the fundraising and oh, we're about to run out of money and then what. And that whole thing is getting to be a bit stressful. And yeah. So it's been good. It's been harder than I thought would be. For now, I would say, still worth it. Not in money, yes.

I hope it will eventually. Coming to the end of the conversation, I wanted to ask you some career reflection. So is there an engineering mistake, the biggest engineering mistake that you saw happen at Uber that was only obvious in hindsight? 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. which just it got so painful later. Does that mean that you'd have done it differently or really? I don't necessarily think so.

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 may be somewhat that was wrong. But it came out of the idea of like, let builders build. Like, 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 struck you. 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 going to nuts.

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 maze 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 how we should have done it but there's definitely something where like we should have better at doing those precision from like full freedom to more structure like one of our prime examples is at some point we start to do

back when Yeager was built for this period tracing. Pretty nice. And everybody thought this pretty nice. And then there was like a mandate to say, okay, we need to enable tracing on all our service because we have a microservice, we have like a thousand 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 15, saying, okay, we're doing tracing. We're doing tracing, all teams must implement tracing. And there 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 there was just like, maybe until maybe 17, 18, they 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. So that's inability to kind of affect global change just made so many projects so hard. And it's really, to very last degree, a cultural problem. But I think it's not just an engineering problem, but it's an engineering culture problem.

And I think that, I think to me that is probably one of the biggest things 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 later on not. So 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 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. to implement a kind of software networking stack. And 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.

When services need to communicate, it goes into an increase and then it gets routed through a network and to the right service. And that whole thing we implement in Node. And I would like, I just distinctly remember there was like a platform click talk or about it. This is like insane. But it was back in 16 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. Turned out they did not know what they were talking about. And that cost a lot of pain and many years of untangling and whatever. So I think that was a big of bad decision. Sorry to anybody who don't think there was, but I think it was. About Uber's culture, earlier you mentioned that, especially with the promo committees, that there's a bit of 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 2017 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? There's a very big cultural difference between Denmark and Silicon Valley. It's very interesting. And in many ways, quite insuffaining. So it was a bit weird to experience because, like, maybe it was.

of those problems we just were like, are these, like, is this how people behave? I thought we were just like coding and having fun. What are you doing over there? Like, apparently doing something very different. So it was like, it was very, well, first of all, quite disconnected because like, we were not, like, we were quite far from that whole thing. Or maybe it's just me, I was like, maybe by just very nice. I don't know.

But first of all, it was good to be at a distance because there was a lot of stuff going on. We could just keep on like executing and doing our thing. So in that sense it was nice. But it was also insane like some of 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 was like every day. You're like what's going to happen now?

But again, daytime. time quiet here because 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 there's some of it of course we also have to adapt to but there was very much like when i joins there was very much like everything was very much about you like performance reviews you promo you conversation you like when you get high and you negotiate your salary, 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, which is insane to me. It's like, I don't get it. So even though that was kind of how Uber works, we had never like gone fully into that mindset. So for us, there wasn't that big of a difference. It was more like, okay, now you're like, because I always thought, Like, I just thought that was how it was in the US. So I was like, okay, so, oh, it's not actually, like, you actually wanted to be different. Like, I thought, I thought you liked it like that. But you're still talking, I don't know why you did it like that then. But anyway, 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? Like, why did you decide to go to a stripper? Or, like, why did you decide 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. Like, what motive is a board member to, like, on a live stream

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? Oh, no. No. That's so bad. Like, what are you thinking about? What is this insanity?

I have mixed feelings about it. I was just happy to be at a distance. But sometimes you could also just feel like, okay, bring out the popcorn and see what's happening. It was like, it was very interesting times. When I went to the US to visit before 17, you go to somewhere in the offices, people like fist bump and then do you want a whiskey?

I don't know. It's like Tuesday at 2 p.m. I don't know. Do I want whiskey? I don't think so. Like, I don't know. You said a thing? If you look back on your career so far and knowing everything you know now,

if you were to give yourself advice when you just started in your career, what would you say? Just try stuff. And don't be afraid just because it looks hard because those other people look much better than you. They might be better than you, sure. But you can also get that. It's not rocket science. It is 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 your curiosity take you wherever. And don't just assume that what you're doing right now is the best thing you can be doing. Because there's probably something that's even better. or will be soon and then don't just discard that just because

kind of having fun now or whatever. Of course, it might be hard to like tell what is better than what you have done. You also just have to take a chance sometime. Awesome. Well, yeah, thanks so much for your time. I really appreciated it for the guests. I'll link to your socials and the show notes. Is there anything else though you want to, you know, point people to, maybe something you're working on or anything like that?

I think my LinkedIn profile is the most relevant place because that's put all the stuff up right. It goes. Okay, cool. Well, thanks so much. I really appreciate it. Awesome. 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 icies 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