CloudKitchens CTO on Intelligence, Regrets, Steve Jobs and Travis Kalanick Stories

Brian Attwell grew to Senior Staff at Uber by age 25. After that he left Uber to join CloudKitchens (Travis Kalanick’s current startup) and quickly became the CTO after his team doubled in size every 6 months. I asked him about how he did it. He also had a bunch of interesting takes about big tech and stories about Travis Kalanick and Steve Jobs. 𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀: • Transcript: https://www.developing.dev/p/cloudkitchens-cto-on-intelligence • YouTube: https://youtu.be/egNtHu4q-vI • Apple: https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835 𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀: 00:00:00 - Intro 00:01:26 - Growth to Senior Staff at Uber 00:10:05 - Was it luck? 00:11:45 - Interviewing for IQ 00:18:02 - Intelligence and prioritization 00:22:19 - How his team doubled every 6 months 00:28:30 - Manager promos tied to scope 00:39:13 - Amazon and Google brutal honesty 00:43:39 - CloudKitchens behind the scenes 00:50:24 - Biggest career regret 00:54:17 - Travis Kalanick experiences 00:56:01 - Most impactful advice received 00:56:56 - Most impactful book for career 00:57:53 - Advice for his younger self 00:58:48 - Outro 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗕𝗿𝗶𝗮𝗻: • LinkedIn: https://www.linkedin.com/in/brian-attwell/ • X/Twitter: https://x.com/attwellbrian • CloudKitchens: https://cloudkitchens.com/careers/ • CloudKitchens tech blog: https://techblog.cloudkitchens.com/ 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman

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

• 0:00Speaker 00

  One time I was on my deathbed, the doctor told me that I was gonna die tomorrow.

• 0:05Ryan Peterman?

  This is Brian Attwell. He grinded to a senior staff engineer at Uber in under four years, and now he's the CTO at Travis Kalanick's current company, and he came with some insane war stories.

• 0:16Speaker 00

  One time at Uber, I was walking home, and I collapsed on the side of the street. My chest was aching, and I couldn't move any part of my body.

• 0:24Ryan Peterman?

  You grinded an obscene amount to get to where you are today.

• 0:28Speaker 00

  If you want to be senior staff at one of the world's best tech companies by the time you're 25, this is the only way to do it.

• 0:34Ryan Peterman?

  He also dropped brutally honest takes about how big tech actually works.

• 0:39Speaker 00

  I held off saying this, but Google had this policy where they wanted to keep as many smart people on staff as possible, and they didn't want their competitors to have them.

• 0:48Ryan Peterman?

  He had a run-in with Steve Jobs that didn't go how he hoped.

• 0:51Speaker 00

  Like, I really made Steve Jobs think I was an idiot.

• 0:54Ryan Peterman?

  And he also opened up about what it's like working directly with Travis Kalanick.

• 0:58Speaker 00

  He says, "Guys, the core problem here is that this is lazy. You're over-indexing on scope. It's uninsightful. You could do so much better. It's worth your time to do better."

• 1:08Ryan Peterman?

  Why is this company so strict on privacy?

• 1:12Speaker 00

  We don't usually talk about it, but I talked to Travis about it, and he said, "I could give you a bit more than we've given anybody for."

• 1:19Ryan Peterman?

  This was just the surface. Here's the full episode.

• 1:26Ryan Peterman?

  Your career grew really quickly to senior staff at Uber. I mean, you got there in less than four years after graduating college. And I kind of want to go over the story of that. So what would you say are some of the top things and the highlights that led to your growth?

• 1:42Speaker 00

  If I think about it, probably the things that really helped a lot is that fairly shortly after graduation, I went to Uber. And early Uber was just a fantastic engineering firm. There's good people to learn from. They're very meritocratic, and they're growing, so there's lots of problems. They were... You don't have to be growing to have problems, but it is one way to have a lot of good problems to solve.

• 2:08Speaker 00

  And the other thing is that I was just naturally, I care a lot about my team. You can't succeed if you're selfish in the long run. Doesn't work out, team support. All right, so those kind of things are just natural and I got for free. But the things that I intentionally did is that I cultivated this tolerance of extreme pain. And pain tolerance early in your career, a lot of this is just work ethic. And if you plot engineers' career growth against how much work they do, it's like a linear relationship. It's at least linear. It's actually super linear for a lot of it because of the compounding effect of how much you work.

• 2:53Speaker 00

  And this is especially true because managers will only give the really valuable work, the really strategic, the technical, the kind of things that helps you with your career once you've already proven you're good at it. And sometimes you've just got to go and you've got to make time to learn that yourself. So I do think that working, pushing really hard early on does have outsized returns. I actually don't totally buy that that means you should stop after because there's always like more levels you can grow, right? There's also levels that haven't been invented yet, so you could do that. But certainly, this is something that I thought about early on. Like when I joined Uber, I was very aware that I had more time than I'd ever have in

• 3:37Speaker 00

  my future and that if I was going to invest in growing, this would be the easiest time to do it.

• 3:41Ryan Peterman?

  It sounds like you grinded an obscene amount to get to where you are today or to kind of grow as much as you did. And I'm curious, like, looking back, was it worth it?

• 3:50Speaker 00

  You know, one time I was on my deathbed and I was told, the doctor told me that I was going to die tomorrow. And I was sitting on, I was sitting there thinking like, damn, I'm going to die, that sucks, I haven't accomplished anything yet. There's like so much stuff professionally I want to do, right? So that expression of like, you're never going to think about wanting to spend more time in the office than on deathbeds, not true, right? Like, I went back when they found out they messed up my medication, I worked harder than ever, and yeah, I totally overdid it sometimes. But the times that I pushed really hard, they were fun. They were like being in a soccer game where you're tied until the last minute and then you score or somebody else scores, your team wins.

• 4:33Speaker 00

  And it was painful, but you look back on your head and you're like, that was great.

• 4:37Ryan Peterman?

  So when you were on your deathbed, you weren't saying, oh, I have regrets that I didn't travel more, do that. Your regret was, I wish I worked harder.

• 4:48Speaker 00

  Yeah, it actually was, yeah. Yeah, I was like, shit, I'm gonna die. Oh, I was really looking forward to building some cool stuff. I was really looking forward to that. And then I got out and I was on an internship and I went back to work the next week and I just worked harder.

