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

11 Nov 2025 · 1 h 27 min · 26 chapters

Ask about this episode

Ask anything about it. ChatGPT or Claude reads this page and answers with the times it was said.

Connect VO and ask about every podcast you hear, including the moments you saved. Add to ChatGPT · Add to Claude

In short

Joakim Recht (Uber Distinguished Engineer) explains how he scaled influence from writing code to leading Uber’s stateful infrastructure platform, Odin, and discusses engineering regrets, promotion fairness, and career advice.

Guest background

Joakim Recht is a software engineer who became one of Uber’s few Distinguished Engineers. He led work on SchemaList (sharded MySQL on Uber) and later helped drive Odin, a fleet-management platform for stateful workloads.

Key claims

  1. “If you’re not writing code, you’re not a software engineer” (ideally daily).
  2. Promotions are mostly tied to scope/impact, but can be unfair because promo outcomes depend on manager advocacy and human judgment.
  3. To influence more engineers, build “force-multiplying” automation so others do less manual work.
  4. Avoid “politics” by focusing on implementing rather than endless planning.

Notable examples

  • SchemaList: moved from bare metal + Puppet-driven MySQL master promotions to Docker-based, orchestrated clusters with monitoring/version control.
  • Odin: unified operations across many stateful technologies; by his departure ~120,000 physical servers and ~500,000 databases were managed by ~20 people, with database expertise still in specialized teams.
  • Promo committee example: early process had managers presenting candidates with no structured evidence, making outcomes “super unfair.”

Written by AI. May contain mistakes. Listen to the episode to check what was said.

Chapters

Tap a time to open that second in VO

The Challenge of Building a New Data Store

0:51 to 3:56

Hear the story behind the creation of a new data store at Uber and its impact.

“What was the initial problem that you were solving?”

Developing the Odin Platform

3:56 to 7:30

Explore the development of the Odin platform for managing stateful workloads at Uber.

“I have a somewhat aversion to GitOps, because GitOps is a one-way thing.”

Overcoming Resistance to Change

7:30 to 14:00

Learn how Joakim and his team navigated pushback while implementing new systems.

“like the ability to be able to upgrade a kernel with a single click or rotate like decommissioned data centers or commission new data centers, all that stuff, which usually takes a whole lot of manual effort.”

Uber's Stateful Architecture Evolution

14:00 to 15:00

Learn about the historical development of Uber's stateful architecture and its organizational challenges.

“Especially because back then, the stateful part of Uber was basically split into two.”

Career Progression through Influence

15:00 to 17:00

Discover how influence and scope of work impact career promotions in engineering.

“If you want to run something, that's where it runs.”

The Lazy Engineer Philosophy

17:00 to 21:00

Understand the concept of the 'lazy engineer' and its implications for improving workflows.

“So if you're actually able to run a project of that scope to success, then I think that a promotion will happen.”

Understanding Promotion Fairness

21:00 to 23:20

Explore the complexities surrounding fairness in promotion processes and committee dynamics.

“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 we can push that down.”

Challenges of Promotion Processes at Uber

23:20 to 28:00

Examine the challenges and perceptions related to promotions and performance evaluations at Uber.

“Let's actually go through all our employees, all our 18 years, just all of them.”

Understanding Software Engineering at Uber

28:00 to 29:04

Explore what it truly means to be a software engineer at Uber and the importance of aligning expectations.

“And it's not about, like, I think I called it something like beating the promo committee or whatever, which can just, like, a catchy title.”

The Importance of Writing Code

29:04 to 31:28

Learn why writing code regularly is essential for growth as an engineer.

“If your title includes engineer, you should be writing code.”
Show all 26 chapters

Balancing Coding and Management

31:28 to 34:52

Discuss the challenge of balancing coding responsibilities with managerial duties and maintaining trust.

“It's almost impossible to learn it by yourself.”

Influencing Without Authority

34:52 to 37:45

Discover strategies for influencing others in a technical environment without relying solely on authority.

“And that just means it gets harder and harder for you to design for the future.”

The Challenges of Team Dynamics

37:45 to 42:00

Examine the dynamics of team relationships and the importance of staying hands-on in engineering.

“But if you don't have skin in the game, I think you should stay out of my things.”

The Importance of Delegation in Engineering

