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

21 Nov 2025 · 59 min · 24 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

Brian Attwell (CloudKitchens CTO) shares career lessons from Uber/Google, argues for “truth-seeking” in engineering ladders and incentives, and explains CloudKitchens’ stealth/privacy approach while pitching its robotics + logistics plan to cut restaurant/meal costs.

Guest backgrounds

Brian Attwell is a former senior staff engineer at Uber (reached senior staff in under four years after college). He’s now CTO at Travis Kalanick’s current company, CloudKitchens. He previously worked at Google.

Key claims

Extreme early work can compound into rapid growth, but warning signs include getting grumpy and needing days off; he cites a near-collapse episode from overwork. Hiring should test real trade-off reasoning (e.g., postmortem debates), not just IQ or rote practice. Promotions tied to “scope” cause empire-building; CloudKitchens/CK redesigned leveling around ~12 skill dimensions derived from ~1,000 high-performance examples, emphasizing truth-seeking over politics.

Notable examples

At Uber, he and Yi Wang prototyped competing approaches (Android/iOS) using postmortem-derived cases, becoming top committers and de facto tech leaders. At Google, he saw a “nice guy” not doing work and later learned he was moved to a demo-only team. CloudKitchens: robots cut restaurant labor ~50%, logistics reduce meal cost ~30–40%, software “Otter” processes ~18% of orders; privacy/stealth aims to avoid distraction and competitor spawning.

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

Career Journey at Uber

0:45 to 1:51

Brian discusses his rapid rise at Uber from graduation to senior staff engineer.

“and they didn't want their competitors to have them.”

Work Ethic and Pain Tolerance

1:51 to 3:15

Exploring the importance of a strong work ethic and the relationship between hard work and career growth.

“They're very meritocratic and they're growing.”

Reflections on Life and Work

3:15 to 4:13

Brian shares a poignant reflection on his near-death experience and career regrets.

“There's also levels that haven't been invented yet.”

Recognizing Burnout

4:13 to 6:22

Discussion on recognizing burnout and managing workload effectively.

“Like I went back when they found out they messed up my medication.”

Learning Through Experience

6:22 to 8:59

Brian recounts how he and a colleague learned and grew as engineers at Uber through hands-on experience.

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

Luck vs. Effort in Career Growth

8:59 to 11:11

A discussion on the balance of luck and hard work in achieving career success.

“A few months later, we're now the guys who commit the most code on the team.”

Interviewing for Quality Talent

11:11 to 13:24

Brian shares insights on how to assess and interview for quality engineering talent.

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

The Role of IQ in Job Performance

14:00 to 18:07

Learn how IQ correlates with job performance and the challenges in hiring processes.

“But like, that is sure as hell filtering out people who are, you know, below the median before they get in.”

Challenges of Interviewing Product Managers

18:08 to 21:55

Discover the complexities in interviewing PMs and the need for structured processes.

“It matters more, you know, how hard you work or your ability to choose impactful work and work in a team, etc.”

Expected Value in Decision Making

21:56 to 25:29

Understand how to calculate expected value for better prioritization in work.

“And there's a column that says, here's the expected value.”
Show all 24 chapters

Transitioning into Management

25:30 to 28:00

Explore the journey and challenges of transitioning from individual contributor to manager.

“We believe it so strongly, but I think it might be wrong.”

Merit-Based Culture and Managerial Challenges

28:00 to 30:02

Explore the complexities of merit-based cultures and the impact on employee roles.

“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 scopes maybe need to be reduced.”

Redesigning Incentive Structures

30:02 to 32:36

Learn about creating effective incentive structures that promote core job performance.

“And you're also encouraging a lot of empire building.”

Truth-Seeking in Engineering

32:36 to 34:25

Discover how to emphasize truth-seeking over traditional performance metrics in tech.

“Otherwise, you could get into a situation where the skill gradient is bullshit at the high levels, right?”

Managing Bias in Performance Evaluations

34:25 to 36:55

Understand the challenges of bias in manager evaluations and how to mitigate them.

“So like, how do you get rid of that incentivizing politics?”

Reward Systems in Tech Companies

36:55 to 39:33

Examine why some tech companies fail to reward high performers and the consequences.

“Or is it different than what every other company does?”

Performance Issues at Google

39:33 to 42:01

Insights into management practices at Google and how they affect team performance.

“Like they think, oh, the equity went up by a lot.”

The Challenge of Maintaining Standards in Companies

42:01 to 43:29

Learn about the dynamics of corporate performance and how standards can decline over time.