• 5:08Ryan Peterman?

  So everyone has a breaking point. Obviously, you can't work 168 hours a week. Where is that breaking point for you? And how do you know when you're working too much?

• 5:19Speaker 00

  I think the best way to know, I have an hours number in my head, but that's less useful. The way that I know is if I start to get a little grumpy. Like if I, let's say that I work a few weeks without taking any day off. I'll start to get a little bit grumpy. I'll be less patient with people and I'm in management, so I really have to be patient.

• 5:41Speaker 00

  So when that starts to happen, usually my partner will tell me. And I'm like, oh, yeah, of course. I haven't taken a day off in weeks. Right? This is me catching it earlier than when I was younger. One time on Uber, I was walking home and I collapsed on the side of the street. My chest was aching and I couldn't move any part of my body for 15 minutes. I just watched people walk by me. Right? Like in that moment, I knew I should have cut back by 5%. Right? I was like, I knew it, but ideally I would have known that a little sooner.

• 6:17Ryan Peterman?

  Did you go to the doctor after that or like, what was that?

• 6:20Speaker 00

  Yeah, I did. And there was nothing where they're like, I don't know, you're too anxious, you're working too much. If you don't take time off and just like every moment of your waking day is trying to do really high quality work, your anxiety levels go up over time. It's the same reason that professional athletes are really intense. They're training all the time, but they are conscious about taking time off to let themselves, their body and their mind regenerate.

• 6:46Ryan Peterman?

  Are there any concrete stories you can tell me that kind of illustrate like how you grew as an engineer?

• 6:51Speaker 00

  There's this guy called Yi Wang. We both joined the same team at Uber. It had been there for a few years before we joined. The reason for this team was to fix some of the maintainability issues that were happening in mobile as the company hyperscaled. So we're the most junior guys. Every day, we overhear some kind of big debate on the team. Like, we'd hear, hey, should we use RX Java streams embedded from this library? Would that make a lot of these issues go away? Or should we use some other more conventional type of multi-thread work distribution system? Should we do something else? And I'd overhear people use their experience to prune out the worst options. That was fairly easy.

• 7:34Speaker 00

  And then picking the best option was a bit more subjective. They'd debate it. They'd go back and forth. Eventually, they would disagree. They'd commit. They'd move on with their lives. Everybody on this team, other than Yi and I, they leave the office at 7:00 P.M. Yi and I work from 9:00 A.M. to midnight. So after I'm done doing a good day's work, my usual kind of stuff, this day, I went and I built the prototype of the RX Java approach. I found eight representative examples that I'd seen in past issues and that I just read in postmortems. And I built compiling examples for them. Then I did the same thing for option B. I did the same thing for option C. While I'm doing this, Yi did it on iOS. I did it on Android. We reviewed each other's stuff.

• 8:19Speaker 00

  And then the next day, everybody comes in and we show them what we've done. And they say, well, yeah, I mean, we thought option B was better, but you guys have done the work. Clearly, option A is better. We can see that. Thank you. We do something like this every day. And at first, our hit rate is not good. It's like, super not good. Uber would not have paid us to do this, to spend this time, because we're hunching around. We're trying to find some kind of unexpected, hidden valuable truth. And most of the time, we're just hitting a knowledge ceiling we can't get past. And our intuition for where to hunt is bad. But after a few months, we're getting better at it. A few months later, we're now the guys who commit the most code on the team.

• 9:04Speaker 00

  And instead of overhearing things and then doing it after hours, people are now going, yeah, what should we do? I don't know. Let's involve Yi and Awo. Okay, so this is like a few months into joining this team. We're now the de facto tech leadership. And we just keep outworking everybody that like basically around us. A few quarters go by and now we're like top three committers across the mobile organization at Uber. And we're also the guys that get pulled in for a lot of the gnarliest things across all of mobile and also the biggest debates, which is like a 400 person team. So at this kind of point, promotions are inevitable, so they happen. Okay, I know that like people listening to this may think this is extreme.

• 9:46Speaker 00

  This is, I also worked weekends, so this is like 90, 100 hours a week. And it hurt physically. My body hurt and my brain hurt. I had a lot of headaches at first until I got used to it. But if you want to be senior staff at one of the world's best tech companies by the time you're 25, this is the only way to do it.

• 10:05Ryan Peterman?

  To someone who says like your career growth was luck and you were lucky to be where you were, what do you say to that?

• 10:12Speaker 00

  Yeah, so luck matters a lot and then things that happen infrequently. Like if you do actions every day, 100 times a day, and you do those very well, it's not really luck that those go well for you. But if you make a decision and you only make it every three years, then luck matters a lot there, like selecting which company you're at. So yeah, I picked Uber for a reason, right? Like I was choosy in the company I picked, but I could have gone wrong. Once I was there, you know, there's a lot of things that I'm doing myself. But if, like, I'm not trying to suggest that everything is solely based off of like your own merit and that there's always deterministic mapping between effort and outcomes.

• 10:56Ryan Peterman?

  So you're saying you increased your chances of luck by shooting so many shots?

• 11:02Speaker 00

  Yeah, well, I guess I'm saying that

• 11:06Speaker 00

  once you're in the company, I think like I was gonna do well. Right. I mean, if you outwork everyone around you and you're fairly smart and you've got a lot of the right mindsets and it's a culture of merit, then you'll probably do well. But what if I had joined a company that wasn't like a merit-based company? And like, that would have set me back. It would have taken me a while to figure that out. People don't tend to job hop that well and it doesn't look that good when you do. So, joining Uber, yeah, there's a bit of luck there.

• 11:37Ryan Peterman?

  You mentioned you were choosy in picking Uber. What did you see at the time that made you pick Uber? And like, what signals are you looking for?

• 11:44Speaker 00

  I think that I would spend, probably foremost, it's my first company, spend time sussing out the quality of the engineers at different companies and trying to figure out, like, what is the process that they use to hire engineers by? Because that's fairly indicative of the quality of the engineers that come in. Processes that hire strong engineers are processes that explicitly test your brain's ability to reason about on-the-spot trade-offs. Of course, perform job-relevant skills, like, there should be, like, difficult coding aspects. Your ability to quickly assimilate and discuss information. There might be like a, "Hey, here's a five-page postmortem. Read this thing and then we're going to debate whether or not this entire team should be restructured based on the