42:00 to 44:50

Learn how effective delegation can lead to faster growth for junior engineers and better project outcomes.

“But that's really not a lot that only you can do.”

Value Over Promotion: A Worthy Perspective

44:50 to 47:58

Discover why focusing on value creation is more beneficial than chasing promotions in your career.

“ones as well, complex ones to kind of warrant it being worth your time.”

Navigating Workplace Politics

47:58 to 52:12

Explore the dynamics of workplace politics and how to maintain authenticity amidst challenges.

“because I think this is a common thing some people experience, is did your role become more political?”

Influence and Leadership in Engineering

52:12 to 56:00

Understand the subtle art of influence and how to inspire others without force.

“I just like to be blunt about it, just like plain stupidity in my view.”

The Impact of Mentoring on Influence

56:00 to 58:12

Explore how mentoring can influence both the mentor and mentee positively.

“It's just to some degree a proud feeling of like, those guys, they learned, they're on the right track now.”

Effective Approaches for Mentees

58:12 to 1:01:44

Learn how mentees can effectively approach mentors for guidance.

“it's like, who's actually learning what now?”

Reflections on Leaving Uber

1:01:44 to 1:13:44

Discover the personal story behind the decision to leave Uber amidst cultural changes.

“say is really not what you should be saying.”

Transitioning to a Startup Environment

1:13:45 to 1:14:48

The speaker shares insights about their experience moving to a startup and the differences from Uber.

“So doing the startup thing is like, if you're doing it, then yeah, why not just go all in on that?”

Engineering Challenges at Uber

1:14:49 to 1:20:04

A discussion about engineering decisions at Uber that became problematic over time.

“I don't like a lot the fundraising and, oh, we're about to run out of money.”

Cultural Observations and Scandals at Uber

1:20:05 to 1:23:38

The speaker reflects on the cultural issues and scandals experienced during their time at Uber.

“What was it like for you experiencing that at the time?”

Insightful Reflections on Workplace Culture

1:23:39 to 1:23:59

A compelling critique of Uber's workplace culture and its impact on employees.

“What motivates 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.”

Career Reflections and Advice

1:24:00 to 1:25:50

The guest shares insights and advice on navigating one's career and embracing curiosity.

“But sometimes you could also just feel like, okay, bring out the popcorn and see what's happening.”

Podcast Engagement and Support

1:25:50 to 1:26:29

The host discusses ways listeners can engage with the podcast and participate in future episodes.

“Well, yeah, thanks so much for your time.”
Hear the part that matters, and keep it.Open this episode in VO. Double tap your headphones to save a moment as you listen.
Get VO free

Transcript

Automatic transcript. May contain errors.

0:00A software engineer needs to write code. If you're not writing code, you're not a software engineer. This is Joakim 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 forceful supplier by allowing other people to work better and faster. 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? It gets super unfair because it all depends on how good is your manager at presenting your case.

0:37And if you are a shit manager, you have 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. Here's the full episode.

0:56What was the initial problem that you were solving? and the story behind the project that eventually got you promoted to Distinguished? 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. Previously, we ran on just Postgres, single instance, just a big-ass machine, and a lot of replicas and stuff like that, but a single database. And that was 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 object stored.

1:33That's called Schema List. There's also a lot of stuff about that out there. Schema List is basically based on sharded MySQL. 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, puppets, 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 manging. Log in, mangle puppet, hope for the best. And that was pretty hard. And it got harder and harder because the system kind of scaled more and more or grew more.

2:18And so around that time also, it's not that Dugger was super new at that point in time, but containerization was a fairly new concept still. So 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 started 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 single host because when you run these charted MySQL things, 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.

3:05It gets pretty expensive, especially because you're not going to utilize it. So why don't we virtualize some, containerize 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 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 say, 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.

3:48So that was basically the idea, roughly. We built that for Schemuless first, and that worked out pretty well. There was a whole ecosystem around that was also monitoring and management and version control. It was all right back then. It was not GitOps. I have a somewhat aversion to GitOps, because GitOps is a one-way thing. You push something, you hope for the best. 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 a whole orchestration layer and monitoring on top of like a traditional GitHub strategy.

4:27And 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 do that for all the different databases that we run? It was basically what became the ODN effort. Can we build something similar that can work for any kind of stateful technology? So 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.