“But generally at large companies, the performance of the company is fairly decoupled from the performance of individual teams.”

The Future of Cooking: Insights from a Stealth Startup

43:30 to 46:33

Discover innovative ideas about the future of food preparation and the efficiency of the food supply chain.

“No, because there's a lot of smart people in the world.”

The Importance of Privacy and Competition in Startup Culture

46:34 to 49:16

Explore why some startups maintain strict privacy and how it impacts competition.

“It said, you know, we're a large stealth startup.”

Reflections on Career Regrets and Communication

49:17 to 53:46

Gain insights into learning from career mistakes and the importance of honest communication.

“I see a lot of other companies, they get started and they start with distribution actually.”

Lessons from Early Career Experiences

53:47 to 56:00

Learn about the value of self-directed learning and the importance of continuous education.

“or at least share that we might want to reconsider.”

Advice That Shaped a Career

56:00 to 58:07

Learn about the importance of self-directed learning and courage in professional growth.

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

Reflecting on Personal Growth

58:07 to 58:45

Explore the significance of emotional awareness and the value of therapy.

“You're going to fail a lot and it's fine.”
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:00One time I was on my deathbed, the doctor told me that I was gonna die tomorrow. 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. 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. You grinded an obscene amount to get to where you are today. 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:34He also dropped brutally honest takes about how big tech actually works. 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. He had a run-in with Steve Jobs that didn't go how he hoped. Like, I really made Steve Jobs think I was an idiot. And he also opened up about what it's like working directly with Travis Kalanick. 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:08Brian Attwell:Why is this company so strict on privacy? 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. This was just The Surface. Here's the full episode.

1:26Brian Attwell: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? 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, right? There's good people to learn from. They're very meritocratic and they're growing. So there's lots of problems, right? 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:09And the other thing is that 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 sport. 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:54And 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 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.

3:29Like when I joined Uber, I was I was very aware that I had more time than I'd ever have in my future. And that if I was going to invest in growing this would be the easiest time to do it.

3:41Brian Attwell: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? 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 and in the deathbed. It's not true.

4:14Right. 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. And it was painful. But you look back on your head and you're like, that was great.

4:36Brian Attwell:So when you were on your deathbed, you weren't saying, oh, I have regrets that I didn't travel more or do that. Your regret was, I wish I worked harder. Yeah, it actually was. Yeah. Yeah. I was like, shit, I'm going to 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. So everyone has a breaking point. Obviously, you can't work, you know, 168 hours a week. Where is that breaking point for you? And like, how do you know when you're working too much?

5:19I 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. 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 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 for 15 minutes I just watched people walk by me in that moment I knew I should have cut back by 5 % I knew it

6:15Brian Attwell:but ideally I would have known that a little sooner Did you go to the doctor after that? What was that? 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 like professional athletes are really intense. They're training all the time, but they are conscious about taking time off to let themselves, their body, their mind regenerate. Are there any concrete stories you can tell me that kind of illustrate like how you grew as an engineer?

6:51There'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 RxJava streams emitted 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 overhear people use their experience to prune out the worst options, right?

7:33That was like fairly easy. And then picking the best option was a bit more subjective. Like 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 you and I, they leave the office at 7 p.m. You and I work from 9 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 ARX Java approach. I found eight representative examples that I'd seen in past issues that I just read in postmortems, and I built compiling examples for them.

8:10Then I did the same thing for option B. I did the same thing for option C. And while I'm doing this, you did it on iOS. I did it on Android, we reviewed each other's stuff. 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, right? It's like super not good. Uber would not have paid us to spend this time because we're hunging around. We're trying to find some kind of unexpected, hidden, invaluable truth.

8:50And 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, right? A few months later, we're now the guys who commit the most code on the team. 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 Ian Atwell. Okay. So this is like a few months and it's joining this team. We're now the de facto tech leaders of it. And we just keep outworking everybody basically around us. A few quarters go by. And now we're like top three committers across the mobile organization at Uber.

9:28And 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 people listening to this may think this is extreme. 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:05Brian Attwell: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? Yeah, so luck matters a lot in the things that happen infrequently, right? 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. So once I was there, you know, there's a lot of things that I'm doing myself.

10:44But 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:56Brian Attwell:So you're saying you increased your chances of luck by shooting so many shots? Yeah, well, I guess I'm saying that once you're in the company, I think like I was going to 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 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:37Brian Attwell:You mentioned you were choosy in picking Uber. What did you see at the time that made you pick Uber? Like what signals are you looking for? 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 very 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.

12:14Like, 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 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.

12:52And 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 is really dedicated to it.