• 12:29Speaker 00

  postmortem." And you absolutely should not be able to pass them unless you have high mental acuity. Like, an interview that tests your ability to recall things, your experience or just your mindsets does not build a strong engineering team. An interview that anyone can pass regardless of IQ, if they can practice enough, that does not build a strong engineering team. And there's actually a lot of, there's like a comically large corpus of studies around how to interview effectively. The reason that companies don't do it is it just takes a ton of work to build a good process. Like, in a tech org, you have dozens of different roles and each one needs different interviews. So, the leadership team needs to be really dedicated to it.

• 13:13Speaker 00

  I would say that our interview process is fairly well designed. I welcome people to try it out. But we still are doing like 20 experiments at any given time to try and improve it.

• 13:24Ryan Peterman?

  So then what is it that you would ask that would actually test for IQ or something like that?

• 13:29Speaker 00

  You know, it's funny, some places will literally do an IQ test upfront and that's not terrible. Our accounting team does that. But if you can come up with something that requires you to hold a lot of concepts in your head and is also job relevant, like you find an applied programming task that also involves requires you to understand a lot of different requirements at a time. And the requirements are a little bit in conflict and a little bit hard to reason about. That kind of thing is really great.

• 13:59Speaker 00

  That postmortem example, right? Like I read a five page postmortem and then just read the whole thing in like five minutes. And then discuss what are the structural problems with the team? Where one part of the postmortem says something and another part, maybe conflicts of the three pages down is the kind of thing that most people and also ChatGPT cannot get anywhere close to doing.

• 14:21Ryan Peterman?

  Interesting. So it sounds like you're saying that if someone's IQ is higher, their job performance will be higher.

• 14:29Speaker 00

  Yeah, I mean, this is like one of the most well researched results in applied psychology. But the reason you don't notice it as much when you're at great tech companies is that everybody that gets in is usually fairly smart already. There's not a lot of differentiation between the performance of people on your team based just on IQ because all of them are already like one or two standard deviations above the norm. But like that is sure as hell filtering out people who are below the median before they get in.

• 14:57Ryan Peterman?

  So then how do you filter among the people that are already like one to two standard deviations above?

• 15:02Speaker 00

  There's a bit of like, how do you design problems that are, they're not just mentally straining. There are a combination of mentally straining and experience and like relevant skills, which shows, okay, are they sharp and have they mastered it and can they apply it? Some people will be stronger when they join. There is no interview process that has an R value of 1.0. Right, nothing, no interview process in the world is 100% predictive on the job performance. Not yet. I maybe, maybe we'll figure it out, Ryan, but I can tell you that I and no company yet in the world has it.

• 15:35Ryan Peterman?

  Well, it's, it's interesting that you say IQ correlates with on the job performance.

• 15:40Speaker 00

  I'm actually very seriously considering just slapping an IQ test in front of some of my interviews. Because, you know, I mean, it's actually a very honest, it's, it's part of why lead code is a thing, right? Like, lead code is not that related to the kind of work that you do, but it's like, kind of tricky. So it just gets how good people are, it's like tricky abstract reasoning. It's like, but it's, but the problem is it's so gameable that you can just practice lead code. IQ tests can't practice it. I don't know, maybe just slap it in front. I'm gonna try it. I'll probably try it for PMs first, because they're harder to interview generally. And also, like, my, the pass rate for my interview bar that I've defined for PMs is like, super low. And I'm just annoyed that I have to keep interviewing them, so maybe I'm gonna slap an IQ test in there and save some time.

• 16:23Ryan Peterman?

  Why, why, why is interviewing PMs harder than interviewing software engineers?

• 16:27Speaker 00

  So, okay, so some aspects of it are very hard skill oriented. Those are very testable. A lot of the issue is, okay, yes, there's soft skills, but it's also that this role is generally less well-defined than the engineering role. It's incredibly well-faceted. There also is not such a thing as school for PMs. PMs are different across different disciplines, like software versus non-software PMs, the discipline's younger, so they just haven't been as much thought put into how to interview them very well. We ended up having to do like a whole rethink of what is a world-class PM? We interviewed CEOs from a varied variety of companies to get their take on it, and we like wrote it down, and then we designed an interview process, and it's like completely different than other companies do it.

• 17:11Speaker 00

  And I think it's good, but it just showed like how little I could borrow from. And look, other companies have interviews, like Meta's PM interview, it's pretty good. I think it could be way better.

• 17:20Ryan Peterman?

  With what? Like, slapping IQ tests?

• 17:23Speaker 00

  Well, actually, I mean, it probably wouldn't hurt. Yeah, if you slapped an IQ test in front of the PM in your process, it wouldn't help differentiate between the excellent and super excellent, but it would help weed out people very early. And then you could spend more time differentiating between the good versus excellent in the rest of your process. And when I talk to places that do IQ tests, because it's not that uncommon at places that have very high standards to do something like this, it's always in the screen stage. It's always just, let's filter people out to save them time and us time.

• 17:52Ryan Peterman?

  I say, oh, you're saying some other companies do run IQ tests?

• 17:56Speaker 00

  Yeah, they do, yeah. I don't think there's that many, though. I think this is a little, this is certainly a move.

• 18:03Ryan Peterman?

  I always hear the common take is that it really doesn't matter how smart you are past a certain point. It matters more how hard you work or your ability to choose impactful work and work in a team, et cetera. What would you say to that?

• 18:20Speaker 00

  IQ is a thing, and it influences how much you can do all the other things. But you definitely need to consciously get good at other skills. And knowing how to fiercely prioritize your time, super, super important. Like, every time that I do, that I'm thinking about what to work on, I think about three things, which is, A, how important is this work? What's the expected value of this initiative over a fixed time window? B is, what's the probability of its success with and without me? And then C is, how much time does it take me? I multiply eight times B, I divide by C, and that's my expected value creation per hour. And I always want to maximize this kind of thing.

• 19:05Speaker 00

  What's kind of interesting about this mindset is that often, you'll often get in the situations where working on the most important thing is not actually the most valuable thing you can do with your time. Because, especially early in your career, early in your career, you may find that by the time that you hear about the company's top priority, there's a lot of stuff figured out, and it's already super well-staffed. So, joining, it'll be fun. But you may be joining as a cog in a really well-oiled machine. Whereas if you go to priority number three, you find something that's valuable. But in a tougher spot, you can maybe go in and be a hero.

• 19:45Ryan Peterman?

  It's interesting that you say that because when I think about prioritization, obviously it's a cost-benefit analysis. Benefit divided by cost. The thing that I think is interesting is that second term where you were saying that what's the probability of it succeeding with and without you? Can you explain that a little more?