5:14and they did bare metal, they did host management, they did host monitoring, provisioning, decommissioning, database management, all that stuff. And it was just a lot of, like, 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 all that? And that basically then became, yeah, Odin. And that took a while to say that. For many reasons, like, there's organizational, or like there's just people because they already built many many teams built their own tool chains like why do we why would 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 a 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 technologies that are inherently not cloud-ready or container-ready, like HDFS, for example, or Kafka used to also be notoriously bad at moving stuff around dynamically.

6:21It's just not a thing. Because host names are encoded everywhere and port numbers and 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. But really, that project just grew and grew and grew in scope. From a very single thing where we just need to manage our own team stuff to actually managing the entire company on the stakehold side. And when I left, it was actually running all the stakehold workloads. Which is like, I don't remember the exact numbers by now, But when I left, I think we had around 120 ,000 physical servers under our control and around half a million databases.

7:11So all co-located and whatever. And running on being kind of operated by a team of 20-ish people, which to me is pretty insane. There were still database teams that did the actual database like Cassandra, MySQL expertise, but just the fleet management part of it. like the ability to be able to upgrade a kernel with a single click or rotate like decommissioned data centers or commission new data centers, all that stuff, which usually takes a whole lot of manual effort. That kind of over time got pretty advanced. And my understanding, the initial motivation was two main things. One is the fragmentation of the machine.

7:56So 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 the consistency of that part. Like you want 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 longer, or whatever it might be?

8:32You don't want everybody to go around doing that by themselves. You want that to just be done once. It sounds like you didn't have a grand plan for it to eventually be managing all of Uber's stateful workloads. What is it that you saw at the beginning, and how did you convince people that you should start using Docker for databases? One of the good things about Uber, especially in the old days, was there was just a lot freedom. That freedom also came with a lot of cost. I think at some point, somebody counted that we were using Adubo. There were like something about 52, maybe different database technologies in use in the company, which is like, that's a lot.

9:15But on the other hand, we also had the freedom to pick what we wanted. So the decision was a fairly easy one because 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. 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 or 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. There it became a bigger project to kind of convince people that it's the right thing.

10:00And 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 will be a very incremental effort. We're 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 kind of knew up front. We also knew that we're not going to have a ready platform from day one anyway. So we don't want to have everybody on day one.

10:46but maybe it was 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 works and then people can kind of say okay maybe it isn't that bad then if they actually see it work somewhere so a more incremental approach to the whole thing and I think that helped a lot it also took a very long time When 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.

11:28So 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 built 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 UBOB didn't and still doesn't have a full software defined network where you can just like virtually move IP addresses around and host names.

12:17If you get a new host, you get a new host name, you get a random port number and that's it. So you can do a logical move of something. And that just for some storage technologies, it makes it really, really hard. and that's of course pretty annoying so that from a local team perspective can be quite frustrating if you then have to 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 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.

13:00NUMA is the whole, like, how does memory attach to 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 have the ability to schedule, but also the actual schedule needs to be able to see how do we best allocate the CPUs to memory. That's a pretty hard thing to do.

13:36And 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, the 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 realized this is a good idea. And then it gained traction and gained traction. I'm curious, as the initiative evolved, did leadership start to get involved at some point? And how did that evolve? We could really only get so far. Especially because back then, the stateful part of Uber was basically split into two.

14:12One was the 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, like the management chain from that actually more or less went through the CEO and back down. So they were like, 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-orgging going on, but also we got more and more support of the management chain to say, by now, this is something you have to do. At some point, they just said, okay, this Odin thing is the future, and you will not be allowed to have your own servers any longer.

15:03If you want to run something, that's where it runs. And that, of course, helped a little bit also with adoption, because there will always be, if you have the full button-up thing, there will also always be stricters or people who are just like, yeah, we don't want to, we have our own thing going. It's super hard to create 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 databases all running through this one platform, that distinguished scope makes a lot of sense.

15:44I'm curious for people who are wanting to know about the career side of things? How did that look at each step when your career was growing through that? I think in general, I think there are many opinions on how you get promoted, what triggers the promotion, I have 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 maybe platform org, and then it goes even beyond that.