13:13Brian Attwell:Like 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. So then what is it that you would ask that would actually test for IQ or something like that? Yeah, you know, it's funny. Some places will literally do an IQ test up front, 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.

13:53And the requirements are a little bit in conflict and a little bit hard to reason about. That kind of thing is really great. 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 with it three pages down is the kind of thing that most people and also chat gbt cannot get anywhere close to doing interesting so it sounds like you're saying

14:23Brian Attwell:that if someone's iq is higher their job performance will be higher uh yeah i mean this is like one of the most well-researched uh 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, you know, below the median before they get in. So then how do you filter among the people that are already like one to two standard deviations above?

15:02There's a bit of like, how do you design problems that are, they're not just mentally straining, they're 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. Maybe we'll figure it out, Ryan. But I can tell you that I am no company yet in the world has it.

15:35Brian Attwell:Well, it's interesting that you say IQ correlates with on-the-job performance. 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 part of why leak code is a thing, right? Like leak 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 at like tricky abstract reasoning. But the problem is it's so gainable that you can just practice leak code. IQ test, you can't practice it. I don't know, maybe just slap it in front. I'm going to try it.

16:07I'll probably try it for PMs first because they're harder to interview generally. And also, the pass rate for my interview bar that I've defined for PMs is super low. And I'm just annoyed that I have to keep interviewing them. So maybe I'm going to slap an IQ test in there and save some time.

16:23Brian Attwell:Why is interviewing PMs harder than interviewing software engineers? 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 is younger. So there just hasn'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.

17:03We 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. 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.

17:19Brian Attwell:I think it could be way better. With what? Like slapping IQ tests? Well, actually, I mean, it probably wouldn't hurt. Yeah, if you slapped an IQ test in front of the PM interview 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 the rest of your process. And when I talk to places that do do IQ tests, because it's not that uncommon at places that have very high standards to do something like this, it is always in the screen stage. It's always just the let's filter people out to save them time and us time.

17:52Brian Attwell:Oh, you're saying some other companies do run IQ tests? Yeah, they do. I don't think there's that many, though. I think this is a little, this is certainly a move. I always hear the common take is that it really doesn't matter how smart you are past a certain point. It matters more, you know, how hard you work or your ability to choose impactful work and work in a team, etc. What would you say to that? 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.

18:34Like 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 A 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. What's kind of interesting about this mindset is that often, you'll often get into situations where working on the most important thing is not actually the most valuable thing you can do with your time.

19:19Because 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:45Brian Attwell:It's interesting that you say that because, you know, when I think about prioritization, obviously it's a cost-benefit analysis, you know, 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? 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 stretched out 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 yeah i'm kind of curious about that expected value calculation as well.

20:52Brian Attwell:Like how do you recommend developing that? What's important to figure out and determining the benefit? 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'd 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.

21:33And 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 those principles behind that. And you can ask these guys. Like you probably should use regular time on your 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 the top initiatives or all the projects of the quarter. And there's a column that says, here's the expected value. Or it says, like, here's why we care as a company. If that column exists, it is gold.

22:08And 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:19Brian Attwell:Talking about management, I'm curious, what's the story behind you eventually getting into management? 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 treated me like their boss.

Read the full transcript

23:05They asked me what they should work on, and I came up with stuff. 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 didn't need a manager. They didn't really have one. And I thought that when my boss said this, that he was right. They deserved somebody, but I didn't like the idea of somebody coming off the street, like of a random people 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.

23:53So I was like, all right, I'll do it, I guess. And I did a terrible job. right like I uh yeah I mean I 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 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 Sure. It was 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.

24:43I 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:52Brian Attwell:Yeah, that's kind of insane for the part of the company that reports to you to double every six months. Why did your team grow so insanely? 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 and 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.

25:32We 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. so a few years ago there was an integrations team that's moved under me this team they built 1200 different integrations 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 at each one of the integrations was originally a very smart bet Analysis was done to decide whether it was needed and it was built. So now there's a lot of inertia around maintaining it.

26:14And the team works super hard to maintain them and keep the data quality good. Kenji, who manages the team, to me says, Ryan, 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 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 was really hard for anyone to say, no, you've got to keep them all open. It's just obvious that some are much less valuable.

26:52So 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. and what ended up happening is that the quality of our product and aggregate got better because now the integrations that matter are well supported and we've got time to build new

27:12Brian Attwell:things it's just a win-win-win 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 that's right yeah i don't ever say And often, folks, often there's a lot of hints. You kind of want to start with what are the things that people just have suspicions around that can be good. That'll get you a few quick wins and then you'll have to dig a bit deeper. You mentioned a lot of teams got moved under you. How does that conversation usually go? Yeah, I mean, the conversation is always really different, but it's got to be done with empathy.