• 20:07Speaker 00

  Yeah, I mean, this is harder. I think getting good at estimating expected value is already a very difficult thing. And then figuring out like what, how to kind of create uplift is even harder. But at early stages, it will often be like, let's say you're fresh out of college. At that point, it's fairly, it's often fairly easy. It's just what is not going to be staffed that's important. And then as you get a little bit further, it's what are the things that you're uniquely good at? And where's that match with something that's valuable? And you can kind of do some fuzzy math, but it's never going to be three significant figures of precision.

• 20:48Ryan Peterman?

  Yeah, I'm kind of curious about that expected value calculation as well. Like, how, how do you recommend developing that? What's important to figure out in determining the benefit?

• 20:59Speaker 00

  Yeah. Okay, so there's absolutely things that everyone can do to get better at this. Engineers, fresh out of college, no business background. It's not a natural thing for most of us. So what I recommend is every time that you have a director or a PM and they talk about, we really want to move this metric by this amount for some quarterly goal. Like, maybe it's, we want to improve recall on this model by 10%. You want to know why they care. Maybe it's because they want to reduce churn. They think that'll happen if they improve recall. And then churn, they're mapping that in their heads to additional dollars and cents. If your manager punts on a project, you kind of want to know what are his principles behind that.

• 21:44Speaker 00

  And you can ask these guys. You probably should use regular time when you're one-on-one to ask why these decisions are being made. But the best possible case is that you find your company already has a spreadsheet somewhere with all of the top initiatives or all of the projects of the quarter. And there's a column that says, here's the expected value. Or it says, here's why we care as a company. If that column exists, it is gold and you should read it. You should just every now and then go read that column. This is all the work that other people have done to calculate expected value or give some sense of it, and you'll pick up intuition from it.

• 22:19Ryan Peterman?

  Talking about management, I'm curious. What's the story behind you eventually getting into management?

• 22:26Speaker 00

  Dude, yeah, I procrastinated. I put it off forever. My manager at Google told me I should do it. My manager at Uber told me I should do it. When I joined CK, I was told I should do it. And we had really great engineers. Travis, our CEO, he built Uber. He was the CEO of Uber. So we pulled a lot of Uber's strongest engineers. They had friends, they pulled them. It was just like this really super-strong, super-tight crew. And I also had eight engineers that sat around me, and they effectively treat me like their boss. They asked me what they should work on, and I came up with stuff.

• 23:10Speaker 00

  So I had all of the fun of being an IC and of having a team and none of the responsibilities of being a manager. It was amazing. And then one day, my boss said that I'm either going to hire a people manager, or you've got to do it. And he was saying that because they did need a manager. They didn't really have one.

• 23:34Speaker 00

  And I thought that what my boss said is that he was right. They deserved somebody, but I didn't like the idea of somebody coming off the streets, like of a random people manager managing them. And I also really didn't like the idea of somebody coming in and messing up my vision for the team, which I thought was pretty good. So I was like, all right, I'll do it. I guess. And I did a terrible job. Right, like I, yeah, I mean, I, you hear about how people, how managers will procrastinate a bit by coding. And it's good for managers to code. But I procrastinated by so much, I did so much coding, that there was somebody that

• 24:19Speaker 00

  joined my team and after three months, he said to me, wait, Brian, are you my boss? Like, are you my manager? I thought you were just a really helpful engineer. It gives really, like, how negligent must I have been in my management responsibilities for someone to have said that? It's a real wake-up call. So after that, I stopped procrastinating so much on these things. I got better at picking up the management fundamentals. And then at that point, the portion of the company that reported to me doubled roughly every six months.

• 24:53Ryan Peterman?

  Yeah, that's kind of insane for the part of the company that reports to you to double every six months. What, why did your team grow so insanely?

• 25:02Speaker 00

  Every time an organization has moved under me, from somebody who's admittedly already pretty smart, I'd still assume that there's at least an order of magnitude improvement that we could make in how this organization performs. And I'll just start truth-seeking with that team. I assume that everybody, including myself, is wrong just all the time. And I get really, really excited when somebody says something like, you know, Brian, we've been doing this thing for years and it's like a religious thing. We believe it so strongly, but I think it might be wrong. Oh, that gets me really excited. And I'll give you a small example.

• 25:41Speaker 00

  So a few years ago, there was an integrations team that was moved under me. This team, they built 1,200 different integrations with other companies, which it sounds like a lot, because it is. And their goal was that they want to basically have all the information about the entire restaurant industry in one place, clearly valuable. Each one of the integrations was originally a very smart bet. Analysis was done to decide what was needed, and it was built. So now there's a lot of inertia around maintaining it. And the team works super hard to maintain them and keep the data quality good.

• 26:19Speaker 00

  Kenji, who manages the team to me, says, Brian, how important could each of these 1,200 integrations be? And just fucking great point, Kenji. That is a lot of integrations. They can't all be equally valuable. So we spent some time digging into that. We spent a couple of days trying to come up with different formulas to quantify the value of each of them. And once we came up with the distribution, it's really hard for anyone to say, no, you got to keep them all open. It's just obvious that some are much less valuable. So we stopped supporting a bunch of them. The amount of pages that the team received went down significantly. The amount of time that the team got back was very large.

• 27:02Speaker 00

  And what ended up happening is that the quality of our product in aggregate got better, because now the integrations that matter are well-supported, and we've got time to build new things. It's just a win-win-win.

• 27:15Ryan Peterman?

  So it sounds like when these teams get moved under you, you start questioning some of the base principles. You try to find the truth in these long-held practices on the team to uncover these huge wins. Is that right?

• 27:30Speaker 00

  That's right. Yeah, I understand. And often, folks, often there's a lot of hints. You kind of want to start with... What are the things that that people just have suspicions around? That can be good. That'll get you a few quick wins and then you'll have to take it a bit deeper.

• 27:49Ryan Peterman?

  You mentioned a lot of teams got moved under you. How does that conversation usually go?

• 27:55Speaker 00

  Yeah, I mean, the conversation is always really different, but it's got to be done with empathy. It's a fact of life that if you have a culture that's based on merit, that in order for some people to rise to the top, that other people's scope maybe need to be reduced. Or some people who are overall quite capable may still may need to be managed out. And you can absolutely have that conversation in an honest way that says like, hey, what we really need here is this, and you haven't been doing that lately, while still showing them a lot of appreciation for what they're they are still doing well or for what they used to be doing well.