16:41And that kind of reflects the job level. also. The more people you have under your influence, it's not like a direct influence, but it's like 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 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 the entire team. It kind of drags a lot of people along. 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.

17:28And a lot of people kind of get shuffled around and then do a project and other projects get canceled 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 it's definitely possible, but it's much easier when the project you're working on has that natural scope expansion. So my promotions, to a very large degree, followed that work. First, 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. We did more and we kind of expanded to standard by SQL and Cassandra and that got me another promotion to...

18:21I forget that because the title names changed a bit on the way. That probably got me to principal engineer. And then when we kind of... Odin was more... It wasn't done-done, but it was like sets. It really didn't require me any longer. It was handed off to the team. and I could do other things. And that bit took me to the distinguished engineer level. But it was a very natural progression. It was not a progression I was like, that was not the reason why we were doing it. It was just, it followed the work that we were 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 being influencing more and more engineers so i have this personal thing and that is i just i just don't like doing things too many times i just i really don't like it uh and i think i might have written something about the lazy engineer at some point, which I like putting these weird titles on things.

19:44But 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 any longer. So that needs to be automated to some degree or abstracted away or whatever it might be. And so I think that's, it's not the only thing. But I think for me, that is 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.

20:29So you kind of start thinking about your own stuff 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 get promoted or whatever. It's just, I just have this natural thing, and it can be pretty annoying sometimes because you can kind of tend to rabbit hole a little bit also, or it's like 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, so I need to build this tool. Oh, but the tool is also annoying to build, so I have to build the build system, or I have to improve the build system, But the business 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.

21:16That'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 systemically like the company and the processes and and in particular your engineering organization uh that's why i'm focused but it can also touch other things but mainly engineering i 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 and yeah so like we also talk about this whole thing about like, yeah, how do you scale yourself?

22:00How 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 we 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 things that they're working on. Like take that problem away. Like think about 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:40One thing you mentioned when 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 promos are not fair sometimes? Well, I think it can mean a lot of things. And I've been part of promo committees for a very long time. And the promo committee structure has also changed a lot. The first time I was in a promo committee was, I think, I wouldn't say one of the scariest experiences of my life.

23:21but but I it was 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 let's go through all the candidates or whatever. Let's actually go through all our employees, all our 18 years, just all of them. And then the manager talks about like, how good are they and should they get promoted? And then we just, and they were like, I don't know, 200 or 500 years, like insane number.

24:05And 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 I was like, okay, we should have some kind of structure. Let's do some kind of point system or whatever. Is this how it works?

24:25And 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're a shit manager, you're 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 you depend on like maybe the thing you were doing actually depended 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 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 what?

25:39are you then not getting promoted or 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 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 and 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's 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 it's just inherently 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.

26:41And 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 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 just 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 and like this is not this is no good like 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.

27:37So we cannot, 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 called 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?

28:18Because you have kind of all those other ideas what that means. But actually, there is something. There is a way to be a software engineer at Uber. Like, there's probably this. And 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 and that was not the thing that it should have been. And that can create a lot of frustration, a lot of disappointment.

28:48And 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 package written a lot of stuff gotten feedback or getting peer feedbacks or whatever and then the promo committee is like nah it's no good 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 mainly just to 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 i don't know 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's from people find that pretty controversial for some i don't know why but apparently it is.

29:50To me, that applies to any level. If your title includes engineer, you should be writing code. It might be different how much code you write, but you should be writing code on a regular basis. To me, regular basis means every day. I know for some people, it might just be once a week or whatever, but to me, it's like every day, ideally. I think the main advice in that thing was really just write code. Don't mess around. And don't overthink it either. Don't think, oh, I need to write advanced at my level code or whatever, like the higher my level, the more advanced my code has to be. No, just write code.

Read the full transcript

30:41Because if you do that, I have just never seen anybody who will not grow along with that and just keep writing the same code. 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 your code nice to review and also 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 real-life software engineering out of college or wherever you are.

31:24It's all theory, but in real life, there's also a 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 AI and whatever, but you have to see somebody doing it in order to improve. Yeah. So I think 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 be out there.

32:05One of my other philosophies is running code beats perfect code any day. I don't know, you can always come up with weird edge cases, but in the big picture, running code will always beat working like pivot code or beautiful code or whatever. And that could be as a software engineer, pretty hard to like, because some people are really, oh no, no, it needs to handle the cases, whatever. or whatever, 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.