28:00It'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 scopes 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 still doing well or for what they used to be doing well.

28:30Brian Attwell: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 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, in those cases, why did people give up their scope or is there not an incentive structure like that at that company? Yeah, I mean, 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.

29:14Actually, I think Travis deserves some credit because we originally had a leveling system and an incentive structure for obvious reasons very similar to Uber. 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 each clause can be better. 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 can do so much better. It's worth your time to do better.

29:52at this point um i'm so i'm convinced that it could be a lot better and i'm also convinced that a lot of companies do a bad job um i we ended up spending a ton of time figuring out more about where other companies were failing um i think i spent basically every evening and saturday for months on this um yeah 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:28Brian Attwell: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? 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, I design processes for the company as a whole. I design, I partner with directors on strategy. I influence other teams on undefined goals. 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.

31:20Some of that's valuable, but if everybody does it, people don't actually learn to be good at the core part of their job and it's bad for the company. So what we did instead is we started with these 1 ,000 different examples 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:01Brian Attwell:Where'd you source the initial thousand examples of high performance from? 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?

32:42It's like just an unachievable dream.

32:45Brian Attwell: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? Yeah, I think the probably main difference is this emphasize on truth-seeking and 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 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.

33:30And 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, instead of just saying it's about like a social, kind of social proofing.

33:48Brian Attwell:I see. But then how do you determine if it's good communication or not? You give a lot of examples, right? In your document where you define these things, you say, okay, 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? I'm not sure how it fixes the politics, social problem of calibrating engineers, because you could have a manager that lists out those examples, but says them in a biased way.

34:29Brian Attwell:So like, how do you get rid of that incentivizing politics? Okay. Yeah. So this is still a thing that managers could try to do. It's a little bit, 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.

35:14There'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 spot-check managers, and if you find them exaggerating, you have to fire them. Easier said than done.

35:30Brian Attwell:I'm curious, like how is it? Well, I mean, I don't know who wants a liar on their team. 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? 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.

36:07The people on the team who are working hard, they're like, yeah, man, Joe is so great. But why the fuck did he just go home at 2 p.m.? Like, why am I working at 6 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:25Brian Attwell:You've mentioned truth-seeking a lot in this new ladder, and I'm kind of curious, how do you prove truth-seeking? How do you give examples of someone that did that well? Yeah, I mean, a lot of it is, have you uncovered something that is highly unconventional?

36:50And 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 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 onto. too.

37:22And then there is a bit of subjectivity. You know, there's not like you could 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:36Brian Attwell:Yeah. Yeah. Well, a lot of companies have some sort of measure of like 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. Yeah, I mean, it's not like these are the way that tech companies have designed their their leveling frameworks, their incentive structures are not completely broken. And in many ways, they're just way better than what exists in the like Dilbert-esque era of the 1980s. there's some ways 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 a little easier for some other people yeah one thing I'm curious about because like a lot of tech companies they incentivize the results not necessarily the thing that happens before the result.

38:39Brian Attwell: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? Oh, yeah, of course. Yeah. Oh, okay. 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 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 measure that you've been doing phenomenal work and we're worthy for that. It's kind of on our fault as leaders that it got canceled so late.

39:13Brian Attwell: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 is like, why Why do these companies not reward their highest performers? 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.

39:48You 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. I just think if you design your company processes around being just, it's going to be better for you in the long run. But you kind of just got to believe that.

40:05Brian Attwell: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 was that like or what did you get from starting at Google? 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. 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? That's not how I talked, but you get the point. And my boss says, yeah, I know, but he's such a nice guy, Brian.

40:47So 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. 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. The team was just like, they're building demos for the gift shop or something like that.

41:23Brian Attwell:So what you got from that is that, like, that's a Google problem and that he should have been fired. Yeah, absolutely. Or, yeah, he should have been fired or there should have been a serious conversation, right? I mean, 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? Right? You can't expect us to keep paying you if you don't. And then he might have gotten back into it. Why do you think that that hard conversation wasn't had at Google? I mean, so there is something Google-specific that exists there, which I can get back to.

42:01But 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 to 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:38It'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 is like, Alphabet's like, oh, there's an existential threat to our existence. The DeepMind team better work hard now. I mean, entrepreneurs 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:24So 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:29Brian Attwell:I see. And do you think there's any merit in that kind of hiring strategy? No, because there's a lot of smart people in the world. I think it's fairly difficult to have a monopoly on intelligence. 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. Yeah. Okay. 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.