• 28:30Ryan Peterman?

  One thing that can happen at some companies is managers' career growth is tied to their scope. And so they kind of hold on to it with, you know, everything that they've got, whether or not it's good for the company or it's a better setup to do so. And so I'm curious, like, in those cases, like, you know, why did people give up their scope? Or is there not an incentive structure like that at that company?

• 28:54Speaker 00

  Yeah, I mean, we there shouldn't be an incentive structure like that. That's not a good way to set up an incentive structure, in my opinion. And one of the things that the head of Picnic and I did a few years back is rethink how we can avoid this. Actually, it was, I think Travis deserves some credit because we originally had a leveling system and an incentive structure for obvious reasons, very similar to Uber's. And we knew there were some problems with it. So Charles and I spent time improving it. We presented it to Travis and he read over it. And he's just like dropping comments everywhere in Google Docs on how we can each clause can be better.

• 29:38Speaker 00

  And he looks up at the end and he says, guys, the core problem here is that this is lazy. You're over indexing on scope. It's uninsightful and you could do so much better. It's worth your time to do better. At this point, I'm convinced that it could be a lot better. And I'm also convinced that a lot of companies do a bad job.

• 30:02Speaker 00

  We ended up spending a ton of time figuring out more about where other companies were failing.

• 30:08Speaker 00

  I think I spent basically every evening and Saturday for months on this.

• 30:14Speaker 00

  And I can get into what we learned, but one of the big things is really that if you tie promotions to scope, you're really over indexing on just one type of complexity. And you're also encouraging a lot of empire building.

• 30:28Ryan Peterman?

  When you were going and redesigning the incentive structure, like what was the biggest changes you made compared to what Uber had for this new company?

• 30:38Speaker 00

  Okay, yeah, so if you look at what Uber and say Meta and Amazon have, they have a lot of competencies that read something like,

• 30:50Speaker 00

  I design processes for the company as a whole. I design, I partner with directors on strategy. I influence other teams on undefined goals. Like, these are really position oriented things. And what this is basically saying is you get promoted by being loud and being well positioned, which kind of fucks up younger people because it's really like be loud, be good at politics, be good at maneuvering. Some of that's valuable, but if everybody does it, people don't actually learn to be good at the corporate job and it's bad for the company. So what we did instead is we started with these 1,000 different examples

• 31:34Speaker 00

  of where people differentiate themselves on ability. We converted that into 250 human attributes. And then I performed a principal component analysis to collapse it down into 12 different dimensions, where each dimension is basically like a skill gradient. And as you climb those skill gradients, your compensation goes up. If you've got more impact and you're more skillful on the things that we might believe matter, then your compensation goes up.

• 32:01Ryan Peterman?

  Where'd you source the initial thousand examples of high performance from?

• 32:07Speaker 00

  Yeah, so this is talking to a ton of engineers. There's like 12 books that I read. I also looked through years of our calibration notes. Every time we do quarterly calibration, we'll talk about why this engineer did well. So I just scraped all of that out. And then wrote them all down. This is about a thousand. And I made certain that they're all things that I knew personally had actually happened. They weren't bullshit. Otherwise, you could get into a situation where the skill gradient is bullshit at the high levels. Right? It's like just an unachievable dream.

• 32:45Ryan Peterman?

  What are the biggest attributes that differ from well-known ladders? Because everyone who works at these big tech companies kind of knows the existing. So what are the things that you introduced that are different because of this analysis?

• 32:59Speaker 00

  Yeah, I think the probably main difference is this is this emphasis on truth seeking and like how you perform very well instead of what you perform very well. If you look at, I think Meta's Leveling Guide, it'll say you have to be able to like influence other teams at E6 with good ideas. And in our ladder, we'll say something like, you have to be right most of the time when questioning a foundational engineering and product decision or industry norm. It's not so much about convincing people. It's how good are you at actually getting good ideas? And there's a separate competency on how good you are at communicating ideas, which we define what good looks like.

• 33:44Speaker 00

  Instead of just saying it's about like this social, kind of social proof thing.

• 33:48Ryan Peterman?

  I see. But then how do you determine if it's good communication or not?

• 33:53Speaker 00

  You give a lot of examples, right? In your in your document where you define these things, you say, OK, here's the verbal description of what it means. And here's a few examples. And then when engineers are scoring themselves, they can kind of look at the examples and go, well. I mean, if I'm being honest, was I that good? Right? If I look at this artifact, does it stand up to that?

• 34:15Ryan Peterman?

  I'm not sure how it fixes the the politics such social problem of calibrating engineers because you could have a manager that lists out those examples, but says them in a biased way. So like, how do you get rid of that incentivizing politics?

• 34:32Speaker 00

  OK, yeah, so this is still a thing that managers could try to do. It's a little bit.

• 34:41Speaker 00

  The kinds of things that they would posture around would be different, though. Right? Like, the engineers aren't going to spend as much time trying to figure out how do I, how do I like design company-wide processes, say, or like explicitly influencing other teams is not necessarily the goal anymore. So you might have people posturing around being good at communication and exaggerating that, but at least they're trying to get good at communication or they're trying to get good at truth seeking, which is almost always beneficial as opposed to something that's not always beneficial. There's still, though, things you can do to protect against this. And the answer is it's like a lot of work. Right? You have to like spot check managers.

• 35:26Speaker 00

  And if you find them exaggerating, you have to fire them.

• 35:29Ryan Peterman?

  Easier said than done. I'm curious, like, how?

• 35:31Speaker 00

  Is it? Well, I mean, I don't know. Who wants a liar on their team?

• 35:35Ryan Peterman?

  There was someone else that I had on before, and he said, "That's a big problem in management is it's someone who is bad for some reason, but is well-liked. They're one of the biggest problems because it's difficult to fire them." What would you say to that?

• 35:52Speaker 00

  Yeah, I, you know, it's funny because I do hear this, but I don't think that it's really true. Right? Like, it feels very difficult to fire them if you're a frontline manager because you like them and you see kind of the social bonds. But often, there is a bit of simmering resentment about that person. The people on the on the team who are working hard, they're like, "Yeah, man, Joe's so great, but why the fuck did he just go home at 2:00 P. M.?" Like, "Why am I working at 6:00 P. M. I feel like a chump." Right? So if you remove this person immediately, it may feel bad, but a month later, the whole team will be happier.