32:49And 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 means like after a month, you do a commit.

33:03that's just not useful because you did not get any feedback you never really saw it you might be a completely wrong crack like god knows what 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 a very common thing that people will push on higher-level engineers and say, stop writing code, go and delegate.

33:43Yeah, and personally, I don't subscribe to that idea at all. I see that a lot. It's also just about, to some degree, is also about what you find interesting. I just like writing code. I just do. I have always liked it. It's just what I like to do. I would probably like it. If I didn't have anything else to do, that's what I would do. If I didn't have a job, I would probably also do it. So I just like it. But I think there's also just a very big overlap between the writing of code and the ability to to perform at any level. And to me, there are many facets to it. One thing is, if you're not running code, you lose touch with the system.

34:37Not on day one, of course, because on day one, if you stop writing 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 probably get a more and more high level view of what's actually going on inside the machine. And that just means it gets harder and harder for you to design for the future. The science you come up with will be more and more decoupled from reality and be more and more idealistic. And then when it gets to actually implementing, it's handed off to somebody else and they're like, what is this shit?

35:20And who came up with this? Oh, that's that guy with the whiteboard and the documents. Who's that to say what we should be doing? Because the actual problems we have are like this. So I think that's one major thing. and tied to that is the kind of how do you actually build a team because as I say 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 is the size of the video kind of cloning yourself which usually doesn't quite work.

36:15But if you need to make your team, when I say your team, the people around you, the people you're supposed to influence, if you're supposed to affect change, whatever the change might be, it's much easier to do if they trust you. They know that you know what their pain points are. and that 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.

37:03So 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, 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 who's that kind of guy to like 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 gonna not go your way at least I've seen that a lot 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.

38:10It'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 but 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 that just it just creates a lot of mistrust and in some cases or 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 that's like, go back and not do any of the stuff that you talked about.

39:03Which 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? Yeah, but I think it's back to that. if you have somebody who you feel don't really know what they're talking about to some degree, they might have an idea but that idea might be completely off because they haven't really spent the time to 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 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 is like somebody says something and 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 in like a danish thing like because it's like there's basically no structure anywhere uh but it's also a thing in bay area where like authority in itself doesn't really get you all the way uh And again, people might say, yeah, nod, smile, and yeah, that's nice.

40:52But if you don't truly believe it, and I have just seen so many times where people say, 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, 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, than you would like it to be. You had to influence a ton of people in getting your project to scale across Uber.

41:30So how do you influence other engineers then and avoid that situation you're talking about? Yeah. And again, as I said before, there's probably always going to be somebody somewhere who's like, they're never going to be convinced. 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 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 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 there's only you who can do.

42:27But that's really not a lot that only you can do. There might be a couple of things, but it's really not a lot. So all the other stuff, there's some tendencies for people to say, oh, because I came up with the idea, I should also implement the most interesting stuff or what are new algorithms or whatever, or like I should 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.

43:05Because again, you don't have to prove anything any longer. 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 my view at least push down the hard stuff to the people who can like barely manage it and then help them make sure that they do it to like 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 with that that's that 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.

43:41Sometimes 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 the other people do the fun work, it will 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, decoding, leading by example, and leading by example just means writing code to a very last degree. And then taking some of that stuff that other people, that you don't really want to do. Might also be improving documentation or fixing riddle bugs, whatever it is.

44:33And there's not a lot of like, there doesn't have to be a lot of glory to it. There's usually not a lot of glory to it. But yeah, 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? But it's also because it usually turns out that the easy stuff has... It's easy because it might be easy to do, but then you're like, oh, this thing, why are we doing this?

45:21And then you start thinking, oh, how can we avoid doing that? So you take some of the easy stuff and it usually turns out to expand that to something that is not trivial any longer, that actually did require you to come in. It was just the intention or purpose, but when you come in and look at like, why do we have this many bugs? What is this? And then you start thinking about, is that because we have bad reviews, because we have bad testing, do something else? And then you can kind of start, how do we 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, pro-committees or mentoring or whatever, saying, oh, how do I get the right project so that I can get promoted?