44:01The 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. Of course they don't. They choose to save 10 hours of their time a week and take it back.

44:28And if you look at the U.S., 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 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 robots that reduce labor costs in real restaurants by 50%. We've built this lunch logistics network that reduces the cost of a meal overall 30%, 40%. We have, what else?

45:17We'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. It makes it a bit more efficient. And we've got all these things going. Some of them are early. Some of them are 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 &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. 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.

46:00So 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. Eventually, robots are going to do all the things. 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:32Brian Attwell: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 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? Yeah, right. So, I mean, we are super strict. You're right. And we don't have a corporate website.

47:10We ask employees not to post that they work here on LinkedIn. We were doing a fairly good compliance round. 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 of this great stuff. And our CEO built 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. if you look at 2018 and you look at like headlines, sentiment, you can actually go and check this.

47:55I've checked it. It took this nosedive towards negativity after Cambridge Analytica happened. The U.S. populists 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-froplace. 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, other people will see that who are enterprising and go, maybe I'll just do that.

48:34When we launched in Korea, we were very public about it. We talked to reporters. There wasn't just one competitor or two. There was 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 U.S. 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 build great stuff and don't talk about it and then win silently and confidently.

49:16Brian Attwell:I mean, this to me is like the very opposite. I see a lot of other companies, they get started and they start with distribution actually. Like they have these rage bait products that go out and explode on Twitter. And then 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. um so like how are you handling distribution then if you're so quiet i mean a lot of the stuff that we do is b2b um 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 adds a bit of difficulty around is hiring.

50:12So people like me have to go on famous podcasts and see if they can mitigate that a bit. Right. But I think it's not as hard for sales as you'd expect.

50:24Brian Attwell: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? 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. So I was a first year undergrad. I was entering an Apple and I was building this like tweak to the US, 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.

51:05So I mentor Ken, amazing guy, just starts like really spouting off on how good his prototype is. He's like super loud.

51:13Brian Attwell:He's like, this is a game changer for the company. It's going to differentiate us so much. It's going to make us so much money. He's like super loud. And Steve hears, he's 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?

51:54Not 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 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 going to go right. And even that night when I got home, I didn't feel too bad.

52:30I 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 have done better. what I do regret is the places where I like knew what I should do um 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 it's like, imagine you're making a decision and you're halfway through it.

53:17You realize it's the wrong thing and you just kind of go with it. Maybe you're just two years in your career. That's a really easy thing to do. But you should be really honest. Like, actually, 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:42Brian Attwell: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. 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:17Brian Attwell:You mentioned Travis earlier. I'm curious. Do you have any interesting stories working directly with Travis? Yeah, I don't know. I mean, I've got a lot. But so, okay, here's what everybody knows about Travis Kalanick. Intense Pallion. What people don't know is like intense dad energy, right? we had this off-site where it was the senior engineering leaders and Travis. It's over the weekend and we've got work sessions. Between them, Travis is just having a blast teaching people how to play backgammon. He's also almost a world-class water skier. He's coaching people how to water ski. He's super patient with us, even those of us that are pretty unathletic.

54:59Let's be honest, we're engineers, so it's like most of us. He's pretty patient with all of us that needed a lot of help.

55:06Brian Attwell: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, when you reflect on that, was that a good decision? Would you recommend that for others? 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 what are their standards. And 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.

55:48And 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:01Brian Attwell:You mentioned receiving advice from other people and I'm curious, is there a single advice that impacted your career most? 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 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 just got to get comfortable with that and accept that you always have to be learning and like pushing yourself to to go kind of beyond your, the immediate area at which you're comfortable.

56:55Was there a top book that impacted your career?

57:01No. 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 MLE or a back end, 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:39So 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:53Brian Attwell:If you could go back to yourself when you just entered the industry and give advice to yourself, what would you say? I'd probably say younger self. Be more courageous and less embarrassed. You're going to fail a lot and it's fine. That's easier said than done. I feel like embarrassment is like you just feel it. Yeah, I know. I mean, this would be the opening two sentences before a larger conversation about how to assert 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:42Brian Attwell:Cool. All right. Well, yeah. Thank you so much for your time today. I really appreciate it, Brian. Yeah, it's fun, Ryan. 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.

From the publisher

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

More from The Peterman Pod

All 60 episodes
CloudKitchens CTO on Intelligence, Regrets, Steve Jobs and Travis Kalanick StoriesThe Peterman Pod · 59 min
Listen in VO