• 36:25Ryan Peterman?

  You've mentioned truth seeking a lot in this this new ladder. And I'm kind of curious, like, how do you prove truth seeking? Like, how do you give examples of someone that that did that well?

• 36:38Speaker 00

  Yeah, I mean, a lot of it is, have you uncovered something that is highly unconventional? And there's a bunch of different dimensions that could result in that. Like, oh, it was actually in plain sight for a while and nobody found it, even though it's highly valuable. It's sort of a signal. Or is it different than what every other company does, but because our constraints are different, it's actually, it's beneficial to go against the grain. Like, just some, there's a bunch of different dimensions that result in truth-seeking being difficult, that you can latch on to.

• 37:22Speaker 00

  And then, there is a bit of subjectivity. You know, there's not like, you have to kind of write it down and then calibrate managers on how to score these things. It's not as easy as counting PR stats is, but we all know that that's not a great way to judge engineers.

• 37:36Ryan Peterman?

  Yeah, yeah. Well, a lot of companies have some sort of measure of directional contribution. Like, you know, how did they, how did you change the direction of everyone based on your contributions? And that sounds very similar to truth-seeking here.

• 37:50Speaker 00

  Yeah, I mean, it's not like these are, the way that tech companies have designed their leveling frameworks, their incentive structures are not completely broken. And in many ways, they're just way better than what exists in the Dilbert-esque era of the 1980s. There's some ways, and they've been, actually, I think, kind of nicely designed to reward you once you get into a specific position. And they're very good at rewarding you once outcomes are achieved. They're a little bit less about the leading indicators, but you're not going to get wildly different results. You'll just make it a little harder for some people and a little easier for some other people.

• 38:32Ryan Peterman?

  Yeah, one thing I'm curious about, because like, a lot of tech companies, they incentivize the result, not necessarily the thing that happens before the result. And so, yeah, is there a case where you could have an engineer does a phenomenal job on something that gets deprioritized, and they would still get rewarded?

• 38:49Speaker 00

  Oh, yeah, of course. Yeah.

• 38:51Ryan Peterman?

  Okay.

• 38:51Speaker 00

  Maybe if you're like at the highest level, you should have the business savvy to know that it's not going to be. But if you're, if you do phenomenal work towards a project and for no reason related to you, this thing gets canceled. You've still done phenomenal work. And we can still imagine that you've been doing phenomenal work and rewarding for that. It's kind of on our fault at least. Our fault as leaders that it got canceled so late.

• 39:13Ryan Peterman?

  One thing I'm curious about is, and I think companies like Amazon are famous for, you know, not really rewarding the high performers that much. And I was curious to ask you because you've worked on company design for a while now, or engineering organization design. It's like, why do these companies not reward their highest performers?

• 39:32Speaker 00

  I held off saying this, but a lot of it is just because they can get away with it. Right? Like they think, oh, the equity went up by a lot. Maybe it's a little bit unjust to pay you less because your equity went up. I think it's unjust. That's basically your investment. You have got a good investment result. It shouldn't factor in future decisions. But they can get away with doing it because people are mostly happy. They got a lot of appreciation. We actually made a point of not doing that earlier on. And I just think it's if you design your company processes around being just, it's going to be better for you in the long run. But you've kind of just got to believe that.

• 40:06Ryan Peterman?

  You know, we've been talking a lot about big tech. And I know you started off at Google. And I'm kind of curious, like, you know, what, what was that like? Or what did you get from starting at Google?

• 40:18Speaker 00

  I think the main thing that I got from working at Google is I got like a real deep seated skepticism for how well tech companies are run.

• 40:28Speaker 00

  In my, all right, so I joined Google. And in my first week, I see there's a guy on my team, doesn't do any work. And let's call him Frank. And I talked to my manager about it. I'm like, what's the deal with Frank, yo? It's not how I talked, but you get the point.

• 40:42Speaker 00

  And my boss says, yeah, I know, but he's such a nice guy, Brian. So just lay off. I talked to my engineering director shortly after this. And I say the same thing. He is a little bit embarrassed. Like, he knows that there's something off about having people that don't do work. But he repeats the same thing, which is that Brian, this guy's a really great guy and everybody likes him.

• 41:07Speaker 00

  I actually complained a lot about it and I can't prove anything, but he was eventually moved off my team onto a team where no one would complain because no one on the team did any work.

• 41:20Speaker 00

  The team was just like, they're building demos for the gift shop or something like that.

• 41:24Ryan Peterman?

  So what you got from that is that like that's a Google problem? And that he should have been fired?

• 41:32Speaker 00

  Yeah, absolutely. Or, yeah, he should have been fired or there should have been a serious conversation. Right? And we're like, so you've been here for a while, you've done good work. We're still paying you like, could you? Could you do work again?

• 41:46Speaker 00

  Right? You can't expect us to keep paying you if you don't. And then he might have gotten back into it.

• 41:50Ryan Peterman?

  Why do you think that that hard conversation wasn't had at Google?

• 41:55Speaker 00

  I mean, so there is something Google specific that exists there, which I can get back to. But generally at large companies, the performance of the company is fairly decoupled from the performance of individual teams. So it does become easier for this kind of thing to happen for managers to do things that are convenient for themselves, even if it hurts the company. But there's also this natural thing that happens at companies of any size where it takes a lot of energy to raise a standard and it takes very little energy to lower it. Few people will complain if you suddenly ask everyone to do less work, which means if you have entropy in a system, standards will naturally fall over time until the company dies.

• 42:39Speaker 00

  It'll just keep going down until the company dies or until some kind of trauma kicks it back into place. Right? Like if you're at Google right now, the DeepMind team, oh, they're working hard. Right? Like Google's like, Alphabet's like, oh, there's an existential threat to our existence. The DeepMind team better work hard now. I mean, entropy will always lower the bar. And there was this thing at Google, which I cannot prove existed, but several managers at Google told me it. So I haven't seen it in writing, but like. A VP and some managers told me it existed that around a decade ago, Google had this policy where they wanted to keep as many smart people on staff as possible, even if they weren't working anymore because maybe they'd work hard again in the future and they didn't want their competitors to have them.

• 43:24Speaker 00

  So that's just a super unique Google thing. I mean, that's kind of crazy. I don't know of any other company that's done that.