46:16Or how do I grow my scope? My advice has always been the same. Let's just forget about that part and just start writing some code. Focus on that. Just do something that works. It doesn't have to be great. It 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, like I said, in a lot of cases, actually, 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 something else and have more stuff in their head.

47:00Think about 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 like you don't have to be like oh I must find something it will come and I have seen it not many times because there are not many but I have seen 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.

47:49But in most cases, it does. And I think to me, it's 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? 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 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 because they also want something.

48:32I don't know. I think maybe you don't have an opinion or you think that is not that nice. so in that sense there's a lot of fighting going on I think you also get much more exposed to the realities like when you're a junior engineer you kind of go we're doing engineering and then somebody else has a grand plan they all know what's going on it's all under control you realize at some point nobody's in control. There's an illusion of control, but there's just people randomly getting ideas and pushing them out. And I think that part is pretty scary.

49:25As a rational engineer, to get to the point where, 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 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:03But if you get sucked into that, then 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 weeks and weeks to do a plan. And then what? Okay, now we did that.

50:23Hooray. And then there's the whole idea of that thing about somebody came up with an idea, and now that needs to get implemented. Then there's a lot of pushback and all this stuff. And of course, everybody has ideas. Who gets hurt? How do we 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 planner as such. Like, oh, this is how I get to this. But I also have a very strong aversion to projects that I can just see are just stupid or dead ends or whatever you call them.

51:16I just stay away from them and let somebody else do that. And that might be a little bit unfair to those other people sometimes. But that's kind of how I kept my sanity, was being able to say, well, okay, this thing, I think you should like, fine, you're already enough people. Like, you have plenty of people. I don't need to be involved. 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're kind of 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.

52:02Some people might also say too much. But that's kind of my way of staying a bit away from all that, because 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 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. First of all, I think 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're just like, I could do it next year. I'm like, okay, that was just a pure waste of time.

52:44One 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 I'm curious, is any part of you regret getting promoted to such a high level and having to deal with politics? Well, there were times where I'm like, this is just, if only. But again, it really also depends on how good you are at resisting pressure and just being yourself, resting in yourself. I don't know, some kind of voodoo stuff. But how confident are you in just yourself? And how much do you care about other people's opinions?

53:34And if you care a lot, it's hard. But if you don't care too much, it's okay. And I like, because I had like, the good thing about it, by the way, we will remote office in Denmark, small office in Denmark. We worked a lot with the teams in San Francisco. And the good thing about that is that our daytime was uninterrupted. We basically do whatever we wanted. the bad thing is you don't have meetings in the evening but it's like but you actually had a day's work like normal work you 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 only 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 uh 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.

54:54Can you elaborate on what you mean by that? Yeah. And it's not that 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 just be small stuff but it can also be a bit larger some larger things like I don't like let's just say like you have resistance on like Odin where you need to rebuild something because you already had the tooling but now if you were actually using Odin you actually had the benefits but you initially you were not like able to kind of see through 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 like 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 nudged 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 um 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 are right kind of thing.

56:38It's just to some degree a proud feeling of like, those guys, they learned, 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 like, oh yeah, this is a good idea. Let's do this. 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:20Yeah. So mentoring in general, it's very like, 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 cannot parallelize it. You're one person, you're talking to one other person. There's only so much time. You only have so much time. So 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 two-way conversations. It's not just me providing whatever. It's just all them talking about something. And that's where if you're all mentoring inside your own team or org, it's like, who's actually learning what now?

58:19And that close range mentoring, I think you can... That is much easier to do, not at scale, but you can kind of talk to people in a group setting more easily about like career advice or whatever. You could do a bit of like informal like, oh, what about that? And what about that? 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 they're doing what.

58:57So that's, 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 whatever. 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 the teams. So you're kind of planting a small seed that, again, it 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.

59:48so that's why like i prefer to like have people who are not 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 you know be mentored by you or spend time with you than you had time for um 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? 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 that's something else.

1:00:30But it can feel like a big thing and a responsibility that you might not actually want. So it might more be like, oh, can you help with something specific or can we just talk about something, a design or a product we're building or whatever. Just have a conversation and you can take it from there. I think that's one thing you can do. If it's about how do you actually approach in the first place, of course, always cold call and it works most of the time. I usually didn't have that many people reach out, but a couple of times. but then also like just show up ask questions like if you I had a lot of presentations like in different offices and 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's a good signal of interest and then just Because I think it's also on the mentor to kind of say, well, okay, what you come and say is really not what you should be saying.