• 43:29Ryan Peterman?

  I see. And do you think there's any merit in that kind of hiring strategy?

• 43:33Speaker 00

  No, because there's a lot of smart people in the world. I think it's fairly difficult to have a monopoly on intelligence.

• 43:39Ryan Peterman?

  And now at this point, I'm kind of curious like, you know, what are you working on these days? And maybe we can talk about that a little.

• 43:45Speaker 00

  Yeah, OK. So it's fairly secret and we don't usually talk about it with reporters because we're in stealth. But I talked to Travis about it and he said, I could give you a bit more than we've given anybody for. So I'll give you some stuff. I'll give you the whole like thesis of the company. The core insight is that no one should cook their own food in a few decades. And no one should cook their own food. And we know that people don't want to because when you look at places with lower costs of labor, like middle, upper class people, they don't cook anymore. Like, of course, they don't. They save, they choose to save 10 hours of their time a week and take it back.

• 44:28Speaker 00

  And if you, if you look at the US, there's like Uber Eats, there's DoorDash. These things are fairly convenient. They offer some of that, but they're super expensive. So nobody can use them every day. If, you know, if these things were way cheaper, though, that would work. And here's the second core insight, which is that there's a ton of avoidable waste in the food supply chain. So we're just kind of scratching the surface on this, but we've built, we've built robots that reduce labor costs in real restaurants by 50%.

• 45:06Speaker 00

  We've built this like lunch logistics network that reduces the cost of a meal overall 30, 40%. We have. What else? We've got this real estate thing where the cost per meal is half of what normal cost per meals are. And we also have this software product called Otter. It processes 18% of the world's orders and makes them a bit more efficient. And we've got all these things going. Some of them are early, some of them have a lot of customers, but it shows just how much inefficiency can be squeezed out. It shows that if you're willing to spend the R and D money, you can make real moves on lowering the cost of food that's made just for you, like fresh, without any labor on your part.

• 45:51Speaker 00

  So if the size of the pie is big enough, we can make this happen. And Americans spend $2.5 trillion a year on food. So if you think about the most conservative cost modeling possible, like you just imagine that you redesign this whole supply chain, you have super thin margins. This is $5 trillion sitting on a table right now, just waiting for the companies that go and solve this problem. And that will happen eventually, no matter what, right? Eventually, robots are going to do all that. But we think that we can do a lot of work now to enable this. And then hopefully, we capture a few trillion dollars of value and our partners capture a few trillion as well.

• 46:32Ryan Peterman?

  You know, one of the things that I'm most curious about, because I remember at some point, I was living in SF, and I got an invite to a recruiting event for Cloud Kitchens. I'd never heard about it. It said, you know, we're a large stealth startup. Hey, we're going to treat you to dinner and just come and listen about it. And it was something I'd never heard about, but it had Travis's name. One of the most unusual hiring strategies I've seen for a company of that scale. So I'm curious, why is this company so strict on privacy?

• 47:04Speaker 00

  Yeah, right. So, I mean, we are super strict. You're right. And we don't have a corporate website. We ask employees not to post that they work here on LinkedIn. We're truly fairly good compliance around. We don't have any PR people. Here's why we wouldn't have done it, and I'll tell you why we did it. When you're founding a company, if you're very public in the media, it's easier to raise money. It's easier to hire. It also makes the founder's ego swell. All these great stuff. And we, our CEO, Bill Uber, he's a billionaire. He's got a good network. He's got funding, and his ego is doing just fine. So these upsides didn't really mean a lot to us. But the downsides of being public did.

• 47:48Speaker 00

  If you look at 2018, and you look at headlines, sentiment, you can actually go and check this. I've checked it. It took this nosedive towards negativity after Cambridge Analytica happened. The US populace just loved reading shitty news about tech companies. So if you're working for a tech company at that time, you're constantly reading bad things about yourself. And it's very distracting to employees, and especially distracting to leadership. It takes your mind off of innovation and puts you more into a damage prone place. And then the other thing is that we really wanted to minimize the amount of competitors we had. If you've got a good idea, and your founding team has a strong track record, and you're visible,

• 48:30Speaker 00

  other people will see that who are enterprising, go, maybe I'll just do that. When we launched in Korea, we were very public about it. We talked to reporters. There wasn't just one competitor, or two, there's three. It was a whole ecosystem of people that decided to compete with us, just because we had a famous starting team. And then the same thing happened in the US, where this company received $150 million. They got a Vision Fund investment, even though they had very little going on for them. And yeah, they were never going to make it. They never had a hope. But it was still annoying. It was still distracting for us. The answer is just shut up and be quiet and like build great stuff and don't talk about it.

• 49:14Speaker 00

  And then win silently and confidently.

• 49:16Ryan Peterman?

  I mean, this to me is like the very opposite. I see a lot of other companies, they they get started and they start with distribution, actually. Like they have these these rage bait products that go out and explode on Twitter. And then, you know, you people start using it from that. And there's obvious benefits to that. It's like you get users, you get people talking about it and all the other benefits that come with that. So like, how are you handling distribution then if you're so quiet?

• 49:48Speaker 00

  A lot of the stuff that we do is B to B. And you can still do marketing around individual products. We have products that we talk about quite a bit, right? We have picnic, there's otter, hundreds of thousands of restaurants use it. And there's ads around those things. We just don't talk about our core company as much. So the main thing that it had a bit of difficulty around is is hiring. So like people like me have to go on famous podcasts, you know, and see if they can mitigate that a bit. Right? But I think it's it's not as hard for sales as you'd expect.

• 50:24Ryan Peterman?

  Coming to the end of the conversation, I just want to go over some career reflections. And so one thing that I'm always curious about is when you think back over your career, what's your biggest career regret?

• 50:37Speaker 00

  So I've messed up a lot of things, especially early stage. And there's things that, you know, you'd think I might regret and then I don't. All right, so I was a first year undergrad, I was interning at Apple. And I was building this like tweak to the OS. It's a fork of it that made the phone easier to use in sunlight, which is a problem at the time. And I remember I was showing it to my mentor at lunch. And it just so happened that Steve was sitting right next to the table beside me. So I mentor Ken. Amazing guy, just starts like really spouting off on how good his prototype is. He's like super loud. He's like, "This is a game changer for the company. It's gonna differentiate us so much. It's gonna make us so much money." He's like super loud. And Steve hears and is

• 51:22Speaker 00

  like, "All right, let me check out this thing." He walks over, he sits right in front of me, and Ken's still going. And I'm like, "Ken, Ken, Ken, wait, come on. It's not that big a deal. It's like 50, 100 lines of code. It wasn't even that hard." Steve like sighs, you know, you could see his why did I sit down. He rolls his eyes, and Ken's trying to win him back, but Steve just like walks away, right? He doesn't say anything. And at this point, Ken explains to me that, just how badly I fucked up, right? Not only did you lose your chance to impress this industry icon, which is like would be a story for your life, but also it's very likely that this thing that you've been working

• 52:04Speaker 00

  on will now never see the light of day. Because my team does not have funding for it. This is just a thing you're trying out, Brian. So you've, by doing this, you've killed it. And, you know, the thing here is that I didn't know anything of a product, how to pitch it, and I was a really awkward 18, 19-year-old kid. So there's really very little chance that that was ever gonna go right. And even that night, when I got home, I didn't feel too bad. I was just like, "Oh, I now know I'm an awkward kid, and I should learn how to pitch better, I guess." Right? Yeah, that kind of thing, I don't regret because I couldn't

• 52:41Speaker 00

  have done better. What I do regret is the places where I like knew what I should do, where maybe I was just too uncomfortable communicating about it, or I was worried I'd do a bad job, so I didn't bother. Those are the kind of things I'm embarrassed about. And do you have a concrete example? I don't know if I have a concrete example that I can say without making people feel bad. But, but it's like, imagine you're making a decision, and, and you're halfway through it, you realize it's the wrong thing, and you just kind of go with it. If you're just two years in your career, that's a really easy thing to do. But you should be really

• 53:24Speaker 00

  honest, like, "Actually, guys, I was way off, and now our product's off track. We can keep going forwards, but everyone on this team deserves to know that I made a mistake in case we want to go and correct it." Even not knowing whether or not we would have corrected, I still look back on that. I'm like, that wasn't great. I should have been more honest.

• 53:42Ryan Peterman?

  So the regret is, I guess, not seeking towards the truth. Like, if you knew there was a problem in the middle of initiative to cut it, or at least share that, we might want to reconsider.

• 53:54Speaker 00

  Yeah, that's right. And I think you kind of, I feel like you owe, even if you think you can't convince people, you owe them a bit of the benefit of the doubt that they're going to be receptive, they're going to hear you out. And you kind of have to try. If they ignore you, it's fine. If you're wrong, it's also very fine. But you should try and you should get better at being able to communicate that kind of thing.

• 54:17Ryan Peterman?

  You mentioned Travis earlier. I'm curious, do you have any interesting stories working directly with Travis?

• 54:22Speaker 00

  Yeah, no, I mean, I've got a lot. But so, okay, here's what everybody knows about Travis Kalanick. Intense polyath. What people don't know is like intense dad energy, right? We had this offsite where it was the senior engineering leaders and Travis. It's over the weekend and we've got, you know, like work sessions. And between them, Travis is just like having a blast teaching people how to play backgammon. And he's also almost like a world-class water skier. So he's coaching people how to water ski. And he's super patient with us, even those of us that are like pretty unathletic. Which, let's be honest, we're engineers, so it's like most of us. He's pretty patient with like all of us that needed a lot of help.

• 55:07Ryan Peterman?

  It sounds like you went to Cloud Kitchens from Uber in large part because Travis Kalanick was founding it. And I'm curious about picking companies based on the founder. And so in your case, like, when you reflect on that, like, was that a good decision? Would you recommend that for others?

• 55:25Speaker 00

  Yeah, I think it can make a lot of sense for founder-led, early-stage companies. Because these companies, a lot of what matters is what is their current positioning? And what is their culture? And that's, and like, what are their standards?

• 55:42Speaker 00

  A lot of the two points there, they're just being set from the top at a company where you have somebody with that much control. And so if you've got a really good person, it can be just a huge multiplier for the effectiveness of the company relative to others. And it also can also go very much the other way if you don't have the right person in charge.

• 56:01Ryan Peterman?

  You mentioned receiving advice from other people, and I'm curious, is there a single advice that impacted your career most?

• 56:08Speaker 00

  Okay, this is gold. I've got something. I had this computer science teacher in high school, and I would ask them a lot of questions. And every time I asked a question, their answer would be like, Brian, figure it out for yourself. And like, I actually never, I'd never learned whether or not it was because this was a good pedagogy, or if they just didn't know the answer. It's possible they knew nothing about computer science, but it didn't really matter. It's very good advice, because 95% of everything that you learn professionally is going to be self-directed learning. So you've just got to get comfortable with that and accept that you always have to be

• 56:46Speaker 00

  learning and like pushing yourself to go kind of beyond your, the immediate area at which you're comfortable.

• 56:55Ryan Peterman?

  Was there a top book that impacted your career?

• 56:59Speaker 00

  No. So instead, I'll give you kind of a cheesy answer for books that I'd recommend. If you are like a front engineer, I'd recommend you read How to Pass the System Design Interview. And if you're like an ML or a backend, read something like How to Pass the PM Interview. What these books do is they're designed to help you cheese your way through an interview process, which is fine. But what's cool about them is that they are designed to give you a very broad and superficial understanding of a domain that you're not already very familiar with. And if you go and you do the exercises, you'll actually remember it.

• 57:39Speaker 00

  So it'll stick in your head, and then you will have a good ability to have productive conversations with people that are in other roles than you. And that's very valuable. It'll also give you some foundation to learn stuff in that domain.

• 57:52Ryan Peterman?

  If you could go back to yourself when you just entered the industry and give advice to yourself, what would you say?

• 58:00Speaker 00

  I'd probably say, younger self, be more courageous and less embarrassed. You're gonna fail a lot and it's fine.

• 58:10Ryan Peterman?

  That's easier said than done. Like, I feel like embarrassment is like, you just feel it.

• 58:16Speaker 00

  Yeah, I know. I mean, but this would be the opening two sentences before a larger conversation about how to search your own feelings and understand them. Maybe it would actually be, Brian, you should go to therapy. That might also be good advice. I think it's generally helpful to be more in touch with your own emotions for your own sake, and it helps you relate with other people better.

• 58:42Ryan Peterman?

  Cool. All right. Well, yeah, thank you so much for your time today. I really appreciate it, Brian.

• 58:46Speaker 00

  Yeah, it's fun, Ryan.

• 58:48Ryan Peterman?

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