1:01:55I 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 can kind of gauge that from just a short discussion of what are they doing, what are the outlooks, what they have to be doing, what are they thinking, and see how they do, how do they react to your thing. and that might take a while I'll take just a bit of time 10-15 minutes and that's I think the other thing is like to me mentoring is much better if it's just pretty informal like I have Uber has been through different a number of different 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 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 like i don't think we're getting going to get like you're not going to go to get more out of it i'm not going to get more of it so this 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?

1:03:32It's not a nice story unfortunately. I don't think so it is because I was actually pretty happy at Uber and surprisingly so because when I joined Uber I was like it's like a crazy It's like a crazy high-paced place. When I joined in 2014, it was also a very hot place to be. And people were coming from Google, Netflix, Amazon. Uber was kind of the place people were going to. And then you get a bit of imposter syndrome because I didn't come from big tech. I came from small tech. So all these people are much better than me. so what can I do? And I was like, so I better hit the ground running and never stop.

1:04:28And you can only do that for so long. I'm like, okay, so when I joined, and again, I didn't have a plan, but I wouldn't be surprised if I'm out of there after three or four years because it's a pretty intense environment. But it turns out it was intense. Also turned out that all those people who came from the other places, well, I don't want to like... They were not that much better than me, 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.

1:05:11But even with the high-paced environment and the performance management and the promos 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 had a lot of senior engineers compared to like, we were a small office, but we had very senior engineers, 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 distinctly engineers, which is like out of, at that point, like 70 people is like out of four and a half thousand years.

1:06:07That's pretty insane. So it was a lot of fun. And we had these projects that we were working on were very challenging and satisfying to work on. And it was all this stuff that if you're just like in a normal company somewhere, you go to a conference or whatever, or you read about a blog post, and you're reading about these people who get to do these optimizations automations, like, ah, if only we had that, if only we could do that. 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.

1:06:59and my manager decided to leave at some point he was like my local manager and was also the site he decided to leave then the the first the distinguishing year in our office decided to leave at around the same point 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 other days, it was very engineering-oriented, especially in platform engineering, where I was. So very much not necessarily only driven by engineers, but engineers were kind of part of the process.

1:07:40When 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 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. Uber 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 on cloud.

1:08:23And no engineer believed that. 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 we could also have done that on-prem and have it even cheaper. But so that whole top-down management just led to a full-on drain of, especially senior engineers, because nobody really wants to be part of it any longer. Nobody wants to be left out any longer, 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 work in an environment where I wouldn't be able to kind of stand behind the decisions that were made.

1:09:19And 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, he said when I was like, I think I'm going to leave. He was like, 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 is pretty nice. But I just don't think I can do it. I don't think I can witness what other people are going through and just do my own thing. I just don't think I can do it. So at that point, I was like, then I have to leave because I have tried enough to change how things are done, no effect.

1:10:06That just means, in my view, that Uber does not have the need for individuals at that level. It's as simple as that. And then I was like, 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 Databricks by now, by the way, but whatever. There's like a 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. Databricks, pretty nice.

1:10:54They had also a local office, opened their local office. A lot of people moved there. A lot of people I knew, but also just to build more infrastructure and more or less to build the same thing we have built once. And we already built it. It wasn't that shit. So I don't know if I want to do it again. It was a lot of fun, but 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 a cultural change. It's nice. But it would also just be nice to... do something else. The other thing is, it's nice to be a senior engineer, but it's also scary.

1:11:38Scary 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 it's 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's like it just doesn't happen uh so those people are just in for a very rough ride because they will face resistance from everybody.

1:12:27Not everybody, but they're going to be a lot of resistance. Everybody will say, yeah, what I told you and will more or less cheer when they fail. It's not super attractive to be a senior like that because the expectations when you come in are so high. Some companies do quite well because they say, well, we can't start slow and embed you're into the team or whatever, you're not on day one kind of. But still, there's just a lot of catching up to do and you have to prove yourself. So it's not that it's going to be done. I'm not saying that I didn't want to do it at all. But I just didn't want to do this like a little move to another company where to just do the same.

1:13:12I was 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 4 ,500 engineers. It's like two million engineers, whatever it is. So that was basically my reasoning around it. It's just like, okay, but let's just... And because the other thing, we can always do the other thing. We can always just go to Databricks or one of the other places. We can even go back to Uber if we wanted to. I don't want to, but there are always the other options. So doing the startup thing is like, if you're doing it, then yeah, why not just go all in on that?

1:13:56So 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 an AI enterprise automation startup going. It's super interesting. And we build so much stuff 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 the reality.

1:14:44Where here, we're building the entire thing. And I just like that a lot. I don't like a lot 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 it would be. But for now, I would say it's 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 reflections. So is there an engineering mistake, or the biggest engineering mistake that you saw happen at Uber that was only obvious in hindsight?

1:15:33I 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's just it got so painful later does that mean that you would have done it differently 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 maybe somewhat that was wrong but it came out of the idea of 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 kill you but in the early days you don't want a lot of 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 nuts.

1:16:36I think the hard part is like, when do you expand? When do you contract? How do you manage that in a good way? That's super hard. And I think some of the things is that I think Uber really should have, and I have not really reflected much on how we should have done it, but there's definitely something where like we should have better at doing those transitions from like full freedom to more structure like one of our prime examples is uh at some point we just started tracing back when jaeger was was built for for this bit of tracing 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 servers because We have a microservice.

1:17:27We have like thousands of microservices. Nobody knows what's going on. Let's do tracing because that will give us a lot of benefit. 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, oh, okay, we're doing tracing. All teams must implement tracing. And then there probably was a deadline three months later. And then three months later, it was like the same because it had not happened, surprisingly. And then there was just like, maybe until maybe 17, 18, there was like, okay, this, now we're doing it. Now we're doing it. But it never got done.

1:18:03And somehow the emails just stopped coming, but it never got done, like for real.

1:18:09So that inability to kind of affect like global change just made so many projects so hard. And it's really, to a very large degree, a cultural problem. But I think it's not just an engineering problem, but it's an engineering culture problem. And 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 that 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 uh at some point and maybe somebody's going to be super angry about this i don't know but uh at some point we tried to implement uh a kind of software networking stack um and the the team building it was like yeah so we're going to do this thing where you're going to build a software network.

1:19:26When services need to communicate, it goes into an ingress and then it gets routed through a network and to the right service. And that whole thing we implement in Node. And I was like, I just distinctly remember there was like a platform TikTok or about it. I'm like, 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 that caused a lot of pain and many years of untangling and whatever so I think that that was a pretty bad decision sorry to anybody who don't think there was but I think it was about uber's culture um 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 2017 or something like that, where there was a lot of stuff going on at Uber.

1:20:45What 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 entertaining. So it was a bit weird to experience because many of those problems, And we just developed, like, are these, like, is this how people behave? I thought we were just, like, coding and having fun. Like, what are you doing over there? You're 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.

1:21:33Or maybe it was just me. I was, like, maybe I was just very naive. 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 executing and doing our thing. So in that sense, it was nice. But it was also insane, 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. Every day, you're just like, what's going to happen now? But again, daytime, 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 and there's some of it of course we also have to adapt to um but there was very much like when i joined there was very much like everything was very much about you like performance reviews you Promo, you.

1:22:33Conversation, you. Like when you get hired 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, I just thought that was how it was in the US. So I was like, okay, so, oh, it's not actually...

1:23:12You actually want it to be different. I thought you liked it like that. But you're still like, I don't know why you did it like that then. But anyway, 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 kind of open up somebody's private data and see where they went? What motivated you to do that? What motivates 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.

1:23:57Oh, no. No. What? That's so bad. 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 very interesting times. when I went to the US to visit before 17 you go so to some of 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 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:46Just try stuff. And don't be afraid just because it looks hard or 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 just let your curiosity take you wherever and don't just don't 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 tell what is better than what you have done.

1:25:46You 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 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? I think my LinkedIn profile is probably the most relevant place because that's where all the stuff I write 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.

1:26:31That'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.

From the publisher

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

More from The Peterman Pod

All 60 episodes
Uber Distinguished Eng On Unfair Promos, Influence, Engineering Regrets (Career Story)The Peterman Pod · 1 h 27 min
Listen in